Subject: [spfbis] Possible new issue: deprecate ptr/%{p}

From: Arthur Thisell <[email-masked]>
Date: Wed, 7 Mar 2012 06:39:38 -0800 (PST)

I realize I'm very late in suggesting issues to be discussed, so I don't know  if the ADs will even consider my two possible issues.   Their ruling isn't that important to me because I don't think these are critical issues and I can live with them not being considered.   I'm breaking up the two issues into two posts for ease of threading...

Second issue:  Should the ptr: mechanism and the %{p} macro be deprecated?

Already in RFC 4408, it says: 

   Note: Use of this mechanism is discouraged because it is slow, it is
   not as reliable as other mechanisms in cases of DNS errors, and it
   places a large burden on the arpa name servers.  If used, proper PTR
   records must be in place for the domain's hosts and the "ptr"
   mechanism should be one of the last mechanisms checked.

Microsoft wanted this to go away entirely, for these reasons.

This note in the RFC is terse, so let me lay out the case against these more fully.

Maybe things have changed dramatically while I've been asleep, but the in-addr.arpa namespace is a mess.  It is poorly maintained, to the point where in some countries, even ISPs can't get delegations for their IP addresses.  Queries to this name space often time out, and even when they give an answer, the answer is often bogus.

Now, with all the other mechanisms/modifiers, the publisher usually has a great deal of control over the nameservers referenced and the content that gets returned.   An mx: mechanism that isn't working right is likely going to cause a lot of other problems so it will be noticed and fixed.   The ptr:/%{p} stuff, on the other hand, is under the loose control of the sender, not the publisher.   If someone sends mail from a host within a bogus in-addr space, the receiver suffers with the timeouts.   The SPF publisher can get inconsistent results when faced with temporary nameserver problems, since error handling is different for ptr/%{p} than other mechanisms/modifiers.

I guess all I'm suggesting is that this note should be raised to a SHOULD NOT publish.   I wouldn't object to having it removed entirely though.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Mar 2012 09:54:34 -0500

On Wednesday, March 07, 2012 06:39:38 AM Arthur Thisell wrote:
> I realize I'm very late in suggesting issues to be discussed, so I don't
> know  if the ADs will even consider my two possible issues.   Their ruling
> isn't that important to me because I don't think these are critical issues
> and I can live with them not being considered.   I'm breaking up the two
> issues into two posts for ease of threading...
> 
> Maybe things have changed dramatically while I've been asleep, but the
> in-addr.arpa namespace is a mess.  It is poorly maintained, to the point
> where in some countries, even ISPs can't get delegations for their IP
> addresses.  Queries to this name space often time out, and even when they
> give an answer, the answer is often bogus.
> 
> Now, with all the other mechanisms/modifiers, the publisher usually has a
> great deal of control over the nameservers referenced and the content that
> gets returned.   An mx: mechanism that isn't working right is likely going
> to cause a lot of other problems so it will be noticed and fixed.   The
> ptr:/%{p} stuff, on the other hand, is under the loose control of the
> sender, not the publisher.   If someone sends mail from a host within a
> bogus in-addr space, the receiver suffers with the timeouts.   The SPF
> publisher can get inconsistent results when faced with temporary nameserver
> problems, since error handling is different for ptr/%{p} than other
> mechanisms/modifiers.
> 
> I guess all I'm suggesting is that this note should be raised to a SHOULD
> NOT publish.   I wouldn't object to having it removed entirely though.

Given the backward compatibility requirements in the charter (this feature is 
used), I don't think removal is in scope.  I think discussing making it a 
SHOULD NOT is a reasonable issue.

For a long time (they've changed it now), the Cisco SPF record was v=spf1 
ptr:cisco.com ~all.  Presumably they know how to make such things work.  There 
are certainly cases where it's just fine.

If I were designing from scratch today, I wouldn't included ptr: or %{p}, but 
we aren't.  

Scott K