Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 08:30:14 -0700

Just a suggestion: Maybe we should include an appendix about this topic.
In RFC6686 too the time to discuss the problem with the transition plan
that was shoe-horned into RFC4408 at the last minute, so maybe here we
should include a paragraph or two that acknowledges what the "right" way to
do the DNS piece would've been, don't use this as an example for future
work, etc.

On Thu, Apr 25, 2013 at 8:05 AM, John R Levine <[email-masked]> wrote:

> That does not imply I am quiet in other places, and I am as many others
>> nervous over the implications.
>>
>
> That we have a large and unaddressed problem of cruddy provisioning
> software?  I entirely agree.
>
>
> Regards,
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.
> ______________________________**_________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dnsext<https://www.ietf.org/mailman/listinfo/dnsext>
>

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Apr 2013 11:41:32 -0400

The barriers to deployment of new RR Types that are outside of the IETF/IANA 
processes haven't changed much since 2005.  I think the lesson ought to be 
that until that's changed it's pretty pointless to try and assign new RR Types 
for new functions (note that other services such as DKIM that came after SPF 
have used TXT and not even attempted a new RR Type).

I think the lesson has been learned and we don't need an appendix about what 
other working groups in the future ought to do.

Scott K

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 25 Apr 2013 17:42:35 +0200

Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Thu, Apr 25, 2013 at 05:03:55PM +0200 Quoting Patrik Fältström ([email-masked]):
> 
> On 25 apr 2013, at 16:44, John R Levine <[email-masked]> wrote:
> 
> > In any event, the SPF draft is in WGLC.  Feel free to read the extensive discussion in the list archives and let them know how you feel.
> 
> They know how i feel. We in IETF do believe in rough consensus. I am this time on the rough side.
> 
> That does not imply I am quiet in other places, and I am as many others nervous over the implications.

This is a slippery slope. One record overload is not bad, but it sort
of opens the floodgates for systematic overloading. DNSEXT and DNSOP
certainly need to get involved; because this is way bigger than just SPF.

And IMNSHO spfbis is out of scope prescribing TXT records, just because
of this contagiousness.

For the record: I think that the spfbis draft is unfit for publication
as RFC unless TXT records are deprectaed as only carrier of data.
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... I want FORTY-TWO TRYNEL FLOATATION SYSTEMS installed within
SIX AND A HALF HOURS!!!

---

From: Dotzero <[email-masked]>
Date: Thu, 25 Apr 2013 12:26:51 -0400

> And IMNSHO spfbis is out of scope prescribing TXT records, just because

It is not so much that SPFbis is prescribing practice as it is
updating to describe practice and avoid potential problems that have
been identified with having both TXT and type 99 records (without a
lot of verbage to address hypothetical future use).

> as RFC unless TXT records are deprectaed as only carrier of data.

Would you be any happier if the WG left type 99 records and in a coy
manner made it clear that usage is overwhelmingly TXT based with
little likelyhood of type 99 gathering any meaningful traction? I'm
sure that if the issues surrounding adoption of new RR types were
resolved we would not be having this discussion - but they haven't
been resolved.

Mike

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Apr 2013 10:33:33 -0700

>And IMNSHO spfbis is out of scope prescribing TXT records, just because

The discussion about the SPF RRTYPE was tracked as Issue #9.  There 
are long threads about that topic in the SPFBIS mailing list 
archive.  The issue was also discussed at IETF 83 ( 
http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt 
).  There is a rough summary of the WGLC of the previous SPFBIS draft 
at http://www.ietf.org/mail-archive/web/spfbis/current/msg01505.html

The SPFBIS charter is at http://tools.ietf.org/wg/spfbis/charters  I 
have read that document several times last year to ensure that I 
understand the working group scope.  The working group was also 
chartered to resolve some experiments and that is what it did.

>as RFC unless TXT records are deprectaed as only carrier of data.

I requested comments from DNSEXT ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html ) 
to ensure that the DNS parameters registry was not being updated 
incorrectly.  I read the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03491.html  I 
unfortunately do not see any arguments to suggest that the SPFBIS WG 
take any action.

Regards,
S. Moonesamy (as document shepherd)

---

From: Pete Resnick <[email-masked]>
Date: Thu, 25 Apr 2013 12:34:19 -0500

> as RFC unless TXT records are deprectaed as only carrier of data.

SPFBIS AD hat on for this:

We are *long* past this discussion. This discussion should have happened 
at SPFBIS *chartering* time, as it is crystal clear from the charter 
that existing features currently in use in SPF are not going away. 
Indeed, the TXT record was specifically mentioned in the charter.

I certainly have the same heartburn as everyone else about having used 
TXT in this manner, but that ship has long sailed. This is running and 
interoperable code and it is being documented on the standards track. 
Unless you think there is a piece of information I missed in my 
assessment that we had consensus to go forward with this work in the 
first place, you are going to have a hard time convincing me that this 
is not in the rough part of the consensus now.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Apr 2013 13:52:34 -0400

In my view, since I was the one who posted and asked questions about 
this very issue in IETF and DNSOP to get a feel about the unnamed RRTYPE 
and rfc3597 "Handling of Unknown DNS Resource Record (RR) Types", the 
current status quo, nine years later, what most preferred, I don't 
believe there was a consensus when you include the inputs from the other 
list to just stay with TXT. My concern was whether an RFC will be 
"sanctioned" as a proposed standard for what most experts believe, 
including myself, is a KLUDGE solution and not ideal in large scale and 
worst as more and more protocols are written using a TXT only solutions, 
its all limited.

What I felt is that some were some key folks who were now more accepting 
of a TXT based record and possibly because DNS servers have failed to 
keep up with this need (support RFC3597 or something like it).  That was 
the expectation in my view and we expected a long term migration to 
occur too.

I would support keeping the RRTYPE. I believe it is be less of a cost 
issue - implementators don't have to "UPGRADE/KEEP UP" to BIS by 
removing RRTYPE overhead.   By making it obsolete, you automatically 
make all SPF implementators "out of date."

Anyway, I am not too sure if everyone will like this outside the SPF BIS 
group. I didn't get that feel. Only a selective few (key cogs) that are 
part of this work has began to show an acceptance to it.  So if that 
matters, what is what I was trying to feel in IETF and DNSOP - who else 
agreed with that from an endorsement standpoint.

--
HLS

---

From: Warren Kumari <[email-masked]>
Date: Thu, 25 Apr 2013 14:16:17 -0400

[ Whee, replying to my own message. Always a good sign…] 
On Apr 25, 2013, at 2:03 PM, Warren Kumari <[email-masked]> wrote:

> 
> On Apr 25, 2013, at 1:34 PM, Pete Resnick <[email-masked]> wrote:
> 
>> We are *long* past this discussion. This discussion should have happened at SPFBIS *chartering* time, as it is crystal clear from the charter that existing features currently in use in SPF are not going away. Indeed, the TXT record was specifically mentioned in the charter.
>> 
>> I certainly have the same heartburn as everyone else about having used TXT in this manner, but that ship has long sailed. This is running and interoperable code and it is being documented on the standards track. Unless you think there is a piece of information I missed in my assessment that we had consensus to go forward with this work in the first place, you are going to have a hard time convincing me that this is not in the rough part of the consensus now.
> 
> I would also recommend that folk actually go and read RFC6686 [0] - I know that having actual measurements interferes with one's ability to have a fun little rant, but, if you do, maybe you can avoid looking silly (like I did with the RFC5507 discussion :-)).
> 
> Maybe stuffing stuff in a TXT record was a poor decision. Maybe it wasn't. There are heaps more SPF in TXT than SPF in SPF, kvetcing won't change that, and I'm sure we can find something else more fun to kvetch about…
> 

Ever have one of those days when you just wake up ornery? Those are probably the days when you shouldn't be responding to mail (or interacting with people at all) :-P

W

> 
> W
> 
> [0]: Yes, I know finding the documents can be hard. Here is a link: http://tools.ietf.org/html/rfc6686
> 
> 
> 
>> pr
>> 
>> -- 
>> _______________________________________________
>> dnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsext
>> 
> 
> --
> "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie."
> -- Terry Pratchett
> 
> 
> 
> 

-- 
A. No
Q. Is it sensible to top-post?

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Apr 2013 21:59:56 +0200

On 25 apr 2013, at 20:03, Warren Kumari <[email-masked]> wrote:

> Maybe stuffing stuff in a TXT record was a poor decision.

What I tried to explain in RFC5507 was that the real pain(*) is when you in an RRSet get back more data than what you want, so that you have to parse the blob of data you get and do whatever you want to do.

The selector of what you want can only be in one of the owner, class or type, and we know the class is sort of not usable, so you are stuck with type and owner. If now owner is TXT on everything,...

The rest is left as an exercise for the reader.

   Patrik

(*) Experience from too extensive use of NAPTR records in various solutions, and the reason I came up with the URI RRType.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Apr 2013 22:02:06 +0200

> The selector of what you want can only be in one of the owner, class or type, and we know the class is sort of not usable, so you are stuck with type and owner. If now owner is TXT on everything,...

Sigh...if now TYPE is TXT on everything...of course...

   Patrik -- going to bed now

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 13:54:39 -0700

> Indeed, the TXT record was specifically mentioned in the charter.

As Ted pointed out, that seems not to be the case.

Meanwhile, some of us have spoken long and loud about how deprecating 
the SPF record is the wrong path, which includes before, during, and 
after spfbis was chartered. Those concerns have consistently been 
shouted down, as you are doing now.

The way forward is simple, spfbis should specify that compliant senders 
MUST publish the SPF record, and compliant receivers MUST query for it 
first. Then down the road at some point we can deprecate TXT for this 
purpose. If that had been done in the beginning we would be celebrating 
the deprecation of the TXT record right about now, instead of having 
another round of contentious arguments about doing it the right way in 
the first place.

Everyone knows the history of how hard it was to get new RRtypes off the 
ground at the time SPF first came into being. A lot of lessons were 
learned from that, and the situation is much better now. Everyone also 
understands that the problem of upgrading 3rd party and/or web-based 
provisioning systems to accommodate new records is still a problem. But 
that problem doesn't get better by ignoring it.

In short, the proponents of SPF (which by the way, I like and use) 
should be focusing on doing the right thing here, instead of the 
expedient thing.

Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 14:09:47 -0700

On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton <[email-masked]> wrote:

> purpose. If that had been done in the beginning we would be celebrating the
> deprecation of the TXT record right about now, instead of having another
> round of contentious arguments about doing it the right way in the first
> place.
>
>
I fail to see how the word "simple" can be legitimately applied here given
the breadth of the deployed base of SPF that's using TXT.  It may be the
right thing to do, but I don't think that's a mountain that's easy to
move.  Certainly it's easy to talk about it though.

> ground at the time SPF first came into being. A lot of lessons were learned
> from that, and the situation is much better now. Everyone also understands
> that the problem of upgrading 3rd party and/or web-based provisioning
> systems to accommodate new records is still a problem. But that problem
> doesn't get better by ignoring it.
>
> In short, the proponents of SPF (which by the way, I like and use) should
> be focusing on doing the right thing here, instead of the expedient thing.
>

I think that same history gives rise to another way forward.  When SPF came
into being, the RRtype issue prevented the right thing from happening.  It
was made worse by late insertion of a sloppy transition mechanism.  It's
much too late to fix that now, but we can take steps to prevent it from
happening with future protocols. Thus: Take our licks and leave this one
alone, but do good work on improving process and provisioning so that it
can't happen again.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Apr 2013 17:40:15 -0400

> should be focusing on doing the right thing here, instead of the

Type SPF has virtually no deployment and there's no incentive for people to 
switch to it (words on paper in 4408bis won't do it).  There are still 
substantial real world barriers to deployment and no operational interest in 
expending resources to resolve them.  The BEST case scenario from not 
deprecating is doubling the number of DNS queries associated with SPF.  That's 
not a good thing.

You might as well go back and get DKIM to create and use a new RR Type while 
you're at it.

Scott K

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 14:39:48 -0700

On 04/25/2013 02:09 PM, Murray S. Kucherawy wrote:
> On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The way forward is simple, spfbis should specify that compliant
>     senders MUST publish the SPF record, and compliant receivers MUST
>     query for it first. Then down the road at some point we can
>     deprecate TXT for this purpose. If that had been done in the
>     beginning we would be celebrating the deprecation of the TXT record
>     right about now, instead of having another round of contentious
>     arguments about doing it the right way in the first place.
>
>
> I fail to see how the word "simple" can be legitimately applied here
> given the breadth of the deployed base of SPF that's using TXT.

I didn't say "Don't query for TXT records any more." I definitely didn't 
say, "Let's throw out SPF altogether." I said "change it to go the right 
way around in the first place." Obviously the transition will take time 
(as I also pointed out), but that doesn't mean that we shouldn't start 
doing it the right way now.

And really, it IS simple. Tomorrow all the extant software that deals 
with SPF gets updated to query for SPF first. The next day all the docs 
for publishing SPF records tell people to publish both. Ok, tomorrow and 
the next day are probably not realistic, but how about next week? Or 
next month? This isn't brain surgery, it really is a very simple change. 
And sure it's going to take time to implement, time to upgrade the 
installed base, and time for the pendulum to swing from TXT being 
queried nearly universally to SPF instead. But it's a minimal amount of 
effort, and the time is going to pass anyway.

There is simply no reason not to do this right, and to start doing it 
right now.

> It may
> be the right thing to do, but I don't think that's a mountain that's
> easy to move.  Certainly it's easy to talk about it though.

We in the DNS world have a ton of experience with the long tail of an 
installed base that doesn't upgrade often. Maybe that's the difference 
in perspective that makes this look like an "easy" problem to us.

>     Everyone knows the history of how hard it was to get new RRtypes off
>     the ground at the time SPF first came into being. A lot of lessons
>     were learned from that, and the situation is much better now.
>     Everyone also understands that the problem of upgrading 3rd party
>     and/or web-based provisioning systems to accommodate new records is
>     still a problem. But that problem doesn't get better by ignoring it.
>
> I think that same history gives rise to another way forward.  When SPF
> came into being, the RRtype issue prevented the right thing from
> happening.

I would argue that the situation at the time made doing the right thing 
more difficult than using the TXT record, not that it made it 
impossible. But I will agree to disagree on that point. :)

> It was made worse by late insertion of a sloppy transition
> mechanism.  It's much too late to fix that now

But it's not. That's the point. I realize that the course of action 
where we throw up our hands and say to ourselves, "better luck next 
time, hopefully this will become a lesson learned" is wildly attractive. 
But it's bad to do that. Bad for SPF, bad for the DNS in general, and 
bad for the Internet as a whole. And most importantly, it would be 
choosing to do the wrong thing when there is no reason not to do the 
right thing.

Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Apr 2013 17:57:08 -0400

I believe the right engineering design choice in MARID was made.  The 
problem was the DNS Servers have not caught up with the very least of 
having a passthru concept with unnamed query types.  It is was clearly 
known what the issues were in MARID, a migration path was provided with 
the protocol and we fully expected the DNS servers will eventually catch 
up and support unnamed types. [1]  It was a long term migration path 
issue as Doug Barton pointed out.

I still believe having a specific record is the right thing and path. 
Eliminating it will only encourage more TXT-based protocols.  The 
question is whether the DNS servers will support it or at the very least 
a passthru.

I suggest to keep it and to relax the requirements, and basically have 
developers keep it as an software design option, i.e. don't forget about 
it, comment it out, compiler directives, etc.  It would be their choice 
to immediately support the ideal migration path that is currently 
described in 4408 (although I have a small issue with the parallel call 
idea, but that's a different issue), or leave the code ready but disable 
it for a TXT only query.  Lets think ahead here now (again), not later 
and begin to encourage DNS server developers/vendors, DNS Managerment 
Software folks, etc, to support unnamed types processing. [1]

--
HLS

[1] http://tools.ietf.org/html/rfc3597

n 4/25/2013 5:09 PM, Murray S. Kucherawy wrote:
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>

---

From: Pete Resnick <[email-masked]>
Date: Thu, 25 Apr 2013 17:41:18 -0500

> As Ted pointed out, that seems not to be the case.

Ted and I just had a discussion about this offline, and just as Ted did, 
you have misread what I wrote. I responded to Måns's suggestion that 
spfbis can not "prescribe TXT records". And I responded that existing 
features currently in use in SPF (of which the use of TXT is such a 
feature) are out of charter to remove. And they are.

The removal of the feature to use RR 99 was an option open to the WG if 
they determined that it was not on the forbidden list of "features 
currently in use". RFC 6686 and the discussion leading up to it document 
why it is, for all intents and purposes, unused.

> shouted down, as you are doing now.

A few things on this point:

1. There is no doubt that the removal of the feature to use RR 99 
engendered a protracted and contentious discussion. However, it was not 
specifically discussed before or during chartering as far as I can tell. 
I've looked through the IETF list, the IESG list, the DNSEXT list, and 
the SPFBIS list and I see nothing on this topic discussed prior to 
chartering. And importantly, I see not a single message from you in 
particular on this topic prior to this, and only a few messages in 
September of last year on any SPF topic.  So I'm not clear on what you 
mean by "some of us" having "spoken long and loud" about this topic 
before or during SPFBIS being chartered.

2. There is also no doubt that during the long discussion in February of 
last year on the SPFBIS list, many folks expressed the view that the 
feature ought not be removed, including by at least one chair of the WG. 
(In fact, that argument drove some of the research that ended up in RFC 
6686.) However, in the end, a consensus call was made that, although 
there were some outstanding objections, those concerns were sufficiently 
addressed *by reasoned technical argument* and that the consensus (with 
some roughness) was that the feature was to be removed. Though there may 
have been shouting at times, there was no "shouting down".

3. I do not intend, and hope I have not, "shouted down" any argument 
here. However, there is now a long record on this argument and how the 
consensus call was made. Though the chairs and I will review all 
discussion that comes out during Last Call (or now), it really is only 
polite for (if not incumbent on) those who might still have objections 
to do some research to see if their particular argument was not 
addressed in that lengthy discussion. My claim in my earlier message was 
(and remains) that it's going to take identifying some piece of 
information that was missed during that discussion to convince me that 
the consensus call was not correct. As I've said elsewhere, number of 
people saying something is not how consensus is judged; it's whether the 
issue itself was properly addressed. (See draft-resnick-on-consensus-02 
for my musings on that.) Coming to consensus is hard work, and it 
shouldn't just be hard work for chairs and ADs; participants have to do 
their part too.

In particular:

> query for it first. Then down the road at some point we can deprecate 
> TXT for this purpose.

This is *not* a new argument. It was one that was discussed at length on 
the SPFBIS list at the end of last February. If you think we missed 
something (and I'd really ask you to read through the discussion of 
issue #9 on the list), I'd encourage you to make that case. But simply 
saying, "MUST publish/MUST query/later deprecate TXT" is not a 
sufficient technical argument given all that has been discussed to date.

> should be focusing on doing the right thing here, instead of the 

If, after reading the discussion, you think SPFBIS was being superficial 
in its treatment of this topic and can identify an argument that was 
missed, fine. But your presumption that this was done simply for 
expedience is at the very least premature.

pr

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 16:28:50 -0700

> feature) are out of charter to remove. And they are.

... and for the Nth repetition, I did not propose to remove the TXT 
record at this time.

> why it is, for all intents and purposes, unused.

Yep, been there, done that. It was a bad decision then, and it's still a 
bad decision now. I realize that it's incredibly unpopular to bluntly 
call bad decisions "bad decisions," but not doing so doesn't make them 
any less bad. And, to make matters worse, not doing so has led to a 
non-trivial number of those bad decisions becoming de facto standards. 
This has at least 2 very bad side effects ... first, we have to live 
with the bad de facto standards; but more importantly we are providing 
encouragement to people who wish to make similar bad decisions down the 
road.

The argument in 6686 boils down to, "We made a series of bad decisions, 
which have led to a bad result. We now want to codify that bad result 
instead of cleaning up our mess." I don't agree with that in principle, 
and I don't agree with that in regards to this particular case.

Further, while cleaning up the SPF mess would require nothing more than 
a marginal amount of extra work now, plus the passage of time, there is 
no reason not to actually clean up the mess.

> chartering.

https://www.ietf.org/mail-archive/web/ietf/current/msg72024.html is 
where the thread starts. There is another parallel thread an a related 
topic around that same time.

> And importantly, I see not a single message from you in
> particular on this topic prior to this,

https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html

> and only a few messages in

With respect, you clearly haven't been paying attention. That thread on 
ietf@ (and the one you referenced on dnsext) took me about 2 minutes to 
find. Admittedly, the ietf@ thread wasn't specifically about SPF, but it 
was about the same exact topic, at the time that the spfbis charter was 
being developed, so one would think that interested parties would have 
wanted to pay attention.

The topic has been raised numerous times since day 1 of SPF, and the DNS 
folk who have said "the SPF RRtype should be the first (if not only) 
choice" have been consistently ignored.

Meanwhile, who said what when isn't the interesting part of the 
discussion. The questions are simple:

1. What is the right thing to do?
2. Can we do it?

We know the answer to 1, and the answer to 2 is yes. So why are we 
spending all of this time trying to find reasons not to do the right 
thing? If as much energy had gone into fixing the problem as has gone 
into justifying not fixing the problem, the problem would be fixed by 
now. :)

