On 15 Jul 2019, at 15:44, Phil Stracchino wrote:
On 7/15/19 3:29 PM, Bill Cole wrote:
On 15 Jul 2019, at 14:02, Phil Stracchino wrote:
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.
The question that comes to mind here is, if one should not reject mail
based on SPF failures, then what is even the point of checking SPF?
A test of SPF can have exactly one out of a fixed set of 7 possible
results. A "PermError" result is not a "Fail" result, it's a technical
error. It is formally impossible to know whether the sending domain
intended to authorize the client IP or not, because SPF does not allow a
full resolution of the record as returned by DNS. It's the equivalent of
a meteor strike destroying an athletic arena: there's not a 'win' or a
'lose' for anyone.
BUT: to the actual point of the question, a lot of people (including me)
do not use any particular SPF result to make an absolute decision on
accepting or rejecting mail without checking other factors. An explicit
SPF "Fail" is so rare these days for mail that gets past postscreen that
it is more likely to be a mistake by the domain owner or an innocent
transparent forward of mail than an attempted forgery. Instead, I use
SPF Pass as a lightweight component of whitelisting, using
SpamAssassin's whitelist_auth mechanism, and SPF Fail is just a strong
but non-fatal SA rule, and SoftFail as a weaker rule. All of the other
results are best handled as identical: useless.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
