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 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@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.
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!
Attachment:
signature.asc
Description: Digital signature