Re[2]: URIDNSBL full message checking

2023-02-06 Thread Rob McEwen




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

2023-02-06 Thread Raymond Dijkxhoorn via users

Hello Michael,


No. Which is fine, because there are usually no URIs in headers, and when
there are, they are likely to be standard List-* headers, which are unlikely
to be useful.


Dont agree with that. We see many usecases for header checks...

We see many spams with a from domain inside SURBL.
And we have been testing this on our corpus for over 18 months now.


You can obviously use 'full' or the 'all' pseudo-header and look for
specific domains, but identifying everything in the header that COULD be a
domain and just testing that against a DNSBL designed for domains found in
URIs could have very bad failure modes.


I think we passed that point some years ago tbh.


How about just say the from or received headers?  Is there something
like check_rbl that would look up a domain name rather than an ip
address that I could look up the domain in that URIBL list?

I played with check_rbl() but this seems only to look up numeric ip
addresses.


You can test with:

header SURBL_MULTI_HDR 
eval:check_hashbl_emails('multi.surbl.org', 'raw/max=10/shuffle/host', 
'ALLFROM/Reply-To', '^127\.0\.0\.\d+$')

priority   SURBL_MULTI_HDR   -100
describe   SURBL_MULTI_HDR   Domain in email headers found in 
surbl multi


And score accordingly.

You could also check off reply-to/the from and so on seperately.

Have fun± Raymond Dijkxhoorn - SURBL

Re: URIDNSBL full message checking

2023-02-06 Thread Michael Grant via users
On Mon, Feb 06, 2023 at 04:16:46PM -0500, Bill Cole wrote:
> On 2023-02-06 at 12:50:29 UTC-0500 (Mon, 6 Feb 2023 17:50:29 +)
> Michael Grant via users 
> is rumored to have said:
> 
> > I’m noticing that check_uridnsbl() seems only to check the message body.
> > Is there some way to make it check the headers as well?
> 
> No. Which is fine, because there are usually no URIs in headers, and when
> there are, they are likely to be standard List-* headers, which are unlikely
> to be useful.

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.

> You can obviously use 'full' or the 'all' pseudo-header and look for
> specific domains, but identifying everything in the header that COULD be a
> domain and just testing that against a DNSBL designed for domains found in
> URIs could have very bad failure modes.

How about just say the from or received headers?  Is there something
like check_rbl that would look up a domain name rather than an ip
address that I could look up the domain in that URIBL list?

I played with check_rbl() but this seems only to look up numeric ip
addresses.

Michael Grant


signature.asc
Description: PGP signature


Re: URIDNSBL full message checking

2023-02-06 Thread Bill Cole

On 2023-02-06 at 12:50:29 UTC-0500 (Mon, 6 Feb 2023 17:50:29 +)
Michael Grant via users 
is rumored to have said:

I’m noticing that check_uridnsbl() seems only to check the message 
body.  Is there some way to make it check the headers as well?


No. Which is fine, because there are usually no URIs in headers, and 
when there are, they are likely to be standard List-* headers, which are 
unlikely to be useful.




In 25_uribl.cf, I have:

urirhssub   URIBL_BLACK multi.uribl.com.A   2
bodyURIBL_BLACK eval:check_uridnsbl('URIBL_BLACK')
describeURIBL_BLACK Contains an URL listed in the URIBL 
blacklist

tflags  URIBL_BLACK net
reuse   URIBL_BLACK

First obvious thing I tried was changing ‘body’ to ‘full’ in 
the above.  It continues to check only the body.  In fact, changing it 
to ‘header’, it continues to check the body.  I then read through 
the man page on URIDNSBL and it does clearly state a ‘body’ rule.


Predictable. :)

Is there some clever way to have a URIDNSBL rule check the header of a 
message as well?  Or is there something else I can use separately that 
would look up a domainname in the header section of an email?


Nothing comes to mind.

You can obviously use 'full' or the 'all' pseudo-header and look for 
specific domains, but identifying everything in the header that COULD be 
a domain and just testing that against a DNSBL designed for domains 
found in URIs could have very bad failure modes.



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


URIDNSBL full message checking

2023-02-06 Thread Michael Grant via users
I’m noticing that check_uridnsbl() seems only to check the message body.  Is 
there some way to make it check the headers as well?

In 25_uribl.cf, I have:

urirhssub   URIBL_BLACK multi.uribl.com.A   2
bodyURIBL_BLACK eval:check_uridnsbl('URIBL_BLACK')
describeURIBL_BLACK Contains an URL listed in the URIBL blacklist
tflags  URIBL_BLACK net
reuse   URIBL_BLACK

First obvious thing I tried was changing ‘body’ to ‘full’ in the above.  It 
continues to check only the body.  In fact, changing it to ‘header’, it 
continues to check the body.  I then read through the man page on URIDNSBL and 
it does clearly state a ‘body’ rule.

Is there some clever way to have a URIDNSBL rule check the header of a message 
as well?  Or is there something else I can use separately that would look up a 
domainname in the header section of an email?

Michael Grant