[BR]: Long lines are let through to an email causing it to bounce

[RalphCorderoy]

The issue:

Mail transport agents can bounce an email if it violates RFCs. One limitation is line length. This is why MIME includes content encodings like quoted-printable so a long original line can be split for email and reassembled by the mail user agent for display.

fail2ban takes the output of a command and puts it in an email. The email is not MIME encoded. No checks on the length of a line are made. Depending on the MTA the email encounters on its journey, it may bounce. The Exim MTA, the default on Debian, is an MTA which bounces emails with long lines. This means the whole message fail2ban was trying to deliver doesn't reach the recipient, not the rest of it once the long lines are dropped.

message has lines too long for transport is an example bounce diagnostic.

An example triggering case is

The IP 208.65.84.108 has just been banned by Fail2Ban after
5 attempts against sshd.

because whois(1) for that IP address gives long lines.

$ whois 208.65.84.108 | awk '{print length}' | sort -nr | sed q
1192

But I don't think the issue is limited to whois's output.

[sebres]

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.

[RalphCorderoy]

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.

[sebres]

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

fail2ban/config/action.d/mail-whois-common.conf

Line 14 in 9bedc3c

_whois = whois <ip> || echo "missing whois program"

[RalphCorderoy]

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.