==== 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.