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).
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