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

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Feb 2021 13:46:06 -0800

G'day SMTP folk,

This draft was prompted by discussion in the emailcore wg, but is 
outside the scope of the wg charter.  So the spec is being pursued as 
AD-sponsored.

The SMTP mailing list is cited in the draft as the discussion venue. 
(emailcore has been bcc'd.)

d/

-------- Forwarded Message --------
Subject: New Version Notification for draft-crocker-email-deliveredto-00.txt
Date: Wed, 03 Feb 2021 11:16:20 -0800
From: [email-masked]
To: Dave Crocker <[email-masked]>

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

Name:		draft-crocker-email-deliveredto
Revision:	00
Title:		Delivered-To Email Header Field
Document date:	2021-02-03
Group:		Individual Submission
Pages:		6
URL: 
https://www.ietf.org/archive/id/draft-crocker-email-deliveredto-00.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-00

Abstract:
    The address to which email is delivered might be different than any
    of the addresses shown in any of the content header fields that were
    created by the author.  The address used by the mail transport
    service is provided separately, through an envelope SMTP "RCPT TO"
    command.  Before final delivery, handling can entail a sequence of
    addresses that lead to the recipient.  It can be helpful for a
    message to have a common way to record each delivery in such a
    sequence, and to include each address used for that recipient.  This
    specification defines a header field for this information.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 4 Feb 2021 18:46:01 -0500

>outside the scope of the wg charter.  So the spec is being pursued as 

This short draft fills in a long standing gap in the specs.  MTAs have been
adding Delivered-To headers for over 20 years but the header has never been
registered with IANA and there's never been a spec saying what it does.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 5 Feb 2021 11:56:55 +0100

Hi Dave,

On Thu 04/Feb/2021 22:46:06 +0100 Dave Crocker wrote:
> G'day SMTP folk,
> 
> This draft was prompted by discussion in the emailcore wg, but is outside the 
> scope of the wg charter.  So the spec is being pursued as AD-sponsored.

A few points:

1)  In the sentence:

    The Delivered-To: header field is added at the time of delivery, when
    responsibility for a message transitions from the Mail Handling
    (Transport) Service to an agent acting on behalf of the specified
    recipient address.

(Please substitute /Mail Handling/Message Handling/, so that it matches RFC 
5598.  Perhaps substituting /Transport/SMTP/ might improve readability.)

That sentence implies there is no Delivered-To: if the message is copied 
locally without going through MHS.  For example, some MDAs accept either email 
addresses (local or remote) or local mailbox paths to deliver a copy.  If one 
specifies delivery by means of local paths, no further Delivered-To: is added 
(and neither could be, since the agent doesn't know the address in that case). 
  Is that worth noting?

BTW, you don't use the term Message Delivery Agent (MDA).  Is it by purpose?

2) ABNF

    "Delivered-To:" FWS Mailbox CRLF

    Note:    The field records only a single address, for one recipient.

Would it be worth to note that Mailbox (capital M) comes from [SMTP], not 
[Mail-Fmt]?

3) IDNs:

When I write a message to [email-masked] (fake user, real domain) the MDA writes
Delivered-To: [email-masked].  I see no reason for doing so.  The message 
is SMTPUTF8 anyway because of the To: [email-masked] header field, which is 
maintained.  Are there reasons to mangle the domain name?

> The SMTP mailing list is cited in the draft as the discussion venue.

Didn't find that citation.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Fri, 5 Feb 2021 06:53:16 -0800

On 2/5/2021 2:56 AM, Alessandro Vesely wrote:
> (Please substitute /Mail Handling/Message Handling/, so that it matches 
> RFC 5598.  Perhaps substituting /Transport/SMTP/ might improve 
> readability.)

oops.  good catch!

> locally without going through MHS. 

I would claim that, in architectural terms, whatever code is doing this 
local processing, figuring out where to place the message, is part of an 
MHS.

  For example, some MDAs accept either
> email addresses (local or remote) or local mailbox paths to deliver a 
> copy.  If one specifies delivery by means of local paths, no further 
> Delivered-To: is added (and neither could be, since the agent doesn't 
> know the address in that case).  Is that worth noting?
> 

It was intentional.  Note that the text is MHS and not MTA.

One of the more interesting bits from the development of RFC 5598, was 
some folk putting forward the idea that the MSA and MDA each has a dual 
personality.  Part MUA; part MHS.  So the boundary for the MHS is 
/inside/ each of those architectural components.

See Figure 5 in RFC 5598, which makes this explicit.

> Would it be worth to note that Mailbox (capital M) comes from [SMTP], 
> not [Mail-Fmt]?

A perfectly reasonable question, which also highlights the basic problem 
with defining shared constructs in multiple places.

But to respond to the question:

https://tools.ietf.org/html/rfc5321#section-2.3.11:

     Mailbox        = Local-part "@" ( Domain / address-literal )

https://tools.ietf.org/html/rfc5322, Section 3.4:

     mailbox         =   name-addr / addr-spec

