Subject: [ietf-smtp] To trace field or not to trace field

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

The discussion has uncovered quite a range of issues with the term
'trace header field'.  For example, by my reading, RFC 5321 has 
conflicting use of the term.

Generally, I think that I and others, have been using the term rather
casually and not in conformance with its actual specification.

On review of the deliveredto draft, I do not see anything that actually
requires linkage to the trace construct.   Whether the definition and 
use of the term needs fixing is worthy of emailcore consideration, but 
it is outside the scope of the deliveredto effort.

So I've revised the relevant draft text, to decouple from explicit trace
linkage.

Here is the previous text:

        <section title="Delivered-To:">
             <t>This specification defines the "Delivered-To" trace
header field, for annotating a delivery event and the address to which
delivery was 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 other trace information, each
additional Delivered-To header field MUST be placed at the 'top' of the
current message, per <xref target="SMTP">Section 4.1.1.4</xref>.</t>

Here is the revised text:

<section title="Delivered-To:">

<t>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 for
similar to some fields specified in <xref target="SMTP"/>, such as in
Section 4.1.1.4.</t>

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

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

> Here is the revised text:

I've also revised the introductory text to the section showing an example:

    <section title="Multi-hop Example">

    <t>The Delivered-To: header field can indicate a sequence of
deliveries, as demonstrated by this example, which has a message
traveling through a mailing list, on through an alias, and then reaching
final delivery...

I should note meta-point about specification writing...

The original draft had a single example header.  Barry suggested making 
it show a sequence.  I've been impressed with the difference.

So my new meta-rule is that defining something that has relevance to a 
sequence should include an example that demonstrates the sequence.

d/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Feb 2021 13:40:36 +0000

Hi Dave,

On 15/02/2021 18:02, Dave Crocker wrote:
> requires linkage to the trace construct.

I don't find your arguments that Delivered-To is not a trace header 
field convincing. The main characteristic of trace header fields comes 
from the following text in RFC 5322:

    More importantly, the trace header fields and resent
    header fields MUST NOT be reordered, and SHOULD be kept in blocks
    prepended to the message.

If you are not going to say that Delivered-To is a trace header field, 
then you need to state something similar for Delivered-To, covering that 
is should also not be moved in relationship to other trace header 
fields. I.e. I don't really want to see any "creative" implementation 
that transforms:

Return-Path: A

Delivered-To: B

Received: C

   into something like:

Return-Path: A

Received: C

Delivered-To: B

> Whether the definition and use of the term needs fixing is worthy of 
> emailcore consideration, but it is outside the scope of the 
> deliveredto effort.
I am Ok with that.
> similar to some fields specified in <xref target="SMTP"/>, such as in

I am ambivalent about new text. But see my comment about properties of 
trace header fields above.

Best Regards,

Alexey