On 2024-09-24 at 12:59:51 UTC-0400 (Tue, 24 Sep 2024 12:59:51 -0400) Jared Hall via users <ja...@jaredsec.com> is rumored to have said:
> 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. > [analysis points elided] > 1) Contraction in the Email services market; less "systems" expertise is > available. A problem we've been battling forever. It won't be getting better any time soon. > 2) DIY installs also "dumb-down" systems knowledge requirements. Yes, and we can't hope to fight against that. Many systems these days are being packaged in ways that "just work" with minimal effort or knowledge, for the large majority of the user audience. > 3) SA has a desire to provide some protection in a default installation. Because we know that people do as little work as possible to get something "working" even if that's in a degraded state. > 4) Migration to Zero-Trust environments. Unclear relevance... > 5) Integration of DNS into O/S (like the stub resolver problems in > Debian/Ubuntu) - can't just slap BIND on a machine anymore. Sounds like a Linux problem :) It's actually quite easy on many platforms to bring up an Unbound recursive resolver for local resolution. I think it was actually presented as a choice for the latest Alma(EL9) and FreeBSD machines I loaded from install media. Yes, the systemd resolver is garbage. > 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. People will always differ on which tools to use at which layer, but I tend to agree that positive reputation sources are best applied to keep mail away from ever hitting SA. SA is a semi-transparent black box. It makes mistakes *intrinsic to its design* in both directions. If you want to exempt mail from ever being blocked by SA, not showing it to SA is best. That's why I use a relatively heavyweight milter (MIMEDefang) which can choose whether or not to expose messages to SA. >>> 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. As I said in a previous message: patches are welcomed. -- Bill Cole