Since the string comes from a RCPT TO, I think the ABNF details need to 
be for /only/ and address (no name) and so it's either an RFC 5321 
<mailbox> or it's an RFC 5322 <addr-spec>.  But since the source of the 
string is 5321, I'll choose the former, unless there's a strong lobby 
for the latter.  (Also, I think the existing use of the capital M 
signals that 5321's version was intended...)

> Delivered-To: [email-masked].  I see no reason for doing so.  The 
> message is SMTPUTF8 anyway because of the To: [email-masked] header field, 
> which is maintained.  Are there reasons to mangle the domain name?

I'd guess that has more to do with software implementation that document 
specification, but if there's a change to this spec you have in mind, 
please offer it.

> Didn't find that citation.

Section 2.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 5 Feb 2021 20:33:58 +0100

On Fri 05/Feb/2021 15:53:16 +0100 Dave Crocker wrote:
> specification, but if there's a change to this spec you have in mind, please 
> offer it.

Meanwhile, I had asked the same question to the developer.  Here's what he 
answered:

     Until mail client are dominantly Unicode, one still needs to make allowance
     for ASCII mail clients that might balk on seeing 8-bit mail headers, hence
     the headers Courier adds will have UTF-8 domains translated to their ACE
     equivalents.

     Courier should accept UTF-8 userids. Can't do anything about that, so
     they'll still show up as UTF-8 in headers. This will require the IMAP or
     the POP3 client to enable Unicode support, else they'll get that warning.

I don't think that that text should go in the I-D.  However, if you can extract 
a savvy principle from it, it may be worth to add it to the spec...

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Fri, 5 Feb 2021 11:51:04 -0800

On 2/5/2021 11:33 AM, Alessandro Vesely wrote:
> I don't think that that text should go in the I-D.  However, if you can 
> extract a savvy principle from it, it may be worth to add it to the spec...

Looks like implementer has applied the same design thinking that 
prompted the design approach of MIME:  Layer an enhancement without 
requiring change to the infrastructure.

d/

---

From: "John Levine" <[email-masked]>
Date: 5 Feb 2021 16:31:21 -0500

In article <[email-masked]> you write:
>Delivered-To: [email-masked].  I see no reason for doing so.

Mine does the same thing. I want to treat A-label and U-label versions
of domain names the same throughout the MTA, so it turns them all into
A-labels on the way in, and only back into U-labels when sending
UTF8SMTP mail. Works fine.

I don't think this is something the draft should address. It's an
implementation detail down in the weeds.

R's,
John

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Fri, 05 Feb 2021 16:44:25 -0500

>     (Transport) Service to an agent acting on behalf of the specified

It's a plausible design that the agent doing final delivery accepts
responsibility for delivery to multiple local mailboxes (I've often had things
that ended up delivering to root@localhost and valdis@localhost with one
invocation of the local delivery agent, for example).  Should the agent
generate two Delivered-To: headers, or does it *actually* get generated
appropriately for each copy (at a time later than when the agent accepted
responsibility)?

---

From: Dave Crocker <[email-masked]>
Date: Fri, 5 Feb 2021 13:53:34 -0800

> appropriately for each copy (at a time later than when the agent accepted

The question for the specification is whether it makes clear what the 
specification calls for.  I think it does, but if readers aren't clear 
about it, it would be good to know what about it isn't clear enough.

A different question is how to implement the specification, so as to 
conform to the specification.

For storing a separate copy for each recipient, that seems straightforward.

For sharing a single copy of the message among multiple recipients, the 
answer probably is not straightforward...

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 6 Feb 2021 12:19:02 +0100

On Fri 05/Feb/2021 22:53:34 +0100 Dave Crocker wrote:
>> invocation of the local delivery agent, for example).

Even then, actual delivery usually happens one mailbox at a time, in a loop.

>> Should the agent generate two Delivered-To: headers, or does it *actually*
>> get generated appropriately for each copy (at a time later than when the
>> agent accepted responsibility)?

The second, IMHO.  Adding multiple Delivered-To: at once, one for each mailbox, 
would violate the MUST NOT in Section 5.

> specification calls for.  I think it does, but if readers aren't clear about 
> it, it would be good to know what about it isn't clear enough.

Perhaps, the case of delivery to multiple mailboxes should be anticipated in 
Section 3.

> A different question is how to implement the specification, so as to conform to 
> the specification.
> 
> For sharing a single copy of the message among multiple recipients, the answer 
> probably is not straightforward...

The case of shared IMAP folders is also straightforward.  The Delivered-To: 
contains the mailbox of that folder if it has one, or the mailbox of the 
recipient whose filter directed the message to that folder.

If the mail store implements messages to multiple recipients as files with 
multiple links, I see no way it can add a Delivered-To:.  Such a complicate 
system perhaps might resort to adding it on the fly whenever a MUA downloads 
the message.  Or it can do without.  Or maybe it may make sense to have 
something like Delivered-To: [email-masked].

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2021 12:11:06 -0500

>Even then, actual delivery usually happens one mailbox at a time, in a loop.

No, that depends on the design of the MDA.  Some do that, some don't.

The goal here is to come up with a spec that matches what MDAs have
done with Delivered-To for the past 20 years, and I think the current draft does that.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 6 Feb 2021 10:54:18 -0800

> Even then, actual delivery usually happens one mailbox at a time, in a 

A variation on John's response:  A protocol specification is not an 
implementation specification.  Your comment is about an implementation 
choice.  The only requirement for a protocol spec is that it not prevent 
reasonable implementation.

> Perhaps, the case of delivery to multiple mailboxes should be 
> anticipated in Section 3.

I've added a pointer to Security Considerations.

>> For sharing a single copy of the message among multiple recipients, 
>> the answer probably is not straightforward...
> 
> 
> The case of shared IMAP folders is also straightforward.  The 
> Delivered-To: contains the mailbox of that folder if it has one, or the 
> mailbox of the recipient whose filter directed the message to that folder.

Shared folders are unrelated.  A Shared folder has a single address.

A different issue is implementations that store a single copy of a 
message sent to multiple addressees.  The text is meant merely to 
highlight a concern for divulging other addresses, not to suggest solutions.

d/

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 11 Feb 2021 18:35:16 -0600

> registered with IANA and there's never been a spec saying what it 

Documenting an existing header field is always a good thing, but a 
couple of questions:

Is there any functional or semantic difference between an MDA adding 
Delivered-To: and an MDA adding a Received: with a 'for' clause 
containing the same address? Is it somehow conveying the semantic 
difference between an MTA and an MDA? It seems like Received: could have 
been used, and it can carry more info. (And perhaps the right question 
to ask before all that is: Why did folks start adding a Delivered-To: 
instead of just adding a Received: field with a 'for' clause?)

Also, does adding the Return-Path: happen before or after adding the 
Delivered-To:? The spec seems to indicate before, but it doesn't mention 
Return-Path: at all.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 11 Feb 2021 18:38:15 -0600

On 11 Feb 2021, at 18:35, Pete Resnick wrote:

> The spec seems to indicate before...

Bah. Sorry: "The spec seems to indicate after..."

---

From: "John R Levine" <[email-masked]>
Date: 11 Feb 2021 20:29:58 -0500

> Delivered-To: and an MDA adding a Received: with a 'for' clause containing 
> the same address? Is it somehow conveying the semantic difference between an 
> MTA and an MDA?

That's it.  If there are address rewrites between the RCPT TO and the 
final delivery, it uses the rewritten address.

This is what qmail does.  I think Postfix does the same thing, can check.

> Delivered-To:? The spec seems to indicate before, but it doesn't mention 

In practice they're added at the same time.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Sam Varshavchik <[email-masked]>
Date: Thu, 11 Feb 2021 20:38:25 -0500

> Documenting an existing header field is always a good thing, but a

My answer is meant to document the existing practice of this header
based on direct knowledge of how it's implemented, here and there.

> containing the same address?

The existing practice tends to be for mail servers to be divided,
internally, between an MTA and a MDA. The MTA that handles all mail.
The MDA handles mail addressed to local mailboxes. The MDA can be an
integral part of the mail server, or a separate MDA can be defined,
that receives a single message that gets handed off to it, from the
MTA.

The Received: header is typically added by the MTA and not an MDA. The
MTA adds the Received: header as the first order of business, before
receiving the entire message from the sender. The entire message
effectively gets appended to this first header line.

This is the typical implementation. The MTA records the obligatory
Received: header identifying itself, then the message it receives, and
it carries this message along where it goes. The MTA does not prepend
the Received: header to a verbatim copy of the message it receives,
before delivering it somewhere.

In this typical implementation, and with multiple recipients, there is
no specific recipient that can be identified in the "for" clause.

The Delivered-To: header then gets added by the MDA portion of the
mail server, for an individual message that's delivered to a single
mailbox, naming the recipient.

The MDA also uses the Delivered-To: headers as a no-brainer mail loop
detection. Before the Delivered-To: header was used, the only thing
that the MTAs did was count the number of Received: headers to detect
a (likely) mail loop. The Delivered-To: header offers a reliable
short-circuit, there's no need to bounce the same message back and
forth a few hundred times, before someone's Received: header limit is
exceeded. If the message already has an Delivered-To: header: this
indicates a mail loop, somewhere. The message can be bounced
immediately. This doesn't prevent all kinds of possible mail loops,
Received: headers continue to get counted; but this stops many of the
basic ones, that's caused by someone's broken forwarding instruction.

The Delivered-To: header is also easier to parse, instead of parsing
the entire Received: header.

> instead of just adding a Received: field with a 'for' clause?)

