Subject: [Emailcore] Ticket #8 (Reboot): IANA registry for trace header fields

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 05 Aug 2021 17:47:17 +0100

Dear WG participants,
Based on our recent struggles to agree on a more generic IANA registry for header fields added by MSAs/MTAs/MDAs, I propose the following alternative. The new proposal is to create a registry of trace header fields only.

Proposed text (document to include it is TBD):

IANA is requested to create a new registry for trace header fields [rfc5322bis]. Header fields appearing in this registry SHOULD also be registered in <https://www.iana.org/assignments/message-headers/message-headers.xhtml> (whether they are registered as Permanent Message Header Field Names or as Provisional Message Header Field Names). The registration template has the following fields:

1) Name of the trace header field

2) Optional reference field that points to one or more document describing the header field.

3) Optional comment

Registration policy for this new subregistry is “Expert Review”. Designated Experts should only check correctness of the information in the registration template without passing any judgement on usuability of a specific trace header field being registered.

Updates to existing entries undergo the same process as registration of new trace header fields.

===============

Does this look agreeable to people?

Best Regards,
Alexey

---

From: Michael Peddemors <[email-masked]>
Date: Thu, 5 Aug 2021 10:36:12 -0700

> Updates to existing entries undergo the same process as registration of new trace header fields.

You know the selection/criteria of "Expert Review" will be controversial 
I am sure...

However, speaking of 'trace' fields, I do think that some resources be 
included on this topic, to get it in RFC, NOT to add non-trace headers 
in 'trace order'..

Couldn't help but look at the headers of the email you just sent.. 
(comments welcome)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1628182076; bh=OqWf1ujkBNhxWI03krOoe1Yk9MAdSUXDhYjgD4+rdvU=;
	h=Date:From:To:Subject:List-Id:List-Unsubscribe:List-Archive:
	 List-Post:List-Help:List-Subscribe;
	b=cbtdWshhHllJJq8LVMoovZmf9PM9uQDqgLa5m7VA4aBsipaFa55H1zEkyQTn4UoUG
	 WB5DQCnX2sCqa+ddhm7FL4d0GAv/3QOIRzvjsng7Tn+emssqiuqWV1s5oCm9tmiDjh
	 0/HHSHctBjuELe7gzd5tsNwOutNeHLwugC1DmdsQ=

** Why are DKIM headers added in the middle of the trace headers?

X-Mailbox-Line: From [email-masked]  Thu Aug  5 09:47:54 2021

** Why/What is this line, and in the middle of trace headers. Should it 
not be inserted end of headers? Or at least after trace headers?

Received: from ietfa.amsl.com (localhost [IPv6:::1])
	by ietfa.amsl.com (Postfix) with ESMTP id 28FC53A18F6;
	Thu,  5 Aug 2021 09:47:54 -0700 (PDT)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1628182074; bh=OqWf1ujkBNhxWI03krOoe1Yk9MAdSUXDhYjgD4+rdvU=;
	h=Date:From:To:Subject:List-Id:List-Unsubscribe:List-Archive:
	 List-Post:List-Help:List-Subscribe;
	b=PZnc2z6nZK6Cgt1W3LsjQ2Pln/8759vP2rtJLBST+ZJ8bL6ehyHLM21R8IgDJbDFa
	 xlYELv144OUvXjZrZF9Aej+GvrnKmpkGSx+CIKjwVWobeSA9XDDrcurRm7pELmTVc7
	 /3qIV6JmjyLf1dbZsLIMuQseLttQ4PUIOZcSlGw8=

More DKIM embedded in trace..

X-Original-To: [email-masked]
Delivered-To: [email-masked]

Is X-Original-To a trace header? I get that the Delivered-To is..

Received: from localhost (localhost [127.0.0.1])
  by ietfa.amsl.com (Postfix) with ESMTP id 0B2C53A1921
  for <[email-masked]>; Thu,  5 Aug 2021 09:47:46 -0700 (PDT)

(2048-bit key)
  header.d=fastmail.fm header.b=wfJjEPcq;
  dkim=pass (2048-bit key)
  header.d=messagingengine.com header.b=SUu5R7df

