Bug#821830: exim4: Exim rejects mail with overlong lines without any explanation

[Francesco Potortì]

>On 2016-04-19 Francesco Potortì <Potorti at isti.cnr.it> wrote:
>> Package: exim4
>> Version: 4.87-1
>> Severity: normal
>
>> I use Exim to get mail from Fetchmail.  In the last days I have lost
>> some mails and got unsubscribed from some mailing lists.  After much
>> digging, I discovered that an ACL rule has now been added which limits
>> line length to 998.
>
>> There are several problems here.
>
>> 1) mail is rejected without any explanation; as a non-expert of Exim, it
>>    took me much digging to discover that an ACL rule exists which
>>    rejects mail without any explanation added to the logs: as a minimum,
>>    a message line should be added to the acl rule
>
>> 2) this change is very important, as it can cause people to lose mail:
>>    the administrator should be clearly notified of it upon upgrade
>
>> 3) there should be an easy way to disable the new behaviour, in the form
>>    of a configuration macro
>
>> 4) apparently people around there send legitimate email with overlong
>>    lines.  Since Exim does not suffer from it, it should apply Postel's
>>    law «be conservative in what you do, be liberal in what you accept
>>    from others»: mail should definitely not be rejected by default
>>    because it contains overlong lines
>
>Hello,
>
>Accepting overling lines is not a solution. - Exim must not *send* *out*
>overlong lines, and therefore cannot accept these messages in the first
>place. This is a rfc MUST and can cause loss of correct mail.
>Quoting <https://bugs.exim.org/show_bug.cgi?id=1684>:
>| 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.

Answer to this below.

>1) is fixed in exim GIT <https://bugs.exim.org/show_bug.cgi?id=1817> and
>will be in the next upstream version.

That's good, thanks.  I suggest that fixing at least 2) and 3) should be
seriously considered.


That said, my four points are in order of importance, from the most to
the less important: this is a significant change, as it can cause lost
mail.  In fact, I would argue for the importance of this report to be
raised above "normal".

Since it is an important change, it should be properly logged (problem
1), the admin should be notified about this (problem 2) and there should
an easy way to disable it, at the very least as a temporary solution for
people who suddenly find that their mailer changed its behaviour
(problem 3) and started bouncing legitimate email that it was accepting
the day before.

As far as point 4), which is the less important, you say that accepting
overlong lines is not a solution, but there is not a problem in
accepting overlong lines per se, and accepting them would respect the
robustness principle.  Moreover, not accepting overlong lines causes
practical problems, as I myself have observed.

The problem is that Exim should not send out overlong lines.  If it
cannot convert them, that's a pity, but the real problem lies in
sending, not in accepting, and finding solutions to the sending problem
should be based on this fact.  Suboptimal solutions can be accepted, if
necessary, but should be recognised as such.

If conversion is not an option or too difficult when acting as a relay,
then overlong lines could be rejected in this case, and accepted for
local delivery, or at least an option to configure this behaviour should
be available.

-- 
Francesco Potortì (ricercatore)        Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR          Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa         Skype:  wnlabisti
(entrance 20, 1st floor, room C71)     Web:    http://fly.isti.cnr.it