[Top] [All Lists]

Re: [ietf-smtp] SPF DNS query limits

2016-05-24 03:32:14
On 23/05/2016 17:44, Steve Atkins wrote:
On May 23, 2016, at 7:52 AM, Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> 

In RFC 7208 section 4.6.4 we're told that the SPF implementation should limit 
the number of include, a, mx, ptr and exists to 10, and if that limit is 
exceeded then we MUST return a 'permerror' result.

1) is this limit of 10 for the whole evaluation process, or does it restart for 
each 'include'/'redirect'? I've presumed it's for the whole process otherwise 
the total number of DNS queries is effectively unlimited if you have many 
nested includes, and the purpose of that section seems to be to limit them.
It's for the whole process, excluding A queries triggered by mx: entries, IIRC. 
(Pretty much, read the RFC if you want the gory details)
I have, but it's not 100% explicit that it's for the whole process. That's what I'd assumed, but then when we were getting so many failures I thought maybe I'd interpreted it incorrectly ;-)

2) Is this limit generally being stuck to by SPF evaluation functions?
It's hard to say overall, as SPF is almost never used on it's own to make 
delivery decisions.
That seems to be changing. I've recently had several customers contact me because their outgoing mail was failing - turned out that it was because they had two SPF records for their domain, which is invalid. It had been working fine until a week or so ago. Once they fixed that, their mail was accepted again. (Various target domains, not sure if they used the same service provider) suggests that it's not 
something that's causing spectacularly bad delivery problems or ebay would have 
fixed it.
Or people have whitelisted ebay because they're a big company...

It's exacerbated by many DNS records being less than half full - either because people 
(or "wizards") generating them don't know that you can have more than 250 
characters in a record, or because they're using DNS management web interfaces that don't 
allow them to do so. That leads to more include records needed and so more queries. 
Running some commonly used included records through the (fairly crude) minimizer at suggests it's bloating by a factor of about 
two, on average.

BTW - do these companies just add all the IP addresses they own to their SPF records? Do Google really have ~230,000 mail servers?

Just as a matter of interest - wouldn't it be worth them using macros in their includes? eg 'include:%{i4r}'. This could cut down drastically on the level of nesting.

ietf-smtp mailing list