Much easier mail loop detection.

> Delivered-To:? The spec seems to indicate before, but it doesn't mention

It's been my experience that their relative order is unspecified,
consistent with all other headers (except for the defined order of the
Received: headers).

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Feb 2021 18:48:20 -0800

> Delivered-To:? The spec seems to indicate before, but it doesn't mention 

One is specified in 821 & 822, ff.  The other is specified in this new 
draft.  Neither is jointly specified.

I haven't noticed anything in the new draft that even mentions them 
jointly.  Indeed, Received: is only cited in the new draft in the 
Security Considerations section.

If there is anything in it that produced the 'seems to indicate' 
impression, I'd like to know what it is, so I can fix it.  Even if they 
are added by the same process, I would not expect there to be any order 
dependency.

d/

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 12 Feb 2021 11:03:51 -0600

On 11 Feb 2021, at 20:48, Dave Crocker wrote:

>> Delivered-To:? The spec seems to indicate [after], but it doesn't 
>> mention Return-Path: at all.
>
>
> impression, I'd like to know what it is, so I can fix it.  Even if 
> they are added by the same process, I would not expect there to be any 
> order dependency.

The examples show Delivered-To: next to the last Received: field, which 
implies that Return-Path: is going to get pre-pended after the 
Delivered-To: field. If in practice they can appear in either order 
(which seems perfectly plausible), that seems like a reasonable thing to 
mention. If in practice they always appear in a particular order (which 
also seems plausible) and some entity later reading the message relies 
on that order (which doesn't seem like a great idea, but weirder things 
have happened), that seems like an important thing to say. Either way, 
setting expectations seems good.

pr

---

From: "John R Levine" <[email-masked]>
Date: 12 Feb 2021 12:25:12 -0500

> implies that Return-Path: is going to get pre-pended after the Delivered-To: 
> field. If in practice they can appear in either order (which seems perfectly 
> plausible), that seems like a reasonable thing to mention. ...

Depends on the implementation.

If you want to add helpful advice, I'd also add Sam V's point that it's 
widely used to break mail loops.  I think that every MDA that adds 
Delivered-To checks to see of the message already has the same D-T and if 
so drops or bounces the message.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Feb 2021 07:52:54 -0800

On 2/12/2021 9:25 AM, John R Levine wrote:
> I think that every MDA that adds Delivered-To checks to see of the 
> message already has the same D-T and if so drops or bounces the message.

MUST or SHOULD or MAY?  Or non-normative?

I'm leaning towards non-normative, mostly because I think important 
handling directives shouldn't be scattered around into stray 
specifications.

That is, I'd think a normative statement about this would be much better 
in a BCP-ish document.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Feb 2021 08:09:40 -0800

> setting expectations seems good.

It's always dangerous to attempt at deriving normative requirements from 
examples, of course.

The current text just says to add Delivered-To: to the top and it says 
what actor is to do this.  I think that has all of what is required 
about the field itself.

RFC 5321 (Section 4.1.1.4) has similar detail, in its 5th paragraph.

Guessing at a requirement about the combination of the fields goes quite 
a bit beyond either of the specifications.

One could imagine a usage document discussing this, but there does not 
seem to be a benefit in creating a constraint about their combination in 
this specification.

d/

---

From: "John R Levine" <[email-masked]>
Date: 14 Feb 2021 11:53:01 -0500

>> I think that every MDA that adds Delivered-To checks to see of the message 
>> already has the same D-T and if so drops or bounces the message.
>

Definitely not normative, just an observation about existing practice.

RFC 5321 says to count Received headers to break loops and I don't want to 
get into updating that.

Regards,

---

From: "Pete Resnick" <[email-masked]>
Date: Sun, 14 Feb 2021 14:23:01 -0600

On 14 Feb 2021, at 10:09, Dave Crocker wrote:

>> The examples show Delivered-To: next to the last Received: field, 
>> which implies that Return-Path: is going to get pre-pended after the 
>> (which seems perfectly plausible), that seems like a reasonable thing 
>> to mention. If in practice they always appear in a particular order 
>> (which also seems plausible) and some entity later reading the 
>> message relies on that order (which doesn't seem like a great idea, 
>> but weirder things have happened), that seems like an important thing 
>> to say. Either way, setting expectations seems good.
>
>
> It's always dangerous to attempt at deriving normative requirements 
> from examples, of course.
>
> Guessing at a requirement about the combination of the fields goes 
> quite a bit beyond either of the specifications.
>
> seem to be a benefit in creating a constraint about their combination 
> in this specification.

To the contrary: I am perfectly happy if there is no defined order or 
constraint on the order, but I do think it's worth saying that they MAY 
appear in either order (i.e., no implementation should ever act on the 
order that they happen to appear in).

pr

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Feb 2021 14:38:16 -0800

> order that they happen to appear in).

I'm not a fan of having a spec include language about various things it 
is not saying, since the list of such things is infinite.  As well, 
saying that it is not being covered is a form of covering it.  And, 
indeed, it invites the reader to find problems with what hasn't been 
said.  And with what has.

d/

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Sun, 14 Feb 2021 17:45:31 -0500

> order that they happen to appear in).

Yeah, that detail sounds like a MAY to me as well...

---

From: "John R Levine" <[email-masked]>
Date: 14 Feb 2021 17:56:05 -0500

>> order that they happen to appear in).

In practice a message may have several Delivered-To headers interspersed 
with Received, depending on the internal forwarding setup.

I'm with Dave here -- there's nothing to standardize here beyond noting 
that Delivered-To is a trace header so whever it's added, it goes at the 
top.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2021 18:04:32 -0500

Here's the top few trace headers on a message I recently received from an IETF server,

The two Delivered-To headers are due to the way qmail handles virtual domains.
It's been doing it that way for over 20 years, so it's definitely existing practice.

Once again, I don't think we have anything to say about the order of the headers
beyond noting that Delivered-To is yet another trace header.

R's,
John

---

From: Pete Resnick <[email-masked]>
Date: Sun, 14 Feb 2021 17:37:42 -0600

On 14 Feb 2021, at 16:38, Dave Crocker wrote:

> I'm not a fan of having a spec include language about various things 
> it is not saying, since the list of such things is infinite.  As well, 

