ietf
[Top] [All Lists]

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

2013-08-21 17:27:36
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

<Prev in Thread] Current Thread [Next in Thread>