On Thu, Feb 13, 2025 at 05:13:43PM +0100, natan wrote:
> 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

Are you SURE there was NO problem? Or is it possible that the problem
*just isn't reported* in SA3? (i.e. SA4 has better reporting than SA3)

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

are you a paying VALIDITY customer? 
Because their public limits are quite low IIRC.
So unless you're paying, you should probably just do what that error
message is suggesting that you do.

But of course, you could do more debugging as described below.

> dig +short
> 127.0.0.1.bzdaby.clicks.mlsend.com.dnsblock_bl.score.senderscore.com
> @127.0.0.1

You are still using unneeded "@127.0.0.1", please skip doing that. 
It can only introduce confusion and error, and never help when testing SA.

Also, are you sure
"127.0.0.1.bzdaby.clicks.mlsend.com.dnsblock_bl.score.senderscore.com"
is right thing to query? Is SA saying that is **exact** query that is
causing RCVD_IN_VALIDITY_RPBL_BLOCKED rule to hit?

Have you done "spamassassin -D -t" on problematic mail as I
suggested? I have not seen output of that. Please run that command on
both SA3 and SA4 on same e-mail and compare what DNS queries ther are
actually sending.

It is hard to debug further without that essential information.
It will tell you what DNS queries the SA is sending, which you then
can ran manually with dig.

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

have you checked this?

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

Also, have you checked this? You need to run "spamassassin -D -t" to
see what SA3 and SA4 are doing. Just because only SA4 reports error
does not mean that SA3 does not also have the error (it is more
likely that it also has the error, but its error detection is not as
good, so it does not inform you of the error).

-- 
Opinions above are GNU-copylefted.

Reply via email to