Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT)

[Ned Freed <[e-mail]>]

(IESG dropped from this since they have better things to do than discuss
message format arcana.)

> Actually, that's not quite true. The spec is clear that the Return-Path:
> is always on top of it's associated Received: fields.

I'm skeptical of this claim. RFC 5322 section 3.6 states:

   It is important to note that the header fields are not guaranteed to
   be in a particular order.  They may appear in any order, and they
   have been known to be reordered occasionally when transported over
   the Internet.  However, for the purposes of this specification,
   header fields SHOULD NOT be reordered when a message is transported
   or transformed.  More importantly, the trace header fields and resent
   header fields MUST NOT be reordered, and SHOULD be kept in blocks
   prepended to the message.  See sections 3.6.6 and 3.6.7 for more
   information.

Seems to me this says that trace fields can't be reordered once they are
generated, but at the same time this appears to provide carte blanche for a
given operation adding trace fields to do it in any order it pleases.

And even if you believe that the ABNF showing that return-path comes first
within a given block overrides this text, there's also the fact that a header
"block" is itsef an ill-defined notion. I can easily envision an implementation
that adds return-path and one received field at one step, followed by
another process that adds another received field to log some additional
processing done to the message.

Since the specification never comes out and says that a given
create/submit/relay/deliver step MUST only add a single block of trace fields,
you've completely lost the ability to call an implementation incompliant when
it meets the technical requirements of the ABNF by generating multiple blocks
during one of these operations.

> And though not  crystal clear, it certainly implies that the Resent-Fields: get 
> prepended *before* being reintroduced into the transport system, which  is what
> ought to be prepending the Received: and Return-Path: fields.

The situation with resent-* is, if anything, worse. It would be one thing if
resent-* were associated exclusively with a particular sort of manual message
submission operation, which necessarily occurs after final delivery and thus if
everything is working perfectly will result in a clear ordering of blocks.

But RFC 5322 doesn't restrict resent-* fields to that role. And that means
that you cannot count on a delivery event having occurred prior to the
"reintroduction" event that's adding the resent-* fields.

Just as one example, sieve redirect can easily be seen to meet the criteria of
RFC 5322 section 3.6.6 irrespective of whether or not it's done prior to final
deliver, and in practice some sieve implementations operating before final
delivery do add resent- fields. (We provide it as an option in our
implementation.) How this then maps onto a particular set of block additions to
the message is anyone's guess.

				Ned