> some roughness) was that the feature was to be removed.

Yes, I know the history. It was a bad decision. The great thing about 
life, especially life in the IETF, is that bad decisions can be revisited.

> Though there may

Others see the problem differently, but let's not quibble on that point.

> issue #9 on the list), I'd encourage you to make that case.

I'll give that a go, sure.

> But simply

But what if all of the previous discussion was wrong? Simply saying "we 
have discussed this extensively" doesn't refute sound technical 
arguments either. :)

> expedience is at the very least premature.

While I didn't follow the spfbis group, I have followed SPF from the 
time before it was even a topic at the IETF. Given what I know of the 
history I stand by my assertion, but would be overjoyed to be proven wrong.

Doug

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 17:15:43 -0700

On 04/25/2013 03:41 PM, Pete Resnick wrote:
> and I'd really ask you to read through the discussion of issue #9 on the
> list

Ok, so I've read through those threads, and the antecedents. I saw the 
following:

1. Some reports of people who wrote code to use the new RRtype early on, 
and had problems, so they stopped.

2. A report that Perl's "Mail::SPF (which is used by Spamassassin) 
checks for Type SPF first by default."

3. Several folks pointing out the valid DNS protocol based reasons why 
overloading TXT is bad, and new RRtypes for new features are good.

4. Lots of messages along the lines of, "We've always used TXT for this, 
so we should keep using it." These arguments all seem focused around the 
concept that having 2 ways to do the same thing is kind of a pain, so 
let's just use the one that is most popular.

5. Some fairly persuasive technical arguments from Andrew Sullivan that 
putting SPF records into your zone is a good idea. Particularly this:
https://www.ietf.org/mail-archive/web/spfbis/current/msg00544.html

#1 was an expected result in the days prior to 3597 (2003), but should 
be little to no trouble now.

#2 Speaks in favor of my proposal.

#3 (Arguably one of the only "reasoned technical arguments" in the 
bunch) seems to have been ignored by the majority of list members.

#4 Is not a "reasoned technical argument."

#5 Is also a "reasoned technical argument," which was not only ignored, 
but twisted on its ear by at least one list member.

It's also worth pointing out that a non-zero number of list members were 
ready (eager?) to shut down the SPF record prior to their being any 
actual discussion of it.

So I stand by my original proposal. We should do the right thing here, 
not the expedient thing. And the fact that a significant piece of 
software is already doing that, and clearly it works, is a pretty big 
point in favor.

Further, there were no "reasoned technical arguments" in that thread 
against doing what I proposed. As I mentioned in #4 above there was some 
whinging about having 2 ways to do the lookup, but as I pointed out 
previously if the switch had been flipped to do the SPF lookup first at 
some reasonable time post-3597, we'd be celebrating the deprecation of 
the TXT record right about now.

And further than _that_, Andrew and a few other list members pointed out 
that with a theoretical v=spf3 on the horizon, that would be a perfect 
time to say "Use the SPF record only, don't use TXT at all." Of course 
that whole line of thought was shot down with the same, "But we've 
always used TXT" argument. Which is unfortunate because I think that 
would have been an excellent compromise position, which has valid 
technical grounds.

Doug

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Apr 2013 17:22:25 -0700

Hi Doug,
At 16:28 25-04-2013, Doug Barton wrote:
>Yep, been there, done that. It was a bad decision then, and it's 
>still a bad decision now. I realize that it's incredibly unpopular 
>to bluntly call bad decisions "bad decisions," but not doing so 
>doesn't make them any less bad. And, to make matters worse,

I am ok if anyone says that it a bad decision.  The thread for the 
discussion started at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html

>The argument in 6686 boils down to, "We made a series of bad 
>decisions, which have led to a bad result. We now want to codify 
>that bad result instead of cleaning up our mess." I don't agree with 
>that in principle, and I don't agree with that in regards to this 
>particular case.

I was the document shepherd for RFC 6686.  There wasn't any comments 
during the Last Call.

>where the thread starts. There is another parallel thread an a 
>related topic around that same time.

I read the messages on that thread around the time they were posted.

>https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html

I also read those messages.

>The topic has been raised numerous times since day 1 of SPF, and the 
>DNS folk who have said "the SPF RRtype should be the first (if not 
>only) choice" have been consistently ignored.

I have to respectfully mention that I read all the messages that were 
posted to the SPFBIS mailing list.  I cannot take into consideration 
comments posted to ietf@ if they are not part of the Last Call.

>But what if all of the previous discussion was wrong? Simply saying 
>"we have discussed this extensively" doesn't refute sound technical 
>arguments either. :)

If all the previous discussions were wrong I hope that the future 
discussions will be right. :-)

>time before it was

You missed 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01440.html :-)

At 17:15 25-04-2013, Doug Barton wrote:
>5. Some fairly persuasive technical arguments from Andrew Sullivan 
>that putting SPF records into your zone is a good idea. Particularly this:

[snip]

>#5 Is also a "reasoned technical argument," which was not only 
>ignored, but twisted on its ear by at least one list member.

The SPFBIS WG Chairs are the persons making the determination for 
discussions within the working group.  I happen to be one of the 
SPFBIS WG co-chairs and the other co-chair is Andrew Sullivan.  I 
didn't ignore his comments.  I didn't ask Andrew Sullivan whether he 
ignored his comments.  If I misunderstood or misinterpreted his 
comments he would likely talk to me about that.  That makes it 
unlikely that any twisting would reach my ears. :-)

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Apr 2013 23:22:39 -0400

> checks for Type SPF first by default."

Mail::SPF is a library.  The way that it makes SPF queries can (now) be 
controlled by the calling application.  I maintain a small Perl application 
that acts as a Postfix policy server for doing SPF checks with Perl.

Mail::SPF was written to be useful as a reference implementation and as a 
result, the author declined, initially to give calling applications the 
ability to control which types where queried for.  This causes problems 
because not all DNS software will answer unknown query types.  As a result, if 
you query for Type SPF first, you'll get a certain fraction of either timeouts 
or SERFVAIL responses while if you query for TXT, you get a response.

It took quite some time to convince him to change it, but he did.  Here's one 
bug report, to serve as an example:

https://bugs.launchpad.net/postfix-policyd-spf-perl/+bug/161133

I report that a piece of software does something is interesting, however the 
fact that doing so causes interoperability problems supports the idea that 
it's a bad idea.  Pushing for Type SPF queries first is only interesting if 
you're interested more in theoretical purism than actual interoperability.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 20:29:14 -0700

On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton <[email-masked]> wrote:

> bad decision now. I realize that it's incredibly unpopular to bluntly call
> bad decisions "bad decisions," but not doing so doesn't make them any less
> bad. And, to make matters worse, not doing so has led to a non-trivial
> number of those bad decisions becoming de facto standards. This has at
> least 2 very bad side effects ... first, we have to live with the bad de
> facto standards; but more importantly we are providing encouragement to
> people who wish to make similar bad decisions down the road.
>
> instead of cleaning up our mess." I don't agree with that in principle, and
> I don't agree with that in regards to this particular case.
>
> Further, while cleaning up the SPF mess would require nothing more than a
> marginal amount of extra work now, plus the passage of time, there is no
> reason not to actually clean up the mess.

I think this continues to trivialize exactly what it means to migrate the
enormous deployed base of SPF in the manner you're pushing. I fully agree
with your premise that it should've been "done right" in the beginning and
I lament that it was not, but I don't agree that fixing this now is worth
moving a mountain, especially when I don't believe the people saying that
here will be among the people doing even a fraction of the moving.

At least half of the reason we landed here is because of an environment
that was basically hostile to doing it right in the first place.  The rules
for getting new RRtypes have been improved -- I think we all agree on that
-- but, as you already conceded, there's still a large deployed base of
faulty firewalls and DNS tools out there that don't exactly make use of
uncommon RRtypes easy.  So how much energy are the DNS experts going to put
into cleaning up their house while demanding the mail people clean up
theirs?  I would even go so far as to say that the DNS part has to happen
first, before any cleanup on the email side is practical to consider.

The deployed SPF base probably won't give a damn if the IETF suddenly
releases an RFC that exclaims "Everybody migrate to type 99!"  From the
perspective of large and small operators around the world, what's out there
is working now, and messing with it is asking for pain; engineers' time to
switch and debug costs a lot of money, so they have no incentive whatsoever
to comply with a proposed change to "fix" a service that is philosophically
broken but operationally just fine.

Thus, I maintain that we take our licks on this one and just take steps to
ensure that nobody follows this path again.

-MSK

---

From: Stuart Gathman <[email-masked]>
Date: Thu, 25 Apr 2013 23:44:22 -0400

> into justifying not fixing the problem, the problem would be fixed by 
Unfortunately, the answer to 2 is no.  There are still too many DNS 
servers out there that "hang" in response to a type 99 (or any other 
unexpected type) query.  The only practical solution is to fire of both 
queries in parallel, and use the first to come back.  But that *doubles* 
the DNS traffic, and I'm sure won't make the DNS people any happier.

Here is something practical that might work:  a "hall of shame" for DNS 
server/firewall vendors that hang on unexpected query types.

When DNS servers actually work, then requiring a check of type 99 first 
makes sense.

There is a chance to "do it right" with v=spf3 (a hypothetical future 
version of SPF - my favorite feature: a HELO mechanism that works like 
PTR but used the HELO name).

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 18:30:43 -0700

Note, I'm going to push back on some of the things you say below, but I 
don't want the main point I'm trying to make to get lost:

1. It's not too late to do the right thing,
2. So we should do that.

Arguing about how we got here is fun and all, but not germane to the 
really important bit.

On 04/25/2013 05:22 PM, S Moonesamy wrote:
>> Yep, been there, done that. It was a bad decision then, and it's still
>> a bad decision now. I realize that it's incredibly unpopular to
>> bluntly call bad decisions "bad decisions," but not doing so doesn't
>> make them any less bad. And, to make matters worse,
>
>> decisions, which have led to a bad result. We now want to codify that
>> bad result instead of cleaning up our mess." I don't agree with that
>> in principle, and I don't agree with that in regards to this
>> particular case.
>

There are only so many times that people can say "this is a bad idea," 
then get ignored, and then have enthusiasm to come back and say the same 
thing again. I didn't follow the pre-publication of 6686, as I had other 
things to do at the time. However the volume of previous discussion over 
the last 8+ years should have been sufficient to render the idea of 
deprecating the SPF RRtype a non-starter. The fact that the draft got 
written in the first place said a lot about the chances of any 
objections being considered.

> comments posted to ietf@ if they are not part of the Last Call.

I have to respectfully point out that a) there is a wider world beyond 
spfbis, and b) the reasoned technical arguments that were presented on 
the list (not to mention the running code) should have been sufficient 
to push the group in the direction of preferring the SPF RRtype with an 
eye toward deprecating TXT in the future.

I don't know why, specifically, that didn't happen; but I also don't care.

What I want to see happen is that we do the right thing now.

> discussions will be right. :-)

Voila! :)

> discussions within the working group.  I happen to be one of the SPFBIS
> WG co-chairs and the other co-chair is Andrew Sullivan.  I didn't ignore
> his comments.  I didn't ask Andrew Sullivan whether he ignored his
> comments.  If I misunderstood or misinterpreted his comments he would
> likely talk to me about that.  That makes it unlikely that any twisting
> would reach my ears. :-)

It wasn't any of your messages I was referring to.

Doug

---

From: David Conrad <[email-masked]>
Date: Fri, 26 Apr 2013 01:05:22 -0500

Murray,

On Apr 25, 2013, at 10:29 PM, "Murray S. Kucherawy" <[email-masked]> wrote:
> I think this continues to trivialize exactly what it means to migrate the enormous deployed base of SPF in the manner you're pushing.

Out of curiosity, what do folks who follow SPF think the current "enormous deployed base" is compared to the future deployed base?

> At least half of the reason we landed here is because of an environment that was basically hostile to doing it right in the first place. 

Well, deprecating the SPF RR will certainly teach the DNSEXT/IESG/IETF community a good lesson.  (Seriously?)

> So how much energy are the DNS experts going to put into cleaning up their house while demanding the mail people clean up theirs? 

So, this is about revenge because it used to be hard to get RRtypes? 

> The deployed SPF base probably won't give a damn if the IETF suddenly releases an RFC that exclaims "Everybody migrate to type 99!" 

Yep.  This gets into projections about the future.  If SPF has topped out, it simply doesn't matter.  If SPF is going to continue to grow, then it probably does matter.

> From the perspective of large and small operators around the world, what's out there is working now, and messing with it is asking for pain; engineers' time to switch and debug costs a lot of money, so they have no incentive whatsoever to comply with a proposed change to "fix" a service that is philosophically broken but operationally just fine.

The point is that it isn't just fine.  It does have operational impacts, from potentially increased fragmentation/fallback to TCP to increased complexity in TXT RR parsers that have to distinguish between the myriad of crap that's residing at the zone apex TXT RR, etc.  Of course, most of these negative impacts are hidden to the folks who are putting the TXT RRs in the zone, so it's all good, right?

> Thus, I maintain that we take our licks on this one and just take steps to ensure that nobody follows this path again.

And how do you propose that exactly, particularly given the precedent set by SPFBIS?

Regards,
-drc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 23:30:13 -0700

On Thu, Apr 25, 2013 at 11:05 PM, David Conrad <[email-masked]> wrote:

> > So how much energy are the DNS experts going to put into cleaning up
> their house while demanding the mail people clean up theirs?
>

Did I really come across as that petty?

No, what I'm saying is that the way things were ten years ago pushed the
SPF community to the place it's in now, ugly as it is.  SPF, in the
interim, has become very widely deployed.  Suddenly now we have a few
voices from the ivory tower asserting that the same community needs to go
out and re-do things the way they should have been done in the first place,
now that we finally have a somewhat more reasonable perspective, even
though some of the vestiges of ten years ago are in fact still around.  My
reaction to that is "You can't be serious."  That doesn't sound like
revenge at all to me, just pragmatism.

> releases an RFC that exclaims "Everybody migrate to type 99!"
>
> Yep.  This gets into projections about the future.  If SPF has topped out,
> it simply doesn't matter.  If SPF is going to continue to grow, then it
> probably does matter.
>

I think it's much closer to the former.

> The point is that it isn't just fine.  It does have operational impacts,
> from potentially increased fragmentation/fallback to TCP to increased
> complexity in TXT RR parsers that have to distinguish between the myriad of
> crap that's residing at the zone apex TXT RR, etc.  Of course, most of
> these negative impacts are hidden to the folks who are putting the TXT RRs
> in the zone, so it's all good, right?
>
> > Thus, I maintain that we take our licks on this one and just take steps
> to ensure that nobody follows this path again.
>

Someone else (Joe, I think) has already referred to other RFCs that talk
about things like IAB advice about how [not] to put application data into
the DNS.  Seems to me this is a perfectly good subject for another such
project.  One may counter that by saying nobody will pay attention to such
a document, but I submit that it's our primary mechanism for making sure
mistakes aren't re-made, so that's the tool we have to use or not use.

If we do the opposite and somehow compel SPFBIS to favour type 99 over TXT,
then I still think we'll be shouting that to an audience that will think
we're nuts and simply go about their business.

-MSK

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 26 Apr 2013 09:44:14 +0200

> you're interested more in theoretical purism than actual interoperability.

Tl;dr: "Overloading TXT is bad, lets fix this mess once and for all"

1. Parsing TXT records and keeping a lookout for various almost SPF
(but not) data (which is legal in TXT) is hard. In the way open-ended
text parsing is. Lots of security holes in that problem vector. It makes
sense to remove this scenario as much as possible.

2. Writing code to do the equivalent of: 

if (exists SPF record) {
	parse and return verdict; 
   } else if ( exists TXT record ) {
	parse and return verdict; 
   } else { 
	return no data
}

...is not very hard. Of course, we'll enter the open-ended parser quite
often today, with this code, but given that That Vendor Which I'll Not
Name gets its act together, that frequency will decrease. All the way,
we'll maintain interoperability. Automatically. And this is if not pure
(not doing TXT from the start would be pure, I'm trying to stop the silt
from clogging the drain here, so purity is long gone.) at least the proper
way to clean up a mess.

3. As a DNS operator (and also running mail gw for employer and myself)
I look at the SPF problem like this:

3a. Having to query twice (in the case of ask-for-SPF-first-and-then-TXT)
is something that is -- to me -- bearable, more so since this is something
that our friend the Computer can do automatically. Moore's law will make
this less of a problem in the future, as code gets corrected. Also, think 
of caching. Sensible TTL will -- providing full-service resolvers are
implemented to make use of caching -- in practice remove the expensive
part of double-querying, at least where this could be a problem, in
heavily loaded mail gateways.

3b. Not all uses of TXT records are automated. Having structured data
in TXT records messes up my manual parsing of other TXT records that
may exist on the same node. (or dig zone.tld. axfr | grep TXT)
This usage does not benefit from the capacity increase according to Moore.

4. Having thus established that TXT overloading is bad, in this
specific case, we must turn to the general case. In the general case,
TXT overloading is bad. Why? Simply, because the above discussion applies
to all those cases as well. (Ok, lots of handwaving here, but I'm right.)

5. Then with the conclusion that TXT overloading is bad, we can turn
to the setting of a precedent. Which this discussion actually is all
about; the presence of TXT records with alleged meaning and some syntax
is undisputed. We already are are in damage-control mode here. Setting
the precedent that caving in and ignoring the bad effects of overloading
TXT because of reasons of defaitism is not how the IETF should do this.

So: I oppose the publication of any text deprecating a specific RR type
in favour of overloading a generic free-form RR. Because overloading
TXT is bad.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... I think I'd better go back to my DESK and toy with a few common
MISAPPREHENSIONS ...

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Apr 2013 16:52:21 +1000

> here will be among the people doing even a fraction of the moving.

The installed base of SPF is miniscule.  As for moving it, you
really only need to update a couple MTA's to use the SPF libraries
that look for SPF first and let time pass.

If you want a hurry on one could add code to nameservers and zone
signers to detected TXT style spf records and add SPF records if
they are missing.

> for getting new RRtypes have been improved --

The rules were dead simple at the time, just nobody in the SPF camp
was willing to try to go down that route.  I know they were simple
because I used them at the time for another type.

> I think we all agree on that

The DNS had deployed support for UNKNOWN RR types at the time.  Most
resolvers have been able to lookup unknown types since RFC 1034 was
published.  For most resolvers it was simply a matter of using 99
rather than a symbolic name.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Fri, 26 Apr 2013 01:28:14 -0700

Hi Doug,
At 18:30 25-04-2013, Doug Barton wrote:
>Note, I'm going to push back on some of the things you say below, 
>but I don't want the main point I'm trying to make to get lost:
>

I'll comment below.

>There are only so many times that people can say "this is a bad 
>idea," then get ignored, and then have enthusiasm to come back and 
>say the same thing again. I didn't follow the

Ok.

>  pre-publication of 6686, as I had other things to do at the time. 
> However the volume of previous discussion over the last 8+ years 
> should have been sufficient to render the idea of deprecating the 
> SPF RRtype a non-starter. The fact that the draft got written in 
> the first place said a lot about the chances of any objections 
> being considered.

When the work started nobody knew what to do.  The following comment 
was made around a year ago:

   "the IESG would simply like to see the SPF *and* Sender-ID 
experiments wrapped
    up, and presumes that the charter is correct and the outcome of 
the experiment
    leads one to conclude that SPF should get advanced to Proposed Standard and
    Sender-ID should not".

In easy terms, it would be good to have a conclusion to those 
experiments.  There was an assumption, i.e. SPF would get 
advanced.  My guess (not technically sound) was that there was a 
higher chance of that happening (e.g. see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html 
).  There is a short discussion predating Issue #9 
(see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00329.html 
).  Philip Gladstone provided some data (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00354.html 
).  Issue #9 was opened based on the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00361.html 
draft-kucherawy-spfbis-experiment was posted after that (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00405.html 
).  There were comments mentioning the ietf@ discussion ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00789.html ).

Anyway, the working group decision about the protocol aspect was made 
based on the analysis.  The question of whether to obsolete the SPF 
RRTYPE or not is an administrative issue.  That is why it is in the 
IANA Considerations Section of draft-ietf-spfbis-4408bis-14.  I am ok 
with whatever the IETF decides about that.

There are several intermingled issues.  If I understood correctly the 
main issue is which DNS RR to use to publish SPF information in the 
DNS.  I suggest discussing about that during the Last Call for 
draft-ietf-spfbis-4408bis.

>I have to respectfully point out that a) there is a wider world 
>beyond spfbis, and b) the reasoned technical arguments that were 
>presented on the list (not to mention the running code) should have 
>been sufficient to push the group in the direction of preferring the 
>SPF RRtype with an eye toward deprecating TXT in the future.

