Re: [Mailman-Developers] MIME footers
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.
I wish I could say "fix the MUAs" but that's probably been futile since the day email was invented. ;)
That said, it's not a totally unreasonable suggestion. I wonder if it makes sense to have that be a user option (then, what's the default, what a standard says, or whatever minimizes user complaints).
Cheers, -Barry
On Fri 2015-02-27 15:07:52 -0500, Barry Warsaw wrote:
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.
Can you point us to those complaints? I'd love to have a "wall of shame" of MIME-aware-but-botched MUAs, complete with version number information and a little carrot to give the devs if they get fixed.
I wish I could say "fix the MUAs" but that's probably been futile since the day email was invented. ;)
:)
--dkg
On 02/27/2015 01:00 PM, Daniel Kahn Gillmor wrote:
Can you point us to those complaints?
<http://wiki.list.org/x/4030707> and the posts linked from there in the archive of the Mailman-users list and many other posts in that archive.
<https://www.google.com/?gws_rd=ssl#q=site:mail.python.org+inurl:mailman-users+footer+attachment>
I'd love to have a "wall of shame" of MIME-aware-but-botched MUAs, complete with version number information and a little carrot to give the devs if they get fixed.
MS Outlook. Good luck on the carrot.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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.
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.
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.
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 <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
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?
Note that this already has precedent in that not all header fields need to be signed, and in that DKIM already provides a (mostly unused) content-length parameter that would allow adding arbitrary material as a footer (I do mean arbitrary, most MUAs still understand uuencode).
It means that a paranoid MUA won't display the unsigned content at all, and a cautious MUA will take actions like disabling links, displaying with a warning theme, or even presenting those parts as buttons accompanied by warning messages so that the user would have to explicitly request display.
In the end, the semantics of signed or unsigned content are up to the receiver, but I think the above ideas are pretty obvious ways to treat such messages.
participants (4)
-
Barry Warsaw -
Daniel Kahn Gillmor -
Mark Sapiro -
Stephen J. Turnbull