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 <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html