I am aware of that. :-)  There isn't much I can do about it.  My task 
was to give due consideration to all the arguments that were 
presented on this mailing list.  Technical arguments are obviously 
more compelling.

If there are any new arguments which have been missed please let me 
know as I can include them in my write-up.  If the argument is solely 
"do the right thing" I will decline including it in the write-up as 
it is, in my individual opinion, non-technical.  I cannot comment on 
what arguments should be provided as I will then be biasing the outcome.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 08:48:40 -0400

> we're nuts and simply go about their business.

I think it's also important to reflect on the interoperability issue that led 
us to seriously consider removing type SPF.  In RFC 4408 you can publish 
either SPF or TXT and you can check either SPF or TXT and be compliant with 
the spec.  There is no common format that is required to publish/check so it's 
possible based on just reading the document for some people to decide to check 
only one type and for publishers to only publish the other resulting in NO 
interoperability.

The first step then was to consider this issue and conclude that specifying one 
of the two as mandatory to publish/check was essential for interoperability.  
The second step what to decide which.  Looking at the deployed base it didn't 
take a great stretch to realize that trying to order the whole internet to 
change to type SPF was silly and that TXT was the only thing that made sense.  
The third step then was to consider if there was any point in maintaining 
duplicate data and doing duplicate checks for something that is known to 
(still) be problematic for interoperation and has effectively no deployment.  
We concluded it didn't.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 09:02:21 -0400

On Friday, April 26, 2013 04:52:21 PM Mark Andrews wrote:
> In message <CAL0qLwYzKnfRArQAVD1M=ccnV079j-D9PHDaB-
[email-masked]>, "Murray S. Kucherawy" writes:
> > > call
> > > and
> > > a

If you look at the data in RFC 6686 it's 40 - 60% of domains being used for 
email.  What does it take to be non-miniscule from your perspective?

As for looking for SPF first, been there, done that.  Doesn't work in the real 
world.  Go fix all the broken DNS implementations and firewalls, provide some 
evidence to support your case and then there might be a basis for discussion.

> signers to detected TXT style spf records and add SPF records if

Scripts to add SPF records if a TXT type SPF record is present in a zone have 
existed since roughly a week after type 99 was assigned to SPF.

> because I used them at the time for another type.

Getting the type assignment was only the smallest part of the problem.  We had 
a huge thread on this on the IETF main list last year.  "I can hand edit a 
BIND zone file and do it" gets you about 1% of the way to deployment.

See if you can spot the fallacy in "I'm one of the world's foremost experts on 
DNS and it's easy for me, therefore it's easy for everyone"?

> rather than a symbolic name.

Yes.  And there was library code to do this a week after type 99 was assigned.  
There were, in fact, a number of AUTH48 changes to the draft that became RFC 
4408 because we were finally able to test using a real second RR type rather 
than just have a paper design.  The SPF community jumped on the type 99 
support bandwagon and most SPF libraries have had support for it for a LONG 
time.

None of that helped deployment at all and there's no evidence that it's going 
to change.  Ever.

> > ensure that nobody follows this path again.

Since there wasn't the same screaming about DKIM, I wonder if this issue is 
really about the RR type at all or if it's really about the design decision on 
where to place the record?  It seems that SPF is not being penalized in some 
form for having gone to the trouble of getting the type assignment and giving 
it a go.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 09:04:23 -0400

On Friday, April 26, 2013 09:44:14 AM Måns Nilsson wrote:
> Subject: Re: [spfbis] [dnsext]   Obsoleting SPF RRTYPE Date: Thu, Apr 25, 
2013 at 11:22:39PM -0400 Quoting Scott Kitterman ([email-masked]):
> > because not all DNS software will answer unknown query types.  As a
> > result, if you query for Type SPF first, you'll get a certain fraction of
> > either timeouts or SERFVAIL responses while if you query for TXT, you get
> > a response.
> > 
> > It took quite some time to convince him to change it, but he did.  Here's
> > one bug report, to serve as an example:
> > 
> > I report that a piece of software does something is interesting, however
> > the fact that doing so causes interoperability problems supports the idea
> > that it's a bad idea.  Pushing for Type SPF queries first is only
> > interesting if you're interested more in theoretical purism than actual
> > interoperability.

My interpretation of this is "I have this theory that it should be easy, so we 
should do it, don't confuse me with facts."

Scott K

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 13:41:33 +0000

[This is really long, because I've spent a lot of time thinking about this and reading the discussion; the tl;dr is that I don't intend to contest the obsoleting of the SPF RRtype any further, but <ad hat off>would not fault others for doing so</>, and <ad hat on>I think there are lessons to be learned about how the process went this time</>, which, if you are interested in that, might be a good reason to continue reading.]

On Apr 25, 2013, at 8:22 PM, S Moonesamy <[email-masked]> wrote:
> I am ok if anyone says that it a bad decision.  The thread for the discussion started at http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html

<no hat>

I undertook the exercise of reading this thread, and it looks like there was some very interesting data collection work done.   I didn't find a point at which a consensus was determined; I presume that happened later, on some other thread.

> I was the document shepherd for RFC 6686.  There wasn't any comments during the Last Call.

FWIW, and I do not intend this as a criticism of what you did, I just went back to the datatracker and looked at the text of the IETF last call.   There is nothing at all in this text that would indicate that the document said anything at all about the continued use of the SPF DNS RRtype.   I've also read the document, and even reading the conclusion of the document, there's very little there that would suggest to me that the spfbis working group was about to deprecate the use of the SPF DNS RRtype.

Of course someone who was already involved in the discussion on the mailing list would know this, but there's no reason to think that anyone reading the dnsext mailing list would have felt it was their duty to review this particular document during the IETF last call, and if they had reviewed it, they might still have remained innocent of any understanding that spfbis intended to deprecate the SPF RRtype in favor of the TXT record.

> If there are any new arguments which have been missed please let me know as I can include them in my write-up.  If the argument is solely "do the right thing" I will decline including it in the write-up as it is, in my individual opinion, non-technical.  I cannot comment on what arguments should be provided as I will then be biasing the outcome.

<still no hat>
It seems to me that the argument in favor of deprecating SPF is that nobody is publishing SPF records, despite widespread support in software.   This results in unnecessary traffic, the elimination of which would have minimal impact.

On the other side, here are the arguments that I understand to have been made:

1. TXT records are not specific to SPF, thus we can't assume that any given TXT record is an SPF record.
Rejoinder: doesn't seem to be an issue in practice—no other TXT records are needed on the names to which SPF TXT records are typically attached.

2. Because TXT records aren't specific to SPF, a query for TXT records may return an unexpectedly large result set, requiring fallback to TCP.
Rejoinder: doesn't seem to be an issue in practice.

3. Using TXT records is a bad idea.
Rejoinder: this isn't really a technical argument; if there is a technical argument in here, it should be stated explicitly, but this argument per se will be ignored.

4. Using TXT records sets a bad precedent.
Rejoinder: the horse is already out of the barn.

I think there's one possible benefit to be considered for using TXT records for SPF: it gets in the way of other uses of TXT records, and acts as a sound technical argument against adoption of TXT records on bare names in future protocols.

Speaking entirely with my AD hat off, and merely as an armchair quarterback, I don't think it's fair to say that the consensus call in spfbis on what was to become RFC6686 and the IETF consensus call on that document, taken together, represent IETF consensus.   I don't think the rejoinders to arguments 1 and 2 are very convincing, although they seem to have carried the day in the spfbis working group, and I understand why.

The reason I reacted the way I did when drc brought this up is that it was a surprise to me that spfbis was eliminating the SPF record from the specification.   It is not surprising that it was a surprise—the process that was followed, which I think was followed correctly and with the best intentions, did not really have much chance of bringing this decision to my attention while it was being discussed in spfbis.

Having reviewed the discussion in spfbis, and argued with this at length with Pete, I am remarkably ambivalent about it.   I don't like the decision the spfbis working group has made.  I don't agree with the decision.  I understand why you made it, and don't fault you for having made it.   It's probably not worth my personal time to dispute it.

I would rather work to hasten the demise of SMTP and all the anti-spam kludges that rode in on it.

<ad hat on>
So, what do I think could have gone better here?   First, it would have been very helpful if the abstract for RFC 6686 had said that the reason the research was being done was to answer the question "should we continue supporting the SPF RRtype, or drop it?"   Authors of drafts that are trying to address issues like this might want to think carefully about how they write abstracts, since it's only the abstract that gets shown in the IETF last call message.   If your abstract doesn't attract the people who ought to be reading the document, it's going to be hard later to argue that the document had a clear IETF consensus, even though it nominally has consensus.

It may be that using the document abstract in the last call announcement is not sufficient—if authors phrased the abstract the way I've suggested, it might be the wrong thing for the document once it's published.   I don't know the answer to this—it might also be the right thing.

I think it's clear that early in this discussion, all present, including the responsible AD, were aware that it was going to be contentious.   I think if a message like the one drc sent to the mailing list yesterday had gone out in February of 2012, you would have gotten the exact same response.   This probably would have created additional hassle on the spfbis mailing list as a bunch of dnsext people dogpiled there, but we wouldn't be having _this_ conversation _now_, so it actually would have been better, despite the short-term hassle.

Andrew did raise this issue to the dnsop working group; he didn't mention raising it on dnsext.   I don't remember seeing it on the dnsop mailing list, and I'm not finding it in the archive; I don't see it in the minutes either.   This doesn't mean it isn't there; it just means that it didn't stand out the way drc's message did.   This ought to be a valuable lesson for working group chairs; if you know something is going to be contentious, rip the bandaid off—don't be quiet about it.   Make sure the people who you know are going to kick up a fuss do it at the right time.   I know Andrew didn't intend to not rip off this bandaid, so I'm not sure how this failed to happen, but it's something to think about.

The responsible AD also knew this was going to be contentious (I think!).   I don't know if he talked this over with Ralph (who was then the responsible AD for dnsext) or not.   If he did, that was the right thing to do, and it's worth considering why it didn't work.   If he didn't, this might be a lesson to remember for the future.   Same thing should have happened with the responsible AD for dnsop; I don't know who that was.

Of course, ADs don't always know that what's being raised in the working group is going to be contentious in other areas.   Working group chairs need to be proactive about this.   ADs can definitely be a resource in spreading the word, though, whether they do it on their own or at the request of working group chairs.   And of course working group chairs may not always know that something will be contentious, but there's nothing we can do about that case other than live with the late surprise.
</hat>

I hasten to emphasize that I don't really know what went wrong here.   It may be that even if all the remedies I've discussed above had happened, we'd still be having a big kerfuffle about this on the dnsext mailing list.   My motivation for suggesting that more could have been done is simply my experience as a participant: I really think I would have participated in the discussion about this if I'd realized it was happening last February.  I get the impression from several other participants in the discussion now that they weren't aware of it either.   I don't have a sense of whether the discussion would have come out differently if we'd participated.

<hat>
As for how to participate now, the right thing to do for people who feel they were left out of the discussion before is to read the draft, read the historical discussion (to which pointers have already been given) and then participate constructively on the spfbis working group mailing list.

"Tromping" on this in IETF last call would not be constructive given that it has not passed a working group last call.  I'm sorry for having suggested that—I understood the document to have already passed WGLC, and stupidly didn't go check to see if my impression was correct.
</hat>

And, by the way, internet dating is quite a lucrative industry, so it's probably a bad example of a hopeless task.   :)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 14:00:58 +0000

> Speaking entirely with my AD hat off, and merely as an armchair quarterback, I don't think it's fair to say that the consensus call in spfbis on what was to become RFC6686 and the IETF consensus ca…

Argh.   I can't say anything right, apparently.   What I mean here is that the consensus call in the working group and the subsequent consensus call on the IETF mailing list do not mean that the IETF definitely has consensus to deprecate the SPF RRtype.   They do mean that the IETF had consensus to publish the document.   Sorry for putting that so badly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Apr 2013 07:52:29 -0700

On Fri, Apr 26, 2013 at 6:41 AM, Ted Lemon <[email-masked]> wrote:

> FWIW, and I do not intend this as a criticism of what you did, I just went
> back to the datatracker and looked at the text of the IETF last call.
> There is nothing at all in this text that would indicate that the document
> said anything at all about the continued use of the SPF DNS RRtype.   I've
> also read the document, and even reading the conclusion of the document,
> there's very little there that would suggest to me that the spfbis working
> group was about to deprecate the use of the SPF DNS RRtype.
>

RFC6686 never set out to make a conclusion about the RRtype question, but
rather to determine which of the four protocols MARID discussed appear to
have enough traction to warrant advancement along the standards track, thus
concluding "the experiment".  Accordingly, the abstract for that document
doesn't say anything about this matter.

In the process of collecting data to answer that question, we realized that
the numbers also highlight the non-use of type 99 by both senders and
receivers.  We were very careful in our wording of RFC6686 to point out
that type 99, though supported both in protocol and software, is actually
not very useful, and said nothing at all about what we planned to do with
it.  RFC6686 provides supporting evidence for what the main spfbis draft is
doing, but does not itself introduce those actions.

I don't think there was process breakage here.

>
> It seems to me that the argument in favor of deprecating SPF is that
> nobody is publishing SPF records, despite widespread support in software.
> This results in unnecessary traffic, the elimination of which would have
> minimal impact.
>

That's not the complete argument I and others have been making.  Widespread
support in DNS software and SPF libraries exists, but there are also
existing components of the infrastructure that interfere with either
publication or handling of type 99 queries and replies, long after the type
was assigned.  RFC6686 calls this out.  The rejoinder we're hearing to this
is merely the gainsay of that position despite both anecdotal and empirical
evidence to the contrary.

On the other side, here are the arguments that I understand to have been
> made:
> Rejoinder: doesn't seem to be an issue in practice—no other TXT records
> are needed on the names to which SPF TXT records are typically attached.
>

Moreover, parsing TXT records is not hard, nor is answering the question
"Does this one start with the string 'v=spf1'?".  We saw one case in our
survey of a zone that had 37 TXT records at the same query point; SPF code
is able to pull out the applicable one just fine.

>
> 2. Because TXT records aren't specific to SPF, a query for TXT records may
> return an unexpectedly large result set, requiring fallback to TCP.

That's not correct; there are still packet filters out there configured by
default to disallow TCP over port 53.  We discovered this during the
RFC6686 surveys.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 11:09:17 -0400

> default to disallow TCP over port 53.  We discovered this during the

And, in the event a domain needs enough other TXT data that an SPF record 
would cause it to spill over into TCP, it's trivially solvable.  For 
example.com:

example.com.     3600    IN      TXT     "v=spf1 redirect=_spf.example.com"
_spf.example.com. 3600   IN      TXT     "v=spf1 [record content] -all"

It needn't ever be more impact than that.

Scott K

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 15:13:16 +0000

On Apr 26, 2013, at 10:52 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:
RFC6686 never set out to make a conclusion about the RRtype question, but rather to determine which of the four protocols MARID discussed appear to have enough traction to warrant advancement along the standards track, thus concluding "the experiment".  Accordingly, the abstract for that document doesn't say anything about this matter.

In the process of collecting data to answer that question, we realized that the numbers also highlight the non-use of type 99 by both senders and receivers.  We were very careful in our wording of RFC6686 to point out that type 99, though supported both in protocol and software, is actually not very useful, and said nothing at all about what we planned to do with it.  RFC6686 provides supporting evidence for what the main spfbis draft is doing, but does not itself introduce those actions.

Okay, fair enough.   Please do note that I didn't say that there was process breakage—I said the process seemed to have been followed correctly, but produced a less than perfect outcome.

The sense in which I mean that with respect to RFC 6686 is that several people have mentioned the IETF last call on RFC 6686 as if it means that the IETF now has an opinion on whether to deprecate SPF.   It sounds like we both agree that it does not, so this wouldn't be an example of process breakage.   However, if people came to the conclusion that it did mean that, it's worth talking about.

That's not the complete argument I and others have been making.  Widespread support in DNS software and SPF libraries exists, but there are also existing components of the infrastructure that interfere with either publication or handling of type 99 queries and replies, long after the type was assigned.  RFC6686 calls this out.  The rejoinder we're hearing to this is merely the gainsay of that position despite both anecdotal and empirical evidence to the contrary.

OK.   But presumably these parts of the internet are going to start really seriously breaking as IPv6 and DNSSEC deployment increase.   So this doesn't _seem_ like a long-term concern.   What am I missing?

Moreover, parsing TXT records is not hard, nor is answering the question "Does this one start with the string 'v=spf1'?".

Sure, and a base-64 encoded string will never have an equals sign in that position, so we don't have to worry too much about a random collision.

  We saw one case in our survey of a zone that had 37 TXT records at the same query point; SPF code is able to pull out the applicable one just fine.

That's not correct; there are still packet filters out there configured by default to disallow TCP over port 53.  We discovered this during the RFC6686 surveys.

These two points taken together seem like a pretty strong argument in favor of _not_ deprecating the SPF record; in this case, only the SPF record would have made it back to the MTA.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 26 Apr 2013 08:02:58 -0700

> That's not correct; there are still packet filters out there configured by default to disallow TCP over port 53.  We discovered this during the RFC6686 surveys.

This is pretty rare but not nonexistent.

If anyone cares, we have some names that test resolver->authority path for truncation, and client->resolver path for proper truncation support.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 15:32:00 +0000

On Apr 26, 2013, at 11:16 AM, Nicholas Weaver <[email-masked]> wrote:
> IF the string is random, thats a 1 in 2^36 chance.  Yawn.
> 
> And if the string is "malicious" and deliberately constructed to be a bad record starting with v=spf1, it only screws up the domain owner's SPF record, so who gives a flying fig?  The domain owner can correct it, be done with it, and move on.

Right.

> If you want DNSSEC, you got to fix THAT problem anyway.

This is a non-sequitur.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Apr 2013 01:38:14 +1000

> only one type and for publishers to only publish the other resulting in NO 

   An SPF-compliant domain name SHOULD have SPF records of both RR
   types.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Now if your nameserver doesn't support type SPF that is a good
reason not to publish it but otherwise I can't think of a reason
that meets SHOULD for not publishing type SPF if you are publishing
TXT spf record.

As for publishing a SPF record without a TXT record.  That is the
expected end state but it was still a while off and would be a
judgement call for as to when to do this as it will result in some
additional blow back / forged mail getting through.

This is similar as to when one decided to go MX only for email and
not supply fallback A records.  A similar decision about when to
stop adverting A records and just rely on AAAA records is also in
the future.

As for looking up SPF and not falling back to TXT when it is not
available is just a broken implementation.  Similarly if you only
look up TXT you are not conforment and will at some point not
interoperate with those that choose to only publish SPF records.

So as far as I can see the entire interop arguement was a load of
garbage.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 26 Apr 2013 08:16:55 -0700

> Sure, and a base-64 encoded string will never have an equals sign in that position, so we don't have to worry too much about a random collision.

Yeah, we don't.

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Apr 2013 11:55:19 -0400

+1

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Apr 2013 02:39:07 +1000

> email.  What does it take to be non-miniscule from your perspective?

It is still miniscule compared to the number of email domains that
will exist in 10 years time.

> evidence to support your case and then there might be a basis for discussion.

We have nameservers that support type SPF (Feb 2007), we have
resolvers that support type SPF (1980), we have registrars that
support type SPF, we have spf libraries that support type SPF (Oct
2008).

As for fixing firewalls that can be done.  We bitched to the vendors
about EDNS, we bitched to the vendors about DNSSEC.  Their new code
is both EDNS and DNSSEC aware.

> existed since roughly a week after type 99 was assigned to SPF.

Script != nameserver. 
 
> BIND zone file and do it" gets you about 1% of the way to deployment.

As for hand editing a zone file, I haven't done that in ages except
for writing test code.  I use nsupdate to update the master server
on another machine (signed with TSIG for authentication) which may
or may not know the details of the type of the record I am updating.
The slave servers all support unknown records since 2003 so I can
add any new type I care about without having to worry about whether
they have been upgraded to know about the new type.

If I'm using a machine which doesn't have a nsupdate that doesn't
know about type SPF I can fallback to unknown.

I could also write a custom tool that uses the existing libraries
on the system to add new record types if I didn't want to use
nsupdate.

Note none of this was beyond the capabilities of the people who
wrote libspf or libspf2 and integrated these into the MTA.

Adding support to return the SPF record in unknown format wasn't
beyound the capabilities of the web developers that wrote tools to
construct SPF records.

> DNS and it's easy for me, therefore it's easy for everyone"?

Adding new types to the dns library is relatively easy for anyone
with a little knowledge of C.  We get the occasional submission of
new records types with requests to add them.  Once they are added
to the library they are available to all the applications that want
to use them.

> None of that helped deployment at all and there's no evidence that it's going 

Except for the fact that type SPF support still continues to increase.
 
> form for having gone to the trouble of getting the type assignment and giving 

Well DKIM used namespace to make its lookups unique.  As for giving
the new type a go, no you really didn't.  Type SPF support was about
where any DNS person would have expected it to be.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Apr 2013 12:46:07 -0400

