ietf
[Top] [All Lists]

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

2013-08-19 17:40:07
On Monday, August 19, 2013 14:54:44 David Conrad wrote:
Hi,

On Aug 19, 2013, at 12:10 PM, Scott Kitterman 
<scott(_at_)kitterman(_dot_)com> 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.

Possibly because your 'a' and 'b' strawman don't reflect the working group's 
rationale.  As previously mentioned, it's in the archives.

Scott K

Attachment: signature.asc
Description: This is a digitally signed message part.

<Prev in Thread] Current Thread [Next in Thread>