On 24 Jun 2019, at 18:15, John Schmerold wrote:
We had an inbound message get rejected because it was sent from a cell
phone, shouldn't SA be checking the most recent hop?
Only if that's what *you* want it to do...
Sometimes you want it to look at the whole transit path, sometimes not.
Many DNSBLs list addresses of Just Plain Bad devices and networks
Is there a way to make this the default?
Yes, but that would be bad, so we don't. We do have a way to documented
way to switch it on for specific DNSBL rules. See the documentation of
the "-lastexternal" suffix for DNSBL rules in 'perldoc
Mail::SpamAssassin::Conf' fort the details.
See also the many rules involving the Spamhaus Zen list in the default
rules file 20_dnsbl_tests.cf. They do reasonable things. You may want to
toss out your local Zen-based rule(s) and just use what's in the
distribution.
It is important to understand that Zen is a multiplexed DNSBL, with
listings of very different classes of IPs you don't want sending you
mail, some (PBL) only suspect at the last hop others (SBL, DROP) worthy
of shunning at any point in the path.
I have this in local.cf:
header RCVD_IN_rbl2spamhausz eval:check_rbl('spamhausz',
'zen.spamhaus.org.')
score RCVD_IN_rbl2spamhausz 3.5
That's more than a bit reckless. You're free to do it with your mail
system, of course, but I definitely wouldn't...
I also wouldn't use any of the "UCEPROTECT" lists
Content analysis details: (9.8 points, 8.5 required)
I guess that 8.5 kinda accommodates the effects of using
hyper-aggressive DNSBLs and a manually-overscored deep-inspecting rule
for anything listed in any slice of Zen.
pts rule name description
---- ----------------------
--------------------------------------------------
0.2 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query
to URIBL was
blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more
information.
[URIs:
icloud.com]
If you can't query URIBL in a legitimate way, don't do it at all. It
does you no good but it is penalizing every message containing any URI
for you.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)