Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Scott Kitterman <[e-mail]>]

On Monday, August 19, 2013 21:57:26 David Conrad wrote:
> John,
> 
> On Aug 19, 2013, at 3:58 PM, John Levine <[e-mail]> wrote:
> >> AFAICT, no one is arguing that overloading TXT in the
> >> way recommended by this draft is a good idea, rather the best arguments
> >> appear to be that it is a pragmatic "least bad" solution to the fact
> >> that (a) people often implement (poorly) the very least they can get
> >> away with and (b) it can take a very long time to fix mistakes on the
> >> Internet.> 
> > Neither of those are the reason the WG dropped type 99 records.
> 
> My apologies for trying to provide a high-level summary of what I believe
> the arguments to be.  My understanding of the reasons the WG decided to
> deprecate the SPF RR:
> 
> 1) the low level of deployment of the SPF RR "both on the publishing side
> and the validation side" relative to TXT RRs
> 
> This corresponds to (a): people implement/deploy TXT because it is currently
> sufficient, both from what people put into their zone data as well as what
> middlebox and DNS UI implementors bother supporting.  I believe it is
> sufficient because the migration strategy proposed in RFC 4408 was in
> error.
> 
> 2) a "race condition" or "interoperability problem" resulting from what is
> documented in RFC 6686, Appendix A, #4.
> 
> This corresponds to (b): there was a mistake in 4408 and fixing that mistake
> takes a long time.
> > Once again, I really don't understand what the point is here.
> 
> To quote from "http://www.openspf.org/FAQ/TXT_abuse" (a page on one of the
> websites referenced in RFC 6686):
> 
> "The Right Thing To Do is to get our own RRtype, and although it took a long
> time to get it, we have it assigned."

According to the history of the page, I wrote that in 2006.  Don't confuse 
engineering and marketing.  Despite the revisionist claims to the contrary, 
the SPF community pushed pretty hard on type SPF deployment, but it didn't 
work out very well.  Most open source libraries have given up on type SPF 
query be default, despite having supported it initially.

Support for type SPF in SPF verifiers is more likely declining than increasing.  
At least for the open source implementations capable of supporting it, the 
code has been there for half a decade.  It's mostly been turned off by default 
for operational reasons.

Scott K