Re: [exim] Line length RFC issues

--On Thursday, January 16, 2020 16:40 -0500 Viktor Dukhovni via
Exim-users <exim-users@???> wrote:

> We'll have to disagree on this, because given non-conformant
> (with RFC5322 Section 2.1.1) input we're free to do whatever
> is reasonably pragmatic and yields a conformant message for
> delivery to the next hop. Perhaps not surprisingly, users
> preferred delivery over bounces.

We may indeed need to disagree, but where the disagreement lies
is elsewhere. If a message is sent to you with over-long lines
(and RFC 5321 says 512 octets for command lines (Section
4.5.3.1.4 and 1000 octets (possibly 1001 for single-octet
periods; Section 4.5.3.1.6), you are free to accept it and
encouraged to do so (Section 4.5.3.1 introductory paragraph).
If you are operating as a relay, you are also free to pass it
along (ibid.). So no problem there (and no problem with
rejecting either (ibid.).

However, 5321 also makes it very clear that SMTP-conformant
servers are not supposed to be tampering with message payloads
(everything that follows the DATA command up to the "." CRLF,
often called "content", but I'm trying to be precise). If you
are violating that rule, you are non-conformant to 5321/SMTP,
regardless of what 5322 may or many not say. Now, I recognize
that common practice today, especially anti-spam provisions,
call for MTAs to inspect payloads (messages headers and message
bodies (also called "content")), and 5321 makes explicit
allowances for that with assorted comments about operational
necessity, but whether that makes such behavior conforming is a
separate question. And, in any event, there is a big difference
between inspecting the message headers and message bodies
(including any MIME body part headers that might be present) and
starting to alter them. Even if one starts making alterations,
in the absence of extensions that authorize something different,
there is a big difference between, e.g., adding a few trace
header fields not explicitly specified in 5321 or 5322 and
altering the message body content itself. It seems to be that
you are doing the latter. It may be reasonable, it may be
justified, but it lies fairly far outside what 5321 anticipated
and authorized. And what 5322 has to say about this is,
relative to the comment I made about 5321 and SMTP, irrelevant.

>...
>> Of course, Postfix is out of conformance with the standard
>> and, maybe more important, breaking any signatures over the
>> message body text, by doing this. Basically you can't win.
>
> If a message does not conform to RFC5322, its signature can't
> be expected to validate.

We may be talking about different types of signatures. In
saying "over the message body text", I was referring to
approaches like PGP and S/MIME, which were explicitly designed
to avoid signing header fields. They were designed that way
precisely to avoid getting entangled in the "what header fields
can on one sign and which ones are a problem" difficulties that
have plagued header field-signing protocols. Unless the
relevant spec to PGP or S/MIME says "message bodies of messages
that do not adhere strictly to RFC 5322 MUST NOT be signed" or
equivalent (I haven't looked closely at recent versions of those
specs, but don't remember any such language). What I vaguely
remember is that the old "ASCII armored" form of signed PGP
messages involved an explicit canonicalization of the message
body to short lines before lines before applying the signature
and the newer, MIME-based, forms for each preserve that
functionality. So, unless my memory is completely wrong, no
issues there and with signing the message body text or needing
to break signatures over that text due to long lines because
there aren't any long lines. Again, if you are talking about
signatures that include message headers, that is an entirely
different can of worms.

best,
john