I experienced this today with my own IMAP folder, so maybe being able to
offer a more specific order of events will help. Also not sure if I
previously mentioned that this is occasionally happening with IMAP
folders even though it's much more common under POP3.
1) I had just cleaned out my Junk folder.
2) Two messages were received without error.
3) I marked the folder as read in Thunderbird.
4) I restarted Thunderbird
5) The next delivery attempt to that mailbox (using dovecot deliver)
failed:
save failed to Junk: Mailbox isn't a valid mbox file
The odd thing is that the delivery *did* succeed because that message is
in there. The very first message header is the one that was corrupted
which always seems to be the case. Does "deliver" read/write the entire
mbox file or just append the new message to the end?
On 06/08/10 11:24, Erik Kratzenberg wrote:
We've had situations where the same user will have their mailbox
corrupted 2 or 3 times a day.
We're not using filesystem quotas and nothing but Dovecot is writing to
these mailboxes.
We've been pushing people to switch to IMAP which seems to be the only
solution so far. That's decreased the number of reports we're getting,
but they're definitely still coming in.
On 05/25/10 15:10, Timo Sirainen wrote:
On Fri, 2010-05-07 at 15:03 -0400, Erik Kratzenberg wrote:
-Dovecot.log : Mar 29 11:00:06 Error: POP3(user_login):
> > Couldn't init INBOX: Mailbox isn't a valid mbox
> > -The mailbox start with either 'FFrom or 'FrFrom'
It's happening several times a day, sometimes to the same mailbox.
How often does the same user get the error?
We also noticed some other storage and assertion errors around the same
time the corruption occurs which may or may not be related:
Mar 26 14:49:36 dovecot: Panic: POP3(u...@home.com):
file mbox-sync.c: line 1314 (mbox_sync_handle_eof_updates): assertion
failed: (offset == 0|| offset> 31)
There's a good chance this is related.
Mar 24 15:21:59 dovecot: POP3(u...@home.com): Cached
message offset 2 is invalid for mbox file
/usr/boxes/mailbox
Are you using filesystem quota for users? That might explain this.
Otherwise, the above shouldn't be happening if Dovecot is the only
software writing to the mbox files..
I'm not sure if "mail_debug=yes" will give us any additional info, but
I'm turning that on now.
No, that won't log anything useful.
