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.
