-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-part messages without content-type in subparts are misparsed #14
Comments
I can confirm this with a fresh CPAN install of Email::MIME (v1.937) and a simpler test case:
Note that there is only one subpart and it has no content-type. I note that the original report is relatively old (2014). Anyone still interested besides me? |
I am still interested, but I have not been bitten and so haven't spent the time to try to make a patch. |
@rjbs - does the test case fail for you? If yes, then perhaps you can point me in a direction to help contribute a patch, but the tricky part seems to be that it's actually that we are tickling a bug in the Email::Simple module, but should protect against it here. |
…s#14) Per RFC 1341, section 7.2 https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html A body part is NOT to be interpreted as actually being an RFC 822 message. To begin with, NO header fields are actually required in body parts. A body part that starts with a blank line, therefore, is allowed and is a body part for which all default values are to be assumed. In such a case, the absence of a Content-Type header field implies that the encapsulation is plain US-ASCII text.
Possible fix attached |
…rts. Per RFC 1341, section 7.2 https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html A body part is NOT to be interpreted as actually being an RFC 822 message. To begin with, NO header fields are actually required in body parts. A body part that starts with a blank line, therefore, is allowed and is a body part for which all default values are to be assumed. In such a case, the absence of a Content-Type header field implies that the encapsulation is plain US-ASCII text.
A multi-part message that has subparts without an explicit content-type (or any other headers) is misparsed. For example:
em.pl:
When run against this file:
ex.email
prints out:
Note that the warnings all come from the second subpart; if a content-type is set in it as in the first subpart, the warnings go away and it works as expected.
I suspect the first paragraph in the second subpart is being parsed as a header.
The text was updated successfully, but these errors were encountered: