-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[BR]: Long lines are let through to an email causing it to bounce #3665
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm slowly really in mode to delete all mailing actions from stock 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. |
I'm not against all mailing actions, but against many of them (especially such with 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
|
I sympathise with email actions causing too much demand for support.
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
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. |
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
because whois(1) for that IP address gives long lines.
But I don't think the issue is limited to whois's output.
The text was updated successfully, but these errors were encountered: