Most of the messages on this thread, other than from bcole, have not been from members of the SpamAssassin PMC. I want to clarify our position and correct some details. I also want to see if dialog with you, Matthias, can lead to a better solution.
The situation is that dnswl has four possible responses when it acts on a query that it has flagged as exceeding the limits of unpaid use: 1) reject with SERVFAIL, 2) reject with BLOCKED, 3) return 127.0.0.255 which is code for blocked, 4) return 127.0.10.3 which is code for "other service" HI non-spam The first two cannot be distinguished from various network or server errors, so SpamAssassin just drops the query with no result. The third is the correct return code to indicate blocking for overuse. When SpamAssassin sees that, it hits a rule whose description is supposed to inform whoever looks at the mail headers or spam report that the ISP has misconfigured their SpamAssassin server's DNS or is at a usage level that requires a paid subscription to dnswl. In addition, to reduce the excessive load on dnswl, when SpamAssassin sees that code it temporarily disables further queries to dnswl, I think for the life of the running process. So we do what we can to make the 127.0.0.255 code have a useful effect. The fourth return code 127.0.10.3 seems to be returned less frequently. Unlike what someone suggested, SpamAssassin cannot treat it the same as 127.0.0.255 because there is at least one IP address in the dnswl database that has that code to indicate it is a high trust site, i.e., the code is used to indicate high trust. It appears that dnswl.org policy is to return that code sporadically to what they consider "abusers" who are people running SpamAssassin or other services using dnswl who do not correct their configuration to use a local nameserver, purchase a subscription, or stop using dnswl, when they continue to get query failures and 127.0.0.255 codes. That results in some possible spam being flagged as dnswl high trust, which is a way of forcing the issue to someone's attention. That policy clashes with the SpamAssassin PMC's explicit policy of not supporting in our default configuration any dnsbl that responds to violation of a "free for some" model by returning wrong information instead of a specified BLOCKED code. If we allow that, it would result in end-users receiving spam that has been labeled as ham, with resulting complaints going to us because it would be SpamAssassin labeling that spam as ham. The policy from dnswl.org does work to put pressure to reduce the abuse. Unfortunately it is not as simple as the pressure being put only on the "abusers". It could be an ISP who hasn't bothered to buy a subscription to pay for their high use and has end users who complain about spam they receive as a result. Or it could be some organization with relatively low email volume but a clueless IT person who cheap out by using a public nameserver like 1.1.1.1 or 8.8.8.8, and nobody paying attention to the mail headers. Or a hosting service that makes SpamAssassin available to VPS customers installed via cpanel and nobody involved has a real clue what is going on. Under some of those circumstances, the complaints go to SpamAssassin and the pressure is put on us. We have fewer choices than an ISP. We can't pressure whoever runs the instance of SpamAssassin any more than you are already doing. We can't change the nameserver configuration or purchase a subscription on behalf of that ISP. We can stop using dnswl in our default configuration. If that is your preference, Matthias, then we are settled. However, if the continued use of dnswl in the default SpamAssassin configuration is worth more to you than the benefits of putting that additional pressure on abusers (and clueless people who end up looking like abusers), maybe we can figure out something that works a little better than what we have been doing. Maybe we can come up with somewhat stronger language in the DNSWL_BLOCKED rule description. Maybe now that I told you that we stop subsequent queries in the process after the first 127.0.0.255 is received you would feel better about relying on that. Or maybe you can think of another compromise suggestion. I can say that if you stop returning false HI results instead of BLOCKED we should always be willing to restore dnswl to our default configuration. Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC Sep 25, 2024 06:44:29 Matthias Leisi <matth...@leisi.net>: > >> Root Cause Analysis (in order): >> >> 1) DNSWL does not provide blocked codes. That deviates from most DNS-query >> based systems. > > This is wrong. > > — Matthias >
