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

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

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.

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.

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.

======== Required information ====
- iRedMail version (check /etc/iredmail-release):  iRedMail-1.8.8
- Linux/BSD distribution name and version: Debian 13
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Nginx
- Manage mail accounts with iRedAdmin-Pro? No
- Related log if you're reporting an issue: -
====

Hi, since I successfully migrated a production server based on the iRedMail script from amavisd/spamassassin to rspamd, I'd like to share the steps I took and possibly validate whether I skipped any important configuration stages. The migration was done on Debian 13/MySQL/NGINX (not the PRO version), so the paths I give are the correct ones for my setup.

1. Backup

Just in case we dump the versions and secure a basic backup.

cd /root
mkdir -p /root/migrate-rspamd && cd /root/migrate-rspamd
tar czf etc-$(date +%F).tgz /etc/postfix /etc/amavis /etc/mail/spamassassin /etc/spamassassin /etc/dovecot /etc/clamav /var/lib/dkim /var/vmail/sieve
tar czf cron-$(date +%F).tgz /var/spool/cron/crontabs /etc/default/spamassassin
mysqldump --single-transaction amavisd > amavisd.sql

dpkg -l | grep -Ei 'amavis|spamassassin|clamav|rspamd' > pkgs.txt
chmod 600 *.tgz amavisd.sql

2. Installing rspamd + redis:

I couldn't use links in post so replace:
FIRST = rspamd.com/apt-stable/gpg.key
SECOND = rspamd.com/apt-stable/
with https on the begining

sudo apt install curl gnupg ca-certificates lsb-release
curl -fsSL FIRST | gpg --dearmor -o /usr/share/keyrings/rspamd.gpg
echo "deb [signed-by=/usr/share/keyrings/rspamd.gpg] SECOND trixie main" > /etc/apt/sources.list.d/rspamd.list
sudo apt update
sudo apt install rspamd redis-server

verification

systemctl enable --now redis-server && redis-cli ping

3. Configuration

The DKIM keys can be kept or regenerated. I kept them.

In /etc/rspamd/local.d/redis.conf

servers = "127.0.0.1:6379";

/etc/rspamd/local.d/dkim_signing.conf

enabled = true;
selector = "dkim";
path = "/var/lib/dkim/$domain.pem";

sign_authenticated = true;
sign_local = true;
sign_inbound = false;

allow_username_mismatch = true;
allow_hdrfrom_mismatch = true;
check_pubkey = true;

3.1 ClamAV

check the path:

grep LocalSocket /etc/clamav/clamd.conf

usermod -aG clamav _rspamd
systemctl restart rspamd

In /etc/rspamd/local.d/antivirus.conf

clamav {
  servers = "/var/run/clamav/clamd.ctl";   # whatever grep LocalSocket /etc/clamav/clamd.conf returned
  symbol  = "CLAM_VIRUS";
  type    = "clamav";
  action  = "reject";
  scan_mime_parts = true;
}

Verification

sudo -u _rspamd test -w /var/run/clamav/clamd.ctl && echo "socket OK"

3.2 I carry over the headers that were present in Amavisd.

/etc/rspamd/local.d/milter_headers.conf

use = ["spam-header","x-spam-status","x-spam-level","authentication-results","x-virus","add-headers","x-spamd-result","x_spam_score"];
routines {
  spam-header {
    header = "X-Spam-Flag";
    value  = "YES";
    remove = 0;
  }
  x-virus {
    symbols = ["CLAM_VIRUS"];
  }
  add-headers {
    headers {
      "X-Virus-Scanned" = "rspamd";
    }
    remove = 0;
  }
}

custom {
  x_spam_score = <<EOD
return function(task, common_meta)
  local ms = task:get_metric_score()
  if not ms then return nil end
  return nil,
    { ['X-Spam-Score'] = string.format('%.2f', ms[1]) },
    { ['X-Spam-Score'] = 0 },
    {}
end
EOD;
}

3.3 Thresholds

The thresholds in rspamd are different; below are the ones I added in /etc/rspamd/local.d/actions.conf

