When working with Fail2Ban's default configuration, you'll notice it sends notifications for both:

• Banned IP addresses (desired behavior)
• Service restarts/stops (often unwanted noise)

The issue stems from how Fail2Ban handles action definitions in jail configurations. The standard sendmail-whois action triggers on all service events.

Your current jail configuration likely looks like this:

[asterisk-iptables]
enabled  = true
filter   = asterisk
action   = iptables-allports[name=ASTERISK, protocol=all]
           sendmail-whois[name=ASTERISK, dest=blah@foo.com, sender=blah@foo.com]
logpath  = /var/log/asterisk/messages
maxretry = 5
bantime = 259200

Create a custom action that only triggers on bans by modifying your jail.local file:

[asterisk-iptables]
enabled  = true
filter   = asterisk
action   = iptables-allports[name=ASTERISK, protocol=all]
           sendmail-ban-notification[name=ASTERISK, dest=blah@foo.com, sender=blah@foo.com]
logpath  = /var/log/asterisk/messages
maxretry = 5
bantime = 259200

Create a new action file at /etc/fail2ban/action.d/sendmail-ban-notification.conf:

[Definition]
actionstart = 
actionstop = 
actioncheck = 
actionban = /usr/bin/printf %%b "Subject: [Fail2Ban] ASTERISK: banned 
From: blah@foo.com
To: blah@foo.com

The IP  has been banned by Fail2Ban after  attempts against ASTERISK.

Here are more details about :
%(ipinfo)s

Lines containing IP: in :
grep -E '' " | /usr/sbin/sendmail -t
actionunban = 

Key points about this solution:

• Empty actionstart and actionstop prevent service notifications
• Only actionban contains the email sending logic
• Uses standard sendmail command for maximum compatibility
• Includes relevant ban details in the notification

After implementation:

1. Restart Fail2Ban: systemctl restart fail2ban
2. Check logs: tail -f /var/log/fail2ban.log
3. Trigger a ban (for testing purposes)
4. Verify you only receive ban notifications

If you prefer not to create custom actions, you can modify an existing one:

cp /etc/fail2ban/action.d/sendmail-common.conf /etc/fail2ban/action.d/sendmail-common.local
# Then edit the local copy to comment out actionstart/actionstop sections

Remember to reference your modified action in the jail configuration instead of the default one.

Many sysadmins encounter this situation: every time your server reboots or you manually restart fail2ban, you get flooded with email notifications. The alerts you actually want - the real ban notifications - get buried in this noise.

In your jail configuration, the action parameter typically chains multiple actions together. The common pattern looks like:

action = iptables-allports[name=ASTERISK, protocol=all]
         sendmail-whois[name=ASTERISK, dest=blah@foo.com, sender=blah@foo.com]

This executes both actions sequentially: first the iptables block, then the email notification.

Create a custom action that excludes service notifications. In /etc/fail2ban/action.d/, create a new file named custom-asterisk.conf:

[Definition]
actionstart = 
actionstop = 
actioncheck = 
actionban = iptables -I f2b-<name> 1 -s <ip> -j DROP
actionunban = iptables -D f2b-<name> -s <ip> -j DROP

Modify your jail configuration to use this new action:

[asterisk-iptables]
enabled  = true
filter   = asterisk
action   = custom-asterisk[name=ASTERISK]
           sendmail-whois[name=ASTERISK, dest=blah@foo.com, sender=blah@foo.com]
logpath  = /var/log/asterisk/messages
maxretry = 5
bantime = 259200

For a quicker fix without creating custom actions, modify your existing config:

action = iptables-allports[name=ASTERISK, protocol=all]
         sendmail-whois[name=ASTERISK, dest=blah@foo.com, sender=blah@foo.com, 
         actionstart=, actionstop=]

After making changes, test with:

sudo fail2ban-client reload asterisk-iptables
sudo fail2ban-client stop asterisk-iptables
sudo fail2ban-client start asterisk-iptables

You should no longer receive start/stop notifications while still getting ban alerts.