Mark,

No hat.

> Except for the fact that type SPF support still continues to increase.

You assert this, but I don't see the evidence you're presenting.  I
would encourage you to read the archives to see the discussion of the
evidence the participants in this working group _did_ collect.  It
didn't support your claim.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Fri, 26 Apr 2013 12:53:28 -0400

> FWIW, and I do not intend this as a criticism of what you did, I just went back
> to the datatracker and looked at the text of the IETF last call.   There is nothing
> at all in this text that would indicate that the document said anything at all about
> the continued use of the SPF DNS RRtype.   I've also read the document, and
> even reading the conclusion of the document, there's very little there that would
> suggest to me that the spfbis working group was about to deprecate the use of
> the SPF DNS RRtype.

As Murray's already responded, the intent of the document that became
RFC 6686 was simply to report on the SPF/Sender-ID experiment.  That
document never meant to recommend a specific course, and didn't -- so
any cross-area review of that document wouldn't have been likely to
raise this discussion, and no text in that document relating to this
issue would have been appropriate.

That said, there is a general need for chairs, shepherds, and
responsible ADs to be aware of these sorts of things.
Chairs/shepherds need to make sure something about them gets put into
shepherd writeups, at least, and ideally gets sent out to relevant
lists earlier.  Best I can tell, there *was* a discussion of this
earlier, but it didn't get this level of attention.

It would also be good for ADs to put things into the last call
notices, pointing out things that participants in other areas might
want to look at.  We don't have a habit of doing that, and we should.
Even something like, "This specification involves aspects of
[technology X] and [technology Y]; experts in those technologies
should pay particular attention and provide reviews and comments,"
might make a big difference.

> Rejoinder: doesn't seem to be an issue in practice—no other TXT records are
> needed on the names to which SPF TXT records are typically attached.

Right: the underscore-prefix technique has been vetted before, and as
far as I can tell this issue and its variants are settled.

> Rejoinder: this isn't really a technical argument; if there is a technical argument
> in here, it should be stated explicitly, but this argument per se will be ignored.

Actually, I don't agree that it's not a technical argument.  The
second part of that sentence is operative, and I want to drill down on
that: if there's a technical argument in here, let's tease out what it
is.

We really have two issues that really seem to matter here:

1. Should we be working on a transition to type=99 only, rather than
deprecating type=99?

2. Claim (quoting Måns here): overloading TXT is bad.

(1) is being adequately argued back and forth; I want to focus on (2):

Why, specifically, is it bad to use TXT records in an "_spf."
subdomain for this purpose?  What harm does it cause, specifically.
Let's bring that out clearly, and have that part of the discussion,
realizing that some possible arguments already have answers:

- It's not hard to parse these; there are many parsers out there that
work, and there are many text-based protocols that work.

- The "_spf." subdomain eliminates the issue of multi-use collisions
-- DKIM queries, for example, will go to "_dkim." subdomains, and
won't see SPF records in the responses.

What other issues does the use of TXT records in this context cause,
which would make it clear that migration away from them in SPF is
important to avoid damage to the Internet, or at least to the DNS
system?

Barry

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Apr 2013 03:08:56 +1000

In message <[email-masked]>, Barry Leiba writes:
> > FWIW, and I do not intend this as a criticism of what you did, I just wen=
> t back
> > to the datatracker and looked at the text of the IETF last call.   There =
> is nothing
> > at all in this text that would indicate that the document said anything a=
> t all about
> > the continued use of the SPF DNS RRtype.   I've also read the document, a=
> nd
> > even reading the conclusion of the document, there's very little there th=
> at would
> > suggest to me that the spfbis working group was about to deprecate the us=
> e of
> > the SPF DNS RRtype.
> 
> > On the other side, here are the arguments that I understand to have been =
> made:
> >
> > 1. TXT records are not specific to SPF, thus we can't assume that any giv=
> en TXT
> > record is an SPF record.
> >
> > Rejoinder: doesn't seem to be an issue in practice=97no other TXT records=
>  are
> > Rejoinder: this isn't really a technical argument; if there is a technica=
> l argument
> > in here, it should be stated explicitly, but this argument per se will be=
>  ignored.
> 
> 1. Should we be working on a transition to type=3D99 only, rather than
> deprecating type=3D99?
> 
> 2. Claim (quoting M=E5ns here): overloading TXT is bad.
> 

Wrong question.  The correct question is "is the use of _spf bad?".

Using a prefix constrains where the solution can be used.  It won't
work with wildcards.  It won't work for all domains.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 26 Apr 2013 10:09:49 -0700

Hi Ted,
At 06:41 26-04-2013, Ted Lemon wrote:
>[This is really long, because I've spent a lot 
>of time thinking about this and reading the 
>discussion; the tl;dr is that I don't intend to 
>contest the obsoleting of the SPF RRtype any 
>further, but <ad hat off>would not fault others 
>for doing so</>, and <ad hat on>I think there 
>are lessons to be learned about how the process 
>went this time</>, which, if you are interested 
>in that, might be a good reason to continue reading.]

I'll comment nelow.

>I undertook the exercise of reading this thread, 
>and it looks like there was some very 
>interesting data collection work done.   I 
>didn't find a point at which a consensus was 
>determined; I presume that happened later, on some other thread.

There are actually several threads about the 
issue of which RRTYPE to use.  The discussions 
also occurred on unrelated threads.  There was an 
intermediate conclusion (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00594.html 
) which was followed by an objection (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00658.html 
).  The SPFBIS WG Chairs posted a message after 
that ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00692.html 
) which I'll quote partially:

   "There appears to be a wide variety of opinion about Issue #9. Moreover,
    the discussion has revealed an 
interoperability concern in the existing RFC."

There was the IETF 83 session (see Item C in the 
minutes) after that where the SPFBIS Chairs stated the following:

   "The conclusion reached by the Chair was that the document will
    say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99."

For what it is worth I edited the minutes by 
listening to the audio recording.  Two drafts of 
the minutes were posted to the SPFBIS mailing 
list (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01369.html 
and 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01419.html 
).  As there wasn't any objection I considered the issue as resolved.

>FWIW, and I do not intend this as a criticism of 
>what you did, I just went back to the 
>datatracker and looked at the text of the IETF 
>last call.   There is nothing at all in

Let's not worry about that and focus on understanding what happened. :-)

>  this text that would indicate that the 
> document said anything at all about the 
> continued use of the SPF DNS RRtype.   I've 
> also read the document, and even reading the 
> conclusion of the document, there's very little 
> there that would suggest to me that the spfbis 
> working group was about to deprecate the use of the SPF DNS RRtype.

Here's an extract from the write-up:

  "The discussions about the RRTYPE 99 DNS Resource Record were controversial.
   The issue was resolved.  There was consensus that Sender ID re-use of
   SPF DNS Resource Records does not have to be called out in the document."

I'll highlight one of the points from Section 6 of RFC 6686:

  "2.  The absence of significant adoption of the RRTYPE 99 DNS Resource
        Record suggests that it has not attracted enough support to be
        useful."

There is some background information about the 
RRTYPE in Appendix A of RFC 6686.

I agree that the document or even the write-up 
may not be clear.  I left it to Pete Resnick to 
translate for the IESG. :-)  I'll describe the 
working group climate as unfriendly.  It was 
surprising that was even consensus.

>Of course someone who was already involved in 
>the discussion on the mailing list would know 
>this, but there's no reason to think that anyone 
>reading the dnsext mailing list would have felt 
>it was their duty to review this particular 
>document during the IETF last call, and if they 
>had reviewed it, they might still have remained 
>innocent of any understanding that spfbis 
>intended to deprecate the SPF RRtype in favor of the TXT record.

I expected some people from DNSEXT to raise an 
issue during the Last Call.  There was some text 
in it which was like asking for trouble.  I'll 
refrain from commenting about DNSEXT reviews.

>It seems to me that the argument in favor of 
>deprecating SPF is that nobody is publishing SPF 
>records, despite widespread support in 
>software.   This results in unnecessary traffic, 
>the elimination of which would have minimal impact.

Yes.

>1. TXT records are not specific to SPF, thus we 
>can't assume that any given TXT record is an SPF record.
>Rejoinder: doesn't seem to be an issue in 
>practice—no other TXT records are needed on the 
>names to which SPF TXT records are typically attached.

Yes.

>2. Because TXT records aren't specific to SPF, a 
>query for TXT records may return an unexpectedly 
>large result set, requiring fallback to TCP.

Yes.

>Rejoinder: this isn't really a technical 
>argument; if there is a technical argument in 
>here, it should be stated explicitly, but this argument per se will be ignored.

Probably. :-)

>Rejoinder: the horse is already out of the barn.

I don't know about this one.

>Speaking entirely with my AD hat off, and merely 
>as an armchair quarterback, I don't think it's 
>fair to say that the consensus call in spfbis on 
>what was to become RFC6686 and the IETF 
>consensus call on that document, taken together, 
>represent IETF consensus.   I don't think the 
>rejoinders to arguments 1 and 2 are very 
>convincing, although they seem to have carried 
>the day in the spfbis working group, and I understand why.

It's debatable.  I would have to read the 
detailed arguments to form an opinion.

>Having reviewed the discussion in spfbis, and 
>argued with this at length with Pete, I am 
>remarkably ambivalent about it.   I don't like 
>the decision the spfbis working group has 
>made.  I don't agree with the decision.  I 
>understand why you made it, and don't fault you 
>for having made it.   It's probably not worth my personal time to dispute it.

At the end of the day a decision has to be 
taken.  It may not be the right decision.  There 
are safeguards in the process if that is the 
case.  I don't mind if anyone disputes the 
decision.  There has been an appeal (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html 
).  It's part of the work.

>I would rather work to hasten the demise of SMTP 
>and all the anti-spam kludges that rode in on it.

:-)

><ad hat on>
>So, what do I think could have gone better 
>here?   First, it would have been very helpful 
>if the abstract for RFC 6686 had said that the 
>reason the research was being done was to answer 
>the question "should we continue supporting the 
>SPF RRtype, or drop it?"   Authors of drafts 
>that are trying to address issues like this 
>might want to think carefully about how they 
>write abstracts, since it's only the abstract 
>that gets shown in the IETF last call 
>message.   If your abstract doesn't attract the 
>people who ought to be reading the document, 
>it's going to be hard later to argue that the 
>document had a clear IETF consensus, even though it nominally has consensus.

That sounds like a good idea.

>It may be that using the document abstract in 
>the last call announcement is not sufficient—if 
>authors phrased the abstract the way I've 
>suggested, it might be the wrong thing for the 
>document once it's published.   I don't know the 
>answer to this—it might also be the right thing.

In the write-up I am supposed to mention whether 
a draft requires review from a particular or from broader perspective.

>I think it's clear that early in this 
>discussion, all present, including the 
>responsible AD, were aware that it was going to 
>be contentious.   I think if a message like the 
>one drc sent to the mailing list yesterday had 
>gone out in February of 2012, you would have 
>gotten the exact same response.   This probably 
>would have created additional hassle on the 
>spfbis mailing list as a bunch of dnsext people 
>dogpiled there, but we wouldn't be having _this_ 
>conversation _now_, so it actually would have 
>been better, despite the short-term hassle.

With hindsight I'll say that it would have been good to have the discussion.

>I hasten to emphasize that I don't really know 
>what went wrong here.   It may be that even if 
>all the remedies I've discussed above had 
>happened, we'd still be having a big kerfuffle 
>about this on the dnsext mailing list.   My 
>motivation for suggesting that more could have 
>been done is simply my experience as a 
>participant: I really think I would have 
>participated in the discussion about this if I'd 
>realized it was happening last February.  I get 
>the impression from several other participants 
>in the discussion now that they weren't aware of 
>it either.   I don't have a sense of whether the 
>discussion would have come out differently if we'd participated.

The discussion would have been more 
controversial.  As a rough guess I would say that 
the Last Call did not work as expected.  Some of 
the reasons for that are mentioned in the (quoted) text above.

>And, by the way, internet dating is quite a 
>lucrative industry, so it's probably a bad example of a hopeless task.   :)

I might ask the Responsible AD to recharter this 
working group to work on that task. :-)

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Apr 2013 13:09:01 -0400

> form for having gone to the trouble of getting the type assignment and giving

In my view, the DKIM decision was entirely based on the fact SPF was 
getting a huge traction and adoption as a TXT solution.  So why not for 
DKIM? It worked for SPF!

We should also note the mindset were among the same authors for 
protocols that are now entirely TXT:

    SPF    - 99/TXT, Levine against SPF, Murray wasn't around MARID
    DKIM   - TXT only, Murray authored
    VBR    - TXT only, Levine authored
    DMARK  - TXT only, and now a new I-D by Murray
    SPFBIS - TXT only, Murray started SPFBIS.

So we don't have too much "diversity" on the design.

SPF goal is still the same design goal for SPF type. The problem are the 
DNS servers. Getting Microsoft DNS servers to support unnamed RRTYPE 
processing at the very least will immediately change the course of the 
RRTYPE needs in the right direction.

Its a different problem in the same way AUTH-RES isn't ready for prime 
time with SPF - an errata is needed and people need to change their 
Received-SPF reporting.  In the mean time, in the name of across the 
board coding and single-sourcing, you support both even if the AUTH-RES 
support needs to be done with a kludge comment field.   Its the same 
with DMARC design pressures, it "works" better when MTA does the SPF 
processing at the 5322 Payload level (DATA state) or you accept the 
message then do the above tests and it may bounce or perhaps, hopefully 
not, discard:

             SPF FAIL POLICY === DKIM/ADSP DISCARD POLICY

Ideally, if we are going to stick with TXT based solutions and to better 
support integrated systems (ones that may support all of the above, it 
will be at least 4 DNS TXT queries), then we explore a direct solution 
of a single call to return all the sender information one may need 
about, including the message owner and copyright holder domain.

--
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Apr 2013 10:37:15 -0700

On Fri, Apr 26, 2013 at 8:38 AM, Mark Andrews <[email-masked]> wrote:

> [...]

Sounds like you're asking operators that went with TXT only to prove they
had some hardship that prevented them from advertising both.  If you'd like
to collect those data I'm sure it would be an interesting survey.  I'm also
sure some quantity of the sample space will simply say "We didn't know" or
"It's what everyone else was doing", but I'm further sure that there will
be some non-trivial part of the sample space that had some problem --
provisioning issues, DNS software support, whatever -- that prevented them
from doing it.

RFC4408 said SHOULD publish both and MUST publish one of them,
simultaneously stating that clients are to query either or both.  A client
would be in its rights to issue a query for only one of the types and a
server would be within its rights to only publish the other for whatever
local justification applied at the time.  That would always result in
NODATA despite correct implementations on both sides.  That sure sounds
like an interoperability problem to me.  Because of the way publication
occurred, this wasn't caught by any kind of real review, and then sat out
there for the last seven years leaving approximately zero incentive to do
it the way you're saying it should've been done in the first place while
deployment continued to increase.

All this sound and fury about the right way and the wrong way doesn't
change any of that reality.  I totally agree that doing it the right way in
the first place would've been nice.

Are you perchance offering to lead the charge to get the industry to swing
over to type 99?  Someone who supports that as the right way forward from
here will have to.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 14:00:34 -0400

On Friday, April 26, 2013 01:09:01 PM Hector Santos wrote:
> > really about the RR type at all or if it's really about the design
> > decision on where to place the record?  It seems that SPF is not being
> > penalized in some form for having gone to the trouble of getting the type
> > assignment and giving it a go.
> 

For DKIM and SPFbis there's a whole working group.  Also DKIM has been through 
not only working group last calls, but several IETF last calls.  I think that 
it's reasonable to conclude that there's IETF consensus around TXT plus and 
underscored namespace being an OK solution to these kinds of problems.  Trying 
to pin this on a few people, particularly when decisions were made in working 
groups that you participated in is just not correct.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Apr 2013 14:00:33 -0400

In my opinion, you're missing the point.  The specs should provide the 
functional specs (it does now, its being eliminated) where developers 
would basically offer deployment options.  Think about how far you went 
to alter the concept of a FAIL/REJECT to also include a 
FAIL/ACCEPT+REPORT.  You want developers to do both in order for 
deployments can have a "Local Policy" setup of either one. That is ideal 
even if some software are not ready for both. Its the same issue with 
the 99/TXT.  Developers will be able to write the proper code, if they 
want to cover it all:

o Method of SPF Calls, choose one:

    (_) SPF type
    (_) TXT type
    (*) Both, per spec.

o Method of handling SPF Fail

    (*) Reject per SPEC
    (_) Accept
    [X] Always report when accepting
    [X] Separate Accepted Failed Mail to User Junk folder

etc.

What you are basically saying is that DNS software will never change and 
therefore, we should always give up on non-TXT DNS applications.  That's 
apparently the direction DKIM, VBR and DMARC took!

It was always stated that this will have endorsement problems, that was 
known since MARID and the status quo is the same today.

                COMPROMISE!

--
HLS

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 26 Apr 2013 20:00:52 +0200

> work with wildcards.  It won't work for all domains.

There CAN be a zone cut between the SPF record and the MX, which in turn might have impact on trust related to DNSSEC.

I have no idea on the implications, but I do not see it being examined.

   Patrik

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Apr 2013 20:38:16 +0200

> Tl;dr: "Overloading TXT is bad, lets fix this mess once and for all"

May I point out that, besides the pointers given by SM to discussions
in SPFBIS WG, this issue was discussed at length in the IETF list, in
various threads starting at:
http://www.ietf.org/mail-archive/web/ietf/current/msg72024.html

> sense to remove this scenario as much as possible.

Why not data?  If it is text/plain rather than binary, TXT suits it
well, doesn't it?

> ...is not very hard.

Been there, done that, it sucks.

> Of course, we'll enter the open-ended parser quite

Doubling the records and the queries seems to be more of a mess to me.

> this less of a problem in the future, as code gets corrected.

If a decade didn't correct anything, what time horizon do you mean?

You are suggesting to keep a RR type that nobody uses, as a fig leaf
to cover our inability to use the DNS more efficiently.  Moore's law
doesn't prescribe that having more resources is a good reason for
wasting them, maybe that's Murphy's one or a corollary thereof.

> This usage does not benefit from the capacity increase according to Moore.

grep -v v=spf1

