[Mailman-Developers] Testing different email structures with MUAs

[Stephen J. Turnbull]

Daniel 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/signature

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.  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