I'll be raising the "which headers are Trace headers precisely". Once I can
publish my "email header registry maintenance" draft, it'll say:
5.1. Fields whose defining documents call them trace fields
For each of the following fields the defining document states, in
terms, that the field is a trace field and is to be prepended and not
reordered. The Trace column for each SHOULD be "yes".
* "Received-SPF" (mail), [SPF], Section 9.1: "The Received-SPF
header field is a trace field (see [RFC5322], Section 3.6.7) and
SHOULD be prepended to the existing header, above the Received
field".
* "Authentication-Results" (mail), [AUTHRES], Sections 2.1 and 4.1:
the field "is therefore considered to be a trace field as defined
in [MAIL]", and "MUST be treated as though it were a trace header
field ... and hence MUST NOT be reordered and MUST be prepended to
the message".
* "DKIM-Signature" (mail), [DKIM], Section 3.5: the field "SHOULD be
treated as though it were a trace header field as defined in
Section 3.6 of [RFC5322] and hence SHOULD NOT be reordered and
SHOULD be prepended to the message".
* "VBR-Info" (mail), [RFC5518], Section 2: "in the terminology of
RFC 5322, VBR-Info is a 'trace header field'".
* "Path" (netnews), [NETNEWS-FMT] Section 3.1.5 and [NETNEWS-ARCH]:
each processing agent prepends to the field, its order is
significant, and [NETNEWS-ARCH] names it a trace header field
alongside "Received" ("trace header fields (like Received in Email
or Path in Netnews)").
* "Injection-Info" (netnews), [NETNEWS-FMT] Section 3.2.8: it is
added only by the injecting agent and exists to assist "in tracing
the article's true origin"; [NETNEWS-ARCH] classes it as trace
information.
* "X400-Trace" and "DL-Expansion-History" (mail), [RFC4021]:
registered with descriptions that are, respectively, "X400 Trace"
and "Trace of distribution lists passed"; both derive from the
X.400 per-hop trace elements of [RFC2156].
Note that "DKIM-Signature" and "VBR-Info" are typically added by the
originating administrative domain rather than by a relay, yet their
authors deliberately chose the "trace header field" designation to
obtain its positional guarantees (prepend, do not reorder). The
Trace column should record what the defining documents say; the "yes"
value reflects that designation.
5.2. Fields that behave as trace fields without the label
The following fields are added by handling agents in transit, at a
defined position, with ordering significance, but their defining
documents do not use the word "trace". Whether the Trace column
should be "yes" for these depends on whether IANA reads the column in
the strict sense of [MAIL] Section 3.6.7 or in the broader
"designated by the defining document" sense used in Section 5.1.
This document recommends "yes" and records the evidence so that IANA
can decide with the facts in hand.
* "ARC-Seal", "ARC-Message-Signature", "ARC-Authentication-Results"
(mail), [ARC]: added by participating domains as the message
transits, with "i=" instance tags that encode the order of
handling ("chain of custody").
* "Delivered-To" (mail, provisional), [RFC9228] Section 4: "MUST be
placed at the current 'top' of the message's set of header fields
... in a fashion similar to the trace fields", and "MUST NOT be
reordered".
* "Original-Recipient" (mail), [RFC3798] Section 2.3: inserted by
the delivering MTA "at the beginning of the message (along with
the Return-Path header)".
Bron.
On Fri, Jul 10, 2026, at 00:58, Pete Resnick wrote:
> Thanks Richard. Are there any other issues people have for the agenda in 2
> weeks? Conversely, are there any of the items that Richard listed below that
> we think are already closed and don't need to be discussed at all?
>
> pr
>
> --
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best
>
> On 9 Jul 2026, at 17:18, Richard Clayton wrote:
>
>> Hash: SHA1
>>
>> I was asked to supply a list of "open issues" that it would be useful to
>> discuss at the Vienna meeting
>>
>> Removal of null recipes for headers
>>
>> ` ie: you always have to document what you changed
>>
>> this considerably simplifies DSN handling, and it seems fanciful
>> that systems in the middle of the network are altering headers at
>> all, let alone in ways they are do not wish recipients to be able
>> to undo
`
>> Should we explicitly forbid Message-Instance headers that only differ by
>> ordinal value
>>
>> ` The spec has some MUST NOT's here but all they do is heat up the
>> planet, they don't actually cause interworking issues
`
>> PQ Algorithm
>>
>> ` The chairs are going to ask for advice and we have had a discussion
>> on how that question should be phrased. Stephen Farrell suggested
>> just insisting that all signatures MUST pass (but long ago the WG
>> disliked that so we have a SHOULD at present)
`
>> Case issues in JSON
>>
>> ` should we insist that header field names in the recipe JSON always
>> be in lower (or indeed UPPER) case ?
`
>> DSN flagging
>>
>> ` Should we provide an explicit way of labelling DSNs (prescribing a
>> Subject header field, or adding a flag?) rather than having MTAs
>> work it out from the context (and what email address is being sent
>> to).
`
>> Feedback
>>
>> ` the specification has a framework for asking for feedback but stays
>> away from saying what that means. Does the WG think there are
>> things to standardise here ?
`
>>
>> richard @ highwayman . com "Nothing seems the same
>> Still you never see the change from day to day
>> And no-one notices the customs slip away"
>>
> _______________________________________________
> Ietf-dkim mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
--
Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
