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 <na...@epf.pl>
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
