[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1684

--- Comment #18 from Jeremy Harris  ---
Tracking as bug 2979.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1684

Jeremy Harris  changed:

   What|Removed |Added

   See Also||https://bugs.exim.org/show_
   ||bug.cgi?id=2979

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1684

--- Comment #17 from Patrick Cernko  ---
Sorry, I only checked the Changelogs and missed that there is a separate
NewStuff file.

The SMTP error was a reject after DATA due to spamassassin results. The error
message included a longer report from spamassassin. In all my tries to
reproduce this error later the message was wrapped by the complaining server
and thus did not hit the line limit.

I extracted (and anonymized) the relevant log lines from the incident:

2023-02-16 10:36:25 1pSagd-006b9M-2u <= <> H=SENDER I=INTERFACE P=esmtp S=1747
for SRS_ENCODED_RECIPIENT
2023-02-16 10:42:05 1pSagd-006b9M-2u ** SRS_DECODED_RECIPIENT
 P=<> R=dnslookup T=remote_forwarded_smtp H=SENDER
I=INTERFACE X=CERTIFICATE_INFO: SMTP error from remote mail server after
pipelined end of data: 550-Rejected spam (score 5.7): Content analysis
details:\n550-* -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at\n550-* 
https://www.dnswl.org/, no trust\n550-*  [ANON_IP listed in
list.dnswl.org]\n550-*  0.8 BAYES_50 BODY: Bayes spam probability is 40 to
60%\n550-*  [score: 0.5000]\n550-*  0.1 DKIM_SIGNED Message has a DKIM or
DK signature, not necessarily\n550-*   valid\n550-* -0.1 DKIM_VALID Message
has at least one valid DKIM or DK signature\n550-*  0.5 MISSING_MID Missing
Message-Id: header\n550-*  1.4 MISSING_DATE Missing Date: header\n550-*  3.0
MPI_OWN_HEADDOM_WO_DKIM mail with one of our domains in From\n550-*  header
but no DKIM signature
found\n550\n550
* 05.7 Total Score DT=2s
2023-02-16 10:42:05 1pSagd-006b9M-2u Frozen (delivery error message)
2023-02-16 10:46:45 1pSagd-006b9M-2u removed by root
2023-02-16 10:46:45 1pSagd-006b9M-2u Completed

2023-02-16 10:42:05 1pSamD-006e0P-1E <= <> R=1pSagd-006b9M-2u U=Debian-exim
P=local S=1533 for postmaster
2023-02-16 10:42:05 1pSamD-006e0P-1E ** POSTMASTER_ALIAS_ADDRESS
 P=<> R=local_user T=dovecot: message has lines too long
for transport DT=0s
2023-02-16 10:42:05 1pSamD-006e0P-1E Frozen (delivery error message)
2023-02-16 10:47:02 1pSamD-006e0P-1E Message is frozen
2023-02-16 10:48:55 1pSamD-006e0P-1E removed by root
2023-02-16 10:48:55 1pSamD-006e0P-1E Completed

I have bounce_return_body enabled but I'm pretty sure, the body of the message
did not contain any longer lines as it was a test mail generated by me directly
via SMTP with telnet.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1684

--- Comment #16 from Jeremy Harris  ---
It would help a lot if you could say what sort of SMTP error message.

The message_linelength_limit introduction was noted, with it's default
value, in the NewStuff file file for 4.95

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1684

Patrick Cernko  changed:

   What|Removed |Added

 CC||pcer...@mpi-klsb.mpg.de

--- Comment #15 from Patrick Cernko  ---
I recently stumbled upon this change. I had a scenario, where my exim generated
a bounce based on a very long SMTP error message and failed to deliver it via
the local LMTP transport because the message *body* (generated by exim itself)
contained a line longer than message_linelength_limit. The result was a frozen
message. This caused a freeze_tell event but the resulting generated message
also had the message_linelength_limit issue (AFAIK). So in the end I had two
frozen messages in the queue but no message to postmaster about that. I only
stumbled upon the frozen messages by accident.
Unfortunately I removed the frozen message from the queue and was not able to
reproduce the behavior later to provide more a more detailed description.

I would like to request two things:
1. Please check all code sections generating (error) messages to not generate
lines longer than message_linelength_limit.
2. I cannot find any documentation about the changed default for
message_linelength_limit in the docs. Only thing I found was the documentation
about the new option with a different default as before. The sections seems to
be introduced in the 4.95 release but the release notes do not mention anything
about the new setting. As the setting definitely changes the behavior of
existing installations, it really should be worth mentioning.

