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

[Ned Freed <[e-mail]>]

> My recollection of Return-Path is that there's always zero or one, and it's
> typically added at the top only during local delivery; any instance of it
> in transit is basically wrong and subject to removal.  I'll have to revisit
> this as well if that's wrong.

Apologies, I should have caught this sooner. It's zero or one per block of
Received/Resent-*/Return-path fields. So yes, you can have more than one of
them. And that means section 7.5.3 is incorrect when it asserts that a message
with more than one is invalid in the first sentence. Perhaps a change to
something like this is in order:

   While legitimate messages can contain more than one Return-Path
   header field, such usage is often an error rather that a valid
   message containing multiple header field blocks as described in
   sections 3.6 of [RFC 5322]. Accordingly, when a message containing
   multiple Return-path: header fields is encountered, all but the
   topmost one is to be disregarded, as it is most likely to have
   been added nearest to the mailbox that received that message.

I think that should cover it.

That said, I've always regarded the notion that such blocks can be reliably
distinguished as nothing but specious nonsense, and that fact that RFC 5322
doesn't contain language recommending against such usage as a problematic
aspect of that specification.

The problem is fundamental: Aside from the dependency of Return-path: fields on
Received: fields (but not vice versa), all of the fields in one of these blocks
are optional. And all the rules only say that fielde must be prepended; they
say nothing about which of the various fields in a given block have to be
prepended first. It is therefore perfectly valid in a one step MSA/MDA situation
to prepend Return-path: first, then Received:, then Resent-*. Or any other
order, and that plus the optionality of all the field creates a situation where
there is no way to determine the boundaries between blocks with any degree of
relability. 

It follows that if you expect the recipient of your message to be able to
consume such information reliably it's a really good idea to remove all
instances of these fields other than your own on submission.

But all this goes far beyond the scope of the present draft, which is 
concerned with malformed mail, and as Pete correctly points out, messages
containing multiple Return-path: fields may be ill-advised but are not
necessarily malformed. Although in practice a lot of them are, because another
thing that happens frequently is that when messages are resent all Received:
fields are removed (because if you don't your mail tends to get caught by loop
checks) but the Return-path: fields are retained. And that's then a malformed
message according to the rules.

				Ned

P.S. I claim no special insight into any of this. Marshall Rose patiently
explained this issue to me many years ago.