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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
