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 Standard2013-08-21 17:27:36Subject: 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 04:52:59PM -0400 Quoting Scott Kitterman (scott@kitterma 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@kittermaApparently.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. As I'm thinking about migration here, let's be generous. Allow publication of TXT too, even if SPF is possible, but then not alone. * 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. Hence my comment about perhaps flying. * 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. Why? There is caching. DNS queries are cheap. The problem of overloading TXT is IMNSHO so bad that it is worth the cost of additional queries; especially if we can collaborate on text to stimulate migration by constructing and specifying algorithms that are faster when using SPF rrtype only. It's much more efficient to go straight to TXT where (ITYM TODAY it is much more efficient and that might change) 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. Indeed, and I was inexact in endorsing current text. What I meant was this sentence: 2. If any records of type SPF are in the set, then all records of type TXT are discarded. (section 4.5, record selection process) I have said before that I don't think an effective transition model exists nor can it be created. I think this stems from two things, both fixable; * The somewhat confused "migration" model of 4408 creating a "cheap escape" for vendors and users. * The lack of normative language stating that SPF MUST be used. 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 happen to think that this wart is malign and will create undesirable growth, as has been proven with a number of other spam-stomping systems using TXT. Short of amputation I think we can justify a lot more surgery than the present make-up. 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. I agree. Focusing to trying to "fix" SPF shouldn't be the priority. It is what it is. SPF is a flagship case for the "use a TXT record and continue to IPO" fast and sloppy crowd. It needs correcting. Badly. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 All of life is a blur of Republicans and meat!
signature.asc |
|