Re: spamassassin4.x problem

Bill Cole skrev den 2025-02-13 21:29:
> On 2025-02-13 at 11:13:43 UTC-0500 (Thu, 13 Feb 2025 17:13:43 +0100)
> natan <[email protected]>
> is rumored to have said:
> 
>> Hi
>> Sorry but University debate....
>> The machines were 1:1 clones
>> For testing, I also updated debian11 -> debian12 to rule out other 
>> issues and the effect was the same
>> 
>> One machne who
>> 
>>> cat /etc/resolv.conf
>>> nameserver 127.0.0.1
>> 
>> IP ban may make sense - but there was a similar problem with another 
>> machine also with spamassin4.x - after returning to 3x there was no 
>> problem
> 
> The difference is that SA 3.x doesn't do anything about BLOCKED 
> responses
> 
> The VALIDITY rules should be set to score 0 unless you've got a 
> contract for using them. Their limits essentially rule out free use 
> with all but the smallest of systems.

score 0 does imho still not stop query in dns

its just hide the problem, no ?

> 
>> it looks like sa4 e.g. asked a few times e.g. about one thing
>> 
>> Feb 13 17:02:06 amavis5 amavis[9316]: (09316-01) _WARN: check: 
>> dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating 
>> /var/amavis/var/.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)
>> 
>> 
>> dig +short 
>> 127.0.0.1.bzdaby.clicks.mlsend.com.dnsblock_bl.score.senderscore.com 
>> @127.0.0.1
>> dig 
>> 127.0.0.1.bzdaby.clicks.mlsend.com.dnsblock_bl.score.senderscore.com 
>> @127.0.0.1
> 
> Try that *WITHOUT* '@127.0.0.1', which tells dig to use 127.0.0.1 
> exclusively, rather than to use the system configuration defined in  
> resolv.conf says. Unless you've told SA to use some other resolver, it 
> uses whatever the system is configured for.

agre @... should not be used for testing