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

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

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
<[e-mail]> 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/