Re: ATTENTION: DNSWL to be disabled by default.

On 9/24/2024 10:10 AM, Matus UHLAR - fantomas wrote:
>
> I understand this case as "abusers" instead of users.
One man's use is another man's abuse.  Limits are reached and False 
Negatives are produced by DNSWL.

Here's the actual use case:

1) Stefan's a web guy.  He hosts his stuff at ScalaHosting.
2) ScalaHosting provides a one-click install of SpamAssassin.
3) Stefan doesn't know what DNS that SpamAssassin instance (think like a 
CloudWays App, or Digital Ocean droplet) is using.   It could be a 
public DNS; could be ScalaHosting's DNS.
4) ScalaHosting does offer their own mail servers for use for a fee.  
Now maybe that has functional DNS, we don't know, but Marketing/Sales 
being what it is, it is probably not a good sign for Stefan.
5) Stefan doesn't know all these particulars (#1 above).  He just knows 
it doesn't work.

Root Cause Analysis (in order):

1) DNSWL does not provide blocked codes.  That deviates from most 
DNS-query based systems.
2) ScalaHosting provides a "buggy" semi-functional package to their clients.
3) SA, being just a messenger, accurately reports the bogus False 
Negative from DNSWL.

Risk Analysis:

1) Anybody that's seen DNSWL's zone files knows that it is a useless 
arbiter of spamminess; not to mention the stale data therein.
2) SA default scores are tuned to 5, all instantly wiped out by a False 
Negative score of -5.
3) "One-Click" install packages are becoming more and more common with 
Cloud providers.

Market Influences:

1) Contraction in the Email services market; less "systems" expertise is 
available.
2) DIY installs also "dumb-down" systems knowledge requirements.
3) SA has a desire to provide some protection in a default installation.
4) Migration to Zero-Trust environments.
5) Integration of DNS into O/S (like the stub resolver problems in 
Debian/Ubuntu) - can't just slap BIND on a machine anymore.

I am 100% FOR dropping DNSWL, any way it is done, although I don't have 
any problem with the existing handling of BLOCKED responses from 
Validity, SpamHaus, and others.  It *seems to me* that DNSWL-type 
services are better used as overrides at SMTP-time to DNSBL blocks.

>> Doing that is a legitimate choice by a reputation service, but it's 
>> not one SA can endorse. The fact that it is enforced by whim rather 
>> than mechanically is not a positive factor.
> Is there any possibility to detect clients using open DNS, perhaps 
> other than RCVD_IN_ZEN_BLOCKED_OPENDNS ?
>
> Then, block all dnsbl/rhsbl rules?
>
I don't see any truly viable solution without conducting other lookups 
first.   A possible alternative would be to configure an unrestricted 
open DNS server that returns to the client, in response to a query, the 
IP address of the DNS host from where the query originated.  Sort of 
like the old, never-used, TCP Echo service.

Of course, the devil is in the details.  But I like your thinking Matus 
:)  My mind is about as sharp as a cooked linguine noodle. I'm sure 
there are a lot of people out there that can conjure up better solutions.


-- Jared Hall