I may be volunteering myself for more work by saying this (and perhaps 
this part of the discussion should be brought back to emailcore), but:

I generally agree with the above stated principle. The thing that seems 
different here is that 822, 2822, and 5322 all (for better or worse) 
treated "trace" as a block containing a Return-Path: field followed by 
one or more Received: fields, and recommended (to only slightly varying 
degrees) keeping them in that order. This document (among others) 
changes that. Compare, for example, RFC 8601 section 4.1, where there's 
a whole discussion about positioning and interpretation. There's 
certainly way more going on in 8601 that justifies that discussion, but 
I'm worried about documents changing the "trace block" assumption of x22 
without saying anything.

Maybe this means that the discussion should really take place in 
5322bis, explaining that things may appear in between Received: fields 
and Return-Path: fields, and you can't really depend on order for any of 
it (cf. ticket #7 in emailcore, hence increased work for me/emailcore). 
If so, such is life. I just want to make sure that an explicit decision 
is being made, and who has the token.

pr

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Feb 2021 16:02:11 -0800

On 2/14/2021 3:37 PM, Pete Resnick wrote:
> changes that.

This prompted my looking over the relevant portion of RFC 5321.

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

I think that calling Delivered-To: a 'trace' header field ties it to 
this model in ways that aren't appropriate. And it isn't the above model 
that should change.

So while Delivered-to: is similar to an SMTP trace field, it isn't 
actually an example of one.  The fact that it is an MDA-generated field 
rather than an MTA-generated one further justifies breaking this linkage.

d/

---

From: "John R Levine" <[email-masked]>
Date: 14 Feb 2021 20:07:53 -0500

> different here is that 822, 2822, and 5322 all (for better or worse) treated 
> "trace" as a block containing a Return-Path: field followed by one or more 
> Received: fields, and recommended (to only slightly varying degrees) keeping 
> them in that order. This document (among others) changes that. ...

If it does, it's wrong.

I took a look at what qmail and postfix do, and they both put the 
Return-Path at the top, with Received and Delivered-To and other trace 
headers below it, added as the message passes through whatever components 
do whatever the trace heeaders describe.  I am not aware of anything that 
reorders Delivered-To headers.

Once again, all we need to say is that Delivered-To is a trace header. 
There is nothing else to say about where it goes in the message or its 
relative position to other headers.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2021 20:18:54 -0500

>rather than an MTA-generated one further justifies breaking this linkage.

Before we commence fighting, would you call Resent-<whatever> traace
fields? They sure look to me like they are, added at the top when
something happens to the message, even though they're added by the
MUA.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 14 Feb 2021 20:30:12 -0500

On Sun, 14 Feb 2021, Dave Crocker wrote:
> I think that calling Delivered-To: a 'trace' header field ties it to this 
> model in ways that aren't appropriate. And it isn't the above model that 
> should change.

I took a look at 5322, in which section 3.6.6 says that Resent fields are 
not trace headers, even though they are added in exactly the same way that 
trace fields are.  Presumably there was a historical reason for that.

I see that 8601 says that A-R says that it is a trace field so I don't see 
why Delivered-To is not also a trace field.  It's just as trace-y.

FYI, Delivered-To is not always added by an MDA.  Sometimes, as in the 
example I sent a few messages back, it's added by the MTA when it rewrites 
an address internally.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Sun, 14 Feb 2021 20:43:10 -0500

--On Sunday, February 14, 2021 14:23 -0600 Pete Resnick
<[email-masked]> wrote:

>>> The examples show Delivered-To: next to the last Received:
>>> field,  which implies that Return-Path: is going to get
>>> pre-pended after the  Delivered-To: field. If in practice
>>> they can appear in either order  (which seems perfectly
>>> plausible), that seems like a reasonable thing  to mention.
>>> If in practice they always appear in a particular order 
>>> (which also seems plausible) and some entity later reading
>>> the  message relies on that order (which doesn't seem like a
>>> great idea,  but weirder things have happened), that seems
>>> like an important thing  to say. Either way, setting
>>> expectations seems good.
>> 
>> 
>> It's always dangerous to attempt at deriving normative
>> requirements  from examples, of course.
>> 
>> The current text just says to add Delivered-To: to the top
>> and it says  what actor is to do this.  I think that has all
>> of what is required  about the field itself.
>> 
>> Guessing at a requirement about the combination of the fields
>> goes  quite a bit beyond either of the specifications.
>> 
>> One could imagine a usage document discussing this, but there
>> does not  seem to be a benefit in creating a constraint about
>> their combination  in this specification.
> 
> To the contrary: I am perfectly happy if there is no defined
> order or constraint on the order, but I do think it's worth
> saying that they MAY appear in either order (i.e., no
> implementation should ever act on the order that they happen
> to appear in).

I don't feel strongly about this, but I've run into several MUAs
over the years that expected Return-to: to be the first/top
header field and that would get more or less confused or
irritated if it was not there.  That is a plausible inference
from, e.g., the use of "beginning of" in Section 4.4.  Other
inferences are also plausible, especially if one assumes that
processing between "final delivery" and the MUA (which the IETF
carefully avoided trying to specify for many years and for
which, AFAIK, there are still no standards track specifications)
could add header fields before the SMTP-specified trace ones...
or if one were concerned about SMTP extensions providing for
such "at the beginning" fields. 

So I would agree that whatever this document chooses to say
should be clear.  And, if this discussion calls for a revision
or clarification of the meaning of "beginning of" in 5321bis,
presumably everyone here knows where and how to generate a
ticket [1].

    john

[1] While addressing some of the same paragraphs, this note is
quite separate from the issue raised in a recent note to that
list (
https://mailarchive.ietf.org/arch/msg/emailcore/8nQGWm2r08OyjsuVAaVaZqik7cI
).  Relative to 5321/ 5321bis, the above is about the
interpretation and implications of "beginning of" while that
other message is about "beginning of <what>".

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Feb 2021 18:25:14 -0800

On 2/14/2021 5:43 PM, John C Klensin wrote:
> should be clear.

If the procedural aspects of the existing language are not already 
clear, please explain and then please offer alternative text.

d/

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Feb 2021 00:26:07 -0500

--On Sunday, February 14, 2021 18:25 -0800 Dave Crocker
<[email-masked]> wrote:

> If the procedural aspects of the existing language are not
> already clear, please explain and then please offer
> alternative text.

Please see Pete's comments to which I was responding.

   john

---

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

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.

d/

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Feb 2021 02:57:36 -0500

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

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Feb 2021 10:54:00 +0000

On 15/02/2021 01:30, John R. Levine wrote:

>> this model in ways that aren't appropriate. And it isn't the above 
>> model that should change.
>
> I took a look at 5322, in which section 3.6.6 says that Resent fields 
> are not trace headers, even though they are added in exactly the same 
> way that trace fields are.  Presumably there was a historical reason 
> for that.
>
> I see that 8601 says that A-R says that it is a trace field so I don't 
> see why Delivered-To is not also a trace field.  It's just as trace-y.
I agree.
> example I sent a few messages back, it's added by the MTA when it 
> rewrites an address internally.

Best Regards,

Alexey

---

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

In article <C600B92F26F58A4D653F125D@PSB> you write:
>That could be Return-path: on top, "Delivered-to:" on top, ...

I took a look at what qmail and postfix actually do.  I believe they
add most if not all of the Delivered-To headers found in the wild.

* If they add both headers at the same time, the Return-Path is
invariably at the top, like it says in RFC 5321.

* Both of them often add only Delivered-To when they rewrite an address or
forward mail internally. It is quite common to find Delivered-To
intermixed with other headers added along the way. See the example
below.

So here's a radical, different, new idea: let's just say Delivered-To
is a trace header. Because that's what it is.

R's,
John

== headers from a message that started on a postfix system and ended up on a qmail system ==

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Feb 2021 13:10:43 -0800

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

>    information at the beginning of the message content, as discussed in

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/

---

From: "John R Levine" <[email-masked]>
Date: 15 Feb 2021 16:18:36 -0500

>>    for use with RFC 5322 [4].

RFC 8601 says that Authentication-Results is a trace field.  Should we 
file an erratum?

Or perhaps this is just the kind of additional trace header that the 
paragraph above contemplates.

I agree that it is unfortunate that 5321 says there can be new trace 
headers and 5322 doesn't, but that just tells us that 8601 should have 
updated the ABNF in 5322, as should this draft.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Feb 2021 13:24:40 -0800

So far, the topic seems to be driven by individual beliefs, rather than 
by technical need.  It appears that insistence on the terminology 
linkage is based on correlations that seem to have no operational or 
semantic import.

You haven't explained the importance of classifying the Deliver-To: 
header field as a trace header field.

Specifically please comment on the revised text I posted this morning 
and explain how it is deficient.

Please cover that issue well enough to believe it compelling.  Maybe it 
will be possible to pursue coherent discussion, with that established.

d/

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Feb 2021 17:36:49 -0500

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
<[email-masked]> 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.
> 
> 
>>    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.  
> 
>>    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.
> 
>>    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.
> 
> 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/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Feb 2021 16:12:27 -0800

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
> messages and inserting time stamps at that point. 

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

>  If you go

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

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

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

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Feb 2021 16:15:08 -0800

> rewrites an address internally.

It's almost amusing to think that a field specific to delivery is 
affixed by a module that doesn't do deliveries.  But only almost.

The idea that an MTA does some deliveries, as an accommodation to the 
alias mechanism, encourages an approach in which it is warts, all the 
way down.  Let's fix one wart by adding another.

Preferring simplicity instead of warts, the better modeling view is that 
aliases are handled by an MDA function.

Some offline discussion has uncovered limitations in RFC 5598 -- 
especially with the architecture diagram -- and that it needs revision, 
to provide better handling of a case like this.  For example, the 
current diagram requires all deliveries to go through a message store, 
which obviously is not correct for the alias example.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 15 Feb 2021 19:22:33 -0500

> It's almost amusing to think that a field specific to delivery is affixed by 
> a module that doesn't do deliveries.  But only almost. ...

I was under the impressiom that our goal here was to document the 
long-standing existing practice of software that adds Delvered-To headers.

If that's not the case, we're wasting our time and we should abandon the 
draft now.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Feb 2021 16:27:34 -0800

> If that's not the case, we're wasting our time and we should abandon the 

John, you are some others have been tenaciously insisting that the 
document use a term that has no normative value.

Quite a bit earlier today, I offered revised text that eliminates use of 
the term and, therefore, eliminates the source of this unnecessary 
controversy.

Perhaps I missed it, but I haven't not seen anyone respond to that 
suggested change, nor to otherwise explain why this bit of bikeshedding 
has been necessary.

If you are looking for something to abandon, that would be a more 
constructive choice.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 15 Feb 2021 19:30:58 -0500

We are going in circles here.  I have no idea what point you're trying to 
make, and I see no chance of arriving at WG consensus.

R's,
John

On Mon, 15 Feb 2021, Dave Crocker wrote:

> John, you are some others have been tenaciously insisting that the document 
> use a term that has no normative value.
>
> Quite a bit earlier today, I offered revised text that eliminates use of the 
> term and, therefore, eliminates the source of this unnecessary controversy.
>
> Perhaps I missed it, but I haven't not seen anyone respond to that suggested 
> change, nor to otherwise explain why this bit of bikeshedding has been 
> necessary.
>

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Feb 2021 16:35:38 -0800

On 2/15/2021 4:30 PM, John R. Levine wrote:
> We are going in circles here.  

Oh?  Sorry.  I tried to be simple and clear.

Let me make it even simpler.  Please respond to:

https://mailarchive.ietf.org/arch/msg/ietf-smtp/fzCKQu9CyhTcdr1IQ-j43qk8-U8/

It offers revised text and it would help to have people read it and 
comment on what problems it causes for use of the draft.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 15 Feb 2021 19:43:19 -0500

Delivered-To is clearly a trace header field, just like 
Authentication-Results is.  I looked at your arguments about why you think 
it's not and I do not see how they follow from either 5321 nor from our 
multi-decade experience of MTAs adding trace headers.

We are at an impasse, there is no chance of consensus, it's time to give 
up.  Too bad.

R's,
John

On Mon, 15 Feb 2021, Dave Crocker wrote:

> It offers revised text and it would help to have people read it and comment 
> on what problems it causes for use of the draft.
>
>
> d/
>

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Feb 2021 16:49:04 -0800

On 2/15/2021 4:43 PM, John R. Levine wrote:
> Authentication-Results is.  I looked at your arguments about why you 
> think it's not and I do not see how they follow from either 5321 nor 
> from our multi-decade experience of MTAs adding trace headers.

That's impressive.  I asked for comment on revised text and yet you 
continue not to provide any.

Try stepping away from the philosophical back hole of the term.

Consider the revised text as offered and if there is something about it 
that is unworkable or inappropriate, please explain what that is.

d/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Feb 2021 10:07:17 +0000

> RFC 8601 says that Authentication-Results is a trace field. Should we 
No :-)
> updated the ABNF in 5322, as should this draft.

Yes, let's fix this in EMAILCORE.

---

From: Ned Freed <[email-masked]>
Date: Wed, 17 Feb 2021 10:46:43 -0800 (PST)

> comment on what problems it causes for use of the draft.

Sorry to have to say it, but the old text was (marginally) better.

The new text says "add at top" but saying nothing about grouping and
prohibiting reordering. Both of which are really important requirements.

By calling it a trace field, you establish the necessary requirements. Yes, the
underlying documents have issues, but they are clear enough. And "trace field"
is a term that most implementors understand.

That said, making the actual requirements explicit would be even better. You
can easily do that by referring to section 4.4 in RFC 5321 and saying that it
all now applies to the combination of Received: and Delivered-to:

I would prefer to do that *and* call Delivered-to: what it is: A trace field.

				Ned

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 17 Feb 2021 12:03:33 -0800

> all now applies to the combination of Received: and Delivered-to:

FWIW, in developing RFC 8617 (ARC), we also designated those headers as
trace fields too, though we didn't trust handlers to do the right thing so
we built in mechanisms to solve for any reordering or ungrouping which may
happen in the transit chain.

--Kurt Andersen

---

From: "John R. Levine" <[email-masked]>
Date: 17 Feb 2021 15:13:34 -0500

> By calling it a trace field, you establish the necessary requirements. Yes, > the
> underlying documents have issues, but they are clear enough. And "trace > field"

