On 2024-11-18 at 12:21:12 UTC-0500 (Mon, 18 Nov 2024 17:21:12 +0000) Nix <n...@esperi.org.uk> is rumored to have said:
> On 14 Nov 2024, Mark London uttered the following: > >> FWIW, Today I discovered that RCVD_IN_VALIDITY_CERTIFIED, >> RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, were being triggered for >> every email that our server received. I do not use a public DNS server. I >> disabled all of them. Strange. - Mark > > I'm seeing this too. I'm not a high-volume site, yet... [... snip of log entries ...] > I'm not a high-volume site, a few thousand mails a day. If I'm blocked, > probably more or less everyone is being blocked. (Are the DNSBLs above > all run by the same entity now?) If you forward DNS queries instead of running your own *fully recursive* DNS resolver locally, you *look* like you are part of a high-volume leech. This almost certainly does not mean you should run dnsmasq locally, it means you need a REAL resolver. Unbound does a good job without the rococo config options of BIND. Many people also like the resolver half of the PowerDNS suite. > ... hm actually perhaps my checks of mail to a couple of high-volume > mailing lists are triggering it. Extremely unlikely. Check your DNS config first. If /etc/resolv.conf doesn't have a nameserver entry with a loopback address, you need to fix that. If you do not have a recursive resolver listening on port 53 on a loopback address, you need to fix that as well. If you already have a real recursing resolver on the local LAN you can use that instead, but if you had that you would already be using it, I expect. > I wonder if I can prevent those DNSBLs > from being consulted just for mail apparently to those lists? Not really. That's what the auto-created "blockfile" is supposed to do: stop queries to services that are blocking you. Looks like it is not working for you... > But, really... what on earth is going on in that message? > > Nov 14 00:00:03 loom warning: check: dns_block_rule > RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating > /etc/mail/spamassassin/helpers/.spamassassin/dnsblock_bl.score.senderscore.com > (This means DNSBL blocked you due to too many queries. Set all affected > rules score to 0, or use "dns_query_restriction deny > bl.score.senderscore.com" to disable queries) > > So there's a mention of a file under > /etc/mail/spamassassin/helpers/.spamassassin/, but that directory is > empty (writable only by root, but spamd is running as root). Is this > just a misfire because it's trying to write after dropping privileges or > something? Yes, it seems likely that it is privileges problem. The code creating the blockfile is in M::SA::Plugin::Check.pm which I don't believe ever runs as root via spamd, even if you start spamd as root. The relevant code has comments implying that the functionality is in response to bug 6728 and is probably not ideally placed. I agree with that. I'm not sure where it should be, but if you run spamd as root then by the time you have a message in hand, you're actually running as either the user running spamc or nobody, which will cause issues if you are trying to create that blockfile in that directory. The point of the big ugly error message is to have a big ugly error message. MOST people who report problems with SA accuracy here have misconfigured their resolvers, apparently because they don't trust documentation or don't read it. -- Bill Cole
