ietf
[Top] [All Lists]

Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

2013-04-30 21:12:45

In message <517FFB33(_dot_)30902(_at_)dougbarton(_dot_)us>, Doug Barton writes:
On 04/30/2013 09:28 AM, Alessandro Vesely wrote:
While it's too late for SPF, we can learn this lesson.

As has been repeatedly pointed out in the discussion on both dnsext and 
spfbis, it is NOT too late for SPF. The way forward is simple:

1. Publish the bis draft which says for senders to publish both SPF and 
TXT versions, and receivers to query first for the SPF RRtype.

2. Update the HOW-TO docs to reflect this change.

3. Update the software to query SPF first (Note, Perl's NET::SPF, used 
by SpamAssassin, already made this change).

As has libspf2.

4. Let time pass.

5. When the next version of the SPF protocol (v=spf{>1}) comes out make 
it SPF/99 only.

The discussion about this on the spfbis list all revolved around the 
fact that TXT is widespread, SPF/99 is rarely used, so let's just stick 
with TXT. In a pre-3597 world there _were_ problems with querying for 
SPF first, so the fact that historically querying for SPF/99 first was 
painful is a valid data point. However the problems encountered in the 
early days of SPF deployment with servers not handing unknown types 
gracefully haven't been relevant for many years now. Yet, the SPF 
community has continued to push TXT only, in spite of the advice of 
4408. Almost like a self-fulfilling prophecy ...

The reasons brought forward by participants in the spfbis group to not 
make this change all revolve around the fact that it would involve 
additional work. Personally I don't find those arguments compelling. 
First, some of the arguments about the extra work are just plain silly 
(ala, "cut and paste of the same data for 2 RRtypes is too difficult"). 
Second, there are not that many implementations that query SPF, and the 
change is not difficult. Third, most of the "work" to be done is to wait 
for time to pass and for people to upgrade to the new versions of 
software. This is a bog-simple "long tail" problem that we deal with in 
the DNS world all the time.

There was one objection that made some sense, which is that right now, 
because the SPF world has steadfastly distributed the advice to use TXT 
only, querying for SPF/99 first gives you what is likely to be 1 
spurious DNS lookup per e-mail message. The obvious answer to that is to 
do a better job of encouraging folks to publish SPF records. Meanwhile, 
I have a fairly traditional mail server implementation that does a 
variety of anti-spam checks. By rough count it generates about 8 DNS 
queries for every message already. Generating 1 more is "in the noise" 
in the short term, and as shown above goes away in the long term.

Not only is this a case where doing the right thing is good for SPF, the 
SPF example of "let's just go with TXT because using a new RRtype is 
hard" has spread like wildfire, especially in the mail authentication 
world (DKIM, DMARC, etc.). The slippery slope has been well-greased at 
this point, and it would be nice to move things back in the right 
direction (see 5507 for example).

To be fair, there was one other objection raised, which is that DNS 
provisioning systems haven't caught up with the need for new RRtypes. So 
some can't go to their registrar's/web hoster's/etc. web interface and 
enter a proper SPF record. That's a problem, sure. But it's a problem 
that has to be solved, assuming we're actually going to take the advice 
in 5507 seriously. Personally I'm not willing to allow all progress 
forward in DNS to be stymied by those unwilling to make an investment in 
their own infrastructure.

In case Dave is still wondering what all the fuss is about, and because 
the folks in spfbis seem completely unwilling to deal with this issue in 
the group, consider this my first draft of an IETF last call objection 
to the fact that 4408bis wants to deprecate use of the SPF RRtype.

Doug

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org