On 27/01/2026 00:20, Joseph Tam via dovecot wrote:
On Fri, 9 Jan 2026, Joseph Tam wrote:
102/189 (54%) were listed by at least one of the RBLs, with the
following stats
RBL hits rate rate (>0 hits)
(col#1) bl.blocklist.de 93 49% 91%
(col#2) auth.spamrats.com 52 28% 51%
(col#3) xbl.spamhaus.org 19 10% 19%
You should try one of the other 2 RBLs: they specificaly list brute
forcers. I use them as pre-emptive block-on-sight for SMTP auth, and
I don't recall ever getting a false positive.
I am embarrassed to discover my RBL statistics have been presented
incorrectly. I was intrigued by John Fawcett's statitics which skewed
towards XBL, so I re-examined my output, and discovered my RBL columns
were mis-ordered
col#1 => xbl.spamhaus.org
col#2 => bl.blocklist.de
col#3 => auth.spamrats.com
I ran an analysis from last week's IMAP brutce forcers, which agrees
with John's results
Total: 352 IPs
RBL hits rate
xbl.spamhaus.org 181 51%
bl.blocklist.de 82 23%
auth.spamrats.com 31 9%
The takeaway is those wanting to use RBLs to combat IMAP brute forcers,
Spamhaus XBL is very effective, catching about half of them, with BLDE
amd Spamrats contributing some extras.
However, I also did false-positive testing: querying legitimate user IPs
against these RBLs. Not blocking legitimate users is far more important
than missing a brute forcer, so FP rates ought to be minimized, or its
use hedged in some way:
Total: 2366 IPs
RBL hits FP rate
xbl.spamhaus.org 81 3.4%
bl.blocklist.de 0 0%
auth.spamrats.com 25 1.1%
Most of the FPs come from, as one would expect, local residential ISPs.
One of the thread responsers posted an auth policy script: catching
clients
trying to authenticate to unknown or defunct users is another useful
complement to RBLs.
Joseph Tam <[email protected]>
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Hi Joseph
thanks for updating your stats.
The assumption is probabably that the FPs come from IPs that were
reallocated and that were either previously exploited, now reallocated
to legitimate users but have not come out of XBL or that they were
previously allocated to legitimate users and have since been reallocated
to exploited devices and have come onto XBL.
Then the FP data may be over (or even under) estimated, where the
blocklist lookups were not done in proximity of the connection.
For example, if you have data from some days ago that there was a
legitimate login, and now that ip is on XBL it could have been added to
the list since the legitimate use and therefore there would have been no
positive and consequently no false positive at the time of the
legitimate use. This leads to over counting of FPs. The opposite can
also be true, you now don't see it on XBL but it was at the time of the
legitimate login, and you are undercounting FPs. The two don't
necessarily balance out.
John
John
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
