--On Sunday, February 14, 2021 14:23 -0600 Pete Resnick
<resnick(_at_)episteme(_dot_)net> 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>".
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp