Background¶

The SMTP specification provides the protocol for how email is transferred between MTAs. One specification within this standard is that lines SHOULD exceed 80 characters (78 plus the carriage-return and line-feed) and MUST NOT exceed 1000 characters (998 plus the carriage-return and line-feed).

Problem¶

MailCleaner's MTA, Exim, has historically ignored lines that were too long. However, in version 4.95, enforcement of long lines was enabled without much fanfare leading to some troubles when we initially upgraded from 4.94.2 to 4.96.

The source of the problem is mostly various mail clients from Microsoft, including Outlook, IIS, etc. These clients do not enforce the line limit at all. This resulted in the message being rejected with an MTA error and logging of lines like this:

T=remote_smtp: message has lines too long for transport

It is still somewhat uncommon for regular plain-text email to exceed this length unless it has several dozen recipients or other long headers, so most mail would go through, but a small percentage would not and the response to the sender was an MTA error code rather than a proper SMTP response.

Solutions¶

To resolve this issue, we published an update which allows you to resolve this problem in a couple of ways. Since the issues actually comes from the remote sender, there isn't really a correct option to fix this, so you are able to choose how you prefer to do so:

• Reject these messages. According to the SMTP standard, this is actually the correct solution. The messages should be refused for containing invalid SMTP content. This will enable a proper 5xx rejection code rather than just an MTA error. However, since Microsoft clients represent a rather large proportion of desired mail, it is not practical for most users if/until Microsoft fixes their mail clients. It is unlikely that they will do so and if they do it will be many years for all users to be upgraded to the fixed version.
• Ignore the invalid long lines. This is to return to the pre-4.95 behaviour and simply process all mail and pass it along. This is now the default behaviour. The issue with this solution is that MailCleaner is not responsible for sending invalid SMTP mail as well. If you are relaying to another machine which does enforce the limit, they will correctly reject messages from MailCleaner. This now includes default Exim configurations which are also quite common (eg. unmodified versions of cPanel).
• Fold long lines. This will accept all long lines, but break them across multiple lines of less than 998 characters. This is arguably the best solution because it allows you to accept all mail while also being able to relay valid SMTP which should be accepted by all remote SMTP machines. However, it does introduce possible complications with DKIM signing. Since parts of the message could be modified, this may fail and the messages may be seen as spam. Outgoing messages signed by MailCleaner will get folded before signing, so this is not a problem. We also discourage using DKIM checks on back-end servers since we already add headers to inbound mail, so it could already be broken. If you ignore DKIM/DMARC checks for MailCleaner on back-end machines, this is probably the option to choose.

In all cases, messages with long lines now provide warning messages in the logs.

Configuration¶

From Configuration->SMTP->SMTP Check, there is a new setting: What to do with invalid long lines

This provides the three options discussed above:

• Ignore errors; relay invalid SMTP (default)
• Fold long lines; makes SMTP vaild, but may break SMTP signing
• Reject invalid long lines

Still too long?¶

The first two options above will set a default line length to 5000000 (5 million) characters. This should be far an above any what any legitimate sender should ever use, however, it is still possible that it is too short for some badly configured MTAs. To set an even higher, or lower, value, you can write a number to the file:

/var/mailcleaner/spool/mailcleaner/exim_max_line_length

Then restart all 3 MTA (Exim) services.