Besides my requests, I really appreciate that new feature!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1684

Arkadiusz Miskiewicz  changed:

   What|Removed |Added

   See Also||https://bugs.exim.org/show_
   ||bug.cgi?id=2827
 CC||ar...@maven.pl

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1684

fel...@felipegasper.com changed:

   What|Removed |Added

 CC||fel...@felipegasper.com

--- Comment #14 from fel...@felipegasper.com ---
(copied from exim-users)

RFC 5322 doesn’t stipulate server behaviour upon receipt of a message that
violates this limitation.

On the contrary, the same section (2.1.1) that gives the 998-character limit
adds, in the next paragraph:


Receiving implementations would do well to handle an arbitrarily large number
of characters in a line for robustness sake.


While Exim’s new default behaviour is reasonable, it doesn’t seem to follow
from the relevant standard. Outlook is in violation, to be sure, but servers
that accept arbitrarily long lines don’t seem to be (by that virtue alone,
anyhow).

-- 
You are receiving this mail because:
You are on the CC list for the bug.-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1684

Jeremy Harris  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Jeremy Harris  ---
Nobody commented

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=1684

--- Comment #12 from Git Commit  ---
Git commit:
https://git.exim.org/exim.git/commitdiff/0de9945258c2e7910c35f715caf07c5e9270aa1b

commit 0de9945258c2e7910c35f715caf07c5e9270aa1b
Author: Jeremy Harris 
AuthorDate: Tue May 12 23:10:08 2020 +0100
Commit: Jeremy Harris 
CommitDate: Wed May 13 12:11:02 2020 +0100

smtp transport: message_linelength_limit option.  bug 1684

 doc/doc-docbook/spec.xfpt| 14 ++
 doc/doc-txt/NewStuff |  3 +++
 doc/doc-txt/OptionLists.txt  |  1 +
 src/src/configure.default|  5 -
 src/src/deliver.c| 24 ++-
 src/src/smtp_in.c|  8 
 src/src/spool_out.c  |  6 +++---
 src/src/transports/smtp.c| 19 +++
 src/src/transports/smtp.h|  1 +
 test/confs/0588  | 42 +
 test/log/0588| 15 +++
 test/scripts/-Basic/0588 | 45 
 test/stdout/0572 |  1 +
 test/stdout/0588 | 40 +++
 14 files changed, 207 insertions(+), 17 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

Jeremy Harris  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #11 from Jeremy Harris  ---
Hmm.  Currently no bounce messages include that level of detail unless you
build with EXPERIMENTAL_DSN_INFO.  If we created a new smtp transport option
then its refusals could at least be put in the obvious data struct
(addr->message) already used for that detail; it would be logged.

Re-opening for that as an RFE.  Default should be 998 per standard, and apply
to number of bytes (not, eg, UTF8 characters) - which I don't think the
standards
cover.  Proposed name "message_linelength_limit".

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

Andreas Metzler  changed:

   What|Removed |Added

 CC||eximus...@bebt.de

--- Comment #10 from Andreas Metzler  ---
(In reply to Jeremy Harris from comment #6)
> $max_received_linelength is already populated with the relevant value.
> This can be checked in the smtp_data acl and the smtp transports:
[...] 
> remote_smtp:
>  driver = smtp
>  message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}
> 
> Doing the latter results in a bounce for a long-line message accepted via
> non-smtp and routed to an smtp transport.  You could reject in the non-smtp
> acl instead, but if support for long-lines in non-smtp traffic is desired
> this would be complex to properly filter.
> 
> Possibly we should add the above to the example configuration file.

