Re: All RCVD_IN_VALIDITY rules being applied to every email.

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 <[email protected]>
> 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)