On 15 Jul 2019, at 14:02, Phil Stracchino wrote:
I have mail from one specific domain (handled by Google) being
rejected
by pypolicyd-spf because of an apparent DNS lookup problem — 'SPF
Permanent Error: Too many DNS lookups'
That should not cause rejection. It should be the equivalent of not
having any SPF record or a "neutral" result.
— but it is not obvious to me
what the problem is, unless it's something to do with having five MX
forwarders to look up.
It is but the 5 GMail MXs are only part of the problem.
A SPF record must not require more than 10 DNS lookups to resolve fully.
See https://tools.ietf.org/html/rfc7208#section-4.6.4. The 5 MX records
eat 5 of those.
Only this one domain seems to be affected. I
can SEND mail to them, but not RECEIVE mail from them. I have added
forevermetalroofs.com to pypolicyd's domain whitelist, and it didn't
help.
I don't know anything about pypolicyd but if it insists on rejecting
mail with a logically neutral SPF result, it's not something I'd want to
know about...
Their SPF record is:
forevermetalroof.com descriptive text "v=spf1 a
1 lookup for the 'a' mechanism
mx
5 for the 'mx' mechanism returning 5 records, so we are at 6 total
include:websitewelcome.com
1 lookup for the include for a running total of 7 so far, BUT now we
need to evaluate what's inside that include:
include:spf.websitewelcome.com
include:spf1.websitewelcome.com
include:spfgwp.websitewelcome.com
include:_spf.google.com
That's 4 more lookups to be done, so we're dead at 11. Even if that was
not enough, it looks to me like the full resolution of the SPF record
for websitewelcome.com through all of those includes (with layers of
includes within them!) requires *13* DNS lookups, of which I will spare
you the gory details. So anyone with "include:websitewelcome.com" is
going to have a broken SPF record.
Some SPF implementations will accommodate this sort of error and allow
more. I've seen 20 lookups allowed, so we could come in just at the
limit with a lenient tool... BUT:
+include:sendgrid.net ~all"
BANG. 21
And here's the log of the last failure:
[...]
Jul 15 13:49:11 minbar policyd-spf[25139]: Starting
Jul 15 13:49:11 minbar policyd-spf[25139]: Config: {'debugLevel': 3,
'HELO_reject': 'SPF_Not_Pass', 'Mail_From_reject': 'SPF_Not_Pass',
AHA! Config!
'PermError_reject': 'True',
I would guess that means that you have *explicitly chosen* to reject
mail when hitting a "PermError."
Don't do that.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
