Re: [Mailman-Developers] MIME footers
On Tue 2015-02-24 15:26:36 -0500, Murray S. Kucherawy wrote:
A while back I introduced an experimental draft about DKIM signature generation that's sensitive to MIME structure. I'm planning to revisit and maybe even implement this to get some experimentation going. It would help guide the design work if I knew this:
How does, or how would, Mailman add a footer to a MIME message? My guess is that it would make a multipart that contains the original message (message/rfc822) as one part and the footer as a text/plain in a second part, but that's purely a guess.
Mailman does not generate any message/rfc822 MIME parts. Here's what it does to add a footer (there are three cases):
If the main content-type of the message is text/plain, then mailman just appends the footer to the body of the message directly.
So it goes from this:
A └─╴text/plain 1216 bytes
to this:
B └─╴text/plain 1418 bytes
If the main content-type of the message is multipart/mixed, it simply appends a new text/plain part at the end of the message. So it goes from this:
C └┬╴multipart/mixed 8690 bytes D ├─╴text/plain 625 bytes E └─╴text/plain attachment [foo.diff] 1290 bytes
to this:
F └┬╴multipart/mixed 8795 bytes G ├─╴text/plain 625 bytes H ├─╴text/plain attachment [patch.loadlin.diff.txt] 1290 bytes I └─╴text/plain inline 200 bytes
(part I is the mailman footer).
If the main content-type of the message is neither text/plain nor multipart/mixed, mailman creates a new root MIME node of type multipart/mixed, takes the previous mime structure as the first child of that root, and places the footer as the second child with a content-type of text/plain.
so it goes from this:
J └┬╴multipart/alternative 10003 bytes K ├─╴text/plain 1459 bytes L └─╴text/html 1996 bytes
to this:
M └┬╴multipart/mixed 10572 bytes N ├┬╴multipart/alternative 3881 bytes O │├─╴text/plain 1459 bytes P │└─╴text/html 1996 bytes Q └─╴text/plain inline 120 bytes
Equally important: What would it do to sign a message that's not MIME to begin with? Could it be compelled to turn it into a MIME message, perhaps treating the original as a single-part text/plain message and doing the same wrapping I described?
Mailman doesn't usually sign messages. What kind of signatures are you asking about?
hth,
--dkg
Thanks for the great explanation Daniel.
On Feb 24, 2015, at 05:08 PM, Daniel Kahn Gillmor wrote:
Mailman does not generate any message/rfc822 MIME parts. Here's what it does to add a footer (there are three cases):
Actually, there's one other case. The condition is different, but this doesn't lead to a fourth outcome.
If the main content-type of the message is text/plain, then mailman just appends the footer to the body of the message directly.
Unless the charset of the message is not "compatible" with the mailing list's preferred language charset. The test here is not wonderful, but essentially when adding the decorations (and this includes a possible header although most lists don't define one) if the charset of the to-be-included text can't be encoded to the message's text/plain charset, then we do the wrapping, just as in the multipart case.
Cheers, -Barry
On Tue, Feb 24, 2015 at 2:08 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
Equally important: What would it do to sign a message that's not MIME to begin with? Could it be compelled to turn it into a MIME message, perhaps treating the original as a single-part text/plain message and doing the same wrapping I described?
Mailman doesn't usually sign messages. What kind of signatures are you asking about?
Sorry, by "sign" I meant "add a footer". I probably said "sign" because this is related to some DKIM work I've been planning, and the morning's caffeine was already wearing off.
Thanks for that detailed answer (and Barry for his followup). It's precisely what I was looking for.
How absurd would it be to propose a flag for Mailman that would take your first case (non-MIME, or single-part text/plain) and convert it to a multipart/mixed with a child part of the original text/plain, and then apply the algorithm you have?
The impetus here is DKIM survivability across lists. Suppose we had a DKIM canonicalization that was MIME-aware, so that it could sign the specific MIME parts or sets of parts. That signature would fail on the message as a whole -- with the footer part added -- but could in theory pass if an appended part were omitted from canonicalization. To put it in context, suppose there were a DKIM canonicalization where the signer signed (using your examples) the CDE message; the receiver gets FGHI which fails, but also has enough information to know that merely verifying FGH will pass; it then knows that FGH was "legitimate" and I was added post-signing, and may or may not be "safe" (for some value thereof) content.
What I'm worried about with such a design is the trivial text/plain message. Obviously merely appending the footer destroys any hope of validating only the original content. We'd have to entertain the idea that Mailman would make the simple message into a multipart/mixed + text/plain, then append the footer part and sign that; the verifier would drop the footer and then strip off the MIME to see if it can verify the original signature that way. That seems like its easy to get wrong, though it's likely to be a very common case.
-MSK
participants (3)
-
Barry Warsaw -
Daniel Kahn Gillmor -
Murray S. Kucherawy