[spfbis] SPFbis WG scope

[Douglas Otis <[e-mail]>]

Attempts to elevate SPF to a standards track document just as Carrier 
Grade or Large Scale NATs appear distracts from a greater need to 
provide scalable cryptographic validation for SMTP servers.  SPF 
provides little protection against spoofing since MAILFROM is not seen.  
Efforts to extend SPF to include PRA suffers from similar problems since 
malefactors can use unseen PRA header fields as well.

The macro expansion required for SPF processing risks DDoS threats with 
little justification.  For example, SPF evaluation may require 
subsequent transactions formed by email-address local-parts.  Since most 
spam campaigns already modify source address local-parts, any targeted 
attack against a domain (which may not be present within these messages) 
will not burden malefactor's DNS since SPF records referenced by the 
domain portion of the email address will have been cached.  This permits 
both spamming and DDoS to occur simultaneously that exploits SPF's 
burden placed upon recipient resources.  Use of "exists" macros is 
equally nonsensical.  Any message with an email address pointing to 
existing resource records as dictated by SPF macros reveals absolutely 
nothing about who sent the message!

The 10 mechanism macro limit must include subsequent transactions 
necessary to resolve authorized IP address lists.  Even this seemingly 
low limit can result in significant levels of network amplification 
oweing to processing burdens placed upon recipients.  While email 
providers are unlikely targets, and processing complex SPF macros are 
seldom logged, there would be few clues regarding this attack from a 
victims perspective.  Assumptions that a valid authorization confirms 
the action of a domain is also wrong.  Often these authorizations are 
essential to ensure delivery can be accomplished by various email providers.

Rather than expecting recipients to discern whether an entire sequence 
of email deliveries properly executed the "who's it" handshake and that 
no one is lying all depends upon the last provider in the sequence.  
Recipients should be allowed to either trust the last provider or not, 
where authentication of this last provider represents the only scalable 
solution.

http://tools.ietf.org/html/draft-kucherawy-dkim-atps-11 provides a 
"single" transaction method for DKIM signers to authorize all last in 
sequence providers.  There is no reason to muddle with the return path 
for DSNs since this will further lower email integrity.

-Doug