Re: [ietf-smtp] New Version Notification for draft-crocker-email-deliveredto-00.txt

[John C Klensin <[e-mail]>]

--On Sunday, February 14, 2021 14:23 -0600 Pete Resnick
<[e-mail]> wrote:

> On 14 Feb 2021, at 10:09, Dave Crocker wrote:
> 
>> On 2/12/2021 9:03 AM, Pete Resnick wrote:
>>> The examples show Delivered-To: next to the last Received:
>>> field,  which implies that Return-Path: is going to get
>>> pre-pended after the  Delivered-To: field. If in practice
>>> they can appear in either order  (which seems perfectly
>>> plausible), that seems like a reasonable thing  to mention.
>>> If in practice they always appear in a particular order 
>>> (which also seems plausible) and some entity later reading
>>> the  message relies on that order (which doesn't seem like a
>>> great idea,  but weirder things have happened), that seems
>>> like an important thing  to say. Either way, setting
>>> expectations seems good.
>> 
>> 
>> It's always dangerous to attempt at deriving normative
>> requirements  from examples, of course.
>> 
>> The current text just says to add Delivered-To: to the top
>> and it says  what actor is to do this.  I think that has all
>> of what is required  about the field itself.
>> 
>> RFC 5321 (Section 4.1.1.4) has similar detail, in its 5th
>> paragraph.
>> 
>> Guessing at a requirement about the combination of the fields
>> goes  quite a bit beyond either of the specifications.
>> 
>> One could imagine a usage document discussing this, but there
>> does not  seem to be a benefit in creating a constraint about
>> their combination  in this specification.
> 
> To the contrary: I am perfectly happy if there is no defined
> order or constraint on the order, but I do think it's worth
> saying that they MAY appear in either order (i.e., no
> implementation should ever act on the order that they happen
> to appear in).

I don't feel strongly about this, but I've run into several MUAs
over the years that expected Return-to: to be the first/top
header field and that would get more or less confused or
irritated if it was not there.  That is a plausible inference
from, e.g., the use of "beginning of" in Section 4.4.  Other
inferences are also plausible, especially if one assumes that
processing between "final delivery" and the MUA (which the IETF
carefully avoided trying to specify for many years and for
which, AFAIK, there are still no standards track specifications)
could add header fields before the SMTP-specified trace ones...
or if one were concerned about SMTP extensions providing for
such "at the beginning" fields. 

So I would agree that whatever this document chooses to say
should be clear.  And, if this discussion calls for a revision
or clarification of the meaning of "beginning of" in 5321bis,
presumably everyone here knows where and how to generate a
ticket [1].

    john

[1] While addressing some of the same paragraphs, this note is
quite separate from the issue raised in a recent note to that
list (
https://mailarchive.ietf.org/arch/msg/emailcore/8nQGWm2r08OyjsuVAaVaZqik7cI
).  Relative to 5321/ 5321bis, the above is about the
interpretation and implications of "beginning of" while that
other message is about "beginning of <what>".