Yup.

At some point we need to fix the 5322 trace field ABNF but emailcore is 
down the hall from here.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Feb 2021 13:02:10 -0800

> prohibiting reordering. Both of which are really important requirements.

OBE.  The draft I submitted text covers that concern.  Alexeys note 
surfaced the ordering issue that I -- and based on the thread here, 
everyone else -- had missed.

See the diffs at:

    https://www.ietf.org/rfcdiff?url2=draft-crocker-email-deliveredto-01

d/

---

From: "John Levine" <[email-masked]>
Date: 17 Feb 2021 17:52:19 -0500

In article <[email-masked]> you write:
w>OBE.  The draft I submitted text covers that concern.  Alexeys note 
>    https://www.ietf.org/rfcdiff?url2=draft-crocker-email-deliveredto-01

I'm still with Ned.  The new text fixes a few things but it mistakenly
took out the language that says Delivered-To is a trace header.

Oddly, it even cites RFC 5321 section 4.1.1.4 which describss what trace
headers are.

Old:

   This specification defines the "Delivered-To" header field, for
   annotating a delivery event and the individual address to which
   delivery has been effected.  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:

   This specification defines the "Delivered-To" header field, for
   annotating a delivery event and the individual address to which
   delivery has been effected.  A sequence of deliveries, such as when a
   message goes through multiple mailing lists,May be recorded with
   a 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.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Feb 2021 15:06:07 -0800

