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