I get that many systems in the email flow may do 'scanning' but they 
should not be putting all these headers in the middle of trace headers 
should they?

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h=
  mime-version:message-id:date:from:to:subject:content-type
  :content-transfer-encoding; s=fm3; bh=zPBQRnSXVNVb3pYjXHx8OYFW4q
  uPFP+/HN1cTlVlacs=; b=wfJjEPcqqOtiWUDXdEzArsBDmQWob0S1O7TU7MPEVK
  W98PhOFP0ods4J4FHODLo34Y69hUrit0gXmyiSkYMZ6t4cR0S+ImQog3tgTtoREg
  hEjZPmHAbs6+/bGGqpfjL3GLQd4ZKVVOxBlMqwkbK6/rslK6H5oBImOu18va/Vbt
  kswtqz3qfVxK0lqUJk0Vx1r10jFQqTK3Z2Sfo6I1vohsAA7UTkVwYQXKrLYYY+ih
  yhdy6Ku2s10E7jR8yVJXVTVTgNpc2+aauLwt5TbdWRHeSwy+cAg4jfFwkzzzDE8q
  gvlWuaHXqRfrktfmDmAl4tRu0MymuyoCGBgI+TOchpzg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
  messagingengine.com; h=content-transfer-encoding:content-type
  :date:from:message-id:mime-version:subject:to:x-me-proxy
  :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=zPBQRn
  SXVNVb3pYjXHx8OYFW4quPFP+/HN1cTlVlacs=; b=SUu5R7dfEnukEZrL7OQt68
  cwJo9yWcf4oGKvgfwpQhjQxXn9rrea9s/i72NLHKZy1pAmYGGyHmUX7OlIuYspby
  bGTWHaBq4XVyinZ2cFe83efQjhHXAvps214y5wTXTlBlUOYz2A6YTez8bpwBgSPq
  a1Hh4cMJ0Dxy9BXm5MAjb41/nscY2WY6eClvNgI44wF+4K53B2p4U6rHwo3dzajZ
  sXt209OV9f4csvnJ6mtvPU7T583DtK5agtakUr2fwkbpZRYJntY3pE/2p8FqSIQs
  d+Bx0lHDezfxKTeuv1DImg0ZQLIjD5nucoyubqxdpi1VP80noQwFOImJhBgp+epQ
  ==

Another DKIM header in the middle of trace headers?

X-ME-Sender: <xms:KhYMYcYsa5D-tBuIqqWz0cs-mv_cWTWjRESjLma823NfYhnCfw_ISw>
  <xme:KhYMYXYQWgr0FT3yPQZL6U71YVtlvWWh9C4L4_iqmkvN4JYeiFzviY-vMlRKB7Yce
  7ouSORee7jDvjv6rQ>
X-ME-Proxy-Cause: 
gggruggvucftvghtrhhoucdtuddrgedvtddrieelgddutddvucetufdoteggodetrfdotf
  fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
  uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtgfesthhqre
  dtreerjeenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghl
  nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepfeegudekve
  egiefhleduhfelfeeigffhuddtheffhfevheeitedvleevuefhhffhnecuffhomhgrihhn
  pehirghnrgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih
  hlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh
X-ME-Proxy: <xmx:KhYMYW9eS8s6Aed93XImeX-Ev0oc1YVhSyHZsWpzjROYa99tOwePGw>
  <xmx:KhYMYWpbJtsUDS9li32wU1R3fJjDZB6PDXCvixQ_QDs7du7pntaQ-w>
  <xmx:KhYMYXrscTNeWyS0beCDo7d4nr_LiH35K7F-ztLCYOgW5fo2NEg_Yg>
  <xmx:KhYMYU0qji2gls72Tyv5H2wgFUduZSGEOEeoS7Izwm81MQ7kD3GQWw>

Are the above Trace headers?

Received: by mailuser.nyi.internal (Postfix, from userid 501)
  id 6A1782180064; Thu,  5 Aug 2021 12:47:38 -0400 (EDT)

Trace Headers maybe should be more explicitly discussed, as being at the 
top of the email, and no other headers that are NOT trace headers should 
be inserted at the top of the message.

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 5 Aug 2021 13:37:45 -0400

