Re: Blocking with RBLs
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 ___ 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]
Re: Blocking with RBLs
On 27 Jan 2026, at 06:01, Dave McGuire via dovecot wrote: > > On January 26, 2026 22:55:40 Lefteris Tsintjelis via dovecot > wrote: >> There are 2 issues if anyone considers using external and not local RBLs: >> >> 1) Speed/connectivity depending on where you are. The total response of all >> RBLs used should be under 10ms if possible >> 2) FPs. You don’t control what is on anyone’s list so you may be forced to >> whitelist and that makes things more complex. >> >> A well trained local list would be much faster, way more reliable with no >> packet loss, and extremely more accurate with close to 0 FPs. My local RBL >> gets at least 95% hits with 0 FPs and of course it is way faster and >> reliable for me as I control it. > > How do you populate it? Auto generated from centralized login and things that would not cause any FPs for anything I run to the local clients and services I have. Lefteris ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
There are 2 issues if anyone considers using external and not local RBLs: 1) Speed/connectivity depending on where you are. The total response of all RBLs used should be under 10ms if possible 2) FPs. You don’t control what is on anyone’s list so you may be forced to whitelist and that makes things more complex. A well trained local list would be much faster, way more reliable with no packet loss, and extremely more accurate with close to 0 FPs. My local RBL gets at least 95% hits with 0 FPs and of course it is way faster and reliable for me as I control it. Lefteris ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On January 26, 2026 22:55:40 Lefteris Tsintjelis via dovecot wrote: > There are 2 issues if anyone considers using external and not local RBLs: > > 1) Speed/connectivity depending on where you are. The total response of all > RBLs used should be under 10ms if possible > 2) FPs. You don’t control what is on anyone’s list so you may be forced to > whitelist and that makes things more complex. > > A well trained local list would be much faster, way more reliable with no > packet loss, and extremely more accurate with close to 0 FPs. My local RBL > gets at least 95% hits with 0 FPs and of course it is way faster and reliable > for me as I control it. How do you populate it? -Dave -- Dave McGuire, AK4HZ New Kensington, PA ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
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 hitsraterate (>0 hits) (col#1) bl.blocklist.de 93 49% 91% (col#2) auth.spamrats.com 52 28% 51% (col#3) xbl.spamhaus.org19 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 hitsrate xbl.spamhaus.org181 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 hitsFP rate xbl.spamhaus.org81 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 ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
I personally would not trust many other external DNSBLs but my own, not
cause of speed which I consider just as critical, but mainly of the
blocking. You have no control of it.
On 15 Jan 2026, at 08:43, Kirill Miazine via dovecot
wrote:
o Aki Tuomi via dovecot [2026-01-09 12:40]:
YOu can also implement simple RBL auth policy server, the auth policy
feature sends JSON blob of fields and excepts a JSON blob in response.
Upside is that the policy check is done before any authentication
happens. You can ignore all the other stuff and just check the remote
IP.
See
[1]https://doc.dovecot.org/2.4.2/core/config/auth/policy.html#authentication-policy
if there's interest, I made a PoC some yearso ago, it uses asyncio and
sets up auth policy server on 127.0.0.1:13380:
[2]https://www.zerobin.no/?a5b52b2539d7912c#4sYaC5WeT9LHzYKN4XxCgUWr8uPdfCi4WsFdXSuzQDXU
This particular version was a WIP and checks Spamhaus DQS in DNS (and I
think I had some idea to use web-service, too, perhaps, but hadn't come
that far), and also sets up an auth policy server on 127.0.0.1:13370
using line-oriented protocol which I used in Exim.
you could use "ai" to clean/tweak it further, if needed.
auth policy server is a great facility, but I ended up just blocking
repeated offenders on the networking level.
Aki
On 09/01/2026 13:19 EET Lefteris Tsintjelis via dovecot
wrote:
On 9 Jan 2026, at 12:31, Aki Tuomi
wrote:
On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot
wrote:
Hi,
Is there a way to block with RBLs? I already have a really good
and very trustworthy and accurate internal one that works
extremely well and fast with my SMTP servers for years now. Is
there a way to apply the same RBL to dovecot? Logs are really
going crazy as they stopped with SMTP and started with IMAP for
a while now since dovecot is wide open to these attacks. Anvil
does not seem to do much here. I am looking for solutions other
than fail2ban or anything similar to this.
Lefteris
You can use auth_policy_server settings to configure an external
service for this, please see e.g.
https://github.com/PowerDNS/weakforced/ as an example of such
service.
Aki
Thank you. Looks very flexible and powerful but in this case seems
like a huge overkill for such a simple thing just for checking one
local DNSBL. I was thinking more like the code below. I think AI
gave me a fast and acceptable solution
#!/usr/bin/env python3
import sys
import socket
data = sys.stdin.buffer.read(1024).split(b'\n')
if len(data) < 3:
sys.exit(1)
username = data[0].decode()
password = data[1].decode() # we don't care
rip = data[2].decode() # remote IP
# DNSBL(s) here
DNSBLS = [
"my.own.dnsbl.gr",
]
def is_blacklisted(ip):
try:
rev = '.'.join(reversed(ip.split('.')))
for zone in DNSBLS:
try:
socket.gethostbyname(f"{rev}.{zone}")
return True
except socket.gaierror:
pass
return False
except:
return False # be fail-open on DNS failure
if is_blacklisted(rip):
sys.stderr.write(f"DNSBL blocked IP {rip}\n")
sys.exit(1)
# Otherwise pass to next auth (PAM, passwd-file, sql, etc)
sys.exit(0)
Lefteris
___
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
___
dovecot mailing list -- [3][email protected]
To unsubscribe send an email to [4][email protected]
___
dovecot mailing list -- [5][email protected]
To unsubscribe send an email to [6][email protected]
References
Visible links
1.
https://doc.dovecot.org/2.4.2/core/config/auth/policy.html#authentication-policy
2.
https://www.zerobin.no/?a5b52b2539d7912c#4sYaC5WeT9LHzYKN4XxCgUWr8uPdfCi4WsFdXSuzQDXU
3. mailto:[email protected]
4. mailto:[email protected]
5. mailto:[email protected]
6. mailto:[email protected]
___
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
• Aki Tuomi via dovecot [2026-01-09 12:40]:
YOu can also implement simple RBL auth policy server, the auth policy feature
sends JSON blob of fields and excepts a JSON blob in response. Upside is that
the policy check is done before any authentication happens. You can ignore all
the other stuff and just check the remote IP.
See
https://doc.dovecot.org/2.4.2/core/config/auth/policy.html#authentication-policy
if there's interest, I made a PoC some yearso ago, it uses asyncio and
sets up auth policy server on 127.0.0.1:13380:
https://www.zerobin.no/?a5b52b2539d7912c#4sYaC5WeT9LHzYKN4XxCgUWr8uPdfCi4WsFdXSuzQDXU
This particular version was a WIP and checks Spamhaus DQS in DNS (and I
think I had some idea to use web-service, too, perhaps, but hadn't come
that far), and also sets up an auth policy server on 127.0.0.1:13370
using line-oriented protocol which I used in Exim.
you could use "ai" to clean/tweak it further, if needed.
auth policy server is a great facility, but I ended up just blocking
repeated offenders on the networking level.
Aki
On 09/01/2026 13:19 EET Lefteris Tsintjelis via dovecot
wrote:
On 9 Jan 2026, at 12:31, Aki Tuomi wrote:
On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot
wrote:
Hi,
Is there a way to block with RBLs? I already have a really good and very
trustworthy and accurate internal one that works extremely well and fast with
my SMTP servers for years now. Is there a way to apply the same RBL to dovecot?
Logs are really going crazy as they stopped with SMTP and started with IMAP for
a while now since dovecot is wide open to these attacks. Anvil does not seem to
do much here. I am looking for solutions other than fail2ban or anything
similar to this.
Lefteris
You can use auth_policy_server settings to configure an external service for
this, please see e.g. https://github.com/PowerDNS/weakforced/ as an example of
such service.
Aki
Thank you. Looks very flexible and powerful but in this case seems like a huge
overkill for such a simple thing just for checking one local DNSBL. I was
thinking more like the code below. I think AI gave me a fast and acceptable
solution
#!/usr/bin/env python3
import sys
import socket
data = sys.stdin.buffer.read(1024).split(b'\n')
if len(data) < 3:
sys.exit(1)
username = data[0].decode()
password = data[1].decode() # we don't care
rip = data[2].decode() # remote IP
# DNSBL(s) here
DNSBLS = [
“my.own.dnsbl.gr",
]
def is_blacklisted(ip):
try:
rev = '.'.join(reversed(ip.split('.')))
for zone in DNSBLS:
try:
socket.gethostbyname(f"{rev}.{zone}")
return True
except socket.gaierror:
pass
return False
except:
return False # be fail-open on DNS failure
if is_blacklisted(rip):
sys.stderr.write(f"DNSBL blocked IP {rip}\n")
sys.exit(1)
# Otherwise pass to next auth (PAM, passwd-file, sql, etc)
sys.exit(0)
Lefteris
___
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
___
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
___
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On Tue, 2026-01-13 at 06:02 -0800, Michael Peddemors via dovecot wrote: > > And yes, while disable_plaintext_auth = yes should be the go to, you Please note that "disable_plaintext_auth" is a 2.3 config and it has been replaced in 2.4 by "auth_allow_cleartext" which defaults to no. See: https://doc.dovecot.org/2.4.2/installation/upgrade/2.3-to-2.4.html#converted-settings gene signature.asc Description: This is a digitally signed message part ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
> On 13 Jan 2026, at 16:46, Marc via dovecot wrote: > > > All these rbls are only acting on bulk, you won't prevent targetted abuse, > and you also need to be able to whitelist. Best is to have your own rbls and > centralised logging for your servers. The logging server adds ip ranges to > your rbl and all servers use the rbl. But beware of clients that are > misconfigured and create a false positive blocking everyone from that ip > (like a business connection) I second and salute this approach. It is by far the best one I have tried over the years. The tricky part is exactly to avoid any false positives. Lefteris ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
RE: Blocking with RBLs
All these rbls are only acting on bulk, you won't prevent targetted abuse, and you also need to be able to whitelist. Best is to have your own rbls and centralised logging for your servers. The logging server adds ip ranges to your rbl and all servers use the rbl. But beware of clients that are misconfigured and create a false positive blocking everyone from that ip (like a business connection) ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
Michael Peddemors via dovecot wrote: And yes, while disable_plaintext_auth = yes should be the go to, you want to stop accepting connections on 110/143 (993/995 should be used). In some environments, you could take it even further by allowing access to the IMAP and SMTP submission ports only via a VPN such as WireGuard or Nebula. ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
You should look for RBL's targeting/with the word PROXY in them. SpamRats RATS-PROXY instance. One of the most prolific actors targeting ISP/Telcos uses proxies as their prime way of disguising their source. And yes, while disable_plaintext_auth = yes should be the go to, you want to stop accepting connections on 110/143 (993/995 should be used). Unfortunatly,it is not just your AUTH, but clients will attempt to connect to port 110/143 sometimes during discovery, or as a fallback, which means they will send credentials plain text, even if you don't allow authentication, allowing them to be 'sniffed'. Email clients 'should' be updated to never do that of course. On 2026-01-12 19:26, John Fawcett via dovecot wrote: for On 12/01/2026 22:59, Michael Peddemors via dovecot wrote: On 2026-01-09 18:04, Joseph Tam via dovecot 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% Forgot one caveat, try to avoid larger RBL's that list dynamic IPs as well, while it might be tempting to try to stop all the 'bot' activity, bots' are not the biggest threat, and are easier to stop.. blocking DUL IPs too will only get you complaints.. It's the real bad actors that RBL's help for IMAP Auth protection ;) Oh, and watch the increasing number of residential 'proxies'.. and do you REALLY want people logging in through VPN's? You want to know who is accessing your customer email accounts.with An even bigger threat, those people who still allow POP 110, or IMAP 143, be nice if that was deprecated in dovecot and every other mail platform.. SSL/TLS only.. Have a great and safe 2026 everyone! Hi Michael I personally disabled pop3 but I would still leave it in the software in case people still find a need for it. I also use IMAP port 143 with STARTTLS so it should be ok. Dovecot setting (2.3 at least) disable_plaintext_auth = yes should stop people authenticating over a non secure connection and that is the default. It is an interesting point about VPNs. I have some experience of bad actors over VPNs. If I could block VPNs I would do it. Is there a list of VPN ips somewhere? best regards John ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected] ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On 12/01/2026 22:59, Michael Peddemors via dovecot wrote: On 2026-01-09 18:04, Joseph Tam via dovecot 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% Forgot one caveat, try to avoid larger RBL's that list dynamic IPs as well, while it might be tempting to try to stop all the 'bot' activity, bots' are not the biggest threat, and are easier to stop.. blocking DUL IPs too will only get you complaints.. It's the real bad actors that RBL's help for IMAP Auth protection ;) Oh, and watch the increasing number of residential 'proxies'.. and do you REALLY want people logging in through VPN's? You want to know who is accessing your customer email accounts. An even bigger threat, those people who still allow POP 110, or IMAP 143, be nice if that was deprecated in dovecot and every other mail platform.. SSL/TLS only.. Have a great and safe 2026 everyone! Hi Michael I personally disabled pop3 but I would still leave it in the software in case people still find a need for it. I also use IMAP port 143 with STARTTLS so it should be ok. Dovecot setting (2.3 at least) disable_plaintext_auth = yes should stop people authenticating over a non secure connection and that is the default. It is an interesting point about VPNs. I have some experience of bad actors over VPNs. If I could block VPNs I would do it. Is there a list of VPN ips somewhere? best regards John ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On 2026-01-09 18:04, Joseph Tam via dovecot 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% Forgot one caveat, try to avoid larger RBL's that list dynamic IPs as well, while it might be tempting to try to stop all the 'bot' activity, bots' are not the biggest threat, and are easier to stop.. blocking DUL IPs too will only get you complaints.. It's the real bad actors that RBL's help for IMAP Auth protection ;) Oh, and watch the increasing number of residential 'proxies'.. and do you REALLY want people logging in through VPN's? You want to know who is accessing your customer email accounts. An even bigger threat, those people who still allow POP 110, or IMAP 143, be nice if that was deprecated in dovecot and every other mail platform.. SSL/TLS only.. Have a great and safe 2026 everyone! -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
You might want to consider a few others as well that might be in RBL format.. Glad you are getting use out of auth.spamrats.com, it specifically targets static known sources of auth attackers.. But consider some proxy RBL's as well. There are a couple out there, eg RATS-PROXY et al. Note, that RATS-AUTH contains RATS-NULL (Drop) lists as well, but you can use things like the SpamHaus DROP lists as well. And if you are aggressive, and you know know noone is checking email from china, you can even use RBL's for that. However! (Caveat) .. you should always implement an auth exemption list mechanism for the odd legitimate IP in the midst of a sea of bad IPs. Eg, the amount of BEC attacks from Google, Digital Ocean, Azure, Tencent etc is immense, and we are seeing more targeting IMAP directly all the time. But you 'might' have a legitimate IMAP poller on one of those IPs. (More necessary on SMTP, where people need to 'relay' from cloud servers through 3rd party email servers) Not to using this list to hype a service, but everyone should be using RBL's in the dovecot AUTH layer... If anyone isn't using RATS-AUTH, API keys are free.. you should be using at least them, if not multiple RBL's, we see far too much abuse through government Zimbra servers, from well know bullet proof hosters, that have been listed for years. On 2026-01-11 16:01, Mateusz Lamparski via dovecot wrote: Do rbl check-in niedz., 11 sty 2026, 15:23 uzytkownik John Fawcett via dovecot <[1][email protected]> napisal/: On 10/01/2026 03:04, Joseph Tam via dovecot wrote: > On Fri, 9 Jan 2026, John Fawcett wrote: > >> I find it useful (both on Postfix and Dovecot) to apply XBL to block >> connection to authenticated services. > > I grep'd through last week's logs for probable brute forcers, and > check the > IPs against 3 RBLs. (Many IPs tried only once.) > > Aggregate statistics: > > 87 - - -(No hits) > 46 + - - > 32 + + - >9 + - + >6 + + + >5 - + - >4 - - + > > 102/189 (54%) were listed by at least one of the RBLs, with the > following stats > > RBLhitsraterate (>0 hits) > (col#1) [2]bl.blocklist.de9349%91% > (col#2) [3]auth.spamrats.com 5228%51% > (col#3) [4]xbl.spamhaus.org 1910%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. > > Joseph Tam <[5][email protected]> > ___ I pulled out the equivalent stats that I see for imap for 7 days 03-09 January. There were 970 apparently rouge connections from 315 distinct ips. 134--- 131--+ 35+-+ 7+-- 3-+- 1-++ 1+++ RBLhitsrateRate > 0 (col#1) [6]bl.blocklist.de4314%24% (col#2) [7]auth.spamrats.com52%3% (col#3) [8]xbl.spamhaus.org16854%94% I'm getting a pretty good coverage with xbl. The 168 is a small overestimate, since I based these numbers on a current lookup of the blocklists to be comparable with yours, whereas at the time of blocking only 158 were on XBL. It is worth mentioning that none of the ips that were not blocked by spamrats and XBL (315-158=157) actually did an authentication attempt, some for SSL errors, some for protocol errors or just for disconnecting without tryinig. My max errors allowed is 1. Out of curiosity I did the same for smtp auth, where volumes of attempts that I see have really dropped off. There were 313 apparently rouge connections from 98 distinct ips. 48--- 35--+ 7+-+ 4-++ 2-+- 1+-- 1+++ RBLhitsrateRate > 0 (col#1) [9]bl.blocklist.de99%18% (col#2) [10]auth.spamrats.com77%14% (col#3) [11]xbl.spamhaus.org4748%94% Also here a reasonable coverage from XBL. Also in this case non of the ips that were not blocked by XBL (98-47=51) actually did an authentication attempt, mostly due to improper pipelining errors or just disconnecting without trying to authenticate. John ___ dovecot mailing list -- [12][email protected] To unsubscribe send an email to [13][email protected] References Visible links
Re: Blocking with RBLs
On 11 Jan 2026, at 05:46, Lefteris Tsintjelis via dovecot
wrote:
# This should be before any other passdb
passdb {
args = /...path to.../local.rbl.sh
driver = checkpassword
result_success = continue
result_failure = return-fail
}
With the above my test mail server easily became an open relay :) So one
SERIOUS correction here, the result_sucess MUST BE continue-fail so the
verification passes to the next passdb in chain. So the correct way to do
it is:
passdb {
args = /...path to.../local.rbl.sh
driver = checkpassword
result_success = continue-fail
result_failure = return-fail
}
Lefteris
___
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
Do rbl check-in niedz., 11 sty 2026, 15:23 uzytkownik John Fawcett via dovecot <[1][email protected]> napisal/: On 10/01/2026 03:04, Joseph Tam via dovecot wrote: > On Fri, 9 Jan 2026, John Fawcett wrote: > >> I find it useful (both on Postfix and Dovecot) to apply XBL to block >> connection to authenticated services. > > I grep'd through last week's logs for probable brute forcers, and > check the > IPs against 3 RBLs. (Many IPs tried only once.) > > Aggregate statistics: > > 87 - - -(No hits) > 46 + - - > 32 + + - >9 + - + >6 + + + >5 - + - >4 - - + > > 102/189 (54%) were listed by at least one of the RBLs, with the > following stats > > RBLhitsraterate (>0 hits) > (col#1) [2]bl.blocklist.de9349%91% > (col#2) [3]auth.spamrats.com 5228%51% > (col#3) [4]xbl.spamhaus.org 1910%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. > > Joseph Tam <[5][email protected]> > ___ I pulled out the equivalent stats that I see for imap for 7 days 03-09 January. There were 970 apparently rouge connections from 315 distinct ips. 134--- 131--+ 35+-+ 7+-- 3-+- 1-++ 1+++ RBLhitsrateRate > 0 (col#1) [6]bl.blocklist.de4314%24% (col#2) [7]auth.spamrats.com52%3% (col#3) [8]xbl.spamhaus.org16854%94% I'm getting a pretty good coverage with xbl. The 168 is a small overestimate, since I based these numbers on a current lookup of the blocklists to be comparable with yours, whereas at the time of blocking only 158 were on XBL. It is worth mentioning that none of the ips that were not blocked by spamrats and XBL (315-158=157) actually did an authentication attempt, some for SSL errors, some for protocol errors or just for disconnecting without tryinig. My max errors allowed is 1. Out of curiosity I did the same for smtp auth, where volumes of attempts that I see have really dropped off. There were 313 apparently rouge connections from 98 distinct ips. 48--- 35--+ 7+-+ 4-++ 2-+- 1+-- 1+++ RBLhitsrateRate > 0 (col#1) [9]bl.blocklist.de99%18% (col#2) [10]auth.spamrats.com77%14% (col#3) [11]xbl.spamhaus.org4748%94% Also here a reasonable coverage from XBL. Also in this case non of the ips that were not blocked by XBL (98-47=51) actually did an authentication attempt, mostly due to improper pipelining errors or just disconnecting without trying to authenticate. John ___ dovecot mailing list -- [12][email protected] To unsubscribe send an email to [13][email protected] References Visible links 1. mailto:[email protected] 2. http://bl.blocklist.de/ 3. http://auth.spamrats.com/ 4. http://xbl.spamhaus.org/ 5. mailto:[email protected] 6. http://bl.blocklist.de/ 7. http://auth.spamrats.com/ 8. http://xbl.spamhaus.org/ 9. http://bl.blocklist.de/ 10. http://auth.spamrats.com/ 11. http://xbl.spamhaus.org/ 12. mailto:[email protected] 13. mailto:[email protected] ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On 10/01/2026 03:04, Joseph Tam via dovecot wrote: On Fri, 9 Jan 2026, John Fawcett wrote: I find it useful (both on Postfix and Dovecot) to apply XBL to block connection to authenticated services. I grep'd through last week's logs for probable brute forcers, and check the IPs against 3 RBLs. (Many IPs tried only once.) Aggregate statistics: 87 - - - (No hits) 46 + - - 32 + + - 9 + - + 6 + + + 5 - + - 4 - - + 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. Joseph Tam ___ I pulled out the equivalent stats that I see for imap for 7 days 03-09 January. There were 970 apparently rouge connections from 315 distinct ips. 134 - - - 131 - - + 35 + - + 7 + - - 3 - + - 1 - + + 1 + + + RBL hits rate Rate > 0 (col#1) bl.blocklist.de 43 14% 24% (col#2) auth.spamrats.com 5 2% 3% (col#3) xbl.spamhaus.org 168 54% 94% I'm getting a pretty good coverage with xbl. The 168 is a small overestimate, since I based these numbers on a current lookup of the blocklists to be comparable with yours, whereas at the time of blocking only 158 were on XBL. It is worth mentioning that none of the ips that were not blocked by spamrats and XBL (315-158=157) actually did an authentication attempt, some for SSL errors, some for protocol errors or just for disconnecting without tryinig. My max errors allowed is 1. Out of curiosity I did the same for smtp auth, where volumes of attempts that I see have really dropped off. There were 313 apparently rouge connections from 98 distinct ips. 48 - - - 35 - - + 7 + - + 4 - + + 2 - + - 1 + - - 1 + + + RBL hits rate Rate > 0 (col#1) bl.blocklist.de 9 9% 18% (col#2) auth.spamrats.com 7 7% 14% (col#3) xbl.spamhaus.org 47 48% 94% Also here a reasonable coverage from XBL. Also in this case non of the ips that were not blocked by XBL (98-47=51) actually did an authentication attempt, mostly due to improper pipelining errors or just disconnecting without trying to authenticate. John ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On 9 Jan 2026, at 12:31, Aki Tuomi via dovecot
wrote:
On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot
wrote:
Hi,
Is there a way to block with RBLs? I already have a really good and
very trustworthy and accurate internal one that works extremely well
and fast with my SMTP servers for years now. Is there a way to apply
the same RBL to dovecot? Logs are really going crazy as they stopped
with SMTP and started with IMAP for a while now since dovecot is wide
open to these attacks. Anvil does not seem to do much here. I am
looking for solutions other than fail2ban or anything similar to this.
Lefteris
You can use auth_policy_server settings to configure an external service
for this, please see e.g. https://github.com/PowerDNS/weakforced/ as an
example of such service.
Aki
I think the following is very light in resources by using POSIX and can be
used with IPv4 and IPv6 and does exactly what I want to check my single
trusted DNSBL.
# This should be before any other passdb
passdb {
args = /...path to.../local.rbl.sh
driver = checkpassword
result_success = continue
result_failure = return-fail
}
The following must be executable:
cat local.rbl.sh
#!/bin/sh
# --- CONFIGURATION ---
DNSBL_ZONE="mysingle.trusted.dnsbl"
LOGGING=1
# Log helper
log_msg() {
if [ "$LOGGING" -eq 1 ]; then
logger -p mail.notice -t dovecot-dnsbl "$1"
fi
}
# 1. CONSUME CREDENTIALS (Read FD 3 if available)
user=""
if [ -e /dev/fd/3 ]; then
data=$(dd if=/dev/fd/3 bs=4096 count=1 2>/dev/null)
if [ -n "$data" ]; then
user=$(echo "$data" | awk -F '\0' '{print $1}')
fi
fi
# 2. GET IP ADDRESS
REMOTE_IP="${TCPREMOTEIP:-$IP}"
# If running manually for a test, allow passing IP as 2nd arg
# usage: ./script.sh dummy_binary 1.2.3.4
if [ -z "$REMOTE_IP" ] && [ -n "$2" ]; then
REMOTE_IP="$2"
fi
if [ -z "$REMOTE_IP" ]; then
# No IP found, allow access (e.g. internal socket or manual run
without args)
log_msg "Allowing (no IP provided)${user:+ for user $user}"
if [ -x "$1" ]; then
exec "$1"
else
printf '\0'
exit 0
fi
fi
# 3. DETECT IP VERSION AND PREPARE QUERY
if echo "$REMOTE_IP" | grep -q ":"; then
# --- IPv6 LOGIC (AWK) ---
REVERSED_IP=$(echo "$REMOTE_IP" | awk '
BEGIN { FS=":"; OFS="" }
{
if (index($0, "::") > 0) {
match($0, /::/);
head = substr($0, 1, RSTART-1);
tail = substr($0, RSTART+2);
n_head = (head == "") ? 0 : split(head, h, ":");
n_tail = (tail == "") ? 0 : split(tail, t, ":");
missing = 8 - n_head - n_tail;
full = head;
for(i=0; i=1; i--) {
val = groups[i];
while (length(val) < 4) val = "0" val;
for (j=4; j>=1; j--) res = res "." substr(val, j, 1);
}
print substr(res, 2);
}')
else
# --- IPv4 LOGIC ---
REVERSED_IP=$(echo "$REMOTE_IP" | awk -F. '{print $4"."$3"."$2"."$1}')
fi
# 4. PERFORM LOOKUP
if [ -z "$REVERSED_IP" ]; then
# Invalid IP, allow
log_msg "Allowing invalid IP $REMOTE_IP${user:+ for user $user}"
if [ -x "$1" ]; then
exec "$1"
else
printf '\0'
exit 0
fi
fi
QUERY="${REVERSED_IP}.${DNSBL_ZONE}"
if host -t A "$QUERY" >/dev/null 2>&1; then
log_msg "REJECTED: $REMOTE_IP is listed in $DNSBL_ZONE${user:+ for
user $user}"
exit 1
fi
# 5. SUCCESS HAND-OFF
log_msg "Allowing $REMOTE_IP (Clean)${user:+ for user $user}"
if [ -x "$1" ]; then
exec "$1"
else
printf '\0'
exit 0
fi
Lefteris
___
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On Sat, 10 Jan 2026, John Fawcett wrote: Out of curiosity are those data from smtp auth or from Dovecot brute force auth attempts? Dovecot. I assume Dovecot but wanted to make sure I understood correctly. Do you do any kind of blocking on Dovecot that could influence the numbers? Not really. I thought perhaps some of my larger Asian firewall blockw could affect this, but the firewall logs do not show this. The volume of BFD attempts are way higher on SMTP than IMAP/POP3. It's a while since I checked blocking performance, but what I seem to remember is that I got a lot more attempts before I started blocking, so what I see now with blocking applied is not necessarily representative of what I would see if I didn't block. My assumption is that behind multiple ips there can be the same actor switching ips to fly under the radar of fail2ban. When applying outright blocking at connection time seems that the actors can move on elsewhere and consequently you end up avoiding more than you actually see as rejects. That's kind of anecdotal, I don't think I have hard evidence of it. I guess some attackers could give up after some rejections, but mostly I see time/user correlated attempt from many different IPs, indicating the same actor is using a botnet. Joseph Tam ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On 10/01/2026 03:04, Joseph Tam via dovecot wrote: On Fri, 9 Jan 2026, John Fawcett wrote: I find it useful (both on Postfix and Dovecot) to apply XBL to block connection to authenticated services. I grep'd through last week's logs for probable brute forcers, and check the IPs against 3 RBLs. (Many IPs tried only once.) Aggregate statistics: 87 - - - (No hits) 46 + - - 32 + + - 9 + - + 6 + + + 5 - + - 4 - - + 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. Joseph Tam Hi Joseph thanks for the tip. I do use auth.spamrats.com on smtp auth, not so far on imap/managesieve. I do know of blocklist.de but I can't remember now if I evaluated to use it in this context. I will look into those. Out of curiosity are those data from smtp auth or from Dovecot brute force auth attempts? I assume Dovecot but wanted to make sure I understood correctly. Do you do any kind of blocking on Dovecot that could influence the numbers? It's a while since I checked blocking performance, but what I seem to remember is that I got a lot more attempts before I started blocking, so what I see now with blocking applied is not necessarily representative of what I would see if I didn't block. My assumption is that behind multiple ips there can be the same actor switching ips to fly under the radar of fail2ban. When applying outright blocking at connection time seems that the actors can move on elsewhere and consequently you end up avoiding more than you actually see as rejects. That's kind of anecdotal, I don't think I have hard evidence of it. John ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On Fri, 9 Jan 2026, John Fawcett wrote: I find it useful (both on Postfix and Dovecot) to apply XBL to block connection to authenticated services. I grep'd through last week's logs for probable brute forcers, and check the IPs against 3 RBLs. (Many IPs tried only once.) Aggregate statistics: 87 - - - (No hits) 46 + - - 32 + + - 9 + - + 6 + + + 5 - + - 4 - - + 102/189 (54%) were listed by at least one of the RBLs, with the following stats RBL hitsraterate (>0 hits) (col#1) bl.blocklist.de 93 49% 91% (col#2) auth.spamrats.com 52 28% 51% (col#3) xbl.spamhaus.org19 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. Joseph Tam ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
YOu can also implement simple RBL auth policy server, the auth policy feature
sends JSON blob of fields and excepts a JSON blob in response. Upside is that
the policy check is done before any authentication happens. You can ignore all
the other stuff and just check the remote IP.
See
https://doc.dovecot.org/2.4.2/core/config/auth/policy.html#authentication-policy
Aki
> On 09/01/2026 13:19 EET Lefteris Tsintjelis via dovecot
> wrote:
>
>
> > On 9 Jan 2026, at 12:31, Aki Tuomi wrote:
> >
> >
> >> On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot
> >> wrote:
> >>
> >>
> >> Hi,
> >>
> >> Is there a way to block with RBLs? I already have a really good and very
> >> trustworthy and accurate internal one that works extremely well and fast
> >> with my SMTP servers for years now. Is there a way to apply the same RBL
> >> to dovecot? Logs are really going crazy as they stopped with SMTP and
> >> started with IMAP for a while now since dovecot is wide open to these
> >> attacks. Anvil does not seem to do much here. I am looking for solutions
> >> other than fail2ban or anything similar to this.
> >>
> >> Lefteris
> >
> > You can use auth_policy_server settings to configure an external service
> > for this, please see e.g. https://github.com/PowerDNS/weakforced/ as an
> > example of such service.
> >
> > Aki
>
> Thank you. Looks very flexible and powerful but in this case seems like a
> huge overkill for such a simple thing just for checking one local DNSBL. I
> was thinking more like the code below. I think AI gave me a fast and
> acceptable solution
>
> #!/usr/bin/env python3
> import sys
> import socket
>
> data = sys.stdin.buffer.read(1024).split(b'\n')
> if len(data) < 3:
> sys.exit(1)
>
> username = data[0].decode()
> password = data[1].decode() # we don't care
> rip = data[2].decode() # remote IP
>
> # DNSBL(s) here
> DNSBLS = [
> “my.own.dnsbl.gr",
> ]
>
> def is_blacklisted(ip):
> try:
> rev = '.'.join(reversed(ip.split('.')))
> for zone in DNSBLS:
> try:
> socket.gethostbyname(f"{rev}.{zone}")
> return True
> except socket.gaierror:
> pass
> return False
> except:
> return False # be fail-open on DNS failure
>
> if is_blacklisted(rip):
> sys.stderr.write(f"DNSBL blocked IP {rip}\n")
> sys.exit(1)
>
> # Otherwise pass to next auth (PAM, passwd-file, sql, etc)
> sys.exit(0)
>
> Lefteris
> ___
> dovecot mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
___
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
On 09/01/2026 11:08, Lefteris Tsintjelis via dovecot wrote: Hi, Is there a way to block with RBLs? I already have a really good and very trustworthy and accurate internal one that works extremely well and fast with my SMTP servers for years now. Is there a way to apply the same RBL to dovecot? Logs are really going crazy as they stopped with SMTP and started with IMAP for a while now since dovecot is wide open to these attacks. Anvil does not seem to do much here. I am looking for solutions other than fail2ban or anything similar to this. Lefteris ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected] Hi Lefteris for smtp port 25 incoming email the use of RBLs is a consolidated practice but for smtp auth the use of RBLs may not be so easy to apply and I think the same goes for IMAP authentication. I find it useful (both on Postfix and Dovecot) to apply XBL to block connection to authenticated services. For me it works, but I have a very low probability that legitimate users will connect from ip addresses on XBL. Others have mentioned that it is not generally feasible if you have a lot of users from dynamic ips, due to the potential of recycling of blocked ip addresses to legitimate users. In Dovecot if I remember correctly Aki previously mentioned that it would be possible to use LUA scripts to do RBL looks prior to authenticating, something that is on my to do list for future investigation. In the meantime I run a locally patched version of Dovecot. I added an "rbl_check" parameter to the protocol section, so it can also be configured for managesieve as well as imap and pop3. I also took the step of making protocol error limits configurable and then setting them to a very low value (in my case 1). I think legitimate clients don't need much space to make protocol errors so I am not too lenient. John ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
> On 9 Jan 2026, at 12:31, Aki Tuomi wrote:
>
>
>> On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot
>> wrote:
>>
>>
>> Hi,
>>
>> Is there a way to block with RBLs? I already have a really good and very
>> trustworthy and accurate internal one that works extremely well and fast
>> with my SMTP servers for years now. Is there a way to apply the same RBL to
>> dovecot? Logs are really going crazy as they stopped with SMTP and started
>> with IMAP for a while now since dovecot is wide open to these attacks. Anvil
>> does not seem to do much here. I am looking for solutions other than
>> fail2ban or anything similar to this.
>>
>> Lefteris
>
> You can use auth_policy_server settings to configure an external service for
> this, please see e.g. https://github.com/PowerDNS/weakforced/ as an example
> of such service.
>
> Aki
Thank you. Looks very flexible and powerful but in this case seems like a huge
overkill for such a simple thing just for checking one local DNSBL. I was
thinking more like the code below. I think AI gave me a fast and acceptable
solution
#!/usr/bin/env python3
import sys
import socket
data = sys.stdin.buffer.read(1024).split(b'\n')
if len(data) < 3:
sys.exit(1)
username = data[0].decode()
password = data[1].decode() # we don't care
rip = data[2].decode() # remote IP
# DNSBL(s) here
DNSBLS = [
“my.own.dnsbl.gr",
]
def is_blacklisted(ip):
try:
rev = '.'.join(reversed(ip.split('.')))
for zone in DNSBLS:
try:
socket.gethostbyname(f"{rev}.{zone}")
return True
except socket.gaierror:
pass
return False
except:
return False # be fail-open on DNS failure
if is_blacklisted(rip):
sys.stderr.write(f"DNSBL blocked IP {rip}\n")
sys.exit(1)
# Otherwise pass to next auth (PAM, passwd-file, sql, etc)
sys.exit(0)
Lefteris
___
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Re: Blocking with RBLs
> On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot > wrote: > > > Hi, > > Is there a way to block with RBLs? I already have a really good and very > trustworthy and accurate internal one that works extremely well and fast with > my SMTP servers for years now. Is there a way to apply the same RBL to > dovecot? Logs are really going crazy as they stopped with SMTP and started > with IMAP for a while now since dovecot is wide open to these attacks. Anvil > does not seem to do much here. I am looking for solutions other than fail2ban > or anything similar to this. > > Lefteris You can use auth_policy_server settings to configure an external service for this, please see e.g. https://github.com/PowerDNS/weakforced/ as an example of such service. Aki ___ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
