On Thu, Jan 16, 2020 at 10:56:08PM -0500, John C Klensin wrote:
> 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).
True when the message conforms to 5322. Otherwise, all bets are off.
Note also that relays sometimes do 8bit-to-7bit conversion when relaying
8BITMIME to 7bit nexthops, which you might also object to, but that's
the real world.
A user-agent that aims for content integrity via SMTP will perform
Quoted-Printable or Base64 transfer-encoding of non-ASCII message body
parts, and/or lines with essential trailing whitespace, and ensure that
all lines in the resulting payload are ~72 bytes (rather than in excess
of 998), and one might then reasonably expect the content to remain
unmolested in transit.
> are violating that rule, you are non-conformant to 5321/SMTP,
> regardless of what 5322 may or many not say.
Once the sender provides content that violates 5322, there's no
expectation that 5321 content-related niceties are honoured. Just as
with non-EAI messages, non-ASCII headers, or non-CRLF line termination.
> 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.
When the message contains booby-trapped or malformed MIME, malware
attachments, or is just broken it often will, and in practice often
*should* be modified in transit. If it was substantially not conformant
with 5322 or MIME, then the original sin is with the sender, not the
gateway that takes defensive (or just cosmetic repair) actions.
> 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.
One may take that perspective from the vantage point of just 5321, but
from a whole-system perspective, when an incoming message violates the
broader requirements of 5321 + 5322 + MIME + ... output modifications to
facilitate downstream delivery come into play.
> > 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.
No we're not.
> 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.
S/MIME signed messages need to be valid MIME, which is a subset of valid
RFC5322, and has specific transfer-encoding mechanisms to allow reliable
transmission of long-lines, binary content, ...
User-agents that create S/MIME or PGP messages that are not valid 5322
content, will unsurprisingly run into downstream message integrity
issues.
> 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).
One can sign whatever one likes, but the result needs to be valid 5322
for the signature to survive in transit, which is one reason why we have
transfer-encodings.
--
Viktor.
