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: [EMAIL PROTECTED]
-==- -=- -==-
