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 2:36 PM, John C Klensin wrote:
> Dave,
> 
> I think you are partially misreading 5321. 

What exactly have I misread?  I mean both specifically and -- most 
importantly -- to what problematic effect, relative to the current draft.


> Other than the IANA
> bit, the sections you cite are about _accepting_ or _receiving_
> messages and inserting time stamps at that point. 

I don't understand how that affects what it says.


>  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

Fine, but that has nothing to do with labeling it a 'trace' field.


> 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

Since I quote the various texts that establish this problem, I do not 
understand how your referring to them constitutes my misreading, partial 
or otherwise.


> 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.

And yet it is 'trace' that is outside the parentheses.  You seem to be 
saying that what is inside the parentheses in 'primary'.


> 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...".

I've no idea what metric you are applying that classes the language I 
used as being dismissive.  Since it wasn't.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net