Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

On Tue, 13 Dec 2005, Douglas Otis wrote:

> The reduction to 111 DNS lookups is not a resounding impact with 
> respect to this concern.

You can do setup that involves multiple CNAME and NS redirections
with DNS and it all could come to those 100 lookups. In practice
these setups do not exist though and neither have I seen any serious 
reports of SPF records that cause 100 lookups (your tests that setup
these records on purpose is not good indicator of how administrators 
enter spf records).

> SPF is not about validating the purported author of a message. SPF 
> deals with forged return-paths.  For this protection, SPF depends
> upon wide adoption by others before a benefit is obtained, hence the 
> reluctance to correct the lack of scope.  BATV, on the other hand, 
> provides immediate benefits when forged return-paths are used in DSNs 
> (the only place where a return-path is intended to be used).

Funny how you forget to mention that what is called BATV was invented
by people working on SPF - at first as advanced version of SRS, which
was thereafter released as SES [1] and anybody with technical knowledge
will quickly see that BATV basically implements subset of SES (although
I agree that is the more useful subset of that proposal).

[1] http://ses.codeshare.ca/files/Working_SES_Format_Definition_16.pdf

However it also happens to be that the same subset can be used quite
well with SPF (in a way BATV would never support) - in particular SES 
allows sender to run not only private validating service that checks
incoming email bounces, but also public validating server (using dns 
protocol for confirming verification) which based on given RFC2821 
mailfrom address can say if it is properly signed SES address. This 
allows for for bad bounces to be stopped closer to the source and
knowing new validation system is not required as it can be done with
SPF record (using exists mechanism to redirect to validating server).

The benefit of such combined SPF/SES setup is that if the email
comes directly from the ip block listed in spf record, then extra 
cryptographic validation (and contacting external service) is not
required (and these account for majority of real-life cases) where
as in other cases using SES service can provide results that would
make SPF work with forwarding and for roaming users.

So in practice SES/BATV cryptographic MAILFROM should not be looked
at an alternative to RMX/SPF method. In fact they both are stronger
when combined together, however unfortunately the different proponents 
fail to point this fact to the wider audience (plus BATV proponents 
obviously ignore the history of this concept both when advocating it
and in the written text).

-- 
William Leibzon
Elan Networks
william@elan.net

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf