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

[Pete Resnick <[e-mail]>]

On 11/27/13 12:04 AM, Ned Freed wrote:

> 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.
>    

wfm.

> 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.
>    

Yeah, well, I was still bright-eyed and bushy-tailed when I wrote that 
text. Grumpy-old me of today would have said different things.

> 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.
>    

Actually, that's not quite true. The spec is clear that the Return-Path: 
is always on top of it's associated Received: fields. 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. 
But yes, ambiguity abounds.

In any event, I agree with Ned that this is discussion of spilled milk 
that has gone over the bridge or under the dam or something. The fix he 
suggests above is perfectly fine for this document.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]