The problem with this approach is that bounce message generated when rejecting
SMTP transmission of a pipe injected message ("/usr/sbin/sendmail
someb...@example.com < longlines.txt") is lacking any information why the
message bounced.

[-- Typ: text/plain, Kodierung: 7bit, Größe: 0,2K --]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  re...@example.com

[-- Anhang #2 --]
[-- Typ: message/delivery-status, Kodierung: 7bit, Größe: 0,1K --]

Reporting-MTA: dns; server.example.com

Action: failed
Final-Recipient: rfc822;re...@example.com
Status: 5.0.0

[-- Anhang #3 --]
[-- Typ: text/rfc822-headers, Kodierung: 7bit, Größe: 0,4K --]

Return-path: 
Received: from ametzler by server.example.com with local (Exim 4.88)
(envelope-from )
id 1cNNWo-0005bq-H4
for re...@example.com; Sat, 31 Dec 2016 18:33:10 +0100
Message-Id: 
From: Andreas Metzler 
Date: Sat, 31 Dec 2016 18:33:10 +0100
X-Exim-DSN-Information: Due to administrative limits only headers are returned

-- 
You are receiving this mail because:
You are on the CC list for the bug.-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

Jeremy Harris  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Jeremy Harris  ---
Nobody commented

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

Git Commit  changed:

   What|Removed |Added

 CC||g...@exim.org

--- Comment #8 from Git Commit  ---
Git commit:
http://git.exim.org/exim.git/commitdiff/8c952127a4d1827ea14da68d94eb5ea8d6174a35

commit 8c952127a4d1827ea14da68d94eb5ea8d6174a35
Author: Jeremy Harris 
AuthorDate: Tue Oct 13 17:04:03 2015 +0100
Commit: Jeremy Harris 
CommitDate: Tue Oct 13 17:08:28 2015 +0100

Check maximum (folded) line length in default spec file data ACL and smtp
transport.  Bug 1684
---
 src/src/configure.default | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/src/configure.default b/src/src/configure.default
index 3223bff..ec60700 100644
--- a/src/src/configure.default
+++ b/src/src/configure.default
@@ -492,6 +492,11 @@ acl_check_rcpt:

 acl_check_data:

+  # Deny if the message contains an overlong line.  Per the standards
+  # we should never receive one such via SMTP.
+  #
+  denycondition  = ${if > {$max_received_linelength}{998}}
+
   # Deny if the message contains a virus. Before enabling this check, you
   # must install a virus scanner and set the av_scanner option above.
   #
@@ -684,9 +689,13 @@ begin transports


 # This transport is used for delivering messages over SMTP connections.
+# Refuse to send any messsage with over-long lines, which could have
+# been receved other than via SMTP. The use of message_size_limit to
+# enforce this is a red herring.

 remote_smtp:
   driver = smtp
+  message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}


 # This transport is used for local delivery to user mailboxes in traditional

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

Jeremy Harris  changed:

   What|Removed |Added

   See Also||https://bugs.exim.org/show_
   ||bug.cgi?id=331

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

Jeremy Harris  changed:

   What|Removed |Added

   Assignee|h...@schlittermann.de |jgh146...@wizmail.org
 Status|NEW |ASSIGNED

--- Comment #7 from Jeremy Harris  ---
I've committed the above as being the minimal possible change.
If people feel the check should be hard-coded, it wouldn't be hard.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[Viktor Dukhovni]

On Sat, Oct 03, 2015 at 07:34:28PM +, ad...@bugs.exim.org wrote:

> remote_smtp:
>  driver = smtp
>  message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}

Is "message_size_limit" really a line-length limit?  If so, the
name seems rather misleading.  More likely, I would guess, that's
a typo and the intended variable has some other name...

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

--- Comment #6 from Jeremy Harris  ---
$max_received_linelength is already populated with the relevant value.
This can be checked in the smtp_data acl and the smtp transports:

acl_check_data:
 denycondition  = ${if > {$max_received_linelength}{998}}
...

remote_smtp:
 driver = smtp
 message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}

Doing the latter results in a bounce for a long-line message accepted via
non-smtp and routed to an smtp transport.  You could reject in the non-smtp
acl instead, but if support for long-lines in non-smtp traffic is desired
this would be complex to properly filter.

Possibly we should add the above to the example configuration file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[Jeremy Harris]

On 03/10/15 20:42, Viktor Dukhovni wrote:
> On Sat, Oct 03, 2015 at 07:34:28PM +, ad...@bugs.exim.org wrote:
> 
>> remote_smtp:
>>  driver = smtp
>>  message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}
> 
> Is "message_size_limit" really a line-length limit?

No, and reading the manual makes it clear what it does.

It is not a typo.
In this usage it is merely a means for refusing to deliver the message.
-- 
Jeremy


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[Viktor Dukhovni]

On Wed, Sep 30, 2015 at 10:53:03PM +0200, Heiko Schlittermann wrote:

> Viktor Dukhovni  (Mi 30 Sep 2015 22:25:14 CEST):
> > On Wed, Sep 30, 2015 at 07:39:11PM +, ad...@bugs.exim.org wrote:
> > 
> > > We should also consider body lines; the spec (rfc 5322 section 2.3) says 
> > > the
> > > same limit applies.  Probably the same variable should control behaviour 
> > > and
> > > the name should reflect this.
> > 
> > Yes, the Postfix SMTP client (outgoing SMTP) folds all overly long
> > message lines (header and body) by inserting "".  Some
> 
> Folds body lines? I'm not sure, you are talking about a somehow MIME
> encoded body, or about any body (including a plain text (MIME headers
> absent) body)?

