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

[Barry Warsaw]

On Dec 05, 2011, at 03:50 PM, Monica Chew wrote:

>Having worked in the DKIM-for-anti-phishing space for a couple of years,
>there is no good way to solve the DKIM problem in Mailman.

I think this is the one big lesson from these discussions: DKIM is mostly
incompatible with mailing lists.  Where the two must be integrated, some
usability will likely be compromised.

>As you point out, people are quite passionate about mailing list
>behavior. However, here's why re-signing is not ideal for anti-phishing
>purposes: anyone can generate a DKIM key and sign a any message using that
>key. Using DKIM for anti-phishing purposes requires that the signing domain
>be the same as the purported sender, otherwise, it's useless.  Everything
>might as well be signed by evil.com :) It is much better if signatures don't
>break.

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?

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

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

It still feels to me like a good solution to DKIM+mailing lists just hasn't
been discovered yet.

-Barry