Re: [ietf-smtp] New Version Notification for draft-crocker-email-deliveredto-00.txt

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

--On Sunday, February 14, 2021 21:31 -0800 Dave Crocker
<[e-mail]> wrote:

> John,
> 
> Thanks, but his note did neither of the things I requested.
> 
> The thread up to the point of your posted had not converged on
> needing specific changes. Hence my request.
> 
> If you want changes, please me specific about what specific
> text is problematic, why, and what text you believe will fix
> it.

Dave, 

Sorry.   Let me explain a bit better.

First of all, I think what Pete and I are both saying is that it
is important that the specification be clear about ordering.
That could be Return-path: on top, "Delivered-to:" on top, or
some way of saying "can be inserted and appear in either order".
I don't see the group as having converged on any of those, so it
is probably not worthwhile recommending text that takes one
position or the other.

Personally, at this moment, and with some allowances for lack of
sleep (i.e., I could change my mind once the sun comes up) I am
somewhat inclined toward John Levine's approach (at least as I
understand it).  My version of that would be to simply define
"Delivered-to:" as a trace field, consider what text (if any) is
needed in 5322bis about the ordering of trace fields, and
consider how (or if) 5321bis should be modified to talk about
trace fields not explicitly covered in that specification.
However, as far as I can tell, the thread has not converged on
that either.

In particular, we should all take note of the paragraph of 5321
(and 5321bis), in Section 4.4, that reads 

	"The text above implies that the final mail data will
	begin with a return path line, followed by one or more
	time stamp lines.  These lines will be followed by the
	rest of the mail data: first the balance of the mail
	header section and then the body (RFC 5322 [11])."

so I don't see much way to move forward with this without some
tuning of 5321.  And, to save someone else pointing it out,
because Section 4.1 of RFC 8601 talks about prepending the
Authentication-Results field based on language in 5322, some
work may be required in or around 8601 or in 5321bis for it as
well and we may need to review whether 5321 and 5322 are
adequately synchronized in that area.  

I would prefer, if possible, to describe whatever is being
described without getting into fine distinctions about what
happens between what 5321 (and 5321bis so far) call "final
delivery" and what we have been calling an MUA (sometimes a
"split MUA") for the last 30 or so years.  While broad
terminology has many advantages, differences among real systems
and their functionality, functionality that conforms to 5321/
5322 and other specs today, are going to make precise
specification in terms of, e.g., MDAs awkward, something that
has, I think, manifested itself several times in these
discussions.

   john