[Mailman-Developers] feature request: one-click setting to preserve DKIM

[Monica Chew]

> I'm no DKIM expert by far, but it seems to me that a mailing list message has
> enough clues that a DKIM verifier could do a better job at helping recipients
> make good choices.  For example, all Mailman messages have a List-Id header
> that contains the domain name hosting the list server.  With re-signing, why
> couldn't you verify the signature against the List-ID host instead of the
> original sender?

Sorry, I'm not being precise. DKIM is mostly agnostic about what is
signed. The only header field it requires being signed is the From
header. What Gmail is doing is requiring not only that DKIM verifies,
but that the domain used for signing (d= in the DKIM header) matches
the payload From. If we exempted signed mailing list mail from these
anti-phishing checks, then the following attack is possible.

DKIM-Signature: d=evil.com;h=list-id:date:from;b=....
From: noreply at paypal.com
List-Id: "A totally legitimate mailing list" <lists.evil.com>

For obvious reasons, this is not a loophole that we want. At the same
time, we don't want senders from highly-phished domains not to be able
to communicate with Gmail users through mailman.

> >Another, hacky option that preserves list behavior for some members would
> >be to ship a list of domains that have this strict DKIM policies, and then
> >use this list to suppress DKIM breakages for members hosted at these
> >domains. So, if someone wrote to a mailman list that included members at
> >these domains, DKIM would not break for these members only. That would
> >include gmail and Yahoo users, too (
> >http://ycorpblog.com/2007/10/04/say-goodbye-to-ebay-and-paypal-fraudsters/).
> >Is this more palatable than adding a one-click setting?
>
> For several reasons I don't think so.  Keeping that list of sites updated will
> be a maintenance nightmare, and give the number of Mailman sites out there
> that are still running several years old versions, I think any approach
> depending on timely updates by site administrators will basically fail.  It's
> also a bit scary to me from a performance standpoint to be loading up more
> personalized message processing at the sending-out-to-upstream-MTA phase.

I understand your point about updates. I don't like this approach
myself, but thought it might be more plausible than adding yet another
setting that's exposed in the UI.

> >> That said, we've talked a lot about having simplified interfaces for quick
> >> list administration and interfaces designed for specific purpose lists. It
> >> seems like this might fit in nicely with some of those ideas, so I'm
> >> definitely not adverse to keeping it in mind as an interface option if
> >> there's evidence that this would be useful to enough list owners.
> >
> >What kind of data would be helpful here? Besides the problem of senders
> >from highly-phished domains having trouble communicating to external lists,
> >Gmail has also been ramping up the amount of UI warnings when the
> >authenticated domain (either DKIM or SPF) does not match the payload From
> >header for all messages:
> >https://mail.google.com/support/bin/answer.py?answer=185812. These warnings
> >basically appear for all mailman users who are also Gmail users.
>
> Mailman 3 supports list-styles, which in theory are composable.  Coming up
> with a good ui for that is a whole 'nuther issue, but the core could support
> something like this fairly easily.

Could you elaborate more? I couldn't turn up documentation on this. If
you mean sufficient hints in the headers to the MUA render subject
tagging and unsubscribe footers unnecessary, then I agree.

Thanks,
Monica