On 18 Nov 2024, Bill Cole spake thusly: > 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.
I'm running BIND (actually, two BINDs, one authoritative one, one recursive resolver). Sorry, I've been doing that for so long I forgot any alternative was possible! :) >> ... 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 am. >> 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. Yeah. I suppose it should be landing in the user's ~/.spamassassin, but it's not... > 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. Not me! This is something else. Maybe lkml is just too high volume... God knows it's too high volume to actually *read* (I'm grabbing it for grepping purposes and I really don't mind if SA doesn't RBL-scan mails directed there -- it's all my other mail I want RBL-scanning.) -- NULL && (void)
