[Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Michael Thomas writes:

 > I'm afraid that there's not much consensus on how to deal with the
 > mailing list issue; the people who say "resign" are guessing as there
 > is little/no evidence that resigning is actually a viable strategy.

>From the point of view of the mailing lists, resigning is *clearly* a
viable strategy; the draft mandates that signature processing SHOULD
continue until a success or all signatures are exhausted.  (And it MAY
continue after a success.)  Assuming conformant verifiers (and no
corruption in the pipeline after the mailing list, of course),
resigning by the mailing list guarantees successful verification.

Of course there's the issue that policy agents might choose to put
100% weight on the failure of the trusted domain's signature, and none
on the success of the mailing list's signature.  See my reply to Joe
Petersen for a scenario of how this could be avoided.  Whether it will
work well in practice depends on whether policy agents (milters and
MUAs, mostly, I should think) will offer such options.  While clearly
you can't make such handling a MUST, I would like to see the BCP
specify that policy agents SHOULD provide such a feature to facilitate
resigning by resenders.

Finally, with regard to "loopback" verification, that's your local
policy problem, really.  It's true that munging by a few mailing lists
is invalidating your outgoing signatures.  Whether that consideration
overrides the mailing lists' editorial policies is a question for
negotiation among you, your users, and the list admins on a case by
case basis.  Remember, you always have the option of S/MIME on
individual SignedData MIME body parts for this purpose, and your
argument for resenders passing things through verbatim would be much
stronger in that case.

 > Let me float this though: how about a "signature friendly" knob that
 > configures the list to not do things that are known to be harmful to
 > signatures (including s/mime and pgp for that matter). I don't think
 > this needs to be _especially_ complicated, but it would probably need
 > to be fleshed out.

[ Actually, for Mailman 3 it would be nice to have a general "theme"
  engine that handles this kind of thing. ]

I think as a practical matter it's only a matter of time before this
becomes a FAQ in *both* directions (people who are having problems
similar to Joe Petersen's as well as those similar to Cisco's).  So I
agree here.

>>>>> "bw" == Barry Warsaw writes:

 bw> I really want to see the spec address mailing list issues in a 
 bw> thorough way, with clear instructions on what such remailers must and 
 bw> should do.

 > I think it would actually work a lot better the other way: with real life
 > experience and real life running code we can make a much better case
 > for what constitutes a best common practice. Part of the problem right
 > now is that a lot of the speculation is just that.

I really really sympathize with Barry (especially since I don't really
have the resources to help with implementation of a verifier or signer
for Mailman), but I have to agree with you here.

 bw> We're removing signature that we know nothing about.  As I said, IWBNI 
 bw> we had code that could check DKIM signatures and sign messages.  So a 
 bw> question to ask, in the face of no available code to do the verifying 
 bw> or signing, is it better to possibly break signatures because of 
 bw> Mailman transformations or better to not have a signature at all.  And 
 bw> why?
 > 
 > Do you remove PGP ascii armor just on the offhand chance that you might
 > destroy a PGP signature with some  configurations of mailman?

That's hardly fair.  Joe Petersen writes (in a response to your
message):

    2) The outgoing MTA (sendmail) milter seemed to only want to sign
    emails that did *not* already have a signature.  Therefore,
    Mailman enabled them to re-sign by removing the old (presumably
    invalid anyway) signature.

First, note that the admin has explicitly stated that the existing
signature is presumed invalid.  He may be wrong, but this isn't an
"offhand chance".

Much more interestingly, note that the milter is broken with respect
to mailing lists.  IMO, Section 5.1 of dkim-base should get language
that says a signer SHOULD NOT refuse to sign a message merely because
there is an existing signature.  Without that, Barry's question is
very relevant.

I would answer Barry that Mailman SHOULD preserve existing signatures
because the spec will get language saying

  o signers SHOULD NOT refuse to re-sign
  o policy agents SHOULD report only successes by default
  o policy agents MAY provide an option to acquire information about
    failures

In particular, in section 6.1,

      INFORMATIVE NOTE:  The rationale of this requirement is to permit
      messages that have invalid signatures but also a valid signature
      to work.  For example, a mailing list exploder might opt to leave
      the original submitter signature in place even though the exploder
      knows that it is modifying the message in some way that will break
      that signature, and the exploder inserts its own signature.  In
      this case the message should succeed even in the presence of the
      known-broken signature.

I'd like to see that last "should" in all uppercase<wink>.  Then
(sorry, Barry!) IMO the burden is clearly on Mailman and other list
manager projects to either implement signing themselves, or publish
their own BCPs strongly recommending use in combination with an MTA
that will do the signing.

 > By removing signatures you go from having about a 99% success rate
 > to a 0% success rate.

That's false.  You go from a 99% success rate *on "loopback" messages*
to 0%.  On other messages the ex ante success rate will be much lower
because the trust relationship is on average much weaker.  However,
the vast majority of *deliveries* are not "loopbacks", and those
non-loopbacks are likely (see (1) below) to suffer from rejection on
the basis that signatures fail.

 > With this change there will be a lot more people getting useless
 > false positives. Is that of no consequence?

Of course it is of consequence.  You keep ignoring the fact that
Mailman has already experienced systematic useless false positives
without this change.  Is that of no consequence?

 > But let's turn this around: why do you think practice is helpful? I
 > really don't understand the motivation at all.

What I really fear is that

    (1) everybody's intuition is that a failed verification is a
        positive indicator for spam (as compared to no signature, as
        well as compared to verified signature), and they want to
        apply policy filters based on that---we can expect that lots
        of people (and let's not forget AOL) will (ab)use the
        information that way, and

    (2) we've already seen list-hostile implementations in the wild---
        we can expect that there will be more.

Both of these are evidently conformant to the current spec.

 > Destroying information -- especially when you're charged with
 > forensic exercises like spam filters are -- is *rarely* the right
 > thing to do.

True, but this is a Pythonic bunch.  "Practicality beats purity." :-)