Doug,
Aren't you tired of repeatedly pointing out your half of the argument? I am of ours. The Monty Python argument clinic sketch comes to mind.
On Tue, Apr 30, 2013 at 10:11 AM, Doug Barton <dougb@xxxxxxxxxxxxx> wrote:
Do we just have SPF operators call you for emotional support during this protracted transition time?
Aren't you tired of repeatedly pointing out your half of the argument? I am of ours. The Monty Python argument clinic sketch comes to mind.
On Tue, Apr 30, 2013 at 10:11 AM, Doug Barton <dougb@xxxxxxxxxxxxx> wrote:
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 ...
As has been repeatedly pointed out, the "haven't been relevant for many years now" conclusion you've reached is contradicted by both anecdotal and empirical data.
I assure you that I hear all of the points you are making. I also assure you that none of them resolve any of the points being made on the other side. There's no dialog happening here.
I assure you that I hear all of the points you are making. I also assure you that none of them resolve any of the points being made on the other side. There's no dialog happening here.
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.
Sure, because you don't have to do the work, nor are you confronted with the weight of the long tail in this case. I submit that it is presumptuous to assert that the properties of one community's long tail problems are the same as they are in others.
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").
I don't think anyone said that's difficult. I would also point out that it's not difficult, given a jumble of TXT RRs in a reply, to find any that start with a particular identifying substring which would mean "this is an SPF record", so let's nip that one in the bud right now.
These are all distractions from the real points being made.
Second, there are not that many implementations that query SPF, and the change is not difficult.
Nobody said that's a problem either.
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.
...during which time the service arguably operates in a degraded state.
The assertion that "You should just fix your DNS infrastructure!" ignores the fact that the interfering piece of the infrastructure may not be under the control of the operator who can't complete an SPF operation, or, worse, that the owner of the problem lacks the resources or interest to get it fixed for a long while, if at all.
Do we just have SPF operators call you for emotional support during this protracted transition time?
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).
This is also a separate argument given the underscore prefix debate.
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.
What are you prepared to do to help address the broken infrastructure? It's all well and good to lob directives over the wall, but I'd like to hear some advice about how to compel inattentive infrastructure operators to make these changes, especially when those operators aren't necessarily the ones affected.
-MSK