On 2024-05-08 at 15:53:47 UTC-0400 (Wed, 08 May 2024 16:53:47 -0300)
kurt.va1der.ca via users <k...@va1der.ca>
is rumored to have said:
I received a (relatively) well crafted Phishing email today. It was
clearly a well planned campaign. The Spamassassin score was as
follows:
X-Spam-Status: No, score=-0.4 required=5.0
tests=GOOG_REDIR_NORDNS=0.001,
HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001,
NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274,
SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397
autolearn=disabled version=3.4.6
DNS white-hole list checks should never ever pass if the SPF checks
fail.
The only "white-hole" item there is RCVD_IN_DNSWL_HI, which is a
DNS-based list where IPs which are supposedly "good" can be listed, i.e.
it is external to SA, not something we manage. You are suggesting that
the knowledge that an IP does not send spam should be entirely ignored
if that IP offers a message which fails SPF, which is a solely a domain
verification and has well-known common failure modes.
I could not disagree more. One purpose in principle for IP-wise
welcomelisting like DNSWL is to identify known-good transparent
forwarders who for whatever reason do not implement SRS but also do not
forward spam.
DNS-based list IP tests are scored in the default distribution without a
strong basis, because they do not normally get handled by the RuleQA
process. It has often been reported here that RCVD_IN_DNSWL_HI is too
forgiving and that seems true to me. You may wish to reduce its positive
power. I set it to -2 based on my local observations. YMMV.
You are free to create a local meta-rule which makes SPF_FAIL cancel out
RCVD_IN_DNSWL_HI. You are free to make the SPF_FAIL score higher. You
are free to use the priority and shortcircuiting features to assure that
SPF_FAIL causes DNSWL checks to not be run. I would not expect any of
these to have an overall positive effect on your email.
In fact, I can't think of any whitelist test that should pass if SPF
fails.
If you operate on the theory that a SPF failure is always a sign of
spam, you can make your SpamAssassin always trust SPF failures
absolutely. I would not recommend that. Some people screw up their SPF
records. Other people forward mail transparently, which reliably breaks
SPF. SPF is broken *by design* as a spam control tool AND as a mail
authentication tool. We knew this 20 years ago, but it remains a useful
tool if you work with its limits rather than assuming that they do not
exist.
I could attach a higher score to SPF_FAIL, but that would unduly
affect cases where the sender wasn't white listed.
I fail to see how that's a problem, in a world where SPF failure
overrides an IP-based welcome list. However, I do not understand that
world in general, so I'm sure there's something I'm missing...
I need a way to force Spammassassin to negate the effect of one test
on the passing of another.
A simple logical problem:
score RULE_A 3
score RULE_B -2
meta CANCEL_B_IF_A RULE_A && RULE_B
score CANCEL_B_IF_A 2
You can also use 'priority' directives to make rules execute in a
defined order and a 'shortcircuit' directive to make SA stop processing
later rules if a specific rule hits. This will also skip any other
'late' checks, so you have to set priorities with care to avoid
shortcircuiting rules that you want checked. Consult the docs for
details.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com
addresses)
Not Currently Available For Hire