On Thu, Aug 5, 2021 at 1:36 PM Michael Peddemors <[email-masked]>
wrote:

> > Based on our recent struggles to agree on a more generic IANA registry
> for header fields added by MSAs/MTAs/MDAs, I propose the following
> alternative. The new proposal is to create a registry of trace header
> fields only.
> >
> > IANA is requested to create a new registry for trace header fields
> [rfc5322bis]. Header fields appearing in this registry SHOULD also be
> registered in <
> https://www.iana.org/assignments/message-headers/message-headers.xhtml>
> (whether they are registered as Permanent Message Header Field Names or as
> Provisional Message Header Field Names). The registration template has the
> following fields:
> >
> > Registration policy for this new subregistry is “Expert Review”.
> Designated Experts should only check correctness of the information in the
> registration template without passing any judgement on usuability of a
> specific trace header field being registered.
> >
I have been told by IANA that there should always be > 1 expert reviewer.
YMMV

tim

---

From: "Peter J. Holzer" <[email-masked]>
Date: Thu, 5 Aug 2021 20:06:21 +0200

On 2021-08-05 10:36:12 -0700, Michael Peddemors wrote:
> Couldn't help but look at the headers of the email you just sent.. (comments
> welcome)
> 
> Return-Path: <[email-masked]>
> Delivered-To: [email-masked]
> Received: (qmail 7435 invoked from network); 5 Aug 2021 16:47:57 -0000
> Received: from mail.ietf.org (HELO mail.ietf.org) (4.31.198.44)
> 	by fe3.cityemail.com with (DHE-RSA-AES256-GCM-SHA384 encrypted) SMTP
> 	(e2b84f0c-f60c-11eb-97ce-f31d7c51c7e3); Thu, 05 Aug 2021 09:47:57 -0700
> 	by ietfa.amsl.com (Postfix) with ESMTP id A629C3A1941
> 	for <[email-masked]>; Thu,  5 Aug 2021 09:47:56 -0700 (PDT)
> 

Were they added in the middle? Or were the prepended and then other
systems prepended their own trace headers? I strongly suspect the
latter and I think this is the right thing to do.

> ** Why/What is this line,

It looks like the line that the mbox mailbox format uses to signal the
start of a new mail. Presumably the mailing list software gets the mail
including this start line and preserves it as an X header.

> and in the middle of trace headers. Should it not be inserted end of
> headers? Or at least after trace headers?

No, definitely not. Please always, always, always prepend new headers.
Never append them. If some headers are appended and some prepended, it
is impossible to tell which headers were added by which system. If
headers are always prepended, it is trivial:

| Some: headers here
| Received: from B by C
| More; headers here
| Received: from A by B
| Even: more headers here

All the headers between "Received: from B by C" and "Received: from A by
B" were added by system B.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | [email-masked]         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

---

From: "John Levine" <[email-masked]>
Date: 5 Aug 2021 16:01:14 -0400

It appears that Alexey Melnikov  <[email-masked]> said:
>Dear WG participants,
>Based on our recent struggles to agree on a more generic IANA registry for header fields added by MSAs/MTAs/MDAs, I propose the following alternative. The new
>proposal is to create a registry of trace header fields only.
>
>IANA is requested to create a new registry for trace header fields [rfc5322bis]. Header fields appearing in this registry SHOULD also be registered in
><https://www.iana.org/assignments/message-headers/message-headers.xhtml> (whether they are registered as Permanent Message Header Field Names or as Provisional
>Message Header Field Names). The registration template has the following fields:

>Does this look agreeable to people?

I'd still rather update the existing registry to add "mail trace" as a protocol value.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Aug 2021 13:22:15 -0700

On 8/5/2021 9:47 AM, Alexey Melnikov wrote:
> The new proposal is to create a registry of trace header fields only.

Just for clarity and precision, what are the pointers to:

1. A technical definition of 'trace' header field, that distinguishes 
one, unamiguously, from other header fields?

2. A specification of the creation/handling/disposition differences for 
trace header fields, distinguishing them from other header fields?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 5 Aug 2021 16:37:35 -0400

