Subject: [spfbis] > Re: FW: Secetion 4.6.4 DNS Lookup Limits

From: Arthur Thisell <[email-masked]>
Date: Wed, 12 Sep 2012 05:37:01 -0700 (PDT)

> To be precise, returning "permerror" based solely on the fact that the
> SPF policy might (or even will) exceed the DNS lookup counts is
> probably not valid.  I might have 30 mechanisms listed, but if on
> evaluation it never gets past the fifth one, what's the harm?

Sorry for the double post, I hit send too soon.

Limiting the amount of work that an SPF record generates is really important for DoS attack prevention.  However, you want that restriction to be as easy to understand as possible.  You want people to be able to accurately do it by hand.  Sure, you could add a rule that mechanisms after -all don't count against the process limits, but then if someone scanning by hand just looks at the "important mechanisms" and misses the -all, they would count the ones after the -all.

RFC 4408 tries to strike a balance between DoS potential and complexity of the rules.   For example, the ptr: mechanism is really a cost per SPF evaluation, rather than a cost per mechanism evaluation.  You are looking up PTR records based on the IP address which never changes, so you could have 1000 ptr: mechanisms without a DoS potential.   

However, trying to explain why ptr: do DNS lookups by they don't count would make the mechanism limit rules a lot more confusing.   So, RFC takes the easy route of saying ptr: mechanisms count just like a:/mx:, while %{p} is free, even if neither is really true.

I would like to keep the process limits as simple as practical.  I feel that it is already to complex/long, but I'm not sure that it can be improved much, especially with the constraints of the charter.