> to all those cases as well. (Ok, lots of handwaving here, but I'm right.)

Non-authoritative answer:
besserwisser.org        text =

        "MN-1334-RIPE"
besserwisser.org        text =

        "SPF is stupid. Very Stupid."

> TXT because of reasons of defaitism is not how the IETF should do this.

Please distinguish two layers:  At a DNS layer discuss the DNS and how
to incorporate variously structured records of specific types in a
simple manner.  At the application layer, when the use of specific
types will have been established, consider migration.

> in favour of overloading a generic free-form RR. Because overloading

I don't think overloading TXT is bad, but even if it were, it's the
only option available now.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 18:42:06 +0000

Yes.

> realizing that some possible arguments already have answers:

I think it's mostly harmless, but it's not what 4408bis does.

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Apr 2013 14:55:56 -0400

There was nothing nefarious about what I stated. They did what any 
practical designer/developer MIGHT do - stick with the path of least 
resistance and propose what has worked for other similar protocols but 
more importantly provides the fastest market entry point solution. This 
is the only problem with the idea - everyone using TXT.

Going with an new RRTYPE is simply nor practical. A TXT fall back would 
be required.  Its better when they have their own name spaces, so it 
isn't a big issue. But SPF doesn't have its own name space.

The issue remains, do you believe SPFBIS will get the endorsement of the 
DNS community to finally make SPF a IETF Standard?

I personally believe many developers understand the practicalities, so 
SPFBIS may get many reluctant approvals for a TXT only solution.  But it 
shouldn't eliminate what the functional specs should say for developers 
to program to be ready when the DNS servers do finally get updated to 
support unnamed type queries and passthrus with the recursion.

Do we believe the DNS servers will get updated, one day? Can we 
encourage it, get the DNS vendors to join in enhancing software?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 14:59:50 -0400

> I think it's mostly harmless, but it's not what 4408bis does.

Yes, but it's a useful discussion point because it helps clarify what the 
objection is.  It appears that the primary objection is not use of TXT per se, 
but use of TXT in the name namespace of the domain.  To the extent this may 
actually be a problem, it's trivially mitigated:

Most of the object to the current design seems highly emotional and not 
particularly empirically based.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Apr 2013 15:13:07 -0400

No hat.

> _spf.example.com. 3600   IN      TXT     "v=spf1 [record content] -all"

That only partly mitigates it.  You _still_ need the TXT record at
example.com.  That's one of the things those of us who find this an
incredibly ugly wart object to: it uses one datatype for other data.
More precisely, it uses a by-definition-unstructured datatype for
structured data.  It's unquestionalbly datatype abuse.  I think the
only question is whether the ship has left the barn; the answer is
yes.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Apr 2013 15:20:59 -0400

> particularly empirically based.

So this is where this wasted multiple calls came from?  Can you imagine 
the huge waste of calls from large email senders/domains when their SPF 
is totally waste in processing with neutral and softfall results?

All mail from Facebook.com, Gmail.com and Hotmail.com is SPF wasted 
called and all of them required at least two calls. Hotmail.com has 4 
includes to "spf" identifying subdomains.  And receivers with end users 
getting mail from the large ESPs is a major victim of this DNS waste! 
Facebook at least has a High Payoff with a -ALL (Fail) policy. Their 
domain will be protected from spoofing. Gmail.com and Hotmail.com won't 
be protected and are forcing all receivers to do at least TWO calls!

I rather have emotion and passion in engineers than not at all.  But 
this isn't that at all and its unfair to blab that out.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 15:30:56 -0400

On Friday, April 26, 2013 03:20:59 PM Hector Santos wrote:
> > objection is.  It appears that the primary objection is not use of TXT per
> > se, but use of TXT in the name namespace of the domain.  To the extent
> > this may actually be a problem, it's trivially mitigated:
> > 

Large complex records (e.g. hotmail.com) are going to require multiple queries 
for includes due to their size and complexity independent of the RR type 
discussion.  That comes from a need to avoid falling back to TCP for 
operational reliability.

Once you throw multiple RR types into the mix, that just doubles the problem.

I agree it's not pretty, but I don't see any measurable harm.

Scott K

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 19:43:49 +0000

> _spf.example.com. 3600   IN      TXT     "v=spf1 [record content] -all"

Sure, but how does this win over just using SPF records?

If your answer is "the middleware doesn't support it," I don't buy that—that was a valid argument five years ago, but not now.

If it's "the provisioning systems don't support it," I still haven't heard a convincing answer from anybody pushing this viewpoint.  I'm not saying the argument is wrong; just that I haven't heard a good answer.   The SPF record is just a TXT record with a different name; why is this hard, other than in the sense of "we would like to continue running the code that we wrote in 1995?"

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 15:49:53 -0400

On Friday, April 26, 2013 07:43:49 PM Ted Lemon wrote:
> If your answer is "the middleware doesn't support it," I don't buy that—that
> was a valid argument five years ago, but not now.
> 
> If it's "the provisioning systems don't support it," I still haven't heard a
> convincing answer from anybody pushing this viewpoint.  I'm not saying the
> argument is wrong; just that I haven't heard a good answer.   The SPF
> record is just a TXT record with a different name; why is this hard, other
> than in the sense of "we would like to continue running the code that we
> wrote in 1995?"

Ask the vendors that don't provide it.  I would imagine it's largely a 
business decision where perceived ROI doesn't merit the investment.  
Unfortunately such people don't generally participate in the IETF.  Should 
they/shouldn't they isn't the question.  It'd do they.

Even once they do, who cares.  I recently noticed that at some point my DNS 
provider started offering type SPF records (no idea when they started), but I 
haven't bothered to publish them.  Why not?  It's not worth my time and it's 
just another chance to screw something up in my DNS.  No ROI.

Scott K

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Apr 2013 12:31:37 -0700

On 04/25/2013 11:30 PM, Murray S. Kucherawy wrote:
> On Thu, Apr 25, 2013 at 11:05 PM, David Conrad <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      > So how much energy are the DNS experts going to put into cleaning
>     up their house while demanding the mail people clean up theirs?
>

Uncharitable interpretation of the current situation could come to that 
conclusion.

> No, what I'm saying is that the way things were ten years ago

As I (and others) have said many times, things were rough at the time 
SPF came to bloom. However, and this is really important to understand, 
it's not 10 years ago anymore.

I'm not being petty when I say that. It really is important to 
understand, the time is going to pass anyway. In the time period between 
then and now a LOT of things have happened in the DNS world, and the 
situation is dramatically different now than it was.

What is even more important to understand is that 10 years from now 10 
more years will have passed. We have a chance now to set in motion 
events that will continue to improve the situation, so that 10 years 
from now we can look back and laugh at the SPF TXT record, and have joy 
that things are so much better. Or, we can spend 10 more years with the 
same silly kludge, and not have made any progress at all. Either way, 
the next 10 years are going to pass.

> pushed the
> interim, has become very widely deployed.

And some of the software that handles SPF has already switched to 
querying SPF/99 first. There is no reason that the rest could not do 
that as well. Then by the time that the next version of SPF is released, 
it can be all SPF/99, and no TXT. Eventually the TXT record will die out 
altogether.

As I have mentioned previously, in the DNS world we have a LOT of 
experience dealing with issues EXACTLY like this. We know how it works, 
we know what long tails look like, and we know that as problems go it's 
a pretty easy problem to deal with.

> Suddenly now we have a few
> voices from the ivory tower asserting that the same community needs to
> go out and re-do things the way they should have been done in the first
> place, now that we finally have a somewhat more reasonable perspective,
> even though some of the vestiges of ten years ago are in fact still
> around.  My reaction to that is "You can't be serious."  That doesn't
> sound like revenge at all to me, just pragmatism.

Um, it's not "suddenly." The advice to do it right in the first place 
has been offered repeatedly, since the very beginning. That's why the 
code point was assigned in the first place.

There is no doubt that in the early days, prior to the widespread 
deployment of 3597, querying for SPF/99 could cause problems. But we're 
not in that world anymore. Thank DNSSEC and IPv6 for shaking things 
loose. There is currently no TECHNICAL reason that the change cannot be 
made NOW to query SPF/99 first. The only argument you (and others) have 
put forward so far is, "We have been using TXT, it works, so we want to 
keep using it." I understand why that course of action is attractive, 
but it's bad. And the right thing isn't hard to do.

>     The point is that it isn't just fine.  It does have operational
>     impacts, from potentially increased fragmentation/fallback to TCP to
>     increased complexity in TXT RR parsers that have to distinguish
>     between the myriad of crap that's residing at the zone apex TXT RR,
>     etc.  Of course, most of these negative impacts are hidden to the
>     folks who are putting the TXT RRs in the zone, so it's all good, right?
>
>      > Thus, I maintain that we take our licks on this one and just take
>     steps to ensure that nobody follows this path again.
>
> about things like IAB advice about how [not] to put application data
> into the DNS.  Seems to me this is a perfectly good subject for another
> such project.  One may counter that by saying nobody will pay attention
> to such a document, but I submit that it's our primary mechanism for
> making sure mistakes aren't re-made, so that's the tool we have to use
> or not use.

But this mistake isn't carved in stone. It CAN be fixed. And the 
solution isn't difficult. Some minor changes are made to software, some 
docs are updated, and then time passes and the old way becomes obsolete.

> If we do the opposite and somehow compel SPFBIS to favour type 99 over
> TXT, then I still think we'll be shouting that to an audience that will
> think we're nuts and simply go about their business.

If that happens (and I personally don't think it will), it's not the 
IETF's problem. We don't (traditionally) write specs to accommodate the 
worst behavior we see in implementations. We write specs to describe how 
it should be done right, and do our best to support people who want to 
write software that does it right.

And I should emphasize again, "Mail::SPF (which is used by Spamassassin) 
checks for Type SPF first by default." So there is already a non-trivial 
implementation that is doing it right. The number of other 
implementations that need to be updated is not very large. Another case 
mentioned in the spfbis thread on "issue #9" was the python lib for spf, 
which already has the code to query SPF/99. It would be a 30 minute job 
to update that to query 99 first.

So if I'm missing some TECHNICAL reasons why this proposal isn't 
feasible, please enlighten me. But all I've seen so far is, "We don't 
want to do it," which I don't find particularly compelling.

Doug

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 19:55:50 +0000

> just another chance to screw something up in my DNS.  No ROI.

Okay.   But using _spf.domain requires significant provisioning changes.   It requires you to update your DNS.   Why is there ROI here, but not in simply using the already documented solution to the problem?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 16:06:38 -0400

On Friday, April 26, 2013 07:55:50 PM Ted Lemon wrote:
> > provider started offering type SPF records (no idea when they started),
> > but I haven't bothered to publish them.  Why not?  It's not worth my time
> > and it's just another chance to screw something up in my DNS.  No ROI.
> 
> Okay.   But using _spf.domain requires significant provisioning changes.  
> It requires you to update your DNS.   Why is there ROI here, but not in
> simply using the already documented solution to the problem?

No, it doesn't.  The provisioning changes needed for _spf have been needed by 
_domainkeys for a long time.  In that case there was no alternative and a lot 
of deployment momentum, so providers did suddenly discover that hosts and 
domains weren't the same thing after all and remove restrictions on use of 
underscore.

To me, managing two sets of identical record would cause work and increased 
risk of error for zero benefit.  I don't view that as a wise investment of my 
time.  I know you won't agree with it, but I think it's a perfectly rationale 
view and one that's common outside the IETF.

Also, the underscore trick requires a one time change.  Double publishing SPF 
records for two RR types requires double changes every time the record is 
changed, so it's not comparable.

Scott K

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 20:11:01 +0000

> changed, so it's not comparable.

You'd have to double publish either way.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 16:12:59 -0400

On Friday, April 26, 2013 08:11:01 PM Ted Lemon wrote:
> > Also, the underscore trick requires a one time change.  Double publishing
> > SPF records for two RR types requires double changes every time the
> > record is changed, so it's not comparable.
> 

No.  When doing the underscore bit the domain level record is static.  You 
change it to a pointer somewhere else and never touch it again (where never is 
until your underscore record gets so big you need two, but not many domains 
need that).

Scott K

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 20:15:19 +0000

> until your underscore record gets so big you need two, but not many domains 

You still have to make the change.   And this doesn't actually solve the problem with TXT records on the domain.   It just makes it less bad.   If you have 37 text records, this isn't going to prevent the MTA having to fall back to TCP.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 16:17:38 -0400

On Friday, April 26, 2013 08:15:19 PM Ted Lemon wrote:
> > change it to a pointer somewhere else and never touch it again (where
> > never is until your underscore record gets so big you need two, but not
> > many domains need that).
> 
> You still have to make the change.   And this doesn't actually solve the
> problem with TXT records on the domain.   It just makes it less bad.   If
> you have 37 text records, this isn't going to prevent the MTA having to
> fall back to TCP.

I agree it's not a complete solution, but if you have 37 TXT records it's 
pretty arbitrary which one you decide gets the blame for falling back to TCP.   
It's a 99.9% solution and that's good enough.

Scott K

---

From: Dotzero <[email-masked]>
Date: Fri, 26 Apr 2013 16:19:41 -0400

> You still have to make the change.   And this doesn't actually solve the problem with TXT records on the domain.   It just makes it less bad.   If you have 37 text records, this isn't going to prev…

If you have 37 text records for a single name space you have a very
interesting record. Could you provide some legitimate examples of this
in the wild that the WG could consider?

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 16:21:11 -0400

> in the wild that the WG could consider?

msk (IIRC) found one in his data survey.

Scott K

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 20:25:49 +0000

> in the wild that the WG could consider?

It was given as an example earlier; you'd have to ask the person who cited it.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 20:29:08 +0000

> It's a 99.9% solution and that's good enough.

Excellent rhetorical judo.   But I refuted your main point, and your rejoinder didn't address my refutation, so I assume you agree: this doesn't actually make anything better, because you still have to update both the top-level DNS and the _spf entry, and you have to have a TXT record at the top level.   If having a TXT record at the top level is okay, your proposed fix adds nothing; if it is not okay, your solution doesn't address the problem.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 16:34:05 -0400

On Friday, April 26, 2013 08:29:08 PM Ted Lemon wrote:
> > pretty arbitrary which one you decide gets the blame for falling back to
> > TCP. It's a 99.9% solution and that's good enough.
> 
> Excellent rhetorical judo.   But I refuted your main point, and your
> rejoinder didn't address my refutation, so I assume you agree: this doesn't
> actually make anything better, because you still have to update both the
> top-level DNS and the _spf entry, and you have to have a TXT record at the
> top level.   If having a TXT record at the top level is okay, your proposed
> fix adds nothing; if it is not okay, your solution doesn't address the
> problem.

I don't know how to be clearer, so I'll just stop.

Scott K

---

From: Dotzero <[email-masked]>
Date: Fri, 26 Apr 2013 16:35:35 -0400

> It was given as an example earlier; you'd have to ask the person who cited it.

And that is exactly my point (I was waiting for folks to pounce) .....
there is a SINGLE example that foks are pointing to. I'm sure that
with some level of effort someone can find a second example. In the
greater scheme of things it doesn't even rise to the level of noise
and is irrelevent to the discussion. If it were represented that 37
text records were found a significant percentage of the time AND that
SPF records were a significant factor THEN we might have a discussion
about this horrible problem SPF text records are creating.

Mike

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2013 21:13:31 -0000

>Okay, fair enough.   Please do note that I didn't say that there was process breakage—I said the process
>seemed to have been followed correctly, but produced a less than perfect outcome.

We understand that it's not the outcome that you'd like, but it's
absolutely the outcome that the data supports.  I have to ask, is
there any amount of data that would change your opinion here?  If not,
we're having a religious argument, not an engineering one, and there's
no point to continuing.

>That's not correct; there are still packet filters out there configured by default to disallow TCP over
>port 53.  We discovered this during the RFC6686 surveys.
>
>These two points taken together seem like a pretty strong argument in favor of _not_ deprecating the SPF
>record; in this case, only the SPF record would have made it back to the MTA.

Well, actually, complex SPF records can easily blow past 500
characters all by themselves.  This issue is well known among people
who use SPF, and there is a well known workaround that Scott mentioned
a few messages back.

As should be obvious, if we were using type 99 records, we would have
the exact same issue, and would address it with the exact same
workaround. There truly is no problem at this point that type 99
solves, and several well documented ones that it causes.

Is it really appropriate for someone who is this unfamiliar with a
protocol as widely deployed as SPF (viz. the ~400,000 domains found in
the RFC 6686 surveys, and the many years of experience by WG members,
some at very large mail systems) to be demanding last minute
redesigns?

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Apr 2013 14:46:03 -0700

At the time the RFC6686 surveys were done there were several domains larger
than this one (in terms of the number of RRs returned), but asking for TXT
from "ut.edu" right now will give you 18 replies.  The rest seem to have
cleaned up their respective acts.

I still have the original data seen during the surveys but this shows a
live example.

-MSK

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 21:49:41 +0000

On Apr 26, 2013, at 5:13 PM, John Levine <[email-masked]> wrote:
>> Okay, fair enough.   Please do note that I didn't say that there was process breakage�I said the process
> absolutely the outcome that the data supports.

You misunderstand my point here.   What I mean is that if this has been raised in a way that attracted attention on DNSEXT in February of 2002, or whenever it became clear that the spfbis was going to deprecate SPF in favor of TXT, we could have avoided this conversation now.   I don't mean that the outcome of the conversation would have been any different.

>  I have to ask, is

I don't think data about what is deployed in the field should be the primary motivating factor for writing standards.   It's important, but it's not the only factor.   Calling my opinion religious, and yours engineering, seems a bit arrogant.

> some at very large mail systems) to be demanding last minute

I'm not demanding a last-minute redesign.   I said I wasn't demanding a last-minute redesign.   Right at the top of the message, two exchanges back.   The reason I'm not demanding a last-minute redesign is that while I do feel I'm qualified to participate in this discussion, I don't feel that my opinion should win, just because it's my opinion.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Apr 2013 14:58:59 -0700

On Fri, Apr 26, 2013 at 12:31 PM, Doug Barton <[email-masked]> wrote:

> As I (and others) have said many times, things were rough at the time SPF
> came to bloom. However, and this is really important to understand, it's
> not 10 years ago anymore.
>

I am keenly aware of the date.  What I am also keenly aware of, as I (and
others) have said many times, is that SPF set off in a specific direction
based on the situation ten years ago and has continued in that direction
all this time.  Now, with the situation "at home"
largely-but-not-completely improved, there are a few people now exclaiming
that it went in the wrong direction, and that needs to be fixed.

It's very easy to make that assertion when one ignores questions of
momentum and inertia.

I'm not being petty when I say that. It really is important to understand,
> the time is going to pass anyway. In the time period between then and now a
> LOT of things have happened in the DNS world, and the situation is
> dramatically different now than it was.
>

Nobody's arguing that point.

> more years will have passed. We have a chance now to set in motion events
> that will continue to improve the situation, so that 10 years from now we
> can look back and laugh at the SPF TXT record, and have joy that things are
> so much better. Or, we can spend 10 more years with the same silly kludge,
> and not have made any progress at all. Either way, the next 10 years are
> going to pass.

Sure.  Is that a good use of engineering resources?  This is where we
appear to differ.  I claim, given current data, that it is not.

>
> And some of the software that handles SPF has already switched to querying
> SPF/99 first. There is no reason that the rest could not do that as well.

I agree with the first sentence, but not the second.

> experience dealing with issues EXACTLY like this. We know how it works, we
> know what long tails look like, and we know that as problems go it's a
> pretty easy problem to deal with.
>

This situation touches more than just DNS code.  You appear to be convinced
that the path to overcoming inertia in the DNS world is the same, or maybe
even harder, than it is in other environments like email.  I am not a
believer.

>
> Um, it's not "suddenly." The advice to do it right in the first place has
> been offered repeatedly, since the very beginning. That's why the code
> point was assigned in the first place.
>

Um, it is "suddenly", or have you a copy of the spfbis archive that's
different from the one I have?

> deployment of 3597, querying for SPF/99 could cause problems. But we're not
> in that world anymore. Thank DNSSEC and IPv6 for shaking things loose.
> There is currently no TECHNICAL reason that the change cannot be made NOW
> to query SPF/99 first. The only argument you (and others) have put forward
> so far is, "We have been using TXT, it works, so we want to keep using it."
> I understand why that course of action is attractive, but it's bad. And the
> right thing isn't hard to do.
>

I'm sorry, but that is not the only argument I (and others) have put
forward so far.  If this conversation is going to be selective in that
manner, then I think I'm done here.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 15:02:04 -0700

Ted, et al,

On 4/26/2013 2:49 PM, Ted Lemon wrote:
> You misunderstand my point here.   What I mean is that if this has
> been raised in a way that attracted attention on DNSEXT in February
> of 2002, or whenever it became clear that the spfbis was going to
> deprecate SPF in favor of TXT, we could have avoided this
> conversation now.

Such an optimist, given the tenacity of those insisting on relying on 
new RRs.

>> I have to ask, is there any amount of data that would change your
>> opinion here?  If not, we're having a religious argument, not an
>> engineering one, and there's no point to continuing.
>
> I don't think data about what is deployed in the field should be the
> primary motivating factor for writing standards.

Right.  Running code and operational practice really aren't all that 
important, when compared against architectural ideals.

As in, wow...

The current situation is pretty simple:

    1. The SPF RR was defined but failed to gain traction.  The market 
has overwhelmingly rejected it.

    2. There is no objective basis for believing that will change.

    3. Retention of unused features makes a specification more complex 
and invites implementation and operations problems.

    4. Specification revision efforts typically drop unused features.

Added to this is the problem of claiming that it's now reasonable to 
deploy new RRs.  This line of claim carefully focuses on only a subset 
of the overall adoption and deployment task and cavalierly dismisses the 
rest.  While portions of the task have indeed improved over the last 10 
years, there are still show-stopping barriers to adoption.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Apr 2013 18:07:18 -0400

No hat

> cleaned up their respective acts.

What do you mean, "cleaned up"?  Several of the TXT records at ut.edu
are _what TXT was for_, which is "text" (although I think they may be
confused about how DNS works, since they have text that says "in the
following record", which is pretty amusing).  Text is, you know, stuff
for humans to read.

Indeed, the ut.edu example is an excellent one of why polluting TXT
with data that is somehow supposed to be used programmatically is a
bad idea.  I also observe that SPF is plainly not the only protocol
doing this.  There's some apparent random cryptographic blob there,
too, and one of those MS= things.  (This makes me want to request an
RRTYPE code assignment for the VOMIT RRTYPE, but I know nobody would
use it, or at least not the people it was aimed at.  Very Offensive
Mangled Interchange Type in case anyone was wondering, though I could
maybe do better with a little more thought.)

The argument that SPF, by using the TXT type, is tromping all over an
otherwise useful type and making that other type harder to use is a
perfectly good one.  The _only_ reason to accept the deprecation of
TYPE 99 is the twin issue that TXT-mostly is a fact of life on the
Internet _and_ we have an interoperability problem in the existing
specification.  That's why I think the hand-wringing about "precedent"
is foolish: there is no precedent here, because of the history of SPF.
What we have to ensure is that a Charlie Foxtrot of the same
proportions doesn't happen again.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 15:11:59 -0700

> proportions doesn't happen again.

Yup.  And whether it entails using a new RR or an underscore prefix (to 
define a scoped TXT usage) that's a solved concern.

d/

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 22:13:26 +0000

On Apr 26, 2013, at 6:02 PM, Dave Crocker <[email-masked]> wrote:
> Such an optimist, given the tenacity of those insisting on relying on new RRs.

Again, you misunderstand my point.   Yes, probably someone would bring this up every six months.   But it would have been settled, so it wouldn't matter that they brought it up again, although I suppose the proponents of the view that prevailed would still feel obligated to beat them up again.

> Right.  Running code and operational practice really aren't all that important, when compared against architectural ideals.

Thanks, Dave.   "Not the primary motivating factor" != "not all that important."   You write a protocol spec because you mean to solve a problem, not because the problem has already been solved.   It's certainly true that running code is important, but so is rough consensus.   And when people claim that running code trumps rough consensus, in the sense that the IETF is only allowed to document precisely what's already been implemented, it's often taken very poorly.

I will refrain from responding to the rest of what you said, because I already said that while I am not happy with the spfbis consensus, I do not dispute it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Apr 2013 15:16:16 -0700

> following record", which is pretty amusing).  Text is, you know, stuff

It's a hodgepodge of data, given that the TXT RRs could be returned in any
order.  The largest recorded example in the RFC6686 surveys included a
reply comprising 43 records, nearly all of which were random strings Google
asked them to add to prove they owned the domain when setting up Google
Apps or something similar.  Those aren't meant for use by humans.  They're
are all gone now, which is what I meant by "cleaned up".

> proportions doesn't happen again.

+1, given that this is a restatement of what I said earlier.  Maybe you
have more credibility than I do.   :-)

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 18:20:52 -0400

On Friday, April 26, 2013 04:34:05 PM Scott Kitterman wrote:
...
> I don't know how to be clearer, so I'll just stop
...

It was pointed out to me offlist that this came across as a cheap shot.  It 
wasn't meant that way, so I withdraw it.  I was attempting to describe a 
communication failure (with no blame attaching to either party, just a 
failure) that I couldn't see how to rectify.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 15:36:33 -0700

On 4/26/2013 3:13 PM, Ted Lemon wrote:
> Again, you misunderstand my point.   Yes, probably someone would
> bring this up every six months.   But it would have been settled, so
> it wouldn't matter that they brought it up again, although I suppose

Well, I'll claim that the question of TXT vs. RR was thoroughly 
discussed at the time, with plenty of DNS expertise present.  In fact, 
including the SPF RR in the spec, then, was the compromise outcome, as a 
concession to RR devotees.

In other words, it /was/ settled a long time ago.  But that hasn't 
stopped any number of folk from claiming it wasn't.

(By way of contrast, and FWIW, I happen to dislike SPF in its entirety, 
from its being path-based to its excessive complexity.  But none of that 
has been worth discussing during spfbis and I haven't raised it.  SPF is 
highly integrated into the global email infrastructure.  So the only 
issues now should be small technical tweaks and documentation 
refinement.  And that's what the wg has done, modulo some, ummmm... 
synchronization challenges in getting consensus on what tweaking has 
been needed.)

>>> I don't think data about what is deployed in the field should be
>>> the primary motivating factor for writing standards.
>>
>> Right.  Running code and operational practice really aren't all
>> that important, when compared against architectural ideals.
>
> Thanks, Dave.   "Not the primary motivating factor" != "not all that
> important."

I acknowledge the semantic distinction.  But a) the IETF historically 
has held very high the goal of documenting existing practice, and b) 
this is a -bis effort, where existing practice really /is/ primary.

> You write a protocol spec because you mean to solve a
> problem, not because the problem has already been solved.

Oh.  You've missed the role of documenting existing practice that I 
thought was held as an IETF ideal and that has been common IETF practice???

>  It's
> certainly true that running code is important, but so is rough
> consensus.

Indeed, but rough consensus in the market trumps any amount of it within 
a tiny community of technology idealists, even if that community's name 
is "IETF".

> And when people claim that running code trumps rough
> consensus, in the sense that the IETF is only allowed to document
> precisely what's already been implemented, it's often taken very
> poorly.

Turn that around.  Rough consensus in a small group that has little 
risk, if an effort fails, should not be allowed to trump rough consensus 
among the larger community that relies on implementations interoperating.

To the extent that an IETF failure to gain rough consensus causes an 
outcome that is contrary to marketplace needs (and rough consensus), it 
is the IETF that become irrelevant.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 15:38:00 -0700

On 4/26/2013 3:20 PM, Scott Kitterman wrote:
> It was pointed out to me offlist that this came across as a cheap shot.

For reference, I thought it was nicely neutral and professional.

Seriously.

d/

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 27 Apr 2013 00:45:20 +0200

> proportions doesn't happen again.

I'd suggest that the spfbis draft gets text along these lines: 

  SPF  records MUST  be published  as  a DNS  SPF (type  99)
  Resource   Record  (RR)  <xref   target="RFC4408"/>.   The
  character  content  of  the  record is  encoded  as  <xref
  target="US-ASCII"/>.   Use of alternate  DNS RR  types was
  supported  in  SPF's  experimental  phase,  but  has  been
  discontinued. The intermediate  practice of publishing SPF
  data in TXT records MAY be retained along the required SPF
  RR  for compatibility reasons,  but MUST  NOT be  the sole
  publication. A SPF (type 99) record MUST be present.

...

  In accordance with how the records are published (see <xref
  target="records"/> above), a DNS query needs to be made for the
  &lt;domain&gt; name, querying for type SPF. If the reply is valid 
  but empty (RCODE NOERROR (0) and answer count == 0), check_host() 
  MAY query for the same &lt;domain&gt; name, but substituting the 
  resource record type with TXT. 

	(XML diffs can be had by asking) 

This way, both sides get what they want. People who wish to run old name
server software can continue, provisioning systems may be subjected to
bitrot, and the stuff that gets upgraded will do the right thing.

( The elephant in the room is Windows Server. When it allows injection of
  SPF RRen in its DNS server, we're good. For real.)

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I am deeply CONCERNED and I want something GOOD for BREAKFAST!

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 22:46:45 +0000

On Apr 26, 2013, at 6:36 PM, Dave Crocker <[email-masked]> wrote:
> Turn that around.  Rough consensus in a small group that has little risk, if an effort fails, should not be allowed to trump rough consensus among the larger community that relies on implementations interoperating.

And I am not arguing that it should, and I have said that repeatedly.   Are the beatings going to continue until morale improves, or can we please drop this useless discussion?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 18:52:35 -0400

On Saturday, April 27, 2013 12:45:20 AM Måns Nilsson wrote:
> Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Fri, Apr 26, 2013 
>   SPF RRen in its DNS server, we're good. For real.)

I don't think this is a good idea, but I'll ask a couple of questions anyway.

What's the appropriate response for SERVFAIL or no response at all (timeout) 
on the type SPF query?

Do you think it is in the scope of the charter language to add a 2119 MUST for 
publishing type SPF when it's essentially unused?

Scott K

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Apr 2013 09:08:42 +1000

In message <4272263.gKzvRQiTlr@scott-latitude-e6320>, Scott Kitterman writes:
> What's the appropriate response for SERVFAIL or no response at all 
> (timeout) on the type SPF query?

For this case you can fallback to making a TXT query as the data
content MUST be identical if present.  This is different to MX query
failures where the implicit MX record may not match the explict MX
record.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 19:19:20 -0400

> failures where the implicit MX record may not match the explict MX

Not according to the text he wrote.  Based on the text, those would get a 
result of temperror even if a TXT query would have gotten a perfectly fine 
answer (and yes, this happens enough that it's one of the reasons no software 
I'm in charge of queries for SPF, it's a waste).  Adding type SPF support back 
in a useful and correct way would be more complex than has been suggested (not 
that we are).

Also, MUST be identical is an interesting requirement that's impossible to 
verify consistently in practice since one type or the other may be cached 
somewhere.  The receiver can't tell if they get two answers that are different 
if they are intentionally different or not.  It's kind of a pointless MUST.

Scott K

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 27 Apr 2013 01:28:58 +0200

> What's the appropriate response for SERVFAIL or no response at all (timeout) 

Good one! SERVFAIL probably terminates processing. "temperror" in the
language of the spfbis. SERVFAIL is returned when the full-service
resolver can find the alleged server for the zone; it is running and
reachable, but it has no data on the zone, not even SOA. Classic case
is the slave that failed to do AXFR. 

In the timeout case all name servers are unreachable (permanent or
temporary). I'd argue for temperror here too. 

Good argument can sway me here, but both cases are pretty hopeless in
terms of getting data out of the zone at all. (at that point in time,
which is an argument for "temperror")

Thus, I find it unlikely to succeed in getting responses back for TXT
when SPF queries have SERVFAILed or timed out. Outdated middleboxes
should return NOTIMP which could trigger re-query using TXT. (yeah,
I'm an optimist.)
 
> publishing type SPF when it's essentially unused?

I do not think the charter permits SPF removal, so spfbis must deal with
its continued existence. 

Naturally, spfbis, by the same logic, can't remove TXT either. It can,
however, discourage its use.  Why should it? Well, apart from "Overloading
TXT is bad" (which we all know, in our soul-searching, is the Right answer
:), I'd state that, IMNSHO, the ut.edu example  is a clear indication as
to why TXT can never be more than a stopgap measure waiting for resolver
and name server code updates.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Yow!  Is this sexual intercourse yet??  Is it, huh, is it??

---

From: S Moonesamy <[email-masked]>
Date: Fri, 26 Apr 2013 16:31:19 -0700

>bitrot, and the stuff that gets upgraded will do the right thing.

Thanks for suggesting text.  I am aware that the 
issue has been discussed previously.  It is an 
unusual situation.  I'll leave it to the working 
group to discuss about the above.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 19:38:39 -0400

> should return NOTIMP which could trigger re-query using TXT. (yeah,

Should, but they don't.  For implementations that don't deal with type SPF, 
SERVFAIL or no answer at all are the most common effects.  So failure of a type 
SPF query in one of these manners doesn't tell you anything about what would 
happen with a TXT query.

[snipped the other bit, since it's pretty clearly something we are going to 
disagree on]

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Apr 2013 21:24:46 -0400

Chair hat on.

> I do not think the charter permits SPF removal, so spfbis must deal with

We actually had protracted discussion about that in the past, and
concluded differently.  In particular, as I already noted in another
thread (on, IIRC, another mailing list), we discovered that there was
an error in 4408 that led to interoperability problems.  

Our charter says this:

        Changes to the SPF specification will be limited to the correction
        of errors, removal of unused features, addition of any enhancements
        that have already gained widespread support, and addition of
        clarifying language.

We did in fact originally decide that deprecating the SPF RRTYPE would
be removing a feature that was not "unused"; this was actually the
subject of an appeal, because some participants felt that the chairs
were interpreting "unused" too strictly.  You may see the results of
all that in
http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html.

But the problem arose once we started to consider an _error_ in 4408,
which is that it specified things in such a way that two conforming
implementations could fail to interoperate; that is surely an error in
the spec.  We have to do _something_, though any action would
introduce a backward incompatibility.  The decision is covered under
"correction of errors" in the charter text above.  After some
deliberation, the WG decided to deprecate SPF.  Each of the options
has problems, but we determined that this is the one most in line with
the facts of the world, the likely future (based on analogies with
other deployment patterns), and the minimization of additional
needless queries in the DNS.

Under the circumstances, I (at least) believe our charter does permit
the deprecation of SPF.  You can ask others how reluctantly I came
to this conclusion, but I nevertheless think it's the right one, given
the evidence.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Apr 2013 12:43:57 +1000

In message <[email-masked]>, Andrew Sullivan writes:
> Chair hat on.
> 
> On Sat, Apr 27, 2013 at 01:28:58AM +0200, Mns Nilsson wrote:
> > 

So it only "broken" when people fail to follow a SHOULD.  I don't see
a broken spec.  I see a excuse.

If you don't follow the SHOULD you need to understand the consequences
which in this case you will not interoperate with everyone.  Guess
what there is NOTHING wrong with not interoperating with everyone.
You get slightly less protection from bounce backs and you provide
slightly less protection to other sites.  You never had 100%
protection anyway.

> to this conclusion, but I nevertheless think it's the right one, given

And I would argue that it was never a error but a deployment choice.

You choose to not upgrade nameservers to ones capable serving SPF records.
You choose to use a registrar that doesn't support type SPF.
You choose to deploy firewalls that block SPF records.
You choose to use a OS with a broken resolver that doesn't let through SPF
records.

These are all local decisions to the people deploying SPF.  Nobody
in the middle of the net is blocking type SPF records.

Mark

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 20:11:33 -0700

> in the middle of the net is blocking type SPF records.

Mark, what are you trying to accomplish?

Operationally, the real-world situation with SPF is quite simple and 
completely clear.

Procedurally, the working group is merely trying to adjust the 
specification to reflect extensive deployment experience; this is 
neither a new nor controversial approach to working group efforts in the 
IETF.

So again I'll ask, what is your constructive intent here?

d/

---

From: S Moonesamy <[email-masked]>
Date: Fri, 26 Apr 2013 23:54:42 -0700

>a broken spec.  I see a excuse.

I read RFC 4408 several times over the last year.  I also reviewed 
draft-ietf-spfbis-4408bis-14 and read all the previous revisions of 
that draft.  I don't find arguments that X is "broken" convincing 
unless it is accompanied by a clear explanation.  "People failing to 
follow a SHOULD" is not a clear explanation in my opinion as I cannot 
verify that claim.

The IETF way is to tell people to go and read the mailing list 
archives.  I provided references to some of the relevant threads as I 
think that it might help people find out how the decision was taken 
and why it was taken.

There were some intertwined issues, e.g. Issue #25 [1].  There is 
message from John Levine which I'll quote partially:

   "So my suggestion is to close this issue, keeping in mind that we may come
    back and remove the section if we deprecate type 99."

I note that there is an "if" in the above.

[snip]

>in the middle of the net is blocking type SPF records.

The SPF specification has a checkered history. I prefer not to 
comment about that.  If I recall correctly some of the above points 
were raised during the discussions.  Some of the arguments which have 
been made in previous WG discussions are being restated.  I don't 
consider that as new information which can be used to reconsider a 
decision.  The Responsible Area Director mentioned [3] what would be 
helpful and that seems clear enough to me.  If someone provides an 
argument together with a good explanation it is not going to be 
ignored no matter how vocal other SPFBIS WG participants are.

Regards,

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00845.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00848.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03497.html

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 27 Apr 2013 09:28:35 -0400

No hat.

> And I would argue that it was never a error but a deployment choice.

But the evidence that we have in RFC 6686 is that the deployment
choice was overwhelmingly made in favour of TXT.  There wasn't a
significant uptake even of the "both" option.  In fact, even people
who did SPF records _didn't all do both_, which means that even among
the tiny minority who used the SPF records, some of them didn't follow
the SHOULD in RFC 4408.  

At some point, you have to say that the running code wins.  Of all
people, you should know this, as clarifications to DNS protocol
documents have on occasion been issued precisely because widely
deployed DNS server code bases did not precisely align with the way
the RFC was written.  Not always, of course, but it's happened, and
for exactly the same reason as in this particular case: that's just
the way the network is, and it's working, so we should make our
documents align with reality rather than trying to be legislators of
the Internet.

Again, I wish _very much_ that TXT is not what SPF used lo these
many years ago.  I also wish _very much_ that there was any evidence
that the SPF RR offers enough of an advantage that we could expect
people to move over, or that there was any evidence that the
overloading of TXT records does enough harm that we ought to jump up
and down and try to get people to accept that argument in the way
we've done for (say) BCP 38.  

But BCP 38 gives us another instructive example: even when there is
demonstrable, clear, real harm that exposes people to civil liability
when they do not deploy something, if there is not a positive
incentive to deploy it then we should expect that some won't.  How
much less the incentive, then, to switch from TXT to SPF, particularly
since 4408bis cannot possibly deprecate the use of TXT and ever be
useful as a protocol document?  The most we could do is specify that
(non-existent) SPF records be looked up first.  I cheerfully predict
that a document with such a requirement would be widely ignored by the
largest mail sites, because it would involve additional latency and an
additional lookup.  If you're processing millions of mails an hour,
those additional lookups add up, and if you have every reason to
believe that the lookup will yield nothing, you just won't do it.  The
report in RFC 6686 (which is sketchy and, admittedly, based on a
possibly flawed study, but the only actual evidence we have) confirms
that prediction, I note.  The only evidence we have of anyone querying
for TYPE 99 is of someone querying for TYPE 99 and TYPE 16 at the same
time, and presumably taking whatever the first answer to return is.

Even worse, if you publish both types, then you need some mechanism to
make sure they're identical.  There's actually no way to ensure this,
and _much worse_ because of caching effects, it's almost certain that
the two types will be observable on the Internet sometimes with
different RDATA.  So the sentence in 4408, "If a domain has records of
both types, they MUST have identical content," is almost guaranteed
not to be true sometimes, and the specification would need to be
considerably more complicated in order to make clear what is ok at
what place in what parts of the DNS.  It's true that DNS is
"eventually consistent", but here we're talking about two distinct RRs
that are supposed to have "the same data" in some sense -- a problem
DNS nerds have confronted in other contexts and which is just as
impossible in this case as it is in those other ones.

The original protocol has DNS problems that can only be resolved
through one of the three courses of action I have already outlined.
As nearly as I can tell, the best trade-off, both operationally and
from a protocol design point of view, is to deprecate RRTYPE 99.  This
does not mean I think it is a good design: it is merely the best of
three bad options.  You seem to disagree with me, but I've yet to see
a reason I can understand as to why your proposal is better.  Because
it increases traffic, it is unlikely to be deployed, so it means the
new RFC just won't get adopted (indeed, what's more likely is that
we'll get 4408bis mostly, except for the parts of 4408 that are
convenient, which means the protocol will acutally be documented
_nowhere_).  This state of affairs would make us look foolish, also.
Finally, your proposal does nothing to solve the problem that the two
record types can never be guaranteed to have the same RDATA
everywhere, which means that there is always the potential for
inconsistent data around the network.  

All of the above is already well-hashed in previous conversations on
this in the archives, and as SM has suggested there's no reason to
revisit this decision unless someone has something new to bring to
this topic.  Do you?  I don't, so this is my last word on it unless
someone comes up with something that hasn't already been considered.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Sat, 27 Apr 2013 11:07:05 -0400

I don't think there has been adequate redesign considerations here. All 
I'm hearing is that TXT-based solutions is going to be the only 
practical design solution for future DNS applications for the fastest 
entry into the market place.

AUTH-RES was kludged into SPFBIS.  It is still not correct, changes are 
still required after the fact, yet, the same can continue to be done 
with SPFBIS in regards to a dual call migration path.  As you saw, dual 
TXT/TXT calls are been advocated and also now done among the larger ESP 
domains and traffic - the victims are the SMTP receivers that has to 
make all these redundant calls for domains that don't need them!! 
gmail.com, hotmail.com, facebook.com - they don't need a TXT/TXT dual 
call SPF operation!  That is just as inefficient as have a 99/TXT call. 
Its all WORST when the policies are relaxed - very little to zero payoff 
in SPF processing for the incoming domain.  Only facebook.com offers a 
high payoff with a SPF fail policy.

This problem is not being solved correctly and I am growing tired of my 
own suggestions being ignored, so why not just ignored SPFBIS?

One thing for sure, we knew since, dare I say the word MARID, that this 
will be a major endorsement issue and it continues to be. I wanted to 
sense the status quo last year when I poised the question in IETF and 
DNSOP and even then and today the status quo remains. Nothing has 
changed except that the folks against SPF during MARID and over the 
years, have finally accepted it and have also leveraged the success of 
SPF with TXT records for their own protocols, case in point; DKIM, VBR 
and now DMARC.  That's not performing a well integrated effort among all 
parties involved; systems engineers, ISVs, DBAs, DNS administrators, 
developers, network, infrastructure folks and also documentation 
writers, etc!

Just get Microsoft rep here to tell us why MS DNS v5.0+ do not support 
and will not support unnamed type processing, and I will finally throw 
up my own hands on this and perhaps even begin to produce future 
TXT-based Domain Policy/Operations I-D proposals too.

Overall, I feel SPFBIS does not have to advocate removal is basically my 
point to achieve the same level support. Consider that it will help 
raise the endorsement barrier that it will surely get in remaining last 
calls and reviews outside this group.  I just hope that we don't get 
into a brushing aside of input and rubber stamp this effort.  You can't 
continue to put good engineering on the spot with this engineering 
issues that are solvable with the right team work going on.

In my honest opinion, SPFBIS does not *completely* fit real operations 
out there and is in many ways, already outdated.

--
HLS

---

From: S Moonesamy <[email-masked]>
Date: Sat, 27 Apr 2013 10:58:36 -0700

Hi Hector,
At 08:07 27-04-2013, Hector Santos wrote:
>AUTH-RES was kludged into SPFBIS.  It is still not correct, changes 
>are still required

There is a thread at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02259.html 
about the Authentication-Results: header field.

>This problem is not being solved correctly and I am growing tired of 
>my own suggestions being ignored, so why not just ignored SPFBIS?

There are two long threads at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html and 
www.ietf.org/mail-archive/web/dnsext/current/msg13025.html  73 
messages were posted on this thread yesterday.  There were 21 
messages the day before that.

I am not ignoring your suggestions.  There is an on-going discussion.

>Just get Microsoft rep here to tell us why MS DNS v5.0+ do not 
>support and will not support unnamed type processing, and I will 
>finally throw up my own hands on this and perhaps even begin to 
>produce future TXT-based Domain Policy/Operations I-D proposals too.

I sent an email to several implementers of RFC 4408 ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03348.html 
).  I did not receive any reply (excluding implementers already on 
this mailing list).  I cannot get anyone to participate in the WG 
discussions if they do not want to participate.

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Sat, 27 Apr 2013 20:43:26 +0000

> SPF query in one of these manners doesn't tell you anything about what would 

Earlier I said that while I disagree with the working group's decision here, I don't oppose it anymore.   This statement is actually the tipping point for me: I now understand why the working group made the decision it made, I think it was the right decision, and I no longer disagree with it.

Thanks for the explanation.   You can pie me in Berlin.

---

From: Stuart Gathman <[email-masked]>
Date: Sat, 27 Apr 2013 22:29:40 -0400

> publishing type SPF when it's essentially unused?
While the bis WG shouldn't be inventing, last night I thought of one 
idea to mitigate the widely deployed brain-dead DNS servers/firewalls 
(that time-out on unknown RRs):

1. When querying for SPF, if there is a timeout, the server is either 
dead, or the braindead variety.
2. So try a TXT query next.  If that times out also, the server is 
dead.  If that succeeds, then the server is the braindead variety.
3. So record the domain with the brain-dead server in a database cache 
with a TTL of at least 3 days, and don't try SPF with that domain again 
until the TTL expires.

I will be implementing this myself in the next week or so.  Should be 
very simple.

As a bonus, said database cache provides a convenient list of brain-dead 
DNS servers, which can be massaged into a "hall of shame".

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 27 Apr 2013 23:42:10 -0400

On Saturday, April 27, 2013 10:29:40 PM Stuart Gathman wrote:
> > Do you think it is in the scope of the charter language to add a 2119 MUST
> > for publishing type SPF when it's essentially unused?
> 

If we were keeping type SPF (99) in the protocol, something like that might be 
useful as a local mitigation of some of the brain damage, but it's not the 
kind of thing that could ever be standardized.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 28 Apr 2013 08:18:23 -0400

No hat.

On Sat, Apr 27, 2013 at 10:29:40PM -0400, Stuart Gathman wrote:

> I will be implementing this myself in the next week or so.  Should
> be very simple.

I believe it was Mencken who said, "For every complex problem there is
an answer that is clear, simple, and wrong." 

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Sun, 28 Apr 2013 09:07:18 -0400

But this isn't a complex problem. It is a simple solution.  The goal is 
for the docs to described what DEVELOPERS need to do, or should do, to 
prepare for the "Future."

o Select method of SPF lookups
    (_) SPF RRTYPE only
    (*) TXT RRTYPE only
    (_) BOTH (SPF/TXT)

Protocol Options are always part of the design game.

The only real problem, is that we currently do not have any control over 
this future (DNS Servers supporting unnamed type processing).  There is 
seriously a lack of communications going on. Where are these DNS 
vendors? Who are the key folks who have some "control" over this future?

---

From: Hector Santos <[email-masked]>
Date: Sun, 28 Apr 2013 09:48:33 -0400

I would like to suggest before eliminating (deprecating) SPF RRTYPE, in 
SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or 
whoever manages/codes the main infrastructure DNS servers) why they are 
not supporting unnamed type processing?  Are they even aware of this 
need?  I believe BIND supports it, but not Microsoft DNS server.  How 
about others?  Are they all/mostly based on Bind source code?

I tried to find out last March 2012 in the Microsoft Windows Server Tech 
Forum [1] if Microsoft DNS v5.0 supported RFC3597 [2] or unnamed type 
processing, and it wasn't known or I just didn't reach the right folks. 
It was surprising that not even Ace Fakey was not aware of this need.

--
HLS

[1] 
http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/5841e884-db22-42a1-8530-615a375662cc/

[2] http://tools.ietf.org/html/rfc3597

---

From: S Moonesamy <[email-masked]>
Date: Sun, 28 Apr 2013 08:06:43 -0700

Hi Hector,
At 06:48 28-04-2013, Hector Santos wrote:
>I would like to suggest before eliminating (deprecating) SPF RRTYPE, 
>in SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or 
>whoever manages/codes the main infrastructure DNS servers) why they 
>are not supporting unnamed type processing?  Are they even aware of 
>this need?  I believe BIND supports it, but not Microsoft DNS 
>server.  How about others?  Are they all/mostly based on Bind source code?

The other DNS implementations I know about are not based on the BIND 
source code.  There is some information in the slides at 
www.ietf.org/proceedings/64/slides/protut-0/protut-0.ppt

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 28 Apr 2013 11:36:37 -0400

> www.ietf.org/proceedings/64/slides/protut-0/protut-0.ppt

Good to know that the operational problems with new RR types were all solved 
in 2005 so everything we think we've seen go wrong since is just our 
imagination.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 28 Apr 2013 12:17:31 -0400

For those who don't have a PPT viewer on their com-putt-er, there is a 
web view of these slides:

https://docs.google.com/presentation/d/1V6slr2VyCUxSzJU2M1yidxrGjv85pK7rCrKmstMbMsM/pub?start=false&loop=false

Can you surmise what these slides say in regards to the key issues or 
dearth preventing SPF RRTYPE development?

--
HLS

On 4/28/2013 11:06 AM, S Moonesamy wrote:
>> this need?  I believe BIND supports it, but not Microsoft DNS server.
>> How about others?  Are they all/mostly based on Bind source code?
>

---

From: S Moonesamy <[email-masked]>
Date: Sun, 28 Apr 2013 09:40:00 -0700

Hi Hector,
At 09:17 28-04-2013, Hector Santos wrote:
>Can you surmise what these slides say in regards to the key issues 
>or dearth preventing SPF RRTYPE development?

There is a slide that mentions some DNS implementations.  It's not 
up-to-date information though.  Somebody will have to go through all 
that and do further research.  The slides do not mention the SPF 
RRTYPE.  There isn't any new information in them.

I will have to go through the SPFBIS mail archives again to be able 
to comment.  I will also have to discuss the entire matter with 
Andrew first.  My focus at the moment is to read the messages being 
posted to see whether there is any new information I may have missed.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 28 Apr 2013 10:42:15 -0700

On Sun, Apr 28, 2013 at 8:06 AM, S Moonesamy <[email-masked]> wrote:

>> SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or whoever
>> manages/codes the main infrastructure DNS servers) why they are not
>> supporting unnamed type processing?  Are they even aware of this need?  I
>> believe BIND supports it, but not Microsoft DNS server.  How about others?
>>  Are they all/mostly based on Bind source code?
>>
>

I don't think anyone is saying DNS servers are the main problem anymore.
Rather, it's firewalls, packet filters, and DNS-related UIs that aren't
accommodating to anything other than the basic types.  The RFC6686
experiments showed that these issues are still out there.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 28 Apr 2013 18:33:38 -0000

>experiments showed that these issues are still out there.

More to the point, 4408 has a technical problem with SPF records, we
debated at great length the various solutions, and decided that
getting rid of type 99 was the least bad.  I see no reason to revisit
that decision, noting that the recent blast from dnsext raised no new
issues and introduced no new facts (well, other than that Cloudflare
seems to be able to provision type 99.  Wahoo.)

I also note that in the six years from 4408 to 6686, the number of
type 99 records in the samples described went from zero to about 6000,
while the number of TXT records went from something to 400,000.  Even
if the number of TXT records doesn't grow at all, at that rate it will
take about 400 years for SPF to catch up.

That's an awfully long time to wait.  Heck, by then, we might even be
using IPv6.

R's,
John

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 28 Apr 2013 21:52:22 +0200

> kind of thing that could ever be standardized.

The fallback could be. 

The problem with the last posted draft is that it completely fails to
implement compatibility, just like 4408 did. Just it fails the other
way around. (or so I'm guessing based on the TXT or death! crowd talk
here.) There (much so because of a certain corporate email system tied
very close to a certain feature-deficient name-server. ) is a large
deployed base of kludgy TXT records out there, records that could be
SPF data or a groceries list. Or a text-only dungeon game. Let's assume
some of them are SPF records. We need to deal with them, and we need to
deal with the issue of broken middleboxes and broken name servers. People
probably will need to publish their grocery shopping lists in TXT in the
future too. The method describe upthread could very well be what we need.

I'd suggest that we satisfy the protocol purists in the ivory tower by
MUST'ing Type 99 SPF, but also MUST'ing a fallback to the old and b0rkened
TXT record, if certain criteria are met. Like SERVFAIL or timeout. But
not, perhaps, NXDOMAIN. 

Or maybe. I take great pride in and work a lot to avoid broken nameservers
and middleboxes, which makes me less exposed to their ideosynchraises.

Like a lot of us purists have written; we know how to deal with a very
long tail of BIND 4 and Server 2008R2 boxes lacking even 10 year old
features. This can be made to work.

/reporting from the ivory tower 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Used staples are good with SOY SAUCE!

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 Apr 2013 20:38:58 +0000

> TXT record, if certain criteria are met. Like SERVFAIL or timeout. But

The goal of reaching consensus is not to satisfy group X or group Y, but to come up with an answer that works well.   Putting in kludges that do not follow the spec because of other kludges that don't follow the spec doesn't make the situation better; that's why I changed my mind about this.

I'm not asking you to change your mind, but if you think the consensus is wrong, you need to say why it is wrong, not what you think it should be.   And why it is wrong needs to be something other than "because it wouldn't be what we'd do if we were designing from a clean slate," because that's not the current situation.   You should be arguing for something that works better in practice than what is being proposed; if you don't have a thing like that, you don't have an argument.

The fact that implementations currently are doing SPF and TXT queries in parallel is actually a really good illustration of the problem.   Think about why they are doing that.   Why aren't they doing what you propose above?   It would work, after all, for some value of work.

---

From: Stuart Gathman <[email-masked]>
Date: Sun, 28 Apr 2013 19:06:49 -0400

> The fact that implementations currently are doing SPF and TXT queries in parallel is actually a really good illustration of the problem.   Think about why they are doing that.   Why aren't they doi…
For this implementer, it was because I didn't think of it (until night 
before last), and apparently no one else did either.  If I had thought 
of it (keeping track of known broken nameservers) back in 2005, it would 
have worked much better to try SPF first (except for known broken 
nameservers).  It was just so much easier to try TXT first to get the 
mail flowing.  I am kicking myself!

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 Apr 2013 23:25:56 +0000

On Apr 28, 2013, at 7:06 PM, Stuart Gathman <[email-masked]> wrote:
> For this implementer, it was because I didn't think of it (until night before last), and apparently no one else did either.  If I had thought of it (keeping track of known broken nameservers) back in 2005, it would have worked much better to try SPF first (except for known broken nameservers). It was just so much easier to try TXT first to get the mail flowing.  I am kicking myself!

So you don't mind keeping the state around for 90 seconds?

---

From: Mark Andrews <[email-masked]>
Date: Mon, 29 Apr 2013 12:49:13 +1000

> take about 400 years for SPF to catch up.

ISC released BIND 9.4.0 which included SPF in Feb 2007, the first .0
released after RFC 4408 was published.
 
Libspf2, with type SPF, support didn't come out until October 2008.
No releases were made between Feb 2005 and October 2008[1].

The SPF camp complain about lack of type SPF record deployment yet
they took over 2 years to release a library which supported type
SPF when it was about a 10 minute fix to add support for it to the
library.

No effort was made to update documentation to say add both SPF and
TXT records as far as I can see to bring it into line with RFC 4408.

They then start measuring support before a hardware deprecation
cycle has even completed.

If I had known that there was going to be a survey about type SPF
support so early in the transition process which I assumed would
take 10 to 15 years or more to complete I would have added code to
complain about missing SPF records.

Now that you want to deprecate SPF I need to add code to tell those
that have SPF records without TXT records that they need to add TXT
records.

Mark

[1] http://www.libspf2.org/spf/.

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 29 Apr 2013 05:40:27 +0200

> The goal of reaching consensus is not to satisfy group X or group Y, but to come up with an answer that works well.   Putting in kludges that do not follow the spec because of other kludges that do…

Ok, I've been reading too much ITU specs last week. Design by comittee is contagious. 

> The fact that implementations currently are doing SPF and TXT queries in parallel is actually a really good illustration of the problem.   Think about why they are doing that.   Why aren't they doi…

I think this problem stems from the failure of middle boxes and name
servers (and to some extent full-service resolvers) to handle new record
types. Especially one vendor in the name server case. I think Hector made
a valid point; this will take time, and until broken devices are fixed,
people will opt to use TXT, because it is the quicker fix. That does not
mean we shouldn't fix it. It just means that while the mechanism and the
potential were there for allocating new RR types, it was so infrequent
that many believed it wouldn't happen. And we've got a lot of outdated 
stuff to deal with. No wonder with DNS now being close to 30 years old. 
 
Remembering the Design by comittee statement from above, I still believe 
that we need to handle this, and my suggestion is this, to preserve the 
functionality people depend on today while limiting the long-run 
damage to the DNS from parseable code in comments. 

We should 

* Mandate SPF/99. This is for the long run. 

* For this specification we're doing now, _also_ mandate checking TXT, 
  if <some_failure_mode> indicates that SPF RR is either not present
  or not reachable. 

* The specification should allow entering TXT records, but should 
  state that their usage SHOULD be limited to damage control in the face
  of broken infrastructure. 

* The specification could allow dual records to be entered, providing they
  tell the same story, to cater for other peoples broken infrastructure.

* Subsequent versions of this standard could evolve, given the 
  evolution of middle boxes and name servers and resolvers into
  modern standards (like not more than 10 years old) and then 
  demote TXT gradually. 

* Some effort needs to be made to come up with a decision logic to 
  discern between zone failure / TXT in lieu of SPF / path failure, 
  so as to recheck and/or abort properly and timely. 

* The result of the above process might be expensive to achieve,
  why I think we should SHOULD a caching mechanism for scalability.
  Especially so since path failures often involve pathetic caching
  failure as well (caching or lack thereof in full-service resolvers,
  that is.)

* To help with scalability, we might want to prescribe via SHOULD a
  longer TTL for records involved. This is bordering on ops, but might
  take a lot of load away. Even though I'm pretty certain 2x question
  rate is no major issue for most.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Eisenhower!!  Your mimeograph machine upsets my stomach!!

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 28 Apr 2013 23:49:48 -0400

On Monday, April 29, 2013 05:40:27 AM Måns Nilsson wrote:
> Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Sun, Apr 28, 2013 
at 08:38:58PM +0000 Quoting Ted Lemon ([email-masked]):
> > The goal of reaching consensus is not to satisfy group X or group Y, but
> > to come up with an answer that works well.   Putting in kludges that do
> > not follow the spec because of other kludges that don't follow the spec
> > doesn't make the situation better; that's why I changed my mind about
> > this.
> > I'm not asking you to change your mind, but if you think the consensus is
> > wrong, you need to say why it is wrong, not what you think it should be. 
> >  And why it is wrong needs to be something other than "because it
> > wouldn't be what we'd do if we were designing from a clean slate,"
> > because that's not the current situation.   You should be arguing for
> > something that works better in practice than what is being proposed; if
> > you don't have a thing like that, you don't have an argument.
> > 
> > The fact that implementations currently are doing SPF and TXT queries in
> > parallel is actually a really good illustration of the problem.   Think
> > about why they are doing that.   Why aren't they doing what you propose
> > above?   It would work, after all, for some value of work.

This is a broken proposal that would be harmful to interoperability if 
implemented.  The reasons why have been repeatedly explained in this thread 
and should be pretty obvious.

Scott K

---

From: Mark Andrews <[email-masked]>
Date: Mon, 29 Apr 2013 14:24:57 +1000

In message <[email-masked]>, "John R Levine" writes:
> > The SPF camp complain about lack of type SPF record deployment ...
> 
> The message to which you replied, and which you quoted, pointed out that's 
> not the reason we're deprecating type 99.
> 
> If you're not even going to read the messages you're replying to, I don't 
> see any point in wasting further time on this.

Last time I looked at the definition of "technical reason" it
didn't include "fail to spend money to upgrade equipment to
be compatible with spec".

---

From: Mark Andrews <[email-masked]>
Date: Mon, 29 Apr 2013 15:02:35 +1000

In message <[email-masked]>, =?utf-8?B?TcOlbnM=?= Nilsson writes:
>
> Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Sun, Apr 28,
> 2013 at 08:38:58PM +0000 Quoting Ted Lemon ([email-masked]):
> > The goal of reaching consensus is not to satisfy group X or group Y,
> > but to come up with an answer that works well.   Putting in kludges that
> > do not follow the spec because of other kludges that don't follow the
> > spec doesn't make the situation better; that's why I changed my mind
> > about this.
>
> > I'm not asking you to change your mind, but if you think the consensus
> > is wrong, you need to say why it is wrong, not what you think it should
> > be.   And why it is wrong needs to be something other than "because it
> > The fact that implementations currently are doing SPF and TXT queries
> > in parallel is actually a really good illustration of the problem.
> > Think about why they are doing that.   Why aren't they doing what you
> > propose above?   It would work, after all, for some value of work.
>

New types have been added very year or so for the life of the DNS:

Base spec 1987, RP 1990, X25 1990, ISDN 1990, RT 1990, AFSDB 1990,
NSAP 1992, GPOS 1994, AAAA 1995, LOC 1996, SIG 1997, KEY 1997, NXT
1997, KX 1997, PX 1998, DNAME 1999, ATMA 2000, OPT 2001, APL 2001,
DS 2003, DNSKEY 2004, RRSIG 2004, NSEC 2004, PSECKEY 2005, SSHFP
2006, CERT 2006, SPF 2006, DLV 2006, NSEC3 2008, NSEC3PARAM 2008,
HIP 2008, URI 2011, TLSA 2012, NID 2012, L32 2012, L64 2012, EUI48
2013, EUI64 2013.

Some of those record are infrequently used but others are wildly
deployed and used including behind firewalls inspect DNS record
contents.

> M=C3=A5ns Nilsson     primary/secondary/besserwisser/machina

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Apr 2013 16:49:57 +0200

On Fri 26/Apr/2013 02:15:43 +0200 Doug Barton wrote:
> 
> 4. Lots of messages along the lines of, "We've always used TXT for
> this, so we should keep using it." These arguments all seem focused
> around the concept that having 2 ways to do the same thing is kind of
> a pain, so let's just use the one that is most popular.
> 
> [...]
> 

Maintaining spf records --whether SPF or TXT-- is a pain in the first
place, especially for larger organizations that have lots of IP
addresses and internal chains of responsibility delegation.  An
annoying feature is the recommendation to stay within UDP size limit,
which forces to use included records containing several lists of
addresses each.

Asking to duplicate the records on top of that is not a trivial
request.  There are no automated tools that duplicate records to
different type, and if RR types make any sense at all, I'd guess there
will never be.  There are domains with SPF and TXT records different
from one another, hence the possibility to introduce errors or
inaccuracies is non-zero.  On the other hand, the domain maintainer
gets zero advantages.  They just wont' do it,  people would rather
stop using spf than mess it up with double records.  Is that a
technical argument?

I'm surprised that nobody objects that spf syntax uses a variable
number of characters, not less than 7, to express an IPv4 address,
while the rest of the world use exactly 4 bytes.  If it has to be
text, why not TXT?

---

From: Stuart Gathman <[email-masked]>
Date: Mon, 29 Apr 2013 11:14:27 -0400

Long ago, Nostradamus foresaw that on 04/28/2013 10:49 PM, Mark Andrews
> that have SPF records without TXT records that they need to add TXT
Mark, the problem wasn't lack of deployment.  The problem was TIMEOUTs
from certain DNS servers/firewalls on unexpected RR types.  This was a
frustrating problem, and I wish I had put more thought into solving it.

Dear WG, please note that publishing SPF *only* (as Mark mentions)
solves the problem also - as client libraries have had a long time to
check both records (and pyspf support both types very early).  Most
libraries do check TXT first, to avoid the TIMEOUT problem.   But
recording domains that TIMEOUT on SPF queries solves the problem on the
client end and allows checking SPF first.

---

From: Stuart Gathman <[email-masked]>
Date: Mon, 29 Apr 2013 11:24:22 -0400

Long ago, Nostradamus foresaw that on 04/28/2013 07:25 PM, Ted Lemon
> So you don't mind keeping the state around for 90 seconds?
The idea is that you endure the TIMEOUT the first time only.  If a TXT
query then succeeds, you know you are dealing with a braindead
server/firewall, and record the domain and timestamp in a database.  
You check the database before making any SPF (type 99) query to avoid
trying known braindead servers.

---

From: Stuart Gathman <[email-masked]>
Date: Mon, 29 Apr 2013 11:31:45 -0400

Long ago, Nostradamus foresaw that on 04/26/2013 11:38 AM, Mark Andrews
+1

But I think we need to suggest at least one practical workaround for the
braindead DNS/firewall problem - which is what has prompted the current
retreat from type 99.  (And parallel queries as suggested in 4408 was
not practical.)