All lines over 998 bytes, whether header or body.  The SMTP protocol
requires all lines to be under 1000 bytes include the CRLF, so all
lines are folded by default.

> Or did I get somethow wrong?
> Because I wouldn't expect to get my my plain text non-mime body lines
> folded in any way. But I could accept a server rejecting my message
> because of overlong physical body lines.

In most cases, better folded, than dropped.  The original message
should have used QuotedPrintable or Base64 to avoid the problem.
Messages that emit raw output with lines longer than 1000 bytes
are handled on a best-effort basis.

Discovering that the message contains such lines and then automatically,
enabling a MIME downgrade to QuotedPrintable or Base64 is possible,
but complicated by the possibility that the message might in fact
be QP encoded, and still have overly long lines, ...

Putting in that much effort for poorly constructed messages was
not deemed worth the effort.

The Postfix approach is to prioritize delivery of mail over being
pedantic about RFC requirements.  So we fold instead of rejecting.
This has the advantage that mail delivered locally can be accepted
and delivered unmangled regardless of line length, only mail relayed
out via SMTP is subject to folding.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

Jeremy Harris  changed:

   What|Removed |Added

 CC||jgh146...@wizmail.org
   Priority|medium  |high
   Severity|bug |wishlist

--- Comment #5 from Jeremy Harris  ---
Changing to a wishlist entry, as this would be a new feature: enforcing a
limitation previously ignored.

The simplest implementation would seem to be a new option to limit the
acceptable length of a header physical line (as opposed to the overall length
of a header which has been folded).  The default value would be 998.  We get
to choose what to do with UTF8 characters; my initial take would be to define
this option to be specifying the limit in bytes.

More complex would be optional header-line re-folding.  I do not think we
want to do this, at least at first.

We should also consider body lines; the spec (rfc 5322 section 2.3) says the
same limit applies.  Probably the same variable should control behaviour and
the name should reflect this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[Viktor Dukhovni]

On Wed, Sep 30, 2015 at 07:39:11PM +, ad...@bugs.exim.org wrote:

> We should also consider body lines; the spec (rfc 5322 section 2.3) says the
> same limit applies.  Probably the same variable should control behaviour and
> the name should reflect this.

Yes, the Postfix SMTP client (outgoing SMTP) folds all overly long
message lines (header and body) by inserting "".  Some
care *may* then be necessary to get "SMTP transparency" right by
not inserting "." at the first position in output line fragments
that start with "." when the line already starts with the inserted
.

One could arguably use MIME parser state to distinguish between
primary/MIME/nested headers vs. MIME bodies and fold MIME bodies
with "" rather than "", but is a lot more
work (Postfix only engages the MIME parser on SMTP output when
doing 8bit->7bit downgrade or output header-checks.

Hope that's useful background.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[Viktor Dukhovni]

On Thu, Oct 01, 2015 at 12:00:55AM +0200, Heiko Schlittermann wrote:

> > > Or did I get somethow wrong?
> > > Because I wouldn't expect to get my my plain text non-mime body lines
> > > folded in any way. But I could accept a server rejecting my message
> > > because of overlong physical body lines.
> > 
> > In most cases, better folded, than dropped.  
>
> I didn't say "drop", but "reject".

Sorry, you're right, I meant "not delivered", i.e. "rejected".

> > The original message
> > should have used QuotedPrintable or Base64 to avoid the problem.
> > Messages that emit raw output with lines longer than 1000 bytes
> > are handled on a best-effort basis.
> 
> What is about the DKIM signatures in such cases? Do the signatures
> tolerate such changes?

Message like that are typically not DKIM signed, and even if DKIM
signature checks fail, mail is often delivered anyway.  Rejecting
or routing to Junk folders on DKIM signature failure happens at
some domains, but I don't consider that a wise choice.

> > Discovering that the message contains such lines and then automatically,
> > enabling a MIME downgrade to QuotedPrintable or Base64 is possible,
> > but complicated by the possibility that the message might in fact
> > be QP encoded, and still have overly long lines, ...
> 
> Again, what about DKIM here? IMHO a MTA never ever is allowed to touch
> the body. If the MTA doesn't want to transport message (because of
> violations of the standards), it should reject the message reception.

Garbage-in garbage-out.  The original message is invalid SMTP, so
all bets are off with DKIM.  However, Postfix will deliver *locally*
without any folding, and can be configured to use higher line length
limits for relaying inbound (if the internal relays tolerate very
long lines).  Postfix can accept messages with artbitrarily long
lines.

