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

[Dave Crocker <[e-mail]>]

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