Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14

[Douglas Otis <[e-mail]>]

On May 23, 2013, at 10:01 AM, S Moonesamy <[e-mail]> wrote:

> Hi Phillip,
> At 09:58 26-04-2013, Phillip Hallam-Baker wrote:
>> The document is clear and describes the SPF mechanism effectively. The only quibble that I could find is that repeated mentions are made of limiting the number of 'DNS queries' without specifying whether these are individual queries or recursive. The count will come out rather differently if looking up TXT/x.example.com counts as one lookup or three. I think it is reasonably clear that this is one but could not find an explicit statement to that effect.
>> 
>> On the security side, the document addresses all the mail issues that I can remember at this point and rather more besides.
>> 
>> I think we have reached the point of diminishing returns.
>> 
>> The document provides a clear enough warning to people configuring SPF records as to the consequences of getting it wrong which is the main concern. The filtering services will know their business well enough to minimize false positives.
>> 
>> Hopefully the email infrastructure will evolve over time towards concentrating on the more policy friendly approaches and it will be possible to simplify the mechanism at a future date.
> 
> There are two comments about the security directorate review of draft-ietf-spfbis-4408bis-14 at http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html and http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html
> 
> The SPFBIS WG does not plan to make any change to draft-ietf-spfbis-4408bis.  Please let me know if you consider that the security directorate review has not been addressed.

Dear SM and Scott,

Greater clarity would have been achieved by separating transactions involving the SPF checkhost process (spfch-transactions) which may then generate some number of recursive dns server transactions (rdns-transactions).

A transaction made at the spfch level will result in some number of transactions at the rdns level, which could then be described as representing some number of separate DNS queries.

Confusion has been caused by conflating checkhost and recursive DNS transactions with that of non-recursive DNS which may involve dozens of unique queries to resolve any particular resource.  This is bad and is a continuing source of confusion.

A practical means to simplify SPF's impact on a receiver's DNS is to first ignore SPF records containing macro expressions.  This happens and this may explain the nearly 100% lack of macro use.  They then limit the number of SPF resource records and MX mechanisms and ignore the PTR mechanism.  Appreciate what receivers consider a reasonable demand on their resources that offers cache-able results.

Regards,
Douglas Otis