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 <jtam.home@gmail.com>
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
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