>>> Apparently, if a mime boundary ends with white-space before the newline, >>> it's not parsed as such by GMime. I'm eyeballing rfc2046, and I think >>> GMime is in the wrong here. Whitespace at the end should be allowed.
Yes, it was prohibited in rfc1521, which was obsoleted by rfc2046, where it's allowed. >>> here, a spurious newline before a mime-part. Reading rfc2046 I'd say >>> that is not allowed, and indeed GMime doesn't like it. And finally: I guess this newline refers to an empty mimepart header (and the second non-empty header is the header of internal message), so it should be correct. >>> this definitely breaks RFC822: the end of the headers is defined by two >>> newlines (CRFL's), so here the rfc822 headers end after the first x-mime >>> header. Maybe it's the same issue as in previous case: first header should refer to mimepart header, which is closed by two CRLFs, and then goes internal message's header, which is closed by two CRLFs too. Среда, 7 августа 2013, 16:42 +02:00 от Paul J Stevens <p...@nfg.nl>: >@talanchor, > > >I'm taking the liberty to CC both Timo and Jeff, since this also affects >both imaptest and GMime. > > >On 07-08-13 14:26, . . wrote: >> It seams like dbmail fails to parse incomming message correctly, if it >> has content type "message/rfc822" with submessage with content type >> "multipart/digest". > >No it doesn't. But malformed MIME is indeed not parsed as imaptest expects. > >This appears to be a very recently added test in imaptest. The mime >formatting appears broken. Perhaps that's intentional. > >> I've attached test files from latest imaptest >> (fetch-body-message-rfc822-mime and fetch-body-message-rfc822-mime.mbox, > >Apparently, if a mime boundary ends with white-space before the newline, >it's not parsed as such by GMime. I'm eyeballing rfc2046, and I think >GMime is in the wrong here. Whitespace at the end should be allowed. > >But the example message is broken in other ways: > >--foo > >From: m...@example.com >Subject: m1 > >m1 body >--foo > >here, a spurious newline before a mime-part. Reading rfc2046 I'd say >that is not allowed, and indeed GMime doesn't like it. And finally: > >--foo >X-Mime: m2 header > >From: m...@example.com >Subject: m2 > >m2 body > >--foo-- > >this definitely breaks RFC822: the end of the headers is defined by two >newlines (CRFL's), so here the rfc822 headers end after the first x-mime >header. > >Normally, if 'broken' MIME is found in the wild, I'd be happy to work >around it. But here we have an artificial construct, which appears to be >aimed at exercising the tolerance of dovecot's mime parser. > >It would be completely bonkers for me to work around that, just to pass >a dubious test. > > >-- >________________________________________________________________ >Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin > > * Premium Hosting Services and Web Application Consultancy * > > www.nfg.nl/i...@nfg.nl/+31.85.877.99.97 >________________________________________________________________ > -- . .
_______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
