On 2021-05-20 at 16:12:40 UTC-0400 (Thu, 20 May 2021 16:12:40 -0400)
Alex <mysqlstud...@gmail.com>
is rumored to have said:
Hi,
I have an email that matched KAM_SENDGRID because it also matched
SPF_HELO_NONE, despite it apparently being a legitimate sendgrid
email. This is from SA trunk.
KAM_SENDGRID is NOT from "SA trunk" it is from the independent rules
channel that Kevin offers, which is NOT part of the ASF SpamAssassin
project.
And FWIW: no matter what version of SA you are running, if you use the
project's default rules channel you get the "trunk" rules. There is only
one current version of the default rules, and it only exists in the
source tree on the 'trunk' branch.
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature
from author's
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not
necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK
signature
1.5 KAM_SENDGRID Sendgrid being exploited by scammers
Received-SPF: Pass (mailfrom) identity=mailfrom;
client-ip=167.89.39.250; helo=o1678939x250.outbound-mail.sendgrid.net;
envelope-from=bounces+3940809-b10a-43194=hotel.example....@em8909.cookspest.com;
receiver=<UNKNOWN>
X-Envelope-From:
<bounces+3940809-b10a-43194=hotel.example....@em8909.cookspest.com>
I'm noticing what I think are a lot of false positives for this rule.
In what way is this a false positive? Looks like a correct positive to
me.
Is there something more we should be doing to reduce the false
positives here, or is it really warranted?
Not a false positive. Note that the score of KAM_SENDGRID is much less
than any reasonable spam threshold.
If you disagree with the scoring or purpose of that rule, you are free
to reduce the score locally or discuss it with KAM. He's a very
reasonable guy who listens to reason. His rule QA is not the same as
that applied to the default rule channel. The default rule QA process is
slow, imperfect, and transparent IF you care to examine the code. KAM's
QA is a 100% black box but he makes changes fast when needed.
The mail server does appear to have an SPF record:
Not relevant.
# dig +short txt em8909.cookspest.com
u3940809.wl060.sendgrid.net.
"v=spf1 ip4:167.89.39.18 ip4:167.89.39.188 ip4:167.89.39.217
ip4:167.89.39.227 ip4:167.89.39.248 ip4:167.89.39.250 ip4:167.89
.39.45 ip4:167.89.39.75 ip4:167.89.39.79 ip4:208.117.61.64 -all"
Or perhaps it's because it's announcing itself as
o1678939x250.outbound-mail.sendgrid.net, which does not have an SPF
record?
Correct. That is what "SPF_HELO_NONE" means, as it documented in the
rules file 25_spf.cf:
describe SPF_HELO_NONE SPF: HELO does not publish an SPF Record
Is it even possible for a sendgrid client to control their SPF record,
let alone SPF HELO?
Probably not, but that's not relevant. It seems to me that the
SPF_HELO_NONE involvement in KAM_SENDGRID is heuristic, not
prescriptive.
Perhaps it's because Return-Path is null?
Return-Path: <>
That's a different problem, apparently with your MTA->SA glue. The fact
that something added a non-null "X-Envelope-From:" header and something
(else?) added a null "Return-Path:" header indicates fundamental
breakage. Whether SA is seeing that or if it is a delivery artifact is
unclear.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
