[BR]: Long lines are let through to an email causing it to bounce about fail2ban HOT 4 OPEN

I'm slowly really in mode to delete all mailing actions from stock fail2ban.
Neither it is advisable to use them at all, nor I am interested to see issues like that now and in the future.

from fail2ban.

Before deleting the ability to send email from fail2ban, it would be nice to document an alternative. For example, logging from fail2ban to syslog and configure whatever is providing syslog to generate an email.

But other programs manage to generate a MIME email which also allows the possibility of multiple parts AKA attachments.

from fail2ban.

I'm not against all mailing actions, but against many of them (especially such with whois etc)...
And even after "removal" one could use them further, just we'd not need to support everything around that actions here.
What I meant was rather "stop to support them officially"... There are really too much issues with mailing actions that bother users and our support, and waste my time for nothing.

As for the issue: guess many places would expect something like that:

- _whois = whois <ip> || echo "missing whois program"
+ _whois = whois <ip> | fold -sw 900 || echo "missing whois program"

in

from fail2ban.

I sympathise with email actions causing too much demand for support.

fold -sw 900 isn't sufficient in the general case.

$ printf '123·456\n' | fold -sw 4
123�
�456
$

A non-MIME email has to be 7-bit ASCII. Text using ISO 8859-1, UTF-8, etc. encodings need MIME encoding. Just adding the fields

MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

to the email's header helps but only if the text is valid UTF-8. Using iconv(1) or uconv(8) can help by transliterating or escaping invalid bytes.

But if mail is to be supported then I'd suggest a dependency on a mail(1) which supports: MIME; UTF-8 in fields and the body; possibly attachments. It is its job to do one thing well.

from fail2ban.