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 21:22:53
Again, I'm not the shepherd on this, but I was involved in the
consensus call in the WG when we determined that the WG wanted to
deprecate use of RRTYPE 99.  (Note that this "deprecation" means just
that users of SPF stop publishing that record.  There's nothing in the
draft to remove the RRTYPE, as that would be absurd.)

On Tue, Aug 20, 2013 at 11:27:25AM +1000, Mark Andrews wrote:
Deployment is happening.  More and more SMTP servers
are making SPF requests before TXT requests.

I think those are the two central premises that are up for dispute.
RFC 6686 made the determination about the former claim, and therefore
that premise is not up for debate: deployment appears not to be
happening.  If people wish to argue with the conclusions of RFC 6686,
that's fine, but it seems that one at least needs to write an
anti-6686 document in that case.  The draft currently up for last call
is relying on the conclusions of RFC 6686 as a premise, and is not
itself arguing whether RRTYPE 99 deployment is or is not happening.

The fact that SPF processors are making SPF queries before TXT queries
is in fact part of the reasoning for why RRTYPE 99 ought to be
deprecated.  If many clients make a query and only a tiny number of
zones have that type published (or are likely ever to publish the
type), it's simply wasteful to continue using that type.  If this
seems a familiar line of argument, it's because it's one you see in
the spfbis list archives when this issue was decided by the WG.
 
Note it doesn't help that companies charge extra to support SPF
over TXT as you well know.

I'm not sure whether that's supposed to be a swipe at my employer, but
just so we're clear: Dyn (my employer) supports the SPF RRTYPE in its
enterprise-focussed offerings.  There's no extra charge.

The front end for the basic DNS service (many people know this as
DynDNS or Dyn's Standard DNS or other such trade names) is intended to
be simple and self-service.  It's cheap, and the margins don't allow
us to provide a lot of personalized support.  Dyn found that people
who were good candidate customers for that self-service system knew
how to do things with TXT, did not know about or care about the SPF
type, and were confused by having two types for one purpose.  For
practical purposes, it was necessary to support SPF over TXT (since
some clients didn't check the SPF type).  So, one type it was, and TXT
at that.  This all happened long before I worked at Dyn, but I assure
you that the commercial pressure for adding TYPE 99 support to the
basic platform (actually, it's just the front end) is just as
non-existent today as it was when that decision was made.

Best,

A

-- 
Andrew Sullivan
ajs(_at_)anvilwalrusden(_dot_)com

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