On 2024-09-24 at 10:10:24 UTC-0400 (Tue, 24 Sep 2024 16:10:24 +0200) Matus UHLAR - fantomas <uh...@fantomas.sk> is rumored to have said:
>>>> TL;DR: Rather than using an in-band signal of a special reply value to >>>> queries from blocked users, as do other DNS-Based List operators, >>>> DNSWL.org sends back a "listed high" response to all queries. I was unaware > >> On 2024-09-24 at 04:18:06 UTC-0400 (Tue, 24 Sep 2024 10:18:06 +0200) >> Matthias Leisi <matth...@leisi.net> is rumored to have said: >>> Not to all queries. It is sent to resolvers who consistently go above the >>> limits, sometimes for months and years after receiving the blocked response. > > On 24.09.24 09:13, Bill Cole wrote: >> I don't see how that's significant. The documented policy is directly and >> intentionally harmful to users. > > I understand this case as "abusers" instead of users. In the context of spam control tactics, I'm not ready to call people who have no idea (and no way to see) that they are part of abusive behavior, "abusers." E.g. the cited bug. It was reported by someone with no control of their SA config, as it is handled by their "web host." Presumably they use something like cPanel which puts email in the hands of the platform provider rather than the domain owner. The provider may (or may not) have seen the BLOCKED replies whenever they actually occurred, but the end user only knows that now, he gets mail from the worst spammers marked as definitively good by DNSWL, courtesy of SA. That's bad for the user, for SA, for DNSWL, and for the host. >> 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? That sounds like a *great* idea and I'm sure it could be implemented. Patches welcome, always. This list's sibling at dev@s.a.o is the ideal place to discuss implementation detail with others. Those of us able to commit to the repo are always happy to add other people's code and credit it, but for the most part the evidence supports the conclusion that as a group we are not wealthy enough in free time to add features to SA. Another approach which could be simpler is to score the *_BLOCKED rules strongly enough to set off alarms. I don't like that much because it is using damage to get attention, but at least it would lead alarmed users to a correct conclusion about the root cause, rather than misrepresenting a reputation service's actual answer. -- Bill Cole
