Hi-
Found a message that will generate a pop3 coredump when using
mbox format. It seems to do with the fact that it has a mime
part with a line that's 10,000 bytes long. However, that doesn't
seem to be the only factor.
Adjusting the size of the mail header seems to cause different kinds
of crashes. I'll avoid attaching the message here but I've
put it at http://www.mv.com/users/mem/x/badmail
Reproducing it here on a BSD/OS system involves something like:
(login to a virgin account or one you don't care about)
% wget http://www.mv.com/users/mem/x/badmail
% rm -rf .imap
% MAIL=mbox:`pwd`/badmail
% limit coredump 10m
% /usr/local/libexec/dovecot/pop3
quit
at which point you should get some errors and/or a coredump. You
may need to do it twice (i.e. let it create the .imap/ index
structure first).
If you can't make it happen I can send along more info.
-mm-
(and yes, this was a real mail message, albeit a spam, except that I
simplified it some and replaced all of the content with "x"
characters)
On Thu, 2003-05-01 at 02:51, Mark E. Mallett wrote:> Hi- > > Found a message that will generate a pop3 coredump when using > mbox format. It seems to do with the fact that it has a mime > part with a line that's 10,000 bytes long. However, that doesn't > seem to be the only factor.There were 3 problems actually: 1) Dovecot stopped parsing messages that had lines longer than 8192 bytes (or 256k if mail_read_mmaped = yes). RFC-(2)822 says maximum line length is 1000 bytes, do MTAs actually allow longer? Fixed anyway. 2) Dovecot thought UIDVALIDITY changed whenever mailbox had been empty. Or in this case, when it thought the whole mailbox was changed because the first message's length was different than it thought. This caused "mailbox inconsistency" error. 3) pop3 server didn't handle inconsistency error separately and tried to print NULL error message. Some sprintf() implementations (GLIBC at least) print it as "(null)", but looks like it crashed with you. Fixed this, and also it now prints NULL error as "BUG: Unknown error".