Mailman 3 December 2011 - Mailman-Developers

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
by Mark Sapiro 06 Dec '11

06 Dec '11

On 12/5/2011 10:58 AM, Monica Chew wrote: > For context, I work at Google on Gmail spam, and one of the things we've > been doing as an anti-phishing measure is enforcing that mail from certain > highly-phished domains must be signed with the DKIM key of the purported > sender. We started this several years ago for just ebay and paypal ( > http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypa…) > and for the last couple of years have been trying to do it for > google.comand a handful of other domains as well. > > A side effect of this has been that mailing-list mailing has been > particularly difficult to classify. We've mostly solved the problem for > groups that we host, but external mailing lists have been a continual > challenge. As a result, many Google employees who want to participate in > standards and open source communities have been unable to (see for example > http://lists.openid.net/pipermail/openid-general/2009-June/018364.html, > where both mail from Google and Facebook employees were not delivered to > openid gmail members) with their standard mailing address. It seems you could solve this particular problem by allowing gmail users an option (non-default) to receive such mail with a "phish" warning rather than not receiving it at all. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 1

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
by Terri Oda 06 Dec '11

06 Dec '11

On 12/06/11 11:17, Murray S. Kucherawy wrote: > It depends on your expectations. If there's an expectation that the author's signature will/should/must persist through a mailing list, then I agree that they're largely incompatible. If on the other hand you intend for lists to re-sign mail and for receivers to evaluate the message based on the list signature rather than the author signature, then it's entirely workable. Of course, sometimes the author signature will indeed survive, and then you have two domains to evaluate instead of one. Bonus! There were a lot of "it depends" in your email, so maybe I've mis-read, but it sounds to me like the long-term path of least user/list admin hassle for Mailman probably is to just re-sign the messages. Except that there's no standard for third parties doing re-signing, and no one's sure how to interpret it if we do? As a developer, this sounds the makings of one of those life-sucking projects you shouldn't touch with a 10-foot pole unless you're getting paid to define and defend a standard. There's no guarantee that anything we choose to do will ever be considered correct, and it could wind up being a lot of arguing and wasted effort at a time when I think we're better off just getting mailman 3 out the door. Which is a pity, because this seems like a great opportunity for us to trailblaze and help correct a mistaken assumption in DKIM. Maybe the other developers are a lot more excited about that than I am and willing to take the risk of implementation, but maybe we should just keep an eye on the expansion of DKIM and revisit this issue after Mailman 3 is released? It sounds like our best option for the near future is to write up a nice little document describing the issue, Monica's fix for lists where DKIM is essential, and leave it at that as far as code goes until things move a bit closer to consensus on how DKIM should handle mailing lists long-term. As a bonus, a nice little document could also be usable with 2.1! If anyone needs wiki author permissions to do this, let me know. Terri

4 3

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
by Terri Oda 06 Dec '11

06 Dec '11

On 11-12-05 11:58 AM, Monica Chew wrote: > Terri and Florian, is this something that the webui group would be > interested in working on? 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'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. 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. Terri

3 2

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
by Barry Warsaw 06 Dec '11

06 Dec '11

On Dec 05, 2011, at 05:12 PM, Monica Chew wrote: >> 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. Hi Monica. I was really just talking about a way to make the setting of list configuration variables more user friendly. A "list style" is just a collection of settings that is applied to the list when it's created. A style could also in theory be applied to a list after it exists. Styles have names, so you could make one available to list owners called "make-dkim-not-break" or some such :). This is the current documentation on that feature: http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mail… Cheers, -Barry

1 0

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
by Barry Warsaw 06 Dec '11

06 Dec '11

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

3 2

feature request: one-click setting to preserve DKIM
by Monica Chew 05 Dec '11

05 Dec '11

Hi, folks! I guess this is as good a time as any to introduce myself, since both Murray's MLM+DKIM RFC and the formation of a new web-ui group are relevant. For context, I work at Google on Gmail spam, and one of the things we've been doing as an anti-phishing measure is enforcing that mail from certain highly-phished domains must be signed with the DKIM key of the purported sender. We started this several years ago for just ebay and paypal ( http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypa…) and for the last couple of years have been trying to do it for google.comand a handful of other domains as well. A side effect of this has been that mailing-list mailing has been particularly difficult to classify. We've mostly solved the problem for groups that we host, but external mailing lists have been a continual challenge. As a result, many Google employees who want to participate in standards and open source communities have been unable to (see for example http://lists.openid.net/pipermail/openid-general/2009-June/018364.html, where both mail from Google and Facebook employees were not delivered to openid gmail members) with their standard mailing address. There are many ways to solve this problem, and I've been tackling two of them: groups that we host, and migrating corporate mail to use a different domain than service mail. However, it would be wonderful for MLMs to support list admins who care about this by having a one-click option to turn off the settings that break incoming DKIM signatures, namely subject tagging and unsubscribe footers. Terri and Florian, is this something that the webui group would be interested in working on? Thanks, Monica

1 0

Mailman-Developers December 2011