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