On 02/27/2015 12:07 PM, Barry Warsaw wrote: > On Feb 27, 2015, at 11:46 AM, Murray S. Kucherawy wrote: > >> 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? > > [...] >> >> 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. > > The biggest downside, and probably the main reason we append the footer text > in the text/plain-compatible-charset case is because of crappy MUAs. I think > we *still* get complaints about the MIME composition not being rendered very > well. Their MUAs will show them attachments without the message content they > actually care about.
Absolutely. It is not a problem with 'reasonable' MUAs that just display the msg_header and msg_footer parts inline with the rest of the message, but there are popular ones that don't. The worst offense being displaying the msg_header as the message and everything else as an attachment. I started thinking about this in more detail, because there are actually 3 ways that Mailman adds the msg_header and msg_footer. 1) The message being decorated is a single part text/plain message with a compatible character set. In this case, msg_header is just addedc to the beginning of the body and msg_header to the end, clearly breaking any signature that wasn't already broken by content filtering, subject prefixing or whatever. 2) The message being decorated is multipart/mixed. In this case, msg_header and msg_footer are added as additional MIME parts to the beginning and end respectively of the multipart/mixed message. 3) The message being decorated is something else. In this case, a new message is created (it doesn't actually happen this way in detail, but effectively it's a new message) which is multipart/mixed and contains the msg_header part, all of the parts from the message being decorated and the msg_footer part. This is very much like case 2 except for the change in Content-Type. It seems to me there are a couple of problems. The first problem is how do you determine in general which are the parts to which the original DKIM sig applied, even it they are all still there (i.e. none removed by content filtering). The second problem is what good is even a valid DKIM sig of only a subset of the parts of a message? I.e., if I can take a valid DKIM signed message and add my own MIME part(s) without any cooperation from the original signer, what is the meaning of the sig in this case? -- Mark Sapiro <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
