Re[2]: URIDNSBL full message checking

[Rob McEwen <ro...@invaluement.com>]

>It's actually just a domain name.  This uridnsbl keys off domain names
>in the body too, I was kinda hoping it would look at the domain names
>in the headers like the body, guess not.

So there's an interesting history here. Back in the early/mid 2000s, 
when SURBL, URIBL, and invaluement's URI lists were just starting (I was 
there!) - we didn't have reliable and universally-used/established 
domain authentication tools like SPF and DKIM and even ESPs were either 
non-existent or just beginning. Therefore, the vast majority of spammers 
were sending from their own servers (or bots!) - and both the mail 
header from and the SMTP-envelope FROM - in spams - was 99+% of the time 
forged. So trying to run a DNSBL that listed the domains found in the 
headers was a horrible idea because a massive percentage of spam used 
forged domains. That was then a losing game of whack-a-mole that would 
only add much useless one-off data to a dnsbl, as well as providing 
spammers with intel they could use to find DNSBL spamtrap addresses.

Today, so much is radically different since now many spams have their 
domains authenticated with things like SPF and DKIM. Therefore, SURBL 
and URIBL and Spamhaus's DBL have since moved more towards purposely 
including those header and SMTP-envelope domains (as well as the domain 
at the end of the PTR record) as things that they specifically target 
with their domain/URI lists. But these are things that "consumed" by SA 
with OTHER rules, not with URIDNSBL. (also, postfix as some good rules 
for this too which don't require callouts to content filters like SA. 
Exim and others probably do, too?

At invaluement - we're very very late to this game - and we're going a 
different route - choosing to target these with a separate list, not our 
URI list - this will be our SED list, which is currently under 
development - although, in the meantime, many of our subscribers use our 
existing URI list in this way, outside of our recommendations, and are 
happy with those results.

The main takeaways are:
(1) these require different rules than the URIDNSBL module (since 
URIDNSBL is for checking domains/IPs inside the clickable links in the 
body of the message)
(2) Any DNSBL trying to do should to pay attention to authentication, 
and not just throwing every such domain in the list without being sure 
it really is them and not a forged domain.

I hope this helps!

Rob McEwen, invaluement

Re: URIDNSBL full message checking

[Bill Cole <sa...@billmail.scconsult.com>]

On 2023-02-07 at 05:07:36 UTC-0500 (Tue, 07 Feb 2023 10:07:36 +0000)
Laurent S. <11...@protonmail.ch>
is rumored to have said:

> You could also use check_rbl_headers

THANK YOU!

I had not recalled that feature when I wrote my reply. I'm glad there 
are people here whose brains are younger and less leaky.

The best feature of SpamAssassin is the user community.



-- 
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Re[2]: URIDNSBL full message checking

["Laurent S." <11...@protonmail.ch>]

You could also use check_rbl_headers

Add this to init.pre or in your favorite .pre file:
loadplugin Mail::SpamAssassin::Plugin::DNSEval

Then add this rule:
if (version >= 3.004003)
  ifplugin Mail::SpamAssassin::Plugin::DNSEval
    header          HEADERBL_URIBL        eval:check_rbl_headers('hdrbl-uribl', 'multi.uribl.com.', '127.0.0.2')
    describe        HEADERBL_URIBL        Header contains domain listed in URIBL
    tflags          HEADERBL_URIBL        net
  endif
endif

You can define in which headers it should look for domains using "rbl_headers". Have a look a the documentation with:
perldoc Mail::SpamAssassin::Plugin::DNSEval

Good luck,
Laurent S.