Re: spamassassin4.x problem

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"
>

--