Hi, we use a current Debian etch distribution as basis for our servers, which are running within a vmware server environment. Our current configuration consists of a dovecot server with imap enabled and a ldap based authentication. Mails are stored using the Maildir format on a central nfs store. We do not use any virtual mailboxes.
Since upgrading from dovecot version 1.0.rc15 (debian stable) to 1.0.13 (debian etch-backport) we got the following error logs.
Excerpt from mail.err: Apr 21 12:04:38 servera deliver(usera): /var/mail/Maildir/usera/dovecot-uidlist: Broken header (uidvalidity = 0, next_uid=9) Apr 21 15:37:50 servera deliver(userb): /var/mail/Maildir/userb/dovecot-uidlist: Broken header (uidvalidity = 0, next_uid=16) Apr 23 10:37:17 servera dovecot: IMAP(userc): /var/mail/Maildir/userc/.Sent/dovecot-uidlist: Broken header (uidvalidity = 0, next_uid=2) Apr 25 17:00:17 servera dovecot: IMAP(userd): /var/mail/Maildir/userd/dovecot-uidlist: Broken header (uidvalidity = 0, next_uid=8)
I did already some mailinglist reviews. They confirmed in some way the problem, but there is still no explanation where it comes from, and how it can be solved or if it may affect the proper operation of the system.
Here are some links with a short comment, which are related to this problem: http://www.dovecot.org/list/dovecot/2007-September/025541.html This post also uses nfs, but pam for authentication, error message is exactly the same as in our case.
http://www.dovecot.org/list/dovecot/2007-July/024001.html Version upgrade from 1.0.0 to one above, also problems with uidvalidity. They described, that it happens only once for each user after upgrading. This is similar to our observations. No user complains as well ;). So it would be only of interest if it is so.
http://wiki.dovecot.org/Clients/NegativeUIDs The number for uidvalidity is zero, so it is non-negative. But maybe it is correlated with these hints.
From my point of view, there could be some problems with time synchronization as well between nfs server and dovecot server machine. But we checked this and they differ never more than 2 seconds.
In total we are running two servers in parallel, each has it's own userspace, all accounts are strictly separated. One server is running the rc15 version, the other (more experimental) is running the backport 1.0.13. The described problem occurs only on the 1.0.13 server, which was previously updated. All other configurations are exaclty the same.
Any hints?
Best regards, Robert
-- Dipl.-Inform. Robert Henjes University of Wuerzburg, Institute of Computer Science, Department of Distributed Systems (Informatik III), Am Hubland, 97074 Wuerzburg, Germany
henjes@informatik.uni-wuerzburg.de Tel: +49 931 888-6652 Fax: +49 931 888-6632