[ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive

[Steve Atkins]

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