>trace header fields, distinguishing them from other header fields?

See section 3.6.7 of rfc5322bis and ticket 7.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Aug 2021 14:41:20 -0700

> See section 3.6.7 of rfc5322bis and ticket 7.

3.6.7:

There are details about specific fields.  The only text describing the 
class of fields is:

>> The trace fields document actions taken as a message moves through the transport system.

Ticket 7:

Ned -
>>  Going back to RFC 822, we have this definition:
>> 
>>     Trace information is used to provide an audit trail of mes-
>>     sage handling. In addition, it indicates a route back to the
>>     sender of the message.

The Ticket then documents an extended discussion that does not seem to 
converge, especially with regard to my two questions.

So the apparent answers to my two questions are No and No.

In practical terms, this reduces to:

      "A trace field is anything we declare a trace field.  There are no 
inherent or common technical characteristics or semantics."

d/

---

From: "Peter J. Holzer" <[email-masked]>
Date: Fri, 6 Aug 2021 08:58:42 +0200

> inherent or common technical characteristics or semantics."

I offer a different view:

"Any field added after initial submission is a trace field."

I agree with the second sentence.

        hp

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 06:18:01 -0700

> I agree with the second sentence.

Here's the thing:

Recently, there was an extended group focus on debating that a new 
proposed field had to be labeled a trace field.

If there are no common syntactic or semantic characteristics to such a 
field, then was is the functional benefit in assigning the label of 
'trace' to it?

d/

---

From: "John Levine" <[email-masked]>
Date: 6 Aug 2021 10:04:30 -0400

It appears that Peter J. Holzer  <[email-masked]> said:
>-=-=-=-=-=-

I don't.  A lot of delivery agents add stuff related to spam and malware filtering
with names like X-Spam-Status.  I wouldn't call them trace fields.

In practice, I think most of us agree which headers are trace headers even if we have
trouble writing down what the Platonian ideal of a trace header is.

R's.
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 07:10:26 -0700

> trouble writing down what the Platonian ideal of a trace header is.

So a trace field is whatever a group of folk decide to call a trace 
field.  It has no consistent, defineable characteristics.

Which goes to the point that the label is arbitrary and carries no clear 
semantics or syntax.

Which means that vigorous concern for whether a field is labeled as a 
trace field has no operational benefit.

d/

---

From: Ned Freed <[email-masked]>
Date: Fri, 06 Aug 2021 07:05:51 -0700 (PDT)

> field, then was is the functional benefit in assigning the label of

There most definitely are common semantics. A trace field is used to record
information about the current message tranfer operation, and as such is not a
normal MUA->MUA communication field. Among other things, this means that MUAs
shouldn't be generating them, and even more importantly, should not be
re-introducing them when copy stuff from an existing message to a new one. And
since there are some very badly written MUAs out there, submission servers
would to well to take note of any trace fields an MUA seeks to introduce.

Another one: Since MUAs aren't supposed to be generating them, they should
never contain message content. This means auditing systems barred from storing
message content can record them.

The common security considerations are also significant. Trace fields can
expose internal details about how the MHS is structured within an ADMD, and as
such may require special processing by security gateways. The issues with
Received: are well known, but Delivered-to: specifically can expose details of
the mailing list expansion process, which can include internal sublist
expansion points, use of which can bypass access checks and content scanning.
(Yes, the use of sublists is security by obscurity, but that doesn't mean it's
not done.)

This is one thing X.400 got right: Trace fields are part of the message
envelope, not something that's conflated with message content. In fact X.400
goes so far as to distinguish between internal and external trace information.
Internal trace information is supposed to be removed when a message leaves an
ADMD. (The way they separated things has some issues, but that's hardly
surprising given when all this was designed.)

Delivered-to: definitely qualifies as a trace field, and should be labeled
as such.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 6 Aug 2021 11:36:27 -0400

>Delivered-to: definitely qualifies as a trace field, and should be labeled

At the risk of poking the hornet's nest, do you mean Delivered-To with an envelope address
or with a loop breaking token, or doesn't it matter?

