On Feb 8, 2008, at 1:41 PM, Michael Thomas wrote:
Steve Atkins wrote:
You can't say "receiver checking DKIM and/or SPF would stop 100%
of fraudulent emails" and then redefine "fraudulent emails" as "mails
stopped by receiver checking of DKIM and/or SPF".
DKIM+SSP will only ever stop a tiny fraction of "illegitimate"
emails,
and pretending otherwise doesn't lead to an honest evaluation of the
benefits and drawbacks of it.
I dunno, you can also get paralyzed by the enormity of the problem too
and do nothing. DKIM and SSP chip away at a very large problem, and I
don't think we've ever tried to sell it as anything else. Instead of
restating the obvious about no silver bullets, perhaps it would be
better to think in terms what small little new thing we can do to
chip away at the problem? We are looking like we're getting close
to last call with nothing new left on our charter ;-)
My original observation was that "discardable" was a reasonable term
for mail for which the sender prefer the recipient not deliver a small
fraction of legitimate email and a small fraction of non-legitimate
email rather than deliver either.
There was an assertion made that the "small fraction" of non-
legitimate email here was actually 100% of the non-legitimate email.
That assertion was shown to be false, so we can ignore that digression
and return to where I came in, which was:
It's an assertion that the sender would prefer that the recipient
not deliver some small fraction of legitimate email as well as some
small fraction of illegitimate email, rather than delivering those
small fractions of legitimate and illegitimate email.
In the senders opinion, it is more important that mail claiming to
be from them not be delivered than for it to be delivered.
The english meaning of "discardable" matches the semantics pretty
well. If we want implementors to easily understand and deploy the
specification, and more importantly the limits of them doing so,
thats fairly important.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html