On Fri, 25 Jun 2010, Dave Crocker wrote: > On 10/16/2009 3:33 PM, Michael Deutschmann wrote: > > I'd like to more emphatically state the case for adding a > > "dkim=except-mlist" policy to ADSP. It will soon become a practical > > issue for me, since my mailserver software (Exim) is going to support > > DKIM in its next version. > > > Simple question: why? That's quite an old message you are responding to.
I do not expect any selfish benefit to publishing DKIM/ADSP, even were the mailing list problem completely solved. Someone mentally lazy enough to be tricked in the absence of DKIM would probably be fooled by a sender using the expected full name in combination with an e-mail address he controls. But I'm not entirely selfish -- I would consider publishing merely to help my fellow hacker with his spam control. The point is not to protect him from being *tricked*, but to help him filter out noise at his computer before it reaches his brain. For this purpose a low FP rate is essential. Because of the confusion over what "all" and "discardable" actually mean, when choosing an assertion I must consider the worst case for FPs -- that the recipient thinks both mean "everything unsigned is *definitely* a forgery and thus noise." In turn, the only policy I can publish is "unknown", which provides no help. In order to publish a stronger policy, I would need to abstain from mailing lists and Usenet (because some newsgroups are gatewayed to mail). Sorry, but my charity doesn't extend that far. But I could publish "except-mlist" right now. And it happens that should another site publish "except-mlist", that would be as helpful to my spam defense as if they published "discardable". I could reject incoming messages with missing/broken signatures when the assertion is correctly except-mlist, and be guaranteed no *additional* false positives. The only way this test could false-trigger is if I forget to whitelist a mailing list, and if that happened every message from the list would already be doomed by my anti-Bcc: filter. ---- Michael Deutschmann <[email protected]> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
