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
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
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>>
127.0.0.1.bzdaby.clicks.mlsend.com.dnsblock_bl.score.senderscore.com
@127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6175
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;127.0.0.1.bzdaby.clicks.mlsend.com.dnsblock_bl.score.senderscore.com. IN A
;; AUTHORITY SECTION:
score.senderscore.com. 3593 IN SOA s0.rpdns.net.
dnsadmin.senderscore.com. 2025021313 2700 3600 604800 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Feb 13 17:12:38 CET 2025
;; MSG SIZE rcvd: 154
W dniu 13.02.2025 o 16:52, Matija Nalis pisze:
On Thu, Feb 13, 2025 at 04:11:52PM +0100, natan wrote:
I have a couple of servers on all of them with spamassassin3x and I have no
problem
and on one where there is spamassassin4 I have problems as above
To put it even simpler 90% of traffic is handled by servers with
spamassassin3x where I have no problem
and 10% of traffic goes to spamassassin4.x where the problem is as above
Correlation does not imply causation.
I.e. just because one system differs in version of spamassassin from
others, does not necessarily mean that spamassassin version is the
cause of the problems. For example, there could be other differences
which are the actual case of the problem.
I can't make it any simpler
On all servers there is only a local pdns-recursor
Just because pdns-recursor is locally installed, does not mean that:
1) it is actually being used (that is why you were asked for the
content of your /etc/resolv.conf file) (and which would be me
prime suspect).
2) that this pdns-recursor, if it is used, has same version and same
configuration as other machines (e.g. cache size, forwarders etc).
IOW, it could be behaving differently.
3) just because SA3 does not show you the errors, does not
necessarily mean that it does not experience same errors (but for
example have errors, but fails to show them)
4) the IP of the problematic server has not been banned previously
for SA or other unrelated reasons for overstepping RBLDNS's ToS
(and other server IPs do not)
5) the times when you are testing the DNS responses might differ from
times when SA is sending the queries (e.g. burst of spams might
trigger the overuse of ToS only for some mails). So you should do
"spamassassin -D -t" at just before you do the DNS dig.
6) some other reason
dig test.uribl.com.multi.uribl.com txt +short @127.0.0.1
Also, you should leave out "@127.0.0.1" part - you are forcing
specific nameserver there, which might not be the one that the system
(including SA) is using (and which is usually specified in
/etc/resolv.conf "nameserver" stanza, although /etc/nsswitch.conf
and others might be overriding that)
And I'd suggest also trying (with dig) the *same* DNS query that
"spamassassin -D -t" says is failing, instead of looking only at
"test.uribl.com.multi.uribl.com"
--
