1 (edited by caretech 2026-10-15 22:17:10)

Topic: Feature request: Fail2Ban Management Issues

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 2026090801 (Backend: pgsql, Date: 2026-09-15 19:52:54) iRedMail Enterprise Edition: https://www.iredmail.org/ee.html
- Deployed with iRedMail Easy or the downloadable installer? First deployed w/ installer, then migrated to EE recently
- Linux/BSD distribution name and version: Debian 12.15
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): PGSQL
- Web server (Apache or Nginx): Nginx
- Manage mail accounts with iRedAdmin-Pro? Yes, iRedMail EE
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

We host thousands of users on a very busy server and our support reps find the Banned IP Address list basically unmanageable. This morning for example, there were at least 17 pages of banned addresses. The list is not searchable; the only way to search is to load 1 page at a time in the browser and use the browser's Find function. With more than a dozen pages to laboriously search one at a time, this is not workable.

Summary:
1. We need a way to search the banned IP address list.

2. Something is not quite right with fail2ban functionality since migrating to EE. Various times we will Unban an address in the admin interface but the user will continue to be banned on some ports. (For example, he might be able to connect to IMAP but not to SMTP, or vice versa). We need to restart fail2ban in order to clear the issue in these cases.

Today one of our techs was helping a customer reset his account password and of course the user got banned during the process. I told our support rep to just clear all 17+ pages of banned addresses since manually hunting all those pages is untenable. He used the Unban All button. The client was then able to send email but not receive. I logged into the server and issued "systemctl restart fail2ban" and that got the client out of IMAP jail.

Regarding #2, let me know if there's specific log data you need for this. I haven't been able to find meaningful log data beyond basic fail2ban info telling of found, banned, and unbanned addresses.

In general we find fail2ban pretty jumpy. It's almost impossible to lead a client through a password change without getting him banned -- this is a routine annoyance.

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: Feature request: Fail2Ban Management Issues

Hi @caretech.

1: You will get the search feature in upcoming EE release.
2: It's possible that user has several MUAs (e.g. desktop MUA, phone) configured with old password, they were still accessing IMAP/POP3 services right after password reset, which triggered the ban.

Fail2ban seems doesn't support "ignore this IP for 1 hour", i will try to figure out an alternative way to handle this issue. Stay tuned.

3

Re: Feature request: Fail2Ban Management Issues

I appreciate your response, thank you! I'll wait for further development on this.

4

Re: Feature request: Fail2Ban Management Issues

To your point on multiple MUA's configured, this is very often the case. Then sometimes you have the user who is "absolutely sure" he updated all his clients but still gets banned randomly; then it turns out some old forgotten iPod gets pulled out of a drawer and turned on once in a while and tries to check mail... but even instances like that aside, it is very difficult to update a few MUAs without getting nailed for incorrect passwords at least once.

In all the details I posted, I also hope that my point about Unbanning not always fully working, making it necessary to restart fail2ban to truly unban clients, was not lost.

5

Re: Feature request: Fail2Ban Management Issues

Checked fail2ban-client command line arguments, this idea may work:

- on EE web ui, add a new button "Ignore" right beside banned IP address
- click "Ignore" to ignore this IP in all jails with command "fail2ban-client set <JAIL> addignoreip <IP>", also saves the IP and timestamp in SQL db.
- add an internal cron job in EE (not the one you manage with "crontab" command), query the SQL db regularly and delete the ignored IP on time with command "fail2ban-client set <JAIL> delignoreip <IP>".

Is it ideal for you? Any suggestions?

6

Re: Feature request: Fail2Ban Management Issues

By the way, do you need to check the log lines which triggered the ban while managing banned IP addresses?

We're considering replacing Fail2ban by fail2ban-rs, it's written in Rust with better performance, but it doesn't save related log lines:
https://github.com/aejimmi/fail2ban-rs

7

Re: Feature request: Fail2Ban Management Issues

I didn't mean to ignore this, I've been away and am just now catching up on items that need my attention.

To your first post: Would addresses ignored in this way be ignored permanently, or just until the next restart of the fail2ban process? If it's permanent I have mixed feelings about it. It's a great idea but I can see Tier 1 technicians abusing this, adding too many addresses to the ignore list... I'll chew on that one and post again if I have better inputs after thinking about it more.

To your second post: Yes, it is very helpful to know why an IP address was banned. It has helped us pinpoint the root problem many times:

1. Which username is causing the issue? (this helps to narrow it down to a limited set of MUA's on a typical SMB client LAN)
2. Was the error related to IMAP or SMTP?
3. What error was thrown? This has helped us in deciding if it's an issue such as trying to use SSL over the StartTLS port, for instance.

I'm in favor of performance increases but would be quite sorry to lose the insights into how fail2ban reached its decision.

I haven't looked long at the shared github repo yet. Do they have this functionality on their radar?

8

Re: Feature request: Fail2Ban Management Issues

caretech wrote:

To your first post: Would addresses ignored in this way be ignored permanently, or just until the next restart of the fail2ban process? If it's permanent I have mixed feelings about it. It's a great idea but I can see Tier 1 technicians abusing this, adding too many addresses to the ignore list... I'll chew on that one and post again if I have better inputs after thinking about it more.

The "fail2ban-client ... addignoreip ..." command ignores the IP until you restart fail2ban service, but as mentioned in my reply, we add an EE internal cron job (not the one you manage with "crontab" command) to delete the ignored IP periodically, e.g. ignore it for 2 or 6 or 12 or 24 hours.

caretech wrote:

I haven't looked long at the shared github repo yet. Do they have this functionality on their radar?

No. I asked in the issue tracker, but no reply yet in 3 weeks: https://github.com/aejimmi/fail2ban-rs/issues/51

9

Re: Feature request: Fail2Ban Management Issues

Update: Upcoming EE release supports searching on Banned IP Addresses page.
Check attached screenshots.

Post's attachments

Screenshot 2026-10-27 at 11.55.46.png 101.06 kb, file has never been downloaded. 

Screenshot 2026-10-27 at 11.55.57.png 56.51 kb, file has never been downloaded. 

Screenshot 2026-10-27 at 11.56.17.png 61.87 kb, file has never been downloaded. 

Screenshot 2026-10-27 at 11.56.26.png 83.79 kb, file has never been downloaded. 

Screenshot 2026-10-27 at 11.59.29.png 90.17 kb, file has never been downloaded. 

You don't have the permssions to download the attachments of this post.

10

Re: Feature request: Fail2Ban Management Issues

Great work on the search. Thank you! Looking forward to this with next update.

OK, yes -- the ability to ignore an IP address for a specified number of hours would be a very welcome addition.

I still think the loss of logs showing why an address was banned would be sorely missed and sure hope that can be added to fail2ban-rs.

11

Re: Feature request: Fail2Ban Management Issues

The addition of search to the Banned IP Addresses page is a really useful improvement, especially for administrators managing busy mail servers with a large number of users. I also think the temporary IP ignore option would help support teams handle password changes without repeatedly triggering bans. However, retaining the logs that explain why an IP was banned is equally important. Knowing the affected username, service (IMAP or SMTP), and error details makes troubleshooting much easier. Hopefully, this information can also be included if iRedMail moves to fail2ban-rs.