Testing different email structures with MUAs
Hi,
So I was testing which kind of message structure would be the best fit for sending out messages with more than one signature part. I tried 3 things:
Message according to 1this(having two signature parts in a 'multipart/mixed' part inside 'multipart/signed' message. My MUA(*mu4e*2) fails to find any signature part at all in this
A 'multipart/alternative' message with each part having same structure and each one having different signature. Now although from rfc20463 it is not a thumb rule to have different 'content-type' for each alternative part in a 'multipart/alternative', but I think MUAs would get confused if they find both alternative parts completely same(in structure). My MUA shows both parts and thus repeats data. Although it shows two signature parts too.
This third type was just my idea, does not follow rfc3156 obviously. I simply added another signature part to the original message and my MUA reads it nicely showing two signatures.
I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure.
-- Abhilash Raj
On Wed, Sep 11, 2013 at 02:28:21PM +0530, Abhilash Raj wrote:
I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure.
A more representative sample of what users (real users!) might see, might be better gained through some of the online tools; litmus http://litmus.com/email-testing may be useful.
-- "Cabbage-- the opinions of taxi drivers." (new definitions, from `I'm Sorry I Haven't a Clue')
On 09/11/2013 06:57 AM, Adam McGreggor wrote:
On Wed, Sep 11, 2013 at 02:28:21PM +0530, Abhilash Raj wrote:
I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure.
thanks, abhilash, i will try to test these shortly and give you feedback about icedove and notmuch at least, both of which are OpenPGP-enabled (notmuch is native, icedove with the enigmail plugin).
A more representative sample of what users (real users!) might see, might be better gained through some of the online tools; litmus http://litmus.com/email-testing may be useful.
Litmus appears to be about HTML rendering, which isn't what abilhash is asking about at all. If you know of a comparable service that provides this kind of comprehensive feedback about cryptographic signatures, i'd be very interested in learning about it.
Regards,
--dkg
Abhilash Raj writes:
I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure.
I don't understand what you think you will learn from this experiment. We're not interested (for your purposes) in what MUAs do with broken messages, including those that can't be validated. Your code simply should never emit them. (OTOH, we are interested in what your code will do with broken messages: it should trap them.)
In particular, in most cases the MUA will parse the multipart structures and tell you what they've found in one way or another. This is true of signed message parts. It's not unreasonable to suppose that some messages will contain additional content after the signed part; the MUA needs to determine the boundaries of the part in any case.
On 09/11/2013 08:44 PM, Stephen J. Turnbull wrote:
Abhilash Raj writes:
I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure.
I don't understand what you think you will learn from this experiment. We're not interested (for your purposes) in what MUAs do with broken messages, including those that can't be validated. Your code simply should never emit them. (OTOH, we are interested in what your code will do with broken messages: it should trap them.)
I think Abhilash is modeling what the messages emitted by a re-signing mailing list might look like.
We've been discussing several options about whether a message should be re-signed by the mailing list before being sent to the subscribers, whether the original author's signature should be kept as well, and if both signatures are present, how they should be attached to the message.
He's created these messages so that people can view them in their OpenPGP-compatible MUAs and see how the message signatures are displayed to the user.
In particular, in most cases the MUA will parse the multipart structures and tell you what they've found in one way or another. This is true of signed message parts. It's not unreasonable to suppose that some messages will contain additional content after the signed part; the MUA needs to determine the boundaries of the part in any case.
I'd actually argue that it *is* unreasonable in the current ecosystem to include some non-signed content after the signed part. Most OpenPGP-compliant MUAs that i've seen (thunderbird+enigmail in particular [0]) cannot clearly indicate to the user which part of a multipart, partially-signed message was the signed part.
[0] see the thread starting at https://lists.enigmail.net/pipermail/enigmail-users_enigmail.net/2013-March/...
Mailman is perhaps the most common generator of messages like this, such that icedove+enigmail currently makes the tradeoff to permit what is effectively a known signature-validation spoofing attack rather than make people think that mailman is stripping signatures from their messages.
If we could make mailman tuck its footer within a larger signature, that would be great.
--dkgDaniel Kahn Gillmor writes:
On 09/11/2013 08:44 PM, Stephen J. Turnbull wrote:
Abhilash Raj writes:
I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure.
I don't understand what you think you will learn from this experiment. We're not interested (for your purposes) in what MUAs do with broken messages, including those that can't be validated. Your code simply should never emit them. (OTOH, we are interested in what your code will do with broken messages: it should trap them.)
I think Abhilash is modeling what the messages emitted by a re-signing mailing list might look like.
Yes, I know that. I don't think his proposed experiment is valid, however; he needs to use messages with valid signatures, because that is what Mailman will produce.
He's created these messages so that people can view them in their OpenPGP-compatible MUAs and see how the message signatures are displayed to the user.
And if they do anything but display a warning that the signed part didn't correctly validate and are you really sure you want to look at the possibly radioactive waste in the payload?, they're broken, no? But that's not our problem, and it's especially not Abhilash's.
In particular, in most cases the MUA will parse the multipart structures and tell you what they've found in one way or another. This is true of signed message parts. It's not unreasonable to suppose that some messages will contain additional content after the signed part; the MUA needs to determine the boundaries of the part in any case.
I'd actually argue that it *is* unreasonable in the current ecosystem to include some non-signed content after the signed part.
You've got the wrong end of the Postel principle. I'm saying you will *see* such mail, not that you should *produce* it. You immediately provide evidence that it's common, and that at least one OpenPGP- wannabe does the wrong thing with it!
Most OpenPGP-compliant MUAs that i've seen (thunderbird+enigmail in particular [0]) cannot clearly indicate to the user which part of a multipart, partially-signed message was the signed part.
Wonderful. :-(
If we could make mailman tuck its footer within a larger signature, that would be great.
So you're proposing this, I guess:
multipart/signed
multipart/mixed
text/whatever # optional mailman header
multipart/signed
text/whatever # original signed content
application/signature
text/whatever # optional mailman footer
application/signatureBut the question is not whether Mailman can do that; it's trivial to produce it by moving the signing handler later in the pipeline. The question is whether OpenPGP-wannabe MUAs will do anything reasonable with it, FVO of "reasonable" that include "letting the user know what exactly was validated". Do you really think MUAs will do anything "reasonable" with it when they do this:
Mailman is perhaps the most common generator of messages like this, such that icedove+enigmail currently makes the tradeoff to permit what is effectively a known signature-validation spoofing attack rather than make people think that mailman is stripping signatures from their messages.
I don't believe my eyes. The MUA is passing off invalid data as valid, and you're saying Mailman should cater to that MUA? The sooner users realize such MUAs are broken by design, the better! Better they should bitch about Mailman (at least on Mailman channels, where we can explain to them what the real problem is).
Steve
On 09/12/2013 03:11 AM, Stephen J. Turnbull wrote:
So you're proposing this, I guess:
multipart/signed multipart/mixed text/whatever # optional mailman header multipart/signed text/whatever # original signed content application/signature text/whatever # optional mailman footer application/signature
yes, that's exactly what i was proposing. Abhilash, can your code produce messages like this?
But the question is not whether Mailman can do that; it's trivial to produce it by moving the signing handler later in the pipeline.
Great! That's well-structured data, that should be able to be legitimately rendered by any OpenPGP-compliant MUA, even ones that can only provide validation information for messages as a whole.
If Mailman did this regularly instead of creating the common anti-pattern:
multipart/mixed
text/whatever # optional mailman header
multipart/signed
text/whatever # original signed content
application/signature
text/whatever # optional mailman footerthen those MUAs like icedove that currently do the wrong thing might be less likely to try to do it anyway.
Note that Icedove/Thunderbird refuse to show any validation information for S/MIME-signed messages that are forwarded through mailman with headers or footers attached like the above structure.
I don't believe my eyes. The MUA is passing off invalid data as valid, and you're saying Mailman should cater to that MUA? The sooner users realize such MUAs are broken by design, the better! Better they should bitch about Mailman (at least on Mailman channels, where we can explain to them what the real problem is).
that's decidedly not what i'm saying. I'm just pointing out that mailman commonly produces what you've called "invalid data", and that its common production of that "invalid data" is precisely what this MUA's author cites as something he wants to be able to validate instead of hiding the main message contents' openpgp signature entirely. [0]
I'm not saying the enigmail folks are doing the right thing here -- there's more than enough bugs and blame to go around here, if we want to get testy :P (including the fact that thunderbird's UI makes a total botch of display of MIME parts themselves, which makes it difficult to attach any verification UI element to anything but the message as a whole).
But producing messages is what mailman does, so maybe we fix the message-producing mailman wackiness on the mailman list and save fixing the enigmail message-displaying wackiness for the enigmail list :)
Regards,
--dkg[0] http://thread.gmane.org/gmane.comp.mozilla.enigmail.general/17707/focus=1786...
Daniel Kahn Gillmor writes:
I'm just pointing out that mailman commonly produces what you've called "invalid data",
In the OpenPGP sense that the whole message cannot be considered to be validly signed, even though it may contain a multipart/signed part with a valid signature.
and that its common production of that "invalid data" is precisely what this MUA's author cites as something he wants to be able to validate instead of hiding the main message contents' openpgp signature entirely. [0]
How is that relevant to us? No matter how you slice it, if Mailman does its thing of adding a header or footer, the MUA has to dig into MIME structure and validate a subpart. Sure, in Abhilash's scheme Mailman will be validating the subpart as a service to lazy (?) or anonymous subscribers, but a PUCT[1] will want to double-check that Mailman did what it claims to do.
But producing messages is what mailman does, so maybe we fix the message-producing mailman wackiness on the mailman list
It's *not* wackiness. It's perfectly standard-conforming, and I see no reason why people who currently don't sign messages, and don't want to ask Mailman to do so because the necessary infrastructure is user- hostile, should be punished or be criticized for producing such messages.
My point is that I have no objection to trying to create valid messages that will validate correctly on as many MUAs as possible. What I object vehemently to is the idea that what a broken MUA (such as TB-E) does is a valid test of anything Mailman does. Especially not with a broken message.
I also have no objection to Mailman lists simply signing everything, so that they can advertise that they do. (OTOH, this is already more or less fulfilled by DKIM, so it's a niche use case.)
Footnotes: [1] Paranoid User of a Certain Type. Ie, trusts the author but not the list.
On 09/11/2013 04:58 AM, Abhilash Raj wrote:
I have attached all 3 type of message, each in a different file. Please can you place it in your maildir and check how your MUAs respond to it and report here? The message signature will not be verified(the signature text is actually gibberish), this experiment is just to check how the MUAs handle the message with such a structure.
I've updated those files slightly so that they each have a different Message-ID: and Subject: header, otherwise they won't be distinguishable in some MUAs. I've also added a Date: header for standards compliance.
Here are snapshots of icedove and notmuch (please excuse my horrid color schemes):
http://dkg.fifthhorseman.net/src/mailman/multisigned-images/
none of them look particularly good :/
If i get a chance to test other MUAs, i'll update that page and let you know.
Regards,
--dkgOn 09/13/2013 12:29 AM, Daniel Kahn Gillmor wrote:
http://dkg.fifthhorseman.net/src/mailman/multisigned-images/
I've added a fourth message, with a variant on the content wrapping structure stephen and i were just talking about:
└┬╴multipart/signed 11903 bytes ├┬╴multipart/mixed 8561 bytes │├─╴text/plain 97 bytes │└┬╴message/rfc822 inline 8133 bytes │ └┬╴multipart/mixed 7921 bytes │ ├┬╴multipart/signed 3270 bytes │ │├─╴text/plain 1825 bytes │ │└─╴application/pgp-signature attachment 897 bytes │ └─╴text/plain inline 171 bytes └─╴application/pgp-signature attachment 1027 bytes
And i've tested them all with claws mail as well, using the pgpmime plugin, and updated the display page to include the other screenshots.
hth,
--dkg
participants (4)
-
Abhilash Raj -
Adam McGreggor -
Daniel Kahn Gillmor -
Stephen J. Turnbull