Subject: Re: [spfbis] #43/#44: New requirement for mx: or ptr records

From: Arthur Thisell <[email-masked]>
Date: Thu, 30 Aug 2012 07:53:52 -0700 (PDT)

>>     in section 5.4 (MX) and section 5.5 (PTR), no mention is made of the new
>>     requirement that there must not be more than 10 records that was added to
>>     section 4.6.4

> My reading of the requirement in Section 5.5 is that it has to do with the 
> number of DNS queries and not the number of DNS records.

Things got a little garbled in the translation from my review of bis-06 into tickets, which is probably my fault.

Ticket #44 does not contain a complete description of the problem, it is really part of #43.  Ticket #43 doesn't contain everything either, it leaves out that I think that the new text should be moved from 4.6.4 to the appropriate sections of 5.X.

RFC 4408's documentation on how the ptr: mechanism works does not depend on how many PTR records there are, so you are right, section 5.3 just talks about PTR lookups.  However, the new text in 4.6.4 radically changes the way the ptr: mechanism works.   I think it would be much clearer if all the description of out ptr: works is kept in one section.

Right now, if an in-addr zone for an IP address has more than 10 PTR records, ptr: will give inconsistent results depending on what order the PTR records are returned.  It might find a matching PTR record, or it might not match.   With the new text, if there are more than 10 PTR records, it is supposed to raise a permerror, in cases were RFC 4408 would never raise an error.  Indeed, RFC 4408 is designed so that ptr: never even raises a temperror, it just doesn't match in those cases.

The %{p} macro is defined in RFC 4408 to always give a result, but the new text in 4.6.4 means it could give an error.

The fact that RFC 4408 doesn't guarantee consistent results for ptr:/%{p} is one of the problems with ptr:/%{p}.  The sender, however, has control over the sending IP address, so you don't want to let the sender to be able to force a permerror instead of a fail.  

So, maybe changing how ptr: works so that it always doesn't match if there are more than 10 PTR records would be an improvement.   Changing how %{p} works, however, is probably not a good idea.  Changing mx: to give a permerror if there are too many MX records is also probably an improvement.