Skip to content

Fail2ban SMTP-Auth Jail, Notify-Only: Getting Emailed on Every Failed SMTP AUTH Without Actually Banning

🛑 Problem

You want to know the moment someone fails SMTP AUTH against your mail server — it's a strong signal of credential stuffing or a leaked password — but you don't want fail2ban to actually ban the source IP. A standard fail2ban jail either bans or does nothing; there's no built-in "just tell me" mode.

This matters specifically after a credential exposure: once a mailbox password has been rotated, you still want visibility into anyone still trying the old one, without the noise (or the risk of banning a legitimate client that's slow to pick up new credentials) that a real ban would cause.

🩹 Setup — Notify Without Banning

The trick is a fail2ban jail with a custom action that only sends mail, paired with a bantime of effectively zero so nothing actually gets blocked.

Action (/etc/fail2ban/action.d/notify-email-marcus.conf):

[Definition]
actionban = printf "Subject: [ACTION REQUIRED] SMTP Auth Failure\nFrom: fail2ban@<host>\nTo: <alert-address>\n\nIP <ip> failed SMTP AUTH on <host>.\n" | /usr/sbin/sendmail -t

Jail (/etc/fail2ban/jail.d/postfix-sasl-<name>.conf):

[postfix-sasl-<name>]
enabled  = true
filter   = postfix-sasl
logpath  = /var/log/maillog
action   = notify-email-marcus
maxretry = 2
findtime = 600
bantime  = 1

The load-bearing setting is bantime = 1 — one second. Fail2ban still runs its normal ban lifecycle (the actionban action fires, the "ban" is recorded), but the ban itself expires almost immediately, so there is no real-world blocking effect. maxretry/findtime control how sensitive the trigger is (here: 2 failures within 10 minutes) — tune those independently of the notify behavior.

Test without waiting for a real attacker:

fail2ban-client set <jailname> banip 127.0.0.1

This fires actionban immediately against a loopback address, which triggers the notify action without needing a real failed-auth event. Confirm the email actually lands before relying on this in production — the action config above depends on a working local sendmail/MTA path, which is a separate thing to verify from the jail configuration itself.

🧭 Why not just use fail2ban's built-in mail actions?

Fail2ban ships action_mw/action_mwl (mail-whois / mail-whois-with-lines) that also ban and notify — the difference here is deliberately decoupling notification from the ban decision entirely, rather than tuning ban duration down. For a jail whose entire purpose is visibility (not enforcement), a dedicated no-op action makes the intent explicit in the config rather than implicit in a short bantime value someone might "helpfully" lengthen later without realizing they've turned on real blocking.

  • 30-Areas/MajorInfrastructure/Servers/majormail.md § Incident Log — the original deployment of this pattern, following a mailbox credential exposure
  • Fail2Ban Digest Mode — Fleet-Wide Quiet Alerts — a related but distinct pattern for reducing fail2ban notification noise fleet-wide