Allow RBL checks during authentication

Idea shared by Rene Eisenmann - 4/15/2026 at 12:50 AM

Proposed

Recently we had a lot of password brute force attempts for mailboxes from various networks, which resulted in numerous mailboxes getting auto-locked. Many of those IP addresses were already listed in either AbuseIPDB or Spamhaus DROP.

My proposal is to make it possible to do a RBL lookup right after a client attempts an authentication, and drop that connection based on the result, before any login can be tried. Blocking offensive IP addresses via the dashbord is cumbersome and only reactive, not proactive.

It would also make it possible to feed offensive IP addresses from other sources into an internal RBL to have a fine grained control over who to block.

5 Replies

Reply to Thread

Derek Curtis Replied

4/16/2026 at 10:56 AM

Employee Post

Hey, Rene

It's an interesting idea. However, RBLs are not known for being quick when returning results, so this could cause a significant slowdown in authentication. So while it might be ok for protocols that use a long-lived connection, like IMAP and POP, it would probably be an issue for EWS, EAS, and MAPI -- and maybe even webmail.

Derek Curtis

CCO

SmarterTools Inc.

www.smartertools.com

Rene Eisenmann Replied

4/17/2026 at 12:03 AM

Hi Derek,

according to the stats (avg time) in our Dashboard, response times are (with one exception) under 50ms. Same for our own internal RBL.

Even if this might affect MS protocols, at least SMTP/IMAP/POP security would benefit a lot from it.

Webmail is session based I guess, so it would only happen once at the login.

As for the slowdown, there could an enforced timeout of eg 1s for RBL requests (and otoh, tarpitting is not that uncommon too).

Douglas Foster Replied

4/17/2026 at 6:00 AM

I see the appeal of this idea. One caveat:

Most RBLs are looking for IPs that should not be acting as email servers. This may include residential IPs and anything else with a dynamic IP address. For your topic, you want to allow residential IPs and other dynamic IP addresses, because you are expecting residential connections. For SpamHaus, the residential IPs can be allowed by excluding results that indicate a match on the PBL list. I don't know if other services flag dynamic addresses or if they provide a way to handle them differently.

Roger Replied

4/18/2026 at 10:52 AM

Hi everyone,

Personally, I wouldn’t integrate this at the application level into a program like SmarterMail; instead, I’d handle it right at the router/firewall using reputation-based lists. With pfSense, for example, you can easily set this up using pfBlockerNG. The advantage is that you can even filter out known sources cleanly using a native alias per port, which significantly reduces noise.

Rene Eisenmann Replied

4/27/2026 at 1:39 AM

@Douglas:

I especially mentioned AbuseIPDB or Spamhaus DROP because those list IP addresses you definitively do not want to connect to your server.

"AbuseIPDB is a project dedicated to helping systems administrators and webmasters check and report IP addresses that are involved in malicious activity such as spamming, hack attempts, DDoS attacks, etc."

"Don't Route Or Peer (DROP) lists the worst of the worst IP traffic. It is an advisory “drop all traffic”, containing IP ranges which are so dangerous to internet users that Spamhaus provides access to anyone who wants to add this layer of protection, free of charge."

If a legitimate customer gets blocked by that, his network has a really big problem.

@Roger:

Not every firewall can handle blocklists in the range of 50-100k entries. Plus, you need to update it daily to add new offenders.

A RBL handles this just fine and is fast enough. Plus, the check logic is already implemented; it "only" needs to be activated during auth.

You can do that in exim (ACL_SMTP_AUTH_BLOCK) or postfix (smtpd_client_restrictions).

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text