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 18:12:47
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

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