Dave,
I think you are partially misreading 5321. Other than the IANA
bit, the sections you cite are about _accepting_ or _receiving_
messages and inserting time stamps at that point. If you go
further down 4.4, you will find both the discussion of
"Return-path:" as part of "final delivery" and the paragraph I
cited earlier about the sequence at the beginning of the "final
mail data". There is a problem as to whether "Return-path:" is
actually a trace header: Its inclusion in Section 4.4 implies
that it is but there is text elsewhere that appears to equate
"trace field" (or "trace information") with "time stamp" and
"Received". And the troublesome "IANA Considerations" section
definitely thinks it is a trace field. I'm happy to try to
untangle that if someone wants to create a ticket in EMAILCORE
and tell me what to do (i.e., if it is or is not a trace field).
Section 7.6 really is about "Received": If people think there is
an information disclosure issue with "Return-path:", please
identify the issue in EMAILCORE and suggest text.
I definitely agree with you about inconsistent definitions in
different places, both within 5321 and between 5321 and 5322.
But, given the language from Section 4.4 mentioned earlier
(paragraph starting "The text above implies...", I don't think
it is fair to dismiss the expectations of an implementation that
depended on either that, the RFC 5322 definition, or both, as
"some implementation behavior...".
best,
john
--On Monday, February 15, 2021 13:10 -0800 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:
On 2/15/2021 12:50 PM, John Levine wrote:
So here's a radical, different, new idea: let's just say
Delivered-To is a trace header. Because that's what it is.
Not according to the definition in RFC 5321...
4.1.1.4. DATA (DATA)
...
When the SMTP server accepts a message either for relaying
or for final delivery, it inserts a trace record (also
referred to interchangeably as a "time stamp line" or
"Received" line) at the top of the mail data.
The only defined 'trace' header field is Received:.
and:
4.4. Trace Information
When an SMTP server receives a message for delivery or
further processing, it MUST insert trace ("time stamp" or
"Received") information at the beginning of the message
content, as discussed in Section 4.1.1.4.
The only header field defined as 'trace' is Received:.
and:
7.6. Information Disclosure in Trace Fields
In some circumstances, such as when mail originates from
within a LAN whose hosts are not directly on the public
Internet, trace ("Received") header fields produced in
conformance with this specification may disclose host
names and similar information that would not normally be
available.
ditto.
Until...
8. IANA Considerations
...
In addition, if additional trace header fields (i.e., in
addition to Return-path and Received) are ever created,
those trace fields MUST be added to the IANA registry
established by BCP 90 (RFC 3864) [11] for use with RFC
5322 [4].
oops.
And then, yes, RFC 5322 has an incompatible definition:
trace = [return]
1*received
return = "Return-Path:" path CRLF
another oops, nicely demonstrating the problem with defining
the same thing in two places.
So please stop taking some implementation behavior and then
trying to retrofit some terminology to fit it. Particularly
since there is no operational or semantic need.
There is nothing wrong with the implementations you cite. The
problem is with making a post-hoc declaration that a new field
is tied to those other fields. It isn't.
d/
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp