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

[David Conrad <[e-mail]>]

Hi,

On Aug 19, 2013, at 12:10 PM, Scott Kitterman <[e-mail]> wrote:
> Operationally, there are far more problems associated with actually trying to 
> use Type 99 than there are with SPF records in Type TXT.

Given the abysmal state of implementation of middleboxes _today_, this isn't surprising.  I'm unsure this sad state applies for all future time to come.

> As Michael Hammer mentioned, we've been through all this before and people 
> might want to review the previous WG discussion on the topic.

+1

However, despite the operational issues mentioned above and the fact that this has been discussed to death, I also strongly oppose the deprecation of the SPF record. 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. 

Of course, both (a) and (b) can be improved over time.  The argument that "it's already been X years and only Y% of implementers have supported SPF so we should throw in the towel now" seems specious to me since:

1) the SPF type code has been allocated -- it isn't going away or going to be reused: deprecation gains nothing from a DNS perspective;
2) pretty much every implementation of name servers supports SPF (to one degree or another);
3) there exist implementations of DNS frontend UIs that support SPF and since the semantics are identical to TXT, future implementation would seem to be trivial if a UI supports TXT; and
4) deprecation of SPF imposes additional complexity on every other protocol implementation that uses TXT at the zone apex either now or in the future.

In the past, the IETF/IESG has frowned on 'squatting' on port numbers, addresses, etc., regardless of the potential operational implications of accepting that squattage. I personally feel the use of TXT in this context is only marginally different than squatting. In my view, deprecating SPF only makes sense if the protocol that would use SPF is not going to see further deployment.  Since as far as I know, the point of 4408bis is to clarify implementation requirements for future implementations, deprecation makes no sense to me.

Regards,
-drc