dovecot - Sep 2005 - 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 at cardgate.net