Bug#797919: Exim configuration breaks with long header lines

[Alex Schumann]

Package: exim4
Version: 4.80-7+deb7u



The SMTP Spec states that:

> 2.1.1. Line Length Limits
>   There are two limits that this standard places on the number of
>   characters in a line. Each line of characters MUST be no more than
>   998 characters, and SHOULD be no more than 78 characters, excluding
>   the CRLF.

However, if exim gets a message in the queue whose line length is longer
than 998 chars it will happily send it to other hosts, thus violating the
protocol.

In addition, MANY  MTAs (including gmail) will respond to an over-length
line by hanging up on the connection (TCP RST) without any error message.
Exim misclassifies this as a host error (as documented in
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-smtp_processing.html#SECToutSMTPerr)


As a result, sending messages that contain long header lines to a local
server for delivery to a remote site  can interrupt delivery of legitimate
messages to that remote site. This has been seen with certain "References"
headers.

As a proposed work-around, a way might be found to limit long header length
in the ACL area, to push the problem up stream toward its source.

I have also reported this upstream to exim, where a more proper solution is
being considered: https://bugs.exim.org/show_bug.cgi?id=1684

Expected behavior: A  message with too-long header line bounces back to
sender with useful message

Observed behavior: All messages to the same MTA as the destination of the
message with malformed header experience delays. Log shows "closed
connection in response to sending data block", and "retry time not reached
for any host"

How to reproduce:

Use netcat or telnet to connect to exim, and send it an email containing a
header such as:

Subject: test
From: your at address
To: your at address
x-test:
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-exim4-maintainers/attachments/20150903/aa7ffeef/attachment.html>