Hi,
I’m a new Dovecot user and using version 2.2.18 on an OpenSuse system. In general it all works quite nicely and clients can connect to Dovecot and manage mails normally. The layout used is maildir. The users are all virtual, i.e. they do not exist on the Linux system. They all log in without any authentication due to a very specialized and internal setup.
However, sometimes Dovecot simply deletes mails from the maildir structure. It also seems to delete entire users too. This is not a simple case of clients deleting mails, but the entire folder for the user seems to sometimes get nuked. I’ve also seen that only the mails and Dovecot’s admin files (indexes etc) are deleted.
The log file is not really too informative, mostly lines of this form:
Jul 01 14:00:36 imap(firstname.lastname@domain.x): Info: Disconnected: IMAP session state is inconsistent, please relogin. in=781 out=2630 Jul 01 14:00:36 imap(operators-east@east.domain.x): Debug: Namespace : /opt/mail/operators-east doesn't exist yet, using default permissions Jul 01 14:00:36 imap(operators-east@east.domain.x): Debug: Namespace : /opt/mail/operators-east doesn't exist yet, using default permissions Jul 01 14:00:36 imap(operators-east@east.domain.x): Debug: Namespace : Using permissions from /opt/mail/operators-east: mode=0700 gid=default Jul 01 14:00:36 imap(firstname.lastname@domain.x): Debug: Namespace : /opt/mail/firstname.lastname doesn't exist yet, using default permissions Jul 01 14:00:36 imap(firstname.lastname@domain.x): Debug: Namespace : /opt/mail/firstname.lastname doesn't exist yet, using default permissions Jul 01 14:00:36 imap(firstname.lastname@domain.x): Debug: Namespace : Using permissions from /opt/mail/firstname.lastname: mode=0700 gid=default Jul 01 14:01:03 imap-login: Info: Login: user=firstname.lastname@domain.x, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=9326, secured, session=<2+YiPc4ZGwB/AAAB> Jul 01 14:01:03 imap(firstname.lastname@domain.x): Debug: Effective uid=1001, gid=100, home=/opt/mail/firstname.lastname Jul 01 14:01:03 imap(firstname.lastname@domain.x): Debug: maildir++: root=/opt/mail/firstname.lastname, index=, indexpvt=, control=, inbox=/opt/mail/firstname.lastname, alt= Jul 01 14:01:07 imap-login: Info: Login: user=operators-east@east.domain.x, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=9333, secured, session=<11NpPc4ZHAB/AAAB> Jul 01 14:01:07 imap(operators-east@east.domain.x): Debug: Effective uid=1001, gid=100, home=/opt/mail/operators-east Jul 01 14:01:07 imap(operators-east@east.domain.x): Debug: maildir++: root=/opt/mail/operators-east, index=, indexpvt=, control=, inbox=/opt/mail/operators-east, alt=
I’ve changed the name and domain. Not sure if the namespace complaints have anything to do with the directories on disk, but normally they are there when the logging comes.
Below is the used config file. I can’t see anything that would trigger deletions and there is no logging or similar about it. To me it’s quite serious that an IMAP server randomly deletes mails and its own files.
########################################################################################### # support only IMAP, no pop3 protocols = imap
# listen only on IPv4 (the default is: "* ::") listen = *
# where logging gets sent log_path = /var/log/dovecot.log
# disable SSL ssl = no disable_plaintext_auth = no
# we're using maildir without any extra folders in the user's home directory (set in userdb) mail_location = maildir:~
# user ids default_login_user = dovenull default_internal_user = dovecot
# auth config auth_verbose = yes auth_mechanisms = plain
# password scheme. Uses an external Python application to verify the password. It gets # sent the username and password and can perform authentication. The current one # simply accepts anything. passdb { driver = checkpassword args = /opt/dovecot-2.2.18/bin/checkpassword.py }
# user database userdb { driver = static args = uid=navie gid=users home=/opt/mail/maildir/%n } ###########################################################################################
Anything obviously wrong? I’ve seen that mail_location and mail_home should not be the same, but using
mail_location = maildir:~/mail
gives the exact same behavior.
Best regards, Jan Ekholm