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)

Reply via email to