[Mailman-Developers] feature request: one-click setting to preserve DKIM
barry at list.org
Tue Dec 6 01:53:56 CET 2011
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
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
>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 (
>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.
More information about the Mailman-Developers