Subject: [ietf-smtp] Fwd: New Version Notification for draft-crocker-email-deliveredto-02.txt

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Feb 2021 11:39:49 -0800

-------- Forwarded Message --------

A new version of I-D, draft-crocker-email-deliveredto-02.txt
has been successfully submitted by Dave Crocker and posted to the
IETF repository.

Name:		draft-crocker-email-deliveredto
Revision:	02
Title:		Delivered-To Email Header Field
Document date:	2021-02-21
Group:		Individual Submission
Pages:		7
URL: 
https://www.ietf.org/archive/id/draft-crocker-email-deliveredto-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-crocker-email-deliveredto/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-crocker-email-deliveredto
Htmlized: 
https://tools.ietf.org/html/draft-crocker-email-deliveredto-02
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-crocker-email-deliveredto-02

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 21 Feb 2021 15:28:20 -0500

The original motivation for this draft was to document the way that existing MTAs
such as Postfix, Courier, and qmail have added Delivered-To headers for over 20 years.

This draft does not do that.  What it describes is nothing like the behavior of those
MTAs, so I don't understand what it is supposed to do.

I have two suggestions of how to proceed. My preferred one is to
abandon this draft, then we all go down the hall to emailcore and help
with the updates of 5321 and 5322. That should be able to clarify what
trace headers are and fix the ABNF in 5322 to deal with more trace
headers than Received. After we've done that, people who are familar
with the relevant MTAs (Sam and me, I think) can do a very short draft
describing existing Delivered-To practice as a trace header.

Alternatively, if we want to progress the current draft, change the header name to something
like Recipient-Address so people don't confuse it with Delivered-To.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Feb 2021 12:43:54 -0800

On 2/21/2021 12:28 PM, John Levine wrote:
> MTAs,

I've asked for specifics, multiple times.  They haven't been provided.

Rather than simply repeating your conclusion, what, exactly, does this 
draft have wrong?

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Feb 2021 13:14:26 -0800

On 2/21/2021 12:28 PM, John Levine wrote:
> The original motivation for this draft was to document the way that
> existing MTAs such as Postfix, Courier, and qmail have added
> Delivered-To headers for over 20 years.
> 
> This draft does not do that.  What it describes is nothing like the
> behavior of those MTAs, so I don't understand what it is supposed to
> do.

To press my continuing query further, here is what I've seen from your
postings, in reverse order:

On 2/18/2021 8:28 AM, John Levine wrote:
> In article <3073462D484914E07B452E20@PSB> you write:
>> If I correctly understand the intended use of Delivered-to and the
>> meaning of "added at the time of delivery", I believe that the
>> examples in Section 4 are in error. ...
> 
> The examples show long standing practice so if they disagree with
> the text, the text is wrong.

That's an explicit statement that at least the example is correct,
rather than 'nothing like the behavior of those MTAs'.

On 2/17/2021 2:52 PM, John Levine wrote:
> Old:
...
>     A sequence of deliveries, such as when
> a message goes through multiple mailing lists, SHOULD be recorded
> with a series of Delivered-To: header fields.  As with some other 
> information, each additional Delivered-To: header field MUST be 
> placed at the current 'top' of the message -- as the first header 
> field, in a fashion similar to some fields specified in [SMTP], such 
> as in Section 4.1.1.4.  In addition, and as with other fields placed 
> at the current top, the Delivered-To header field MUST NOT be 
> reordered, with respect to other Delivered-to fields AND those other 
> fields.
> 
> New:
...
>      A sequence of deliveries, such as when
> a message goes through multiple mailing lists,May be recorded with a

That's a normative difference of MAY instead of SHOULD.

> series of Delivered-To: header fields.  As with some other 
> information, each additional Delivered-To: header field is a trace 
> header field and so it MUST be placed at the current 'top' of the
 >         message -- as the first header
> field, in a fashion similar to other trace header fields specified
 >         in [SMTP]
> in Section 4.1.1.4.  In addition, and as with other trace header
 >         fields
> the Delivered-To header field MUST NOT be reordered, with respect to
> other Delivered-to fields AND those other fields.

Wording differences that have no semantic or operational difference.

and just to be complete, here's the comparable text from today's version 
of the draft:

>   a series of Delivered-To: header fields.  As with some other
>    information, each additional Delivered-To: header field MUST be
>    placed at the current 'top' of the message -- as the first header
>    field, in a fashion similar to the trace fields specified in [SMTP],
>    such as in Section 4.1.1.4.  In addition, and as with other fields
>    placed at the current top, the Delivered-To header field MUST NOT be
>    reordered, with respect to other Delivered-to fields AND those other
>    fields.

So, John, I've looked back through Feb 15 and am not finding any 
semantic or operational difference other than in that one normative choice.

What else is there, that explains your terminal assessment?

d/