On 9 Jan 2026, at 12:31, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:

...

On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot <dovecot@dovecot.org> 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

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

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#4sYaC5WeT9LHzYKN4XxCgUWr8uPdfCi4WsF...

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 <dovecot@dovecot.org> wrote:

...

On 9 Jan 2026, at 12:31, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:

...

On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot <dovecot@dovecot.org> 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org

---

dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org

On 9 Jan 2026, at 12:31, Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:

...

On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot <dovecot@dovecot.org> 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<missing; i++) full = full ":0000"; if (tail != "") { if (full != "") full = full ":" tail; else full = tail; } } else { full = $0; } split(full, groups, ":"); res = ""; for (i=8; 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

 On 9 Jan 2026, at 12:31, Aki Tuomi via dovecot <dovecot@dovecot.org>
 wrote:

   On 09/01/2026 12:08 EET Lefteris Tsintjelis via dovecot
   <dovecot@dovecot.org> 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<missing; i++) full = full ":0000";

           if (tail != "") { if (full != "") full = full ":" tail; else

full = tail; }

       } else { full = $0; }



       split(full, groups, ":");

       res = "";

       for (i=8; 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

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 <jtam.home@gmail.com>

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

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 <jtam.home@gmail.com>

---

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

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]dovecot@dovecot.org> 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
  >
  >     RBL                hits    rate    rate (>0 hits)
  >     (col#1) [2]bl.blocklist.de        93    49%    91%
  >     (col#2) [3]auth.spamrats.com     52    28%    51%
  >     (col#3) [4]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 <[5]jtam.home@gmail.com>
  > _______________________________________________

  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) [6]bl.blocklist.de    43    14%    24%
  (col#2) [7]auth.spamrats.com    5    2%    3%
  (col#3) [8]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) [9]bl.blocklist.de    9    9%    18%
       (col#2) [10]auth.spamrats.com    7    7%    14%
       (col#3) [11]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 -- [12]dovecot@dovecot.org
  To unsubscribe send an email to [13]dovecot-leave@dovecot.org

References

Visible links
1. mailto:dovecot@dovecot.org
2. http://bl.blocklist.de/
3. http://auth.spamrats.com/
4. http://xbl.spamhaus.org/
5. mailto:jtam.home@gmail.com
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:dovecot@dovecot.org 13. mailto:dovecot-leave@dovecot.org

---

dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org

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

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

Michael Peddemors via dovecot <dovecot@dovecot.org> 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.

On 13 Jan 2026, at 16:46, Marc via dovecot <dovecot@dovecot.org> 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

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>

On January 26, 2026 22:55:40 Lefteris Tsintjelis via dovecot <dovecot@dovecot.org> 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

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