> took out the language that says Delivered-To is a trace header.

Please point me to a consensus-based, published definition of trace 
field that is still correct and that I can cite in the draft.

      As I documented earlier, I could not find one.

After my request is not satisfied, please point me to a draft version of 
text that defines it, to an extent that at least has solidsupport.  I 
haven't noticed that, either.

And finally, I will repeated my query about the syntactic or semantic or 
operational deficiency in the draft.  Failing to include an un- or 
ill-defined term hardly qualifies.

d/

---

From: "John R Levine" <[email-masked]>
Date: 17 Feb 2021 18:31:02 -0500

> Please point me to a consensus-based, published definition of trace field 
> that is still correct and that I can cite in the draft.

I provided language.  Let's see if we have consensus from the rest of the 
WG.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Feb 2021 18:56:02 -0800

On 2/17/2021 3:31 PM, John R Levine wrote:
> I provided language.  Let's see if we have consensus from the rest of 
> the WG.

John,

I've reviewed your postings and do not find any definition of 'trace 
header field'.  So there's nothing for the working group to consider.

Again, you appear to be insisting on inclusion of a term that has no 
consensus definition -- nevermind one that has been published -- and no 
operational effect on the draft.  (It's also not a wg draft.)

d/

---

From: "John R Levine" <[email-masked]>
Date: 17 Feb 2021 22:23:07 -0500

Hi there.

A little while ago I sent the list a message with a complete replacement 
paragraph for a paragraph in the delivered-to draft.  As I said, let's 
see if we have consensus from the rest of the WG.

It looks like you're losing messages so you might want to see why they're 
going astray and catch up from the mail archive or IMAP server.

R's,
John

On Wed, 17 Feb 2021, Dave Crocker wrote:

> I've reviewed your postings and do not find any definition of 'trace header 
> field'.  So there's nothing for the working group to consider.
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Feb 2021 19:48:45 -0800

On 2/17/2021 7:23 PM, John R Levine wrote:
> It looks like you're losing messages

It looks like you didn't read my last note very carefully.

d/

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Feb 2021 00:41:45 -0500

--On Wednesday, February 17, 2021 13:02 -0800 Dave Crocker
<[email-masked]> wrote:

>>> It offers revised text and it would help to have people read
>>> it and comment on what problems it causes for use of the
>>> draft.
>> 
>> The new text says "add at top" but saying nothing about
>> grouping and prohibiting reordering. Both of which are really
>> important requirements.
> 
> 
> OBE.  The draft I submitted text covers that concern.  Alexeys
> note surfaced the ordering issue that I -- and based on the
> thread here, everyone else -- had missed.
> 
> See the diffs at:
> 
> 

Dave, Ned, others,

Looking at the new text at the end of Section 1, this is a
question, not a suggestion or objection:

It seems to me that, with "Delivered-to:" and a large number of
non-standard headers, we are creating a rather long list of
mechanisms for "detecting a delivery sequence loop" as compared
to the times 821 (and even 2821) were written when the
expectation was, more or less, that "Received:" was both
necessary and sufficient for that job.   With the understanding
that this I-D is probably not the place to put the text, do we
need to offer/specify advice about how that selection of fields
might used in relationship to each other for such detection.
Or are we happy saying "this can be used for loop detection" in
several documents and leave which ones to use up to
implementation creativity?

      john

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 18 Feb 2021 16:58:28 +0100

On Thu 18/Feb/2021 03:56:02 +0100 Dave Crocker wrote:
> Again, you appear to be insisting on inclusion of a term that has no consensus 
> definition -- nevermind one that has been published -- and no operational 
> effect on the draft.  (It's also not a wg draft.)

IMHO, SMTP identifies trace fields and Received:'s as it considers only the 
trace fields defined by SMTP.  Indeed, it provides for additional trace fields 
to be registered in the (then) future.

At any rate, a minimal improvement is as follows:

OLD:
    in a fashion similar to some fields specified in [SMTP],
    such as in Section 4.1.1.4.

NEW:
    in a fashion similar to the trace fields specified in
    Section 4.1.1.4 of [SMTP].

That doesn't imply that Delivered-To: /is/ a trace field.  Just that it should 
be treated in the same way.  (The trace attribute is not registered at IANA.)

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Feb 2021 08:09:16 -0800

On 2/18/2021 7:58 AM, Alessandro Vesely wrote:
> That doesn't imply that Delivered-To: /is/ a trace field.  Just that it 
> should be treated in the same way.  (The trace attribute is not 
> registered at IANA.)

My goodness.  How diplomatic.  I like it.  done!

d/

ps. Notwithstanding making the change to the draft, it's important to 
realize that RFC 5321 is quite explicit that Received: is THE trace 
header field.  The only language in 5321 that says otherwise is 
commentary, not definition.  Here's the clearest documentation of this fact:

    4.4.  Trace Information