I can't immediately think of a reason why they wouldn't both be trace headers.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 08:43:07 -0700

> or with a loop breaking token, or doesn't it matter?

John,

In spite of your confident and repeated claims, you have yet to provide 
any actual evidence that these are different.

But that's over on the SMTP mailing list, so perhaps such matters of 
fact aren't relevant here.

d/

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Aug 2021 12:24:55 -0400

FWIW, I strongly agree with Ned's analysis, including the
comment about X.400 and its layered envelope.  

I also, fwiw, agree with the suggestions (by John Levine and
others) that it would probably create much less short-term, and
perhaps even long-term, confusion if we added "Main trace" or
some such thing to the existing registry rather than create a
new one.  If _we_ don't have strong consensus about what trace
fields are or are not, it is unreasonable to expect that random
people looking for things in registries will know where to look
if we split trace fields out.

Additional comment: I don't want to open this can of worms, much
less start a long discussion or subject Pete and myself to the
actual extra work of making a change, but this and other recent
discussions on the topic make it increasingly clear to me that,
insofar as trace fields are inserted as part of the transport
function, we should have defined their application, syntax, and
semantics in 2821/5321 rather than putting them into 2822/5322
because they are syntactically header fields.  Among other
things, breaking things down that way would have made for an
extremely simple and clear definition, e.g., if a [transit] MTA
(or maybe a gateway) put something in, it is a trace field and,
if not...   Of course, it isn't quite that simple given
intermediate systems that attempt to do validation or
malware-checking and then document their actions, but
5321bis/5322bis don't talk about that, at least so far.

    best,
     john

--On Friday, August 6, 2021 07:05 -0700 Ned Freed
<[email-masked]> wrote:

>> >>       "A trace field is anything we declare a trace field.
>> >>       There are no inherent or common technical
>> >> characteristics or semantics."
>> > 
>> Recently, there was an extended group focus on debating that
>> a new proposed field had to be labeled a trace field.
> 
>> If there are no common syntactic or semantic characteristics
>> to such a field, then was is the functional benefit in
>> assigning the label of 'trace' to it?
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 11:33:46 -0700

On 8/6/2021 7:05 AM, Ned Freed wrote:
> There most definitely are common semantics. A trace field is used to
> record information about the current message tranfer operation, and
> as such is not a normal MUA->MUA communication field. 

So, a mailing list should not add any trace information?

> Among other
> things, this means that MUAs shouldn't be generating them, and even
> more importantly, should not be re-introducing them when copy stuff
> from an existing message to a new one. And since there are some very
> badly written MUAs out there, submission servers would to well to
> take note of any trace fields an MUA seeks to introduce.

So a message that transit a mailing list should have all handling 
information, which was produced in getting the message into that list's 
inbox?  The recommendation is that all handling sequence information 
involving a sequence of delivery/post activities, should be lost?

d/

ps. As for common semantic, I think what you've described is a common 
type of activity in their production and in their handling, but no 
specific semantic associated with it them.

---

From: "Peter J. Holzer" <[email-masked]>
Date: Fri, 6 Aug 2021 23:05:11 +0200

> So, a mailing list should not add any trace information?

Quite. Of course one could argue that a mailing list is not a "normal"
MUA, but some kind of hybrid between user agent and MHS agent.

> > Among other things, this means that MUAs shouldn't be generating
> > them, and even more importantly, should not be re-introducing them
> > when copy stuff from an existing message to a new one. And since
> > there are some very badly written MUAs out there, submission servers

Some mailing lists might do this for privacy reasons. But I don't think
this should be a general requirement, and more importantly, such a
requirement would be contrary to current practice. Most (all?) mailing
lists I have subscribed do NOT discard any headers, certainly not
Received headers.

Also, when I resend a mail using mutt's "bounce" function, all headers
are preserved.

        hp

---

From: Ned Freed <[email-masked]>
Date: Fri, 06 Aug 2021 21:04:26 -0700 (PDT)

> So, a mailing list should not add any trace information?

Nothing I said implies that. Mail is delivered to the list processor. That
would generate a Delivered-to:, assuming of course that Delivered-to:'s are
being generated.