> > The Postfix approach is to prioritize delivery of mail over being
> > pedantic about RFC requirements.  
> > This has the advantage that mail delivered locally can be accepted
> > and delivered unmangled regardless of line length, only mail relayed
> > out via SMTP is subject to folding.
> 
> I do not agree. Much trouble we have here is explaining people, that
> there are some standards and that their mails have to follow that
> standards.  (Starting with mistyped addresses that people want to have
> delivered anyway, continued with broken headers, long message body
> lines, …) Most other parts of our life do not tolerate violating some
> rules. Why mail should?

  http://tools.ietf.org/html/rfc5322#section-2.1.1

The 998 character limit is due to limitations in many implementations
that send, receive, or store IMF messages which simply cannot handle
more than 998 characters on a line.  Receiving implementations would
do well to handle an arbitrarily large number of characters in a line
for robustness sake.  However, there are so many implementations that
(in compliance with the transport requirements of [RFC5321]) do not
accept messages containing more than 1000 characters including the CR
and LF per line, it is important for implementations not to create
such messages.

Note that the limit is motivated by the constraints of RFC5321
(SMTP), and is not a fundamental prior feature of the message format
itself.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[Heiko Schlittermann]

Viktor Dukhovni  (Mi 30 Sep 2015 23:10:08 CEST):
...
> All lines over 998 bytes, whether header or body.  The SMTP protocol
> requires all lines to be under 1000 bytes include the CRLF, so all
> lines are folded by default.
> 
> > Or did I get somethow wrong?
> > Because I wouldn't expect to get my my plain text non-mime body lines
> > folded in any way. But I could accept a server rejecting my message
> > because of overlong physical body lines.
> 
> In most cases, better folded, than dropped.  

I didn't say "drop", but "reject".

> The original message
> should have used QuotedPrintable or Base64 to avoid the problem.
> Messages that emit raw output with lines longer than 1000 bytes
> are handled on a best-effort basis.

What is about the DKIM signatures in such cases? Do the signatures
tolerate such changes?

> Discovering that the message contains such lines and then automatically,
> enabling a MIME downgrade to QuotedPrintable or Base64 is possible,
> but complicated by the possibility that the message might in fact
> be QP encoded, and still have overly long lines, ...

Again, what about DKIM here? IMHO a MTA never ever is allowed to touch
the body. If the MTA doesn't want to transport message (because of
violations of the standards), it should reject the message reception.

> The Postfix approach is to prioritize delivery of mail over being
> pedantic about RFC requirements.  
> This has the advantage that mail delivered locally can be accepted
> and delivered unmangled regardless of line length, only mail relayed
> out via SMTP is subject to folding.

I do not agree. Much trouble we have here is explaining people, that
there are some standards and that their mails have to follow that
standards.  (Starting with mistyped addresses that people want to have
delivered anyway, continued with broken headers, long message body
lines, …) Most other parts of our life do not tolerate violating some
rules. Why mail should?

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
-- 
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01  -


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

Rubin  changed:

   What|Removed |Added

   See Also||https://bugs.exim.org/show_
   ||bug.cgi?id=1687

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

--- Comment #4 from Heiko Schlittermann  ---
According to the spec, header_line_maxsize imposes a limit on the total length
of all joined lines of a specific header - so it's limit on the logical line
length.

And I'm sure you'll find legitimate logical header lines with >998 characters
in total, folded into individual physical lines.

Auto-folding may be an option (as Viktor writes) and maybe additionally a
configurable limit on the length if an individual physical line.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

--- Comment #3 from Rubin  ---
Note that adding: 

header_line_maxsize = 998

to the main config section, will stop exim from accepting messages that cause
this.

I propose the default value of that variable should be changed to that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

Rubin  changed:

   What|Removed |Added

 CC||ru...@afternet.org

--- Comment #1 from Rubin  ---
Examples in the wild:


2015-09-01 15:52:37 1ZWWXK-0005PZ-Oe Remote host
alt2.gmail-smtp-in.l.google.com [173.194.219.26] closed connection in response
to sending data block


Later one can get: 'retry time not reached for any host' when sending unrelated
messages to the same destination mta.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 1684] Malformed headers which exceed length spec willingly passed to remote servers

[admin]

https://bugs.exim.org/show_bug.cgi?id=1684

--- Comment #2 from Heiko Schlittermann  ---
Exim should not accept messages with such oversized lines. This can be
accomplished by an ACL entry in the DATA ACL. 

Once the message is accepted, Exim should do it's best to transmit it.
I'm not sure if reformatting the oversized headers is a good solution. Exim
should not touch any content of the message ever.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##