Hi Terri, Thanks for the response.
We have a significant complexity problem already in the admin interface. > If this is really just a matter of two settings (subject tagging and > unsubscribe footers) it would probably make more sense to add an > appropriate FAQ entry / documentation rather than adding Yet Another > Setting, especially since we'd have to deal smoothly with indicating the > over-rides and I suspect there's a bonus possibility for confusion as a > result. > I am completely sympathetic to the too-many-settings problem. > I'm not entirely convinced that this is a good way to solve the dkim > problem for Mailman in the long-term, since I'm pretty sure a lot of users > will balk at having the subject line tags removed, and many list owners > will balk at having unsubscribe footers removed, so maybe it's best to look > into the more complex re-signing solutions and not spend time encoding (and > translating, and user-testing) a stop-gap measure into the interface. > 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. 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. The only things I can currently recommend to affected users are to switch domains (hence my goofy googlers.com alias), but not surprisingly many people are passionate about changing their email address, maybe even more passionate than about mailing list behavior. 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? > 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. Thanks, Monica Terri > _______________________________________________ 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
