I'm going to jump in and top post because I only have one comment to add.
ESPs (Email Service Providers) seem to be especially bad with lots of includes
and lots of individual records inside the includes.
From: ietf-smtp [mailto:ietf-smtp-bounces(_at_)ietf(_dot_)org] On Behalf Of
Sent: Monday, May 23, 2016 11:37 AM
Subject: [!!Mass Mail]Re: [ietf-smtp] SPF DNS query limits
On Monday, May 23, 2016 03:52:39 PM Paul Smith 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 is for the whole evaluation process.
2) Is this limit generally being stuck to by SPF evaluation functions?
This limit goes back to the experimental RFC 4408, so it's a decade old. All
the open source implementations of which I'm aware follow it (although
some provide configuration options to ignore it). I don't know the status of
any proprietary implementations.
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
- secureserver.net - contains "include:spf-ss1.domaincontrol.com" - so
- spf-ss1.domaincontrol.com - contains
- 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).
This is not atypical of records I've seen that are not well considered and
looking at the guidance supplied by godaddy.com  not terribly surprising.
Their guidance is not unusually bad. I've yet to see any kind of a record
generation wizard that can substitute for actually knowing what you're doing
(at least a bit).
ietf-smtp mailing list
ietf-smtp mailing list