reject = 15;            # final rejection
rewrite_subject = 7;    # prefix [SPAM] in the subject
add_header = 6;         # tag (X-Spam-Flag) -> Junk
greylist = 4;           # greylisting

# subject for the 'rewrite subject' action (%s = original subject)
subject = "[SPAM] %s";

3.4 Web UI panel

If anyone wants such a panel, per the rspamd documentation

rspamadm pw

/etc/rspamd/local.d/worker-controller.inc
bind_socket = "127.0.0.1:11334";
password = "$2$...";

rspamadm configtest && systemctl restart rspamd

3.5 Finish

We apply the configuration:

rspamadm configtest
systemctl enable --now rspamd
systemctl restart rspamd
systemctl status rspamd --no-pager
ss -tlnp | grep -E '11332|11333|11334'

4. Postfix

In /etc/postfix/main.cf you should comment out

content_filter = smtp-amavis:[127.0.0.1]:10024

as well as

smtp-amavis_destination_recipient_limit = 1

In /etc/postfix/master.cf

You should comment out all occurrences of

-o content_filter=smtp-amavis...

We run

postconf -X pickup/unix/content_filter

4.1 DKIM keys (if you keep the already generated ones)

chown -R _rspamd:_rspamd /var/lib/dkim
chmod 0400 /var/lib/dkim/*.pem
find /var/lib/dkim -type d -exec chmod 0700 {} \;
sudo -u _rspamd head -c1 /var/lib/dkim/dts-frankfurt.de.pem >/dev/null && echo "keys OK"

4.2 Reload postfix:

postconf -e 'smtpd_milters = inet:127.0.0.1:11332'
postconf -e 'non_smtpd_milters = inet:127.0.0.1:11332'
postconf -e 'milter_protocol = 6'
postconf -e 'milter_default_action = accept'
postfix check && systemctl reload postfix

5. Disabling amavisd and spamassassin

systemctl disable --now amavisd spamassassin

Comment out the crons

1   2   *   *   *   python3 /opt/www/iredadmin/tools/cleanup_amavisd_db.py >/dev/null

Verification:

You can verify correctness in the logs:

tail -f /var/log/mail.log

Check the signing with the tool:

rspamc -u postmaster@your_domain.com <<'EOF' | grep DKIM_SIGNED  //change this
From: postmaster@your_domain.com  //change this
To: someone@someone.com  //change this
Subject: DKIM test

Test message
EOF

Spam test:

printf 'Subject: test gtube\n\nXJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X\n' \
  | sendmail postmaster@your-domain.com  //change this

======

I hope I didn't miss anything. iRedAPD reads the tables from the database so I left it as is; I assume the lists will still work. Unfortunately Bayes has to be trained from scratch. You can do it on the emails you have.

If anyone had the Bayes auto-learning scripts from the iRedMail documentation configured, they need to be changed:

# before: output="$(${SA_LEARN} --spam ${SPOOL_LEARN_SPAM_DIR})"
output="$(/usr/bin/rspamc learn_spam ${SPOOL_LEARN_SPAM_DIR})"
...
# before: output="$(${SA_LEARN} --ham ${SPOOL_LEARN_HAM_DIR})"
output="$(/usr/bin/rspamc learn_ham ${SPOOL_LEARN_HAM_DIR})"

If any messages get stuck in the Postfix queue, they need to be requeued:

postsuper -r ALL
postqueue -f
postqueue -p

There are differences in behavior:
Amavis did DISCARD, rspamd does REJECT for messages considered infected.

iRedAPD — wblist works but the per-user thresholds from amavis.policy are no longer used.

By default rspamd does not use the system resolver. It has to be changed in the settings.

If you have experience with this kind of migration or notice anything I might have missed, please let me know. I assume everyone will need to adjust the Rspamd configuration to their own needs starting from the defaults. I hope I didn't miss anything

Hi, i want to migrate accounts from one domain to another (inside same server):
- I will use imapsync to synchronize emails to new domain, and that is working.
- Also, update address with old domain to new one inside roundcubemail database to migrate Roundcube settings

I also want to add alias for emails that come to old domain to be forwarded to new one. But, i want to disable (delete) old accounts - to remove duplicate mailboxes.

How to do that?

Thanks in advance,

BACKGROUND
----------

Recent iRedMail releases recommend upgrading Netdata to v2.x. I upgraded
from Netdata v1.44.1 to v2.12.0 on a small iRedMail server (2 GB RAM, no
SOGo, ClamAV disabled to save memory). After the upgrade, Netdata used a
lot more memory: about 380 MB across all of its processes. Its main
process alone had used about 116 MB under v1.

Most of the increase came from two plugins that Netdata v2 starts by
default:

  netflow-plugin  (about 143 MB)
      Collects NetFlow / IPFIX / sFlow flow records exported by routers
      and switches.

  otel-plugin     (about 34 MB)
      Receives OpenTelemetry (OTLP) metrics and logs pushed by other
      applications.

A typical iRedMail server neither receives flow exports from network gear
nor has applications pushing OpenTelemetry data to Netdata. On a server
like that, both plugins sit idle while holding memory.

With both disabled, Netdata's total memory use dropped from about 380 MB
to about 211 MB. All the normal charts (system, Nginx, MySQL/MariaDB,
PHP-FPM, and so on) kept working.

Your numbers will differ. Check your own server with this command
(RSS is in KB):

    ps -eo rss,comm --sort=-rss | grep -E 'netflow|otel|netdata|plugin'

WHO SHOULD NOT DO THIS
----------------------

Leave these plugins enabled if any of the following applies:

  * You point routers, switches or firewalls at this server to export
    NetFlow / IPFIX / sFlow data and view it in Netdata. That is exactly
    what netflow-plugin does.

  * You have applications or collectors sending OpenTelemetry (OTLP)
    metrics or logs to this Netdata agent. That is what otel-plugin does.

  * You are not sure whether anything uses them and have plenty of RAM.
    In that case the saving may not be worth the risk.

If you only use Netdata's built-in dashboard to watch the mail server
itself, you most likely use neither.

HOW TO DISABLE THEM
-------------------

These steps were done on Debian 12 with Netdata installed the way
iRedMail installs it: the static build under /opt/netdata. They may
help on other distributions, but the location of netdata.conf can
differ. With a native distro package, for example, it is usually
/etc/netdata/netdata.conf. Adjust paths for your system.

Step 1. Check that the two plugin switches exist in your version. The
        running configuration lists every option, with defaults
        commented out:

    curl -s http://127.0.0.1:19999/netdata.conf | sed -n '/^\[plugins\]/,/^\[/p' | grep -E 'netflow|otel'

        You should see "# netflow = yes" and "# otel = yes". Adjust the
        port if your Netdata does not listen on 19999.

Step 2. Back up the config file:

    cp -a /opt/netdata/etc/netdata/netdata.conf /opt/netdata/etc/netdata/netdata.conf.bak

Step 3. Edit /opt/netdata/etc/netdata/netdata.conf. You can also use
        Netdata's helper:

    /opt/netdata/etc/netdata/edit-config netdata.conf

        If the file already has a [plugins] section, add the two lines
        below to it. Otherwise, add this whole block at the end of the
        file:

    [plugins]
        netflow = no
        otel = no

Step 4. Restart Netdata:

    systemctl restart netdata

Step 5. Verify. After about 30 seconds, run:

    systemctl is-active netdata
    ps -eo rss,comm --sort=-rss | grep -E 'netflow|otel'
    curl -s http://127.0.0.1:19999/netdata.conf | grep -E '^\s*(netflow|otel) ='

        - The first command should print "active".
        - The second command should print nothing.
        - The third command should show "netflow = no" and "otel = no"
          without a leading "#".

        Then open your Netdata dashboard and confirm your usual charts are
        still there.

NOTES
-----

  * The setting survives Netdata upgrades. Running a newer static
    installer (netdata-x86_64-vX.Y.Z.gz.run) left my existing
    netdata.conf untouched.

  * To undo, remove the two lines (or set them to "yes") and restart
    Netdata.

  * The same [plugins] section can switch off other plugins you do not
    need, such as "ebpf" or "network-viewer". Check what each one does
    before disabling it.

  * Measure on your own server before and after. The figures above come
    from one small server and are only an indication.

Now I will prepare a "short" instruction for it ..