ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] return-path vs delivered-to, was New Version Notification for draft-crocker-email-deliveredto-00.txt

2021-02-15 15:11:05
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/




--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>