On Wednesday, August 21, 2013 22:05:37 Måns Nilsson wrote: > Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender > Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) > to Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting > Scott Kitterman (scott@kitterma > > > Apparently. > > > > Translated: > > > > RFC 4408 was in error because it didn't abandon it's installed base. I > > gather this is an error you propose to rectify. > > Well, almost. 4408 sort of blunders about like the elephant in a china > shop wrt. query method and depreciation. > (As I have been sternly lectured off-list that I do not understand > the SPF payload and therefore am in no position to discuss the > DNS usage, I'd like to assert that the payload syntax matters > marginally, if at all, for the discussion about which DNS records > to use and how.) > > Specifically, 4408 section 3.1.1 should be updated to: > > * A domain SHOULD use SPF and MAY use TXT. The latter is only suitable if > SPF is impossible to publish. This is the point where you abandon the installed base. Particularly given the charter, I think this is an inappropriate approach. > * If it is possible to use SPF as a result of having modern provisioning > systems, SPF MUST be used and consequently, TXT SHOULD NOT be used. (I'd > like MUST here, but I'm not certain it flies.) If SPF and TXT coexist, > they MUST agree wrt content. draft-schlitt-spf-classic-02, which became RFC 4408, had this MUST when it was approved by the IESG. Since at the time of IESG approval, the RRTYPE for SPF hadn't been allocated yet, they - by necessity - approved a paper design. Fortunately the RRTYPE was allocated sufficiently before AUTH48 that we were able to experiment with running code and determine that this MUST was operationally extremely problematic, so it was removed as part of the AUTH 48 review. > * The notion of a sunset date as introduced by Mark Andrews, is interesting. > > Section 4.1.1 in 4408 should be altered to direct implementations to > FIRST look for SPF and then _perhaps_ (I'm open for discussion) ask for > TXT, thus creating an incentive to improve performance by serving SPF > rather than TXT. After a possible sunset, TXT MUST NOT be queried for. The performance implications are more generally constraining on the receive side in high volume mail systems. Adding a second set of sequential DNS queries is a non-starter. It's much more efficient to go straight to TXT where 99%+ of the time I'll get a correct answer [there are a minute number of domains that publish SPF only, but virtually all type SPF publishers also publish TXT]. I think you're putting the performance implications on the wrong end of the conversation. Let's say we get to this magical sunset date, whose behavior do you think it will influence if they are finding the TXT queries still useful (if they aren't, they won't do it and you don't need the sunset date)? > The preference for SPF vs TXT that is present in 4408 is to be kept > unaltered. Here's a related conundrum that I haven't seen operationally (due to limited RRTYPE SPF deployment, but I have seen similarly for real in the fallback to v=spf1 records in the SenderID RFCs). It's an example of why you can't ignore the payload. One of the widely used features of SPF is the "include" mechanism. It allows a sender to authorize the hosts of a third party to send mail on its behalf. It also allows SPF records to be chained together to publish more information while staying in the standard UDP packet limit. Here's an example for the latter from Microsoft's current SPF record: v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com ... A key aspect of "include" is that the targe domain MUST have an SPF record. If it doesn't, it's a "permerror" - permanent error. Let's imagine for a moment that example.com has this record published in RRTYPE SPF: v=spf1 a include:example.org -all Then let's consider example.org and imagine that, like most SPF participants today, they have their record published in RRTYPE TXT only: v=spf1 a -all A receiver, as you suggest, checks RRTYPE SPF when they get mail from example.com. Their SPF verifier processes the "include" mechanism and determines it needs to do a lookup for example.org's SPF record. They query RRTYPE SPF and they get ANSWER: 0 in return. Should this verifier: 1. Return a "permerror" because the target domain of an "include" doesn't exist? 2. Press on and query RRTYPE TXT, get an SPF record back, and finish the transaction without error? RFC 4408 doesn't help us here because it's treatment of the TXT/SPF coexistence model is not complete. I have said before that I don't think an effective transition model exists nor can it be created. I think Olafur Gudmundsson's suggestion that 4408bis document this use of TXT as an architectural wart and move on is a good one. I think this is a symptom of the larger problem that most initial development work in this space is done outside the IETF and only brought to the IETF when it's reasonably well baked. This is true for SPF, DK -> DKIM, and DMARC, all of which use TXT. I would encourage those who want this to be different in the future to make contact with the people involved in DMARC (I wasn't) and ask them what it would have taken to get them to consider a new RRTYPE in their design. Whatever those barriers are, that's what needs to be addressed. Focusing to trying to "fix" SPF shouldn't be the priority. It is what it is. Scott K