talanchor at mail
Aug 7, 2013, 8:30 AM
Post #3 of 6
(23 views)
Permalink
|
|
Re: dbmail: fetch multipart rfc822 message errors
[In reply to]
|
|
>>> 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 <paul [at] nfg>:
>@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: m1 [at] example
>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: m2 [at] example
>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/info [at] nfg/+31.85.877.99.97
>________________________________________________________________
>
--
. .
|
fetch-body-message-rfc822-mime.mbox
