[Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Michael Thomas writes:

 > I'm not saying I think that resigning is a Bad Thing, I'm saying that it's
 > speculative whether it's a Good Thing. You seem to keep ignoring the
 > inherent attack involved with resigning:

Have you actually read my posts, or just enough to feel defensive?

I have specifically referred many times to the user-list trust
relationship implicit in a double-opt-in list.  I have provided
examples of how the receiving system can acquire information about
such relationships, as well as acknowledging that getting such
information is a nontrivial problem in the context of busy admins and
slow implementation cycles.

The standard specifies that whether to trust a signature is a local
policy decision.  It seems to me that Mailman's decisions about
whether to put signing and verification capabilities into Mailman
itself will depend on the developers' estimate of whether list
signatures will be trusted in those local policies.  It seems to me
that Mailman's decisions about how to default the signature-stripping
functionality depend on our estimate of whether broken signatures will
be given negative weight compared to no signature.

My position is that Mailman lists[1] SHOULD participate in the DKIM
protocol, because I think that if Mailman lists are important to
users, they will respond to DKIM-related obstruction of their traffic
by demanding that their MTAs trust their Mailman lists.  If that's a
PITA for the admins, too bad---that's the flip side of the admin
benefits that come with use of DKIM to filter spam.  And of course
admins and MUA developers *will* develop trust management tools.
Maybe you have less confidence in your vendors, of course---I *know*
mine will rise to the occasion.

So far, you talk out of both sides of your mouth.  On the one hand,
you fault my proposal because of the attacks inherent in trusting any
old re-signature; on the other, you claim that you don't have trust in
anybody's signature, and you don't even treat your own specially!
Elsewhere you have implied that for you verification == trust if
"From == signing domain".  Just generalize that to include
"List-Id == signing domain" in the policy agent software!  And
"Sender == signing domain".

Users need never know that the "sender" who was verified is not the
>From header.  Why not recommend that UIs SHOULD treat *any* of the
three conditions above as "sender verified", until experience shows
that's a bad idea?  I suspect that naive users will happily accept it
if policy agents tell them "sender was verified, so we present you
with this mail for your consideration."  They may misconceive that the
>From header was verified, but why should that matter?

If it *does* matter to them (eg, because they know that "Mom would
never send me porn spam"), then here's the recommended UI for spam
discards when the sender has been verified as a mailing list:

    Treat similar messages as spam?  [[yes]] [no]

    Note: this message was verified to have been relayed by the Mailman
    Developers mailing list at python.org, which accepts responsibility
    for relaying it to you.
    ( ) I am not a member of this list.  Treat messages from this list
        as spam in the future.
    (o) I am a member of this list.  Carefully scan messages from this
        list in the future.

Something similar could be recommended for other cases where the
verified sender is in a different domain from "From" (as I am, for
example).  Isn't that the way it's supposed to work?  Do you really
think that users will care as long as you explain that they're not
blacklisting their mothers, and the spammer does get blacklisted?


Footnotes: 
[1]  Whether Mailman itself should be a signer or verifier is another
question; I'm agnostic on that.