The list expands and reintroduces the message to the transport, an operation
which could add whatever trace information the list thinks is appropriate,
although a Delivered-to: field is clearly not something that would be added
at this pint.

This could happen multiple times when sublists are involved.

> inbox?

The majority of list processors receive mail directly from the MDA. There's no
inbox involved. 

And before you say that I'm talking about implementation rather than
architecture, let me remind you that you yourself have agreed that there's a
path from the MDA to the MTA missing from RFC 5598. If that's no longer agreed
to, then we have a very very big problem indeed.

> The recommendation is that all handling sequence information

Nope. And again, nothing I said implied that.

> specific semantic associated with it them.

Then I suggest you reread what I wrote, because you have clearly have not
understood it.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 07 Aug 2021 07:22:48 -0700 (PDT)

> This could happen multiple times when sublists are involved.

On further reflection, it's actually the case that a mailing list doesn't add
trace information. It may preserve existing trace information (or not), but it
doesn't add it.

A mailing list may also change the content of a message (or not). But that's
not the same as trace information. It's actions may cause trace information to
be added, as described above, but the list itself isn't doing that.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 9 Aug 2021 10:39:40 +0200

>> "Any field added after initial submission is a trace field."

+1, except for some of the fields added after delivery.  Scripting 
tools like Sieve, which allow to modify the header, often offer append 
as an alternative to prepend.

> with names like X-Spam-Status.  I wouldn't call them trace fields.

Why not?  The mailing list software makes decisions, possibly spread 
over coordinated agents, based on X-Spam-Status:.  Semantically, it 
looks very similar to Authentication-Results:, which is considered to 
be a trace field, according to RFC 8601.

> trouble writing down what the Platonian ideal of a trace header is.

The description Peter gave upthread is dynamic rather than semantic, 
but it seems to capture the essence:

     Please always, always, always prepend new headers.  Never append
     them. If some headers are appended and some prepended, it is
     impossible to tell which headers were added by which system.  If
     headers are always prepended, it is trivial.

John K. reworded it about like so:

     if a [transit] MTA (or maybe a gateway) put something in, it is a
     trace field and, if not...

Validations, like A-R, as they are integral parts of the transmission 
mechanisms, have to be trace fields as well.

Given this "dynamical" concept, the production in rfc5322bis which 
starts with:

     fields          =   *(trace

can be considered a tautological definition,  saved for the fact that 
post-delivery scripts may subvert that order.

Best
Ale
--

---

From: Ned Freed <[email-masked]>
Date: Tue, 10 Aug 2021 15:46:09 -0700 (PDT)

> as an alternative to prepend.

First, saying "*after* initial submission" is incorrect, because initial
submission itself routinely adds trace fields.

Second, "*anything* after initial submission" is incorrect, because as you say
it includes all kinds of random stuff. An even better example is mailing lists,
which exercise MUA authority and routinely muck around with
From:/To:/Cc:/Subject:.

And when you include submission and exclude stuff done after delivery,
you're left with what's already in RFC 5322bis:

   The trace fields document actions taken as a message moves through
   the transport system. 

> > with names like X-Spam-Status.  I wouldn't call them trace fields.

To be honest I'm not sure what a lot of these fields are, what purpose they
serve, or why they are being added to messages. If the message is undergoing
final delivery, then OK, I can understand why you might want to document what
your spam filter thought. (And note that RFC 5598 specifically allows for MDA
actions that are both inside (hMDA) and outside (rMDA) the MHS.)

But when the message is going right back out to some place that likely
doesn't understand whatever bizarre nonsense usually shows up in these
fields? All it does is bloat up messages - I've seen it double or even
triple the size of many messages - for no good purpose.

And often as not they are appended, not prepended, making it impossible
to determine the context in which the evaluation was made.

> be a trace field, according to RFC 8601.

Some do, many, if not most, do not. And as I noted above, fields 
used to communicate between the MDA and MUA do not have to be trace
fields.

As such, I fail to see the relevance of any of this. Why are we trying to
divine the intent of someone who took advantage of RFC 5322 extensiblity
and RFC 5598 flexibility to insert X-X-Large-Spam-Mess:? 

				Ned