Dovecot version upgraded to 1.0r26 (did not fix problem).
The server is a CentOS 4 x86 box.
Using ext3 filesystem.
Previous attempts to fix the issue have included simply moving aside
the user's INBOX to recreating a new account from scratch. Sometimes
the email behaves for a while, but within a day is not working
again. In Mail.app (the user's usual mail client) the INBOX folder
simply appears empty. mutt (run locally on the server) shows the
messages there correctly.
The problem is easily reproducible. Move /var/spool/mail/[username]
to a backup file and remove all .imap directories for that user.
Mail may work for a while, but will stop within 24 hours. The
SquirrelMail message is: ERROR:
The server couldn't find the message you requested.
Most probably your message list was out of date and the message has
been moved away or deleted (perhaps by another program accessing the
same mailbox).
Click here to return to INBOX
dovecot -n :
# /etc/dovecot.conf
log_path: /var/log/dovecot.log
info_log_path: /var/log/dovecot.debug.log
login_dir: /var/run/dovecot/login
login_executable(default): /usr/libexec/dovecot/imap-login
login_executable(imap): /usr/libexec/dovecot/imap-login
login_executable(pop3): /usr/libexec/dovecot/pop3-login
mail_location: mbox:~/mail:INBOX=/var/spool/mail/%u
mail_full_filesystem_access: yes
mail_executable(default): /usr/libexec/dovecot/rawlog /usr/libexec/
dovecot/imap
mail_executable(imap): /usr/libexec/dovecot/rawlog /usr/libexec/
dovecot/imap
mail_executable(pop3): /usr/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/imap
mail_plugin_dir(imap): /usr/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/pop3
auth default:
mechanisms: plain login
passdb:
driver: pam
args: dovecot
userdb:
driver: passwd
Thanks!
Alex
???
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20070314-124124-6561.in
Type: application/octet-stream
Size: 84 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070314/1fef8158/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20070314-124124-6561.out
Type: application/octet-stream
Size: 433 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070314/1fef8158/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anon-INBOX
Type: application/octet-stream
Size: 137602 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070314/1fef8158/attachment-0008.obj>
On Wed, 2007-03-14 at 13:26 -0700, Alex Boster wrote: X-IMAPbase: 1173814340 4280058374 $NotJunk JunkRecorded X-UID: 4280058361 This is your problem. Your UID has gotten higher than 2^31 which confuses many clients, even though it's still valid from IMAP protocol's point of view. As for why it has gotten this high.. Well, recent Dovecot RCs could break them sometimes, but at least with 1.0.rc27 everything should be working. If you remove the X-IMAPbase, X-IMAP and X-UID headers and delete Dovecot's index files the messages will be given new UIDs beginning from 1. If this just keeps happening, then I think it's because the incoming mails contains invalid X-UID headers. Normally those shouldn't break anything as long as you haven't deleted Dovecot's index files or the mbox file isn't empty. If they do and you can figure out how to reproduce it, please let me know. Anyway, the problems would most likely go away if you just filter out all the X-UID headers from incoming mails. See the bottom of http://wiki.dovecot.org/MboxProblems