On May 23, 2016, at 7:52 AM, Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk>
wrote:
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
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.
http://tools.wordtothewise.com/spf/check/ebay.com suggests that it's not
something that's causing spectacularly bad delivery problems or ebay would have
fixed it.
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 http://tools.wordtothewise.com/spf/minimize
suggests it's bloating by a factor of about two, on average.
And that's not the only common SPF mistake made that bloats records.
The reason I ask is that our SPF implementation is regularly hitting this
limit (eg one or two per minute on a low volume server).
For instance, we got a spam message claiming to come from cncdost.com (chosen
at random from our incoming messages). That results in:
- cncdost.com - contains "a mx ptr include:secureserver.net" - so that's 4
already
- secureserver.net - contains "include:spf-ss1.domaincontrol.com" - so that's
5
- spf-ss1.domaincontrol.com - contains "include:spf-ss2.domaincontrol.com
include:spf.messaging.microsoft.com" - so that's 7
- spf-ss2.domaincontrol.com - contains "include:spf-ss3.domaincontrol.com" -
that's 8
- spf-ss3.domaincontrol.com - contains "a:..." - that's 9
- spf.messaging.microsoft.com - contains "include:spf.protection.outlook.com"
- that's 10
- spf.protection.outlook.com - contains "include:spfa.protection.outlook.com"
- that's 11
(there are more includes after that, but our evaluator has given up by now.
In fact, the source IP address was not listed on any of the SPF records, so
would have resulted in a FAIL if it had got that far).
The SPF spec says immediate FAIL with too many DNS queries, regardless of
whether you found a match. I appreciate the intent, but given the number of
includes that are required if you're outsourcing multiple services (and need
the return path to point back at you) the limit of ten queries is a bit of a
problem.
Given SPF only affects the return path, it's not actually required to include
an outsourced providers SPF includes if the bounces go back to them (which they
usually do). At least until you get into wanting custom return paths because
you want DMARC-esque alignment, so as to get the delivery benefits of that...
Cheers,
Steve
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp