Jul 21 14:27:41 betty dovecot: IMAP(foobar): Maildir /var/vpopmail/domains/foobar.baz/foobar/Maildir sync: UID inserted in the middle of mailbox (4412 > 4385, file = 1214817167.16333_0.betty:2,RST)
Show your dovecot -n output?
Sorry, should have included that right away.
betty - ~ # dovecot -n # 1.0.14: /etc/dovecot/dovecot.conf log_timestamp: %Y-%m-%d %H:%M:%S listen: *:9000 disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login login_greeting_capability: yes login_max_processes_count: 256 first_valid_uid: 89 mail_location: maildir:~/Maildir dotlock_use_excl: yes maildir_copy_with_hardlinks: yes maildir_copy_preserve_filename: yes mail_process_size: 512 mail_plugins: quota imap_quota trash lazy_expunge imap_client_workarounds: outlook-idle delay-newmail namespace: type: private inbox: yes namespace: type: private separator: / prefix: .Trash/ location: maildir:~/Maildir/.Trash hidden: yes namespace: type: private separator: / prefix: .Trash/ location: maildir:~/Maildir/.Trash hidden: yes namespace: type: private separator: / prefix: .Trash/ location: maildir:~/Maildir/.Trash hidden: yes auth default: user: vpopmail verbose: yes passdb: driver: checkpassword args: /data/vpopmail/bin/vchkpw userdb: driver: prefetch plugin: quota: maildir trash: /etc/dovecot/dovecot-trash.conf lazy_expunge: .Trash/ .Trash/ .Trash/
I suppose the users don't have direct access to these maildirs, and nothing else besides Dovecot and procmail touches them?
No, this is qmail with Vpopmail, so all mail is owned by the vpopmail user. Default MDA is qmail-local, but where procmail filters are enabled, it takes over all local delivery, and never hands it back to qmail-local. I haven't actively looked for a pattern yet, but from the top of my head, all users I can think of experiencing this problem use procmail for delivery.
This error means that Dovecot lost that file and thought it was expunged. But sometimes afterwards it saw the file again.
Hm. What is the normal scenario where something like this might happen, if there is such a thing?
Any help would be greatly appreciated, as none of my testing thus far have made any difference, and I can't seem to find any hints elsewhere. Could upgrading to 1.1 help at all? (I'd rather not try unless I know for sure)
v1.1 might not remove the root problem, but it will handle this better by renaming the file and showing it to client as a new message instead of returning "inconsistent state" error.
That does sound more graceful. Squirrelmail shows an error for every dropped connection, so the end result is that users are seeing a whole bunch of error messages, without actually experiencing any problems (from what I've heard). I'd prefer to cure the problem, but if I can't, curing the symptom might be adequate.
-- -==- -=- -==- Christer Mjellem Strand yitzhaq System administrator ICQ: 9557698 GSM +47 922 000 12 JID: yitzhaq@jabber.no -==- -=- -==-