---

From: Stuart Gathman <[email-masked]>
Date: Mon, 29 Apr 2013 11:45:19 -0400

Long ago, Nostradamus foresaw that on 04/29/2013 10:49 AM, Alessandro
> stop using spf than mess it up with double records.  Is that a
RFC 4408 has said SHOULD publish both SPF and TXT for many years now. 
As Mark Andrews pointed out, an equally simple way to avoid the
duplication is to say SHOULD publish *only* SPF.  That still leaves
leeway for checkers to check TXT.  As long as there is a practical
workaround for the braindead DNS server/firewall problem, there is no
reason *not* to do this.

Very *un*technical observation:
I was so pleased when upgrading mail servers to RHEL6 - the supported
BIND *finally* has the SPF keyword!  I had been running scripts to
generate hex coded TYPE99 records for older BIND versions.   How
disappointed I was to shortly afterwards read that SPFBIS was dropping
SPF entirely!  :-(

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Apr 2013 18:00:16 +0200

> deployed and used including behind firewalls inspect DNS record

May I ask how many of those types have a TXT equivalent?

A good deal of this thread assumes that TXT records are bad.  Would
anyone say why?  I read RFC 5507, and I'd agree that not using a
prefix such as _spf creates unneeded conflicts.  However, I'm unable
to understand the reasons why "TXT is evil".  Do we need to create new
types whenever the use changes, as we do file extensions?

---

From: Hector Santos <[email-masked]>
Date: Mon, 29 Apr 2013 12:28:32 -0400

Exactly, and it all be done with a installation wizard by the 
implementation package.  It can do do a test and spit out a warning:

+-[ SPF Setup Check ]-------------------------------------------+
|                                                               |
| Your DNS resolver does not appear to support SPF RRTYPE       |
| and/or unnamed types processing.  Your setup will default to  |
| TXT only SPF queries.                                         |
|                                                               |
|                [OK] [CANCEL] [RETRY]                          |
+---------------------------------------------------------------+

Keep in mind issues will be random and based on the path a DNS client takes.

This is really not a big thing.  We are making it a big thing.  The goal 
of the functional specs is to spell it all out for the developers to 
decide what to do.

But also we really do need to get a handle on what exactly are the 
barriers here:

     DNS Servers?
     DNS Proxies at NATs, Routers?
     Firewalls?

Overall, recursive queries need to support a passthru concept for 
unnamed types.  Thats the problem I believe overall, that even your own 
local resolvers is supportive, there could be an uplink that doesn't/

That was I recall seeing even with SRV support.  Even XMPP had a dual 
discovery concept and I recall the many earlier failures and fall backs 
to A records logged.  Overtime, it finally began to work better.

--
HLS

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Apr 2013 17:31:53 +0000

> trying known braindead servers.

I think turning your SPF resolver into a non-compliant caching resolver is a bit heavyweight, though.   That's effectively what you're doing here...

---

From: Mark Andrews <[email-masked]>
Date: Tue, 30 Apr 2013 06:51:55 +1000

> frustrating problem, and I wish I had put more thought into solving it.

Servers that drop requests are not RFC 1035 compliant and they are
mostly gone as those that did it also tended to dropped AAAA lookups
which a MTA can't avoid.  And not there are not and never have been
a lot of them.

If your firewall drops records.  REPLACE IT with one that isn't
BROKEN.  If you want to use SPF you need to make sure *your*
equipement is compliant with it.  This what we tell sites that
have problems with EDNS packets.  Guess what, it works.

> client end and allows checking SPF first.

Or you can send both queries in parallel and use whichever returns a
record first.  

Or send a SPF request then send a TXT request 200ms later if you havn't
got a response yet and again use whichever returns a RRset first.

If a site gets lots if blow back they will fix their servers.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Apr 2013 14:03:09 -0700

Folks,

This is one of those threads that will go on for as long as people seem 
to think they need to keep posting, but it won't make any "progress" or 
resolve any issues.

For that matter, I have no idea what anyone thinks they are 
accomplishing by continuing to post on it, which raises the question of 
why they keep bothering.

And 'bothering' is what this thread mostly /is/ doing, in reducing the 
S/N ratio.

Please shut the thread down.

d/

---

From: Mark Andrews <[email-masked]>
Date: Tue, 30 Apr 2013 07:05:12 +1000

> types whenever the use changes, as we do file extensions?

It is TXT without a prefix that is bad.  It overloads the use of
the TXT record.  It does not seperate SPF use from other uses.  It
is just bad engineering to use it long term.  Experimenting with TXT
is fine.

Mark

---

From: Hector Santos <[email-masked]>
Date: Mon, 29 Apr 2013 17:15:15 -0400

If anyone wishes to see one aspect of what is wrong with IETF Diversity, 
then see whats going on in SPF BIS WG where a key IETF cog essentially 
attempts to shutdown discussions and communications, attacks posters 
which by my estimate were making progress.

Progress is a status quo - DON'T CHANGE THE RFC4408 SPECIFICATION in 
SPFBIS.

Many in DNS community do not agree with the change of removing a long 
term migration path to a SPF RRTYPE.  In fact, not changing the existing 
specification would end the issue and hopefully satisfy all principles.

--
HLS

---

From: Mark Andrews <[email-masked]>
Date: Tue, 30 Apr 2013 09:07:42 +1000

The really annoying thing is that SPF is techically superior
	to TXT is lots of ways.

	1. It uniquely identifies the roll of the record.

	2. As SPF records are singletons you don't need to identify
	   and remove the old record when updating.  You can just
	   remove all SPF record and add the replacement.

	   For TXT you need to lookup the existing RRset, extract
	   the v=spf1 record from it.  You then need to create a
	   UPDATE message to delete just that record as well as add
	   the new TXT record.   You then have to hope that no one
	   else is performing a simultanious update as you may get
	   two TXT v=spf1 records in the RRset.

	The complains about using SPF is that there are broken
	firewalls and some servers drop queries for it, some registars
	don't support it.

	For firewalls, fix/replace the firewall if you intend to
	deploy SPF and it doesn't support it.  It is total !@##@#
	that firewall are incapable of handling new DNS record
	types.  New records we exected to occur from the very
	beginning and have been coming out regularly ever since the
	DNS was invented.  Firewall vendors that are incapable of
	handling new DNS types are incompetent and do not deserve
	repeat business.

	For servers than drop SPF queries they really are at the
	noise level.  When you identify one you complain to the
	owners of it.  Yes, that does work.  We needed to do that
	for AAAA records.

	For registrars, change registrar to one that does.

	Mark

---

From: S Moonesamy <[email-masked]>
Date: Mon, 29 Apr 2013 17:38:55 -0700

Hi Dave,
At 14:03 29-04-2013, Dave Crocker wrote:
>Folks,
>
>This is one of those threads that will go on for as long as people 
>seem to think they need to keep posting, but it won't make any 
>"progress" or resolve any issues.
>
>accomplishing by continuing to post on it, which raises the question 
>of why they keep bothering.
>
>And 'bothering' is what this thread mostly /is/ doing, in reducing 
>the S/N ratio.
>

May I humbly suggest leaving this matter to the SPFBIS WG Chairs?

Thanks,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Apr 2013 17:42:14 -0700

> May I humbly suggest leaving this matter to the SPFBIS WG Chairs?

How long should we wait?

d/

---

From: S Moonesamy <[email-masked]>
Date: Mon, 29 Apr 2013 17:43:17 -0700

Hi Hector,
At 14:15 29-04-2013, Hector Santos wrote:
>If anyone wishes to see one aspect of what is wrong with IETF 
>Diversity, then see whats going on in SPF BIS WG where a key IETF 
>cog essentially attempts to shutdown discussions and communications, 
>attacks posters which by my estimate were making progress.
>
>Progress is a status quo - DON'T CHANGE THE RFC4408 SPECIFICATION in SPFBIS.
>
>Many in DNS community do not agree with the change of removing a 
>long term migration path to a SPF RRTYPE.  In fact, not changing the 
>existing specification would end the issue and hopefully satisfy all 
>principles.

The following messages were posted to the SPFBIS mailing list:

http://www.ietf.org/mail-archive/web/spfbis/current/msg03593.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg03598.html

It has also been mentioned that there are two long threads at:

http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg13025.html

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 29 Apr 2013 17:57:54 -0700

Hi Dave,
>How long should we wait?

I'll have to review all the messages posted on the thread and then 
discuss the matter with Andrew Sullivan.  My current focus is the 
reviews and the follow-up.  I am copying this message to the 
Responsible Area Director in case I am doing anything inappropriate.

Regards,
S. Moonesamy (SPFBIS WG co-chair)

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Apr 2013 17:59:22 -0700

> I'll have to review all the messages posted on the thread and then

ack. tnx.

d/

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 30 Apr 2013 12:29:51 +0200

> I think turning your SPF resolver into a non-compliant caching resolver is a bit heavyweight, though.   That's effectively what you're doing here...

Or not. It is the application that is told what to ask for. The resolver
is (in all its brokenness) unaffected. Lithmus test: Can another application 
ask the same full-service resolver about SPF/99 and get responses? 

If the resolver fails on all SPF/99; why is it so? 

- is it because it is broken? 

- is it because it is behind something broken? 

Both cases need workaround if it is impossible to do the proper thing
and fix the bad resolver/path.

If the resolver returns proper data (ie. SPF/99 from where it is set up
and NODATA from where it is not), the application should cache this and
ask the right questions henceforth.

In this case the resolver is not broken and the application adapts to
the effects of 4408 semantics.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Somewhere in Tenafly, New Jersey, a chiropractor is viewing "Leave it
to Beaver"!

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 30 Apr 2013 12:39:40 +0200

Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Mon, Apr 29, 2013 at 06:00:16PM +0200 Quoting Alessandro Vesely ([email-masked]):
 
> to understand the reasons why "TXT is evil".  

First, it's a parsing problem, since it requires additional processing in
determining whether the TXT record at hand is SPF or not. Having Type
99 records limits the problem space. It does not, however eliminate it.

Second, the risk of fallback to TCP (I'm not sure there even IS a
software product that does not support SPF/99 while doing EDNS0, bar a
few BIND versions.) is limited when TXT megablobs like 

ut.edu. IN TXT 

aren't to be encountered and sieved off enroute to the SPF data. 

Third, a DNS update operation aimed at altering the SPF contents for
a given node in DNS does not have to discern between cookie recipes
and SPF data if the SPF data has a dedicated RRtype. If TXT is used all
sorts of Heath Robinson machinery need to be employed, often in recursive
fashion, to determine what to keep and what to remove. The risk of manual
intervention is quite high. (Mark Andrews noted this in another thread)

Finally (and I'm afraid the SPFbis crowd could hardly care less, but 
that is just this junior protocol nerd being jaded) using TXT, expecially
in the face of an existing special type, sets a bad precedent. The DNS
is designed to evolve. We as DNS people _need_ it to evolve. We've just
pulled a big change through, DNSSEC, which took all of 15 years and
a number of RFCen. And a sizable bunch of the new record types Mark
Andrews outlined upthread.

DNSSEC makes the DNS not only secure to tampering, it also enables a big
spectrum of new uses; DANE (RFC 6698) being one of special importance
to the continued evolution of the Internet.

This new level of trust in DNS published data could not have happened
without a lot of work in getting name servers upgraded and new features
rolled out. As a result, a lot of software supports DNSSEC. (some of the
software available a few years back is investigated in this excellent
report: https://www.iis.se/docs/DNSSEC-Admin-tools-review-Final.pdf)

With SPFbis going out to a lot of implementers who are email people first
and perhaps DNS operators a distant fourth, and in effect telling them
"Well, this DNS stuff that is absolutely impossible to change is something
you have to kludge around using this comment datatype and hope that the
parser won't barf on someones cookie recipe" a seriously bad attitude is
cemented, where other more pressing changes to DNS might be impossible
to roll out because nobody thinks the DNS can be changed.

Well, guess what, it can. 

To be able to evolve further in the future, one of the observations from
the earlier research in this wg (6686) is indeed important to keep in
mind: There is a very long tail of old software out there. This, however,
is not news to the DNS community. DNSSEC, EDNS0, TSIG, and a lot of new
RRtypes were pulled in the system and continue to work in spite of very
old and sometimes very broken software still in operation.

This takes work, and work best performed in -bis wg contexts where there 
is operational experience.   The data in 6686 looks compelling and I can well
understand why the wg felt that the pain associated with DTRT would be 
unbearable, and in the light of that, modifying 4408 3.1.1 to just
discard SPF/99 is the easy way out.

We can do better than that, though. As I hopefully have described above, 
there are valid reasons to continue prescribing SPF/99. The text in 4408
3.1.1 does a bad job of that, and there probably is the reason why TXT
deployment is so overwhelming. Nobody needed to even think of migrating
out of the lab. 

My suggestion stands roughly as before; 

* SPF/99 is a MUST,

* TXT containing SPF data MAY be used IF operations reveal problems with
  local or remote intermediate infrastructure,  but this does not remove
  the requirement that SPF/99 be present to be compliant. We can't
  dictate what people run, but we should point out a good model. 

* Querying should reflect above so that SPF/99 MUST be sought first. 

* If SPF/99 query fails in obvious or suspicious ways, not exhausting
  the posibility of a TXT being present, a query for TXT SHOULD be made.

* State for this (ie. the failure/success for given node names wrt SPF
  or TXT) SHOULD be kept but not too long. Probably less than 24h. 
  The validating application is responsible for this. 

SPFBIS set out to codify and improve 4408, and this is a
backwards-compatible and sustainable evolution of 4408 that won't harm
the DNS or the email vetting community.

> Do we need to create new

As long as we get traction on using SPF/99, no. The rest can be done
in-band. 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Maybe we could paint GOLDIE HAWN a rich PRUSSIAN BLUE --

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 30 Apr 2013 14:40:45 +0200

> 99 records limits the problem space. It does not, however eliminate it.

Yeah, sanitizing input is always needed.

> aren't to be encountered and sieved off enroute to the SPF data. 

There are some good points:  EDNS0 would allow to relax the size a
bit, which would be a good relief given the annoyance of breaking down
lists of addresses into "include" records.  This was discussed and the
conclusion was that EDNS0 is not yet ready.

Of course, having the syntax and size checks before publishing would
be a great advantage, but this is so clearly not yet ready that it
wasn't even discussed.  I guess it's the same using SPF/99.

> intervention is quite high. (Mark Andrews noted this in another thread)

You mean the zone file editor?  Among the stuff of ut.edu there are
snippets with CNAME that seem to be intended to belong to different
records.  Yeah, TXT is not syntax checked.  But then so is SPF/99.

> Andrews outlined upthread.

That's the point I made:  Successful new types have a binary format
which is syntax checked before going to the wire.  I wish SPF was like
that, but it's not.  A /real/ SPF type would be very different from
the fig leaf we've been using til now.

> report: https://www.iis.se/docs/DNSSEC-Admin-tools-review-Final.pdf)

TXT can be signed like any other record.

> Well, guess what, it can. 

Good news.  However, it is not by asking mail admins to do something
that is not yet supported that the DNS will change.  DKIM may be a
better example, because although it is computationally more complex,
it is administratively simpler than SPF.  When you set up DKIM you
create keys, and the utility program terminates displaying "Hey, I
prepared a TXT record for you to insert in the zone file."  It is a
public key, it wouldn't hurt to publish it anyway.  The application is
just unable to do it.  Why?

With SPF, in addition, the operator is required to manually keep track
of all the data and compose the domain's policy.  Aren't computers
able to do that?  No, there is the DNS that cannot be changed.  Oh,
well...

Yes.

Yes.

> My suggestion stands roughly as before; 

For who?

>   dictate what people run, but we should point out a good model. 

That's error-prone.  It roughly doubles the difficulties of
maintaining a domain policy, and you cannot ask users to do that
without offering some advantages in exchange.

> * Querying should reflect above so that SPF/99 MUST be sought first. 

Querying a type first doesn't guarantee that the replies arrive in the
same order.

>   the posibility of a TXT being present, a query for TXT SHOULD be made.

Ah, you mean _after the timeout_?  No thanks.

>   The validating application is responsible for this. 

24h seems to be a lot.  Negative caching of servfail is recommended to
be around five minutes, if at all.  SPF would never have used DNS if
the validating application had been required to maintain its own cache.

> the DNS or the email vetting community.

Planning it that way would not harm, indeed, because of the silent
convention that nobody will actually do it.  Fig leaf.

A realistic plan to introduce a new type must not provide for using
TXT instead.

> As long as we get traction on using SPF/99, no. The rest can be done

Wouldn't it be savvier to start with easier types first?  How about a
RIPE type for the maintainer ID?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Apr 2013 12:44:46 +0000

On Apr 30, 2013, at 6:29 AM, Måns Nilsson <[email-masked]> wrote:
> Or not. It is the application that is told what to ask for. 

No, you misunderstand me.   What I mean is that your "application" has *become* a non-compliant caching resolver.   It is doing name resolution; it is caching the results; but it is not following the protocol specification.   So this is not, IMHO, a reasonable alternative.

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 30 Apr 2013 16:22:31 +0200

> No, you misunderstand me.   What I mean is that your "application" has *become* a non-compliant caching resolver.   It is doing name resolution; it is caching the results; but it is not following t…
 
I see what you mean. I might agree, and it is not necessarily
something needed, so I'm prepared to drop it.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Look DEEP into the OPENINGS!!  Do you see any ELVES or EDSELS ... or a
HIGHBALL?? ...

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 30 Apr 2013 17:57:25 +0200

> workaround for the braindead DNS server/firewall problem, there is no

Neither there is a reason to do it.  We could as well involve
Leprechauns, but a principle of parsimony, economy, or succinctness
suggests not to.

> disappointed I was to shortly afterwards read that SPFBIS was dropping

I agree it's disappointing.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 30 Apr 2013 18:28:52 +0200

> 	   two TXT v=spf1 records in the RRset.

That's true, except that one has TXT records anyway.

> 	firewalls and some servers drop queries for it, some registars

Nits, as explained below.  The basic fact that killed the SPF type is
the ability to use TXT as a replacement.  There must be an analogous
of Gresham's law:  "Bad types drive out good ones."

> 	For registrars, change registrar to one that does.

While it's too late for SPF, we can learn this lesson.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 30 Apr 2013 19:16:07 +0200

On Fri 26/Apr/2013 21:13:07 +0200 Andrew Sullivan wrote:
> example.com.

By mandating a fixed prefix we'd have invaded a namespace.

> That's one of the things those of us who find this an incredibly
> ugly wart object to: it uses one datatype for other data. More
> precisely, it uses a by-definition-unstructured datatype for 
> structured data.  It's unquestionably datatype abuse.

I can still write "v=spf1 ip6=foo".  I'll get permerror but it is
possible, while I cannot write foo in an AAAA record.  There's a
difference between "possibly structured" but still (potentially)
unstructured and actually structured.

On the other hand, I don't think TXT was devised to publish
Shakesperean sonnets or other poetic epigrams.  If it's supposed to be
machine readable text, it has to obey some lower level kind of syntax,
which can be called structured.

> I think the only question is whether the ship has left the barn;
> the answer is yes.

And that's the real point.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 30 Apr 2013 11:46:23 -0700

Hi Stuart,
>client end and allows checking SPF first.

Please note that I am not ignoring your comments.  If you find that I 
missed anything please email me or raise it on the mailing list.

Thanks,

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 May 2013 11:04:52 +1000

> That's true, except that one has TXT records anyway.

	nsupdate
	update del example.com SPF
	update add example.com 3600 SPF v=spf1 ....
	send

	txt=`dig +short example.com TXT | \
	sed -n -e '/^"v=spf1 /s/^/update del example.com TXT /p' \
	       -e '/^"v=spf1"$/^/update del example.com TXT /p'`
	nsupdate << EOF
	$txt
	update add example.com 3600 TXT v=spf1 ....
	send
	EOF

	But that doesn't work for 'example.com TXT "v" "=" "s" "p" "f" "1"'
	which is a perfectly legal SPF record.

	sed -n -e '/^"v=spf1 /s/^/update del example.com TXT /p' \
	       -e '/^"v" "=spf1 /s/^/update del example.com TXT /p' \
	       -e '/^"v" "=" "spf1 /s/^/update del example.com TXT /p' \
	       -e '/^"v" "=" "s" "pf1 /s/^/update del example.com TXT /p' \
	       -e '/^"v" "=" "s" "p" "f1 /s/^/update del example.com TXT /p' \
	       -e '/^"v" "=" "s" "p" "f" "1 /s/^/update del example.com TXT /p' \
	       -e '/^"v" "=" "s" "p" "f" "1" " /s/^/update del example.com TXT /p' \
	       -e '/^"v=spf1"$/^/update del example.com TXT /p'`
	
	And keep going because the delete needs the rdata to be a
	perfect match to identify the record to be removed.

	I'm sure I could come up with a more compact way of identifying
	a spf record but it wouldn't be needed if people published type
	SPF.

>p > 	firewalls and some servers drop queries for it, some registars
> > 	don't support it.
>