Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits

[Scott Kitterman <[e-mail]>]

On Wednesday, March 07, 2012 06:43:15 PM Alessandro Vesely wrote:
> On 07/Mar/12 14:10, Scott Kitterman wrote:
> > On Wednesday, March 07, 2012 01:41:57 PM Alessandro Vesely wrote:
> >> On 07/Mar/12 13:06, Scott Kitterman wrote:
> >>> 
> >>>
> >>> First, I don't think there's a lot of point in computing the
> >>> maximum number of lookups possible.
> >>
> >> 
> >>
> >> Why?  It doesn't sound difficult to specify of implement.  I mean,
> >> isn't it easier to say "you can do at most 111 lookups" than "you can
> >> evaluate at most 10 terms worth 10 lookups each plus an exists as a
> >> bonus"?
> >
> > 
> >
> > The 111 is a corner case.  Your reformulation makes it the standard
> > case.  I don't think it's a good idea.
> 
> No, wait.  I don't mean one has to do all the lookups.  The limit is
> meant to guard against an excessive number of lookups, whether
> malicious or buggy.  As long as we believe that's not the norm, and
> only happens in corner cases, a non-partitioned amount of lookups may
> be more flexible and simpler than a structured limit devised to
> prevent a particular attack only.

The current rules are:

No more than 10 terms that need DNS lookups
No more than 10 a lookups from an mx mechanism
No more than 10 a lookups from a PTR mechanism.

So there is currently a primary limit of 10 and a secondary limit of 10 
lookups per primary of a certain type.

Is there any evidence that the primary limit of 10 is not adequate?  I am not 
aware of any.  Most of the largest email providers that exist have published 
records that fit within this limit.

Why would we want to change it?  Because we're changing the spec and it makes 
the spec clearer is not a good reason if it requires code to be re-written.  
Your proposal would.

As has been mentioned, one of the primary design principles in SPF was to 
produce a deterministic output based on a defined input.  If we change the 
current 1 + 10 + 10*10 limit to 111, then every SPF library that properly 
implements RFC 4408 10.1 would have to be changed.  

Based on that, I think the proposal is out of scope, but I also think it's a 
bad idea in any case.

Scott K