[Dovecot] Two strange behaviours with dovecot+postfix+squirrelmail
Hi all,
About a week ago I was forced to migrate my main (production) email server from RH9 to Centos4.1. The installation has dovecot-0.99.11 + postfix-2.1.5 and >600 mbox accessed email accounts.
Number 1. Some users accessing thru squirremail (installed in my webserver) can read their INBOX at /var/spool/mail directory but when trying to delete a message they receive the following error message from squirrelmail:
ERROR: Could not complete request. Consulta: COPY 1279 "mail/Trash" Reason Given: Internal error occured. Error report written to server log. [2005-09-16 15:08:04]
and the error logged is the following: Sep 16 15:09:27 mail imap(username): mkdir_parents(/home/username//mail/.imap/Trash) failed: Permission denied
I never stated that .imap/Trash when configuring dovecot and the strangest thing is that my account, as most of others, can delete messages moving from /var/spool/mail/my_name to /home/my_name/mail/Trash
Number 2. Randomly, some users connecting from Mozilla Thunderbird via IMAP get an error message telling that there has been an error connecting to INBOX. Watching the maillog I found the following:
Sep 16 13:07:43 mail imap(otheruser): File isn't in mbox format: /var/spool/mail/otheruser
I accessed the user's inbox file with vi and found that there was a "--604" at the beginning of the file. In other case I found that the file was beginning with a truncated email message.
Trying to "walk on the safer side", I changed the mbox_lock setting from "fcntl" to "dotlock" in the /etc/dovecot.conf file.
Any suggestions and comments about his will be highly appreciated. Forgive me about my English, it is not my native lanaguage.
Regards,
-- Francisco Neira B. Administrador de Red Defensoria del Pueblo Lima, Peru, -05:00 UTC
Francisco Neira wrote:
Hi all,
About a week ago I was forced to migrate my main (production) email server from RH9 to Centos4.1. The installation has dovecot-0.99.11 + postfix-2.1.5 and >600 mbox accessed email accounts.
It sometimes surprises me how far behind some distributions are with their versions. In the case of 0.99, it is highly advisable to upgrade to 0.99.14, if it's available.
Number 1. Some users accessing thru squirremail (installed in my webserver) can read their INBOX at /var/spool/mail directory but when trying to delete a message they receive the following error message from squirrelmail:
ERROR: Could not complete request. Consulta: COPY 1279 "mail/Trash" Reason Given: Internal error occured. Error report written to server log. [2005-09-16 15:08:04]
and the error logged is the following: Sep 16 15:09:27 mail imap(username): mkdir_parents(/home/username//mail/.imap/Trash) failed: Permission denied
Sounds like you have your default_mail_env set to something like: mbox:~/mail/.imap:INBOX=/var/spool/mail/%u Is this correct?
I never stated that .imap/Trash when configuring dovecot and the strangest thing is that my account, as most of others, can delete messages moving from /var/spool/mail/my_name to /home/my_name/mail/Trash
Well, there's moving, marking for deletion, and expunging. Moving something to Trash is just that - moving. Marking for deletion just sets a flag that the mail is to be deleted, and expunging actually deletes all the messages in a folder marked for deletion.
It looks to me like your mail is being delivered fine, but your user's home directories have permission problems.
Are they able to access other mail folders ok?
Number 2. Randomly, some users connecting from Mozilla Thunderbird via IMAP get an error message telling that there has been an error connecting to INBOX. Watching the maillog I found the following:
Sep 16 13:07:43 mail imap(otheruser): File isn't in mbox format: /var/spool/mail/otheruser
I accessed the user's inbox file with vi and found that there was a "--604" at the beginning of the file. In other case I found that the file was beginning with a truncated email message.
Trying to "walk on the safer side", I changed the mbox_lock setting from "fcntl" to "dotlock" in the /etc/dovecot.conf file.
Most would agree that locking is the first place to look. My advice is that you check which locking scheme the LDA is using, and use exactly that. Since most locks are only advisory, if you're not using the same scheme, your locks won't work.
Any suggestions and comments about his will be highly appreciated. Forgive me about my English, it is not my native lanaguage.
Honestly, I hadn't realised you weren't a native English speaker until you pointed it out.
-- Curtis Maloney cmaloney@cardgate.net
participants (2)
-
Curtis Maloney
-
Francisco Neira