Support multipart messages without content-type in subparts. (GH: #14) #28
Conversation
|
Thanks for waiting so patiently on this… I think the idea here is on the right track. I'm not sure about this line;
If the input is CRLF delimited lines, won't this match a single CRLF, rather than two line-delimiting sequences? Maybe this should be using |
…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.
wolfsage
force-pushed
the
topic/gh-14-multipart-implicit-headers
branch
from
2b9d213 to
981d820
Compare
|
Ah, whoops. Nice catch. Updated PR to add test for CRLF emails and include associated fix. |
|
I'm still reviewing this, I think I'm seeing more fundamental problems with the pre-existing code. But in the meantime: |
|
Basically, Email::MIME is not great. When we look for Next problem (I think): You're adding a header to each MIME part that lacks one. This means the message won't round-trip. That means that DKIM signatures (RFC 4871) will break if you read in a message without that property and then reinject |
When we come across a part that has no specific content-type, we inject one to satisfy RFC 1341, section 7.2. We must inject a header because Email::MIME body parts are just Email::Simple objects -- which expect messages that have at least one header. After we've generated the part, we can then remove the added header, and be on our merry way. This is awful, but works.
|
As discussed, solved the possible DKIM signature breaking change by adding a header temporarily and then removing it after we're done. As to the first part (CR before CRLF).. I'm not sure what to do here. |
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.