[Dovecot] File isn't in mbox format - Couldn't open INBOX
While I saw another thread on the list similar to the issue I was experiencing (http://dovecot.org/pipermail/dovecot/2005-February/006168.html), I was wondering if there was a way around this problem (the thread simply suggested upgrading, but are the later version (specifically the 1.0-test releases) ready for prime time?)...
We're periodically having this with some users (not sure what client they are using, but I am pretty sure it is MS Outlook) where the inbox is in near perfect shape except for some extra characters at the beginning of the file. POP or IMAP delivery fails with an error stating "File isn't in mbox format - Couldn't open INBOX". It looks like those characters are of a previous message that was not completely removed from the file, and those characters seem to throw everything out of wack..
It's easily correctable by removing the bogus characters from the beginning of the file, but that gets annoying quickly..
-Rich
At 10:03 AM 4/14/2005, Rich West wrote:
While I saw another thread on the list similar to the issue I was experiencing (http://dovecot.org/pipermail/dovecot/2005-February/006168.html), I was wondering if there was a way around this problem (the thread simply suggested upgrading, but are the later version (specifically the 1.0-test releases) ready for prime time?)...
We're periodically having this with some users (not sure what client they are using, but I am pretty sure it is MS Outlook) where the inbox is in near perfect shape except for some extra characters at the beginning of the file. POP or IMAP delivery fails with an error stating "File isn't in mbox format - Couldn't open INBOX". It looks like those characters are of a previous message that was not completely removed from the file, and those characters seem to throw everything out of wack..
It's easily correctable by removing the bogus characters from the beginning of the file, but that gets annoying quickly..
I see it too. You running procmail by any chance? In our case it appears to be due to file locking, with procmail grabbing the mail spool while the user is deleting messages. Not sure if it is procmail specific or not, but the client doesn't seem to matter as it happens with pretty much all of them.
/steve
Yup, using Procmail. That's the main reason I never went to Cyrus.. it's difficult to get procmail to work with it.
I'm using fctnl for locking, if that matters any..
-Rich
I see it too. You running procmail by any chance? In our case it appears to be due to file locking, with procmail grabbing the mail spool while the user is deleting messages. Not sure if it is procmail specific or not, but the client doesn't seem to matter as it happens with pretty much all of them.
/steve At 10:03 AM 4/14/2005, Rich West wrote:
While I saw another thread on the list similar to the issue I was experiencing (http://dovecot.org/pipermail/dovecot/2005-February/006168.html), I was wondering if there was a way around this problem (the thread simply suggested upgrading, but are the later version (specifically the 1.0-test releases) ready for prime time?)...
We're periodically having this with some users (not sure what client they are using, but I am pretty sure it is MS Outlook) where the inbox is in near perfect shape except for some extra characters at the beginning of the file. POP or IMAP delivery fails with an error stating "File isn't in mbox format - Couldn't open INBOX". It looks like those characters are of a previous message that was not completely removed from the file, and those characters seem to throw everything out of wack..
It's easily correctable by removing the bogus characters from the beginning of the file, but that gets annoying quickly..
--On Sunday, April 17, 2005 3:52 PM -0400 "Stephen K. Gielda" <dovecot@steve.cotse.net> wrote:
I see it too. You running procmail by any chance?
One of my users had this happen to her Trash folder today. She's using Mozilla 1.8b1 and the server is dovecot-0.99.13-4.FC2. I found the file had a string of null's at the front. I removed the nulls and everything was fine again.
I have procmail set as the delivery agent, but that folder should never get mail delivered to it. (She has no .procmailrc to do per-folder delivery.)
I don't see anything else in the log to suggest why the folder might have gotten corrupted.
At 12:25 AM 4/19/2005, Kenneth Porter wrote:
--On Sunday, April 17, 2005 3:52 PM -0400 "Stephen K. Gielda" <dovecot@steve.cotse.net> wrote:
I see it too. You running procmail by any chance?
One of my users had this happen to her Trash folder today. She's using Mozilla 1.8b1 and the server is dovecot-0.99.13-4.FC2. I found the file had a string of null's at the front. I removed the nulls and everything was fine again.
I have procmail set as the delivery agent, but that folder should never get mail delivered to it. (She has no .procmailrc to do per-folder delivery.)
I don't see anything else in the log to suggest why the folder might have gotten corrupted.
Procmail does seem to be a common denominator, don't know if it's coincidental or not. The same happens to us, some users have folders that procmail shouldn't have been delivering to. It happens when the user is deleting, but I'll be damned if I can pin it down further because I have not yet been able to duplicate.
/steve
Stephen K. Gielda wrote:
I see it too. You running procmail by any chance? In our case it appears to be due to file locking, with procmail grabbing the mail spool while the
"Me too". I've tried every locking config option I can find (including good old .lock files), and still seem to have this problem periodically. It almost certainly is a locking problem, though I can't figure where.
Many times when this happens with our users I find that they are using our webmail (squirrelmail) client and are accessing their mail via imap *or* pop3 client software at the same time (mozilla and outlook are two specific ones i've confirmed this has happened with; though I don't think the client should matter).
I haven't actually been able to set up a situation that always leads to corruption though. It only happens sometimes. So this is very frustrating. I begin to suspect the moon may in some way be involved.
The best answer, of course, is Maildir! But alas... no resources to tackle that job. For now I have a script that scans all the mboxes for corruption every few hours and emails me if it finds it... which happens once or twice a week on average (it's not a huge mail server).
-- Tim Middleton | Vex.Net | But the trouble was that my hysterical fit x@veX.net | VexTech.ca | could not go on for ever. --Dost (NFTU)
"Me too". I've tried every locking config option I can find (including good old .lock files), and still seem to have this problem periodically. It almost certainly is a locking problem, though I can't figure where.
[..snip..]
It does seem that way, doesn't it? What version of dovecot are you running?
The best answer, of course, is Maildir! But alas... no resources to tackle that job. For now I have a script that scans all the mboxes for corruption every few hours and emails me if it finds it... which happens once or twice a week on average (it's not a huge mail server).
I'd be curious to see that script, if you wouldn't mind sharing! :-)
-Rich
Rich West wrote:
It does seem that way, doesn't it? What version of dovecot are you running?
0.99.14 on FreeBSD 4.9
I'd be curious to see that script, if you wouldn't mind sharing! :-)
Sure... it's nothing special. Just checks that each file starts with "From ". No intelligence. Cron emails the output, if any. I had thought of putting in code to automatically fix the corrupt boxes; but at the time I wanted to look into each as they happened to see if I could figure out why it was happening.
-- Tim Middleton | Vex.Net | "Are the gods not just?" "Oh no, child. x@veX.net | VexTech.ca | What would become of us if they were?" (CSL)
participants (4)
-
Kenneth Porter
-
Rich West
-
Stephen K. Gielda
-
Tim Middleton