> -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark....@python.org > [mailto:mailman-developers-bounces+msk=cloudmark....@python.org] On Behalf Of > Barry Warsaw > Sent: Monday, December 05, 2011 4:54 PM > To: Monica Chew > Cc: Terri Oda; mailman-developers@python.org > Subject: Re: [Mailman-Developers] feature request: one-click setting to > preserve DKIM > > 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.
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! As Monica points out, DKIM itself is oblivious to the context in which it's being used. > 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? You could. The issue isn't that doing so is wrong or impossible. It's simply that those semantics aren't built into DKIM, largely because we have no evidence that that's a useful test. The ESP community has argued that third-party signatures (those different than the one in the From: field) shouldn't be valued any less than one that does match, for various reasons. That argument was apparently persuasive. ADSP, and a draft I'm advancing called ATPS, extend DKIM's semantics to do more than just say "domain X handled this message" (which is really all a valid DKIM signature tells you). They both attempt to say things based on whether the domain delivered as part of a valid DKIM signature matches some identifier in the message, like the domain in the From: or in the List-ID field. If Mailman (or an MUA, or a filter, or something) implements such checks and finds that it's operationally beneficial to end users do so, then it could publish that mechanism in an RFC or elsewhere, and people could start to use it. The resistance isn't that this is a bad idea, but just that there's no evidence to back it up that would justify its standardization. The trick, of course, is not just to do something like this, but to get MUA buy-in. That is, when a signature validates and it presents a domain name that matches some identifier, change the presentation of the message to show this in some meaningful way. And then make sure in doing so that you don't inadvertently discredit legitimate messages for which that's not true. -MSK _______________________________________________ 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
