Maintenance of the IANA Message Header Field Registries

1.1. Metadata That Was Supplied but Not Recorded

[RFC4021] registered roughly ninety mail and MIME header fields in a single Standards Track document. Section 2 of that document contains a complete [REG-PROC] registration template for each field, and each template carries both an explicit "Status:" line and an explicit "Specification document(s):" line naming the document that actually defines the field. Section 3 of [RFC4021] states that "Section 2 of this specification provides initial registrations"; the templates are therefore the registration instructions, and there is no separate, abbreviated table for IANA to work from.¶

Neither the status nor the specification document reached the registry. Every one of those entries carries a blank Status, and cites [RFC4021] in the Reference column instead of the document named in its own template. So, for example, the registry records "Content-Disposition" with no status and a reference to [RFC4021], where [RFC4021] told IANA that the field is standards-track and is specified by [RFC2183].¶

This is the largest source of missing metadata in either registry. Fixing it requires no judgement, since the values can be copied directly from [RFC4021].¶

1.2. Why "standard" Appears Unevenly

The unevenness of the Status column between the mail/MIME fields and the netnews fields has a documented origin. Section 4.2.1 of [REG-PROC] directs a registrant to specify¶

• "standard", "experimental", "informational", "historic", "obsoleted", or some other appropriate value according to the type and status of the primary document in which it is defined.¶

Writing what became [NETNEWS-FMT], Charles Lindsey read that list as lumping the standards-track maturity levels together, and said so on the ietf-822 list on 2004-05-14: the template "seems to suggest that all the varieties of standard-track document are to be lumped together and assigned the status 'standard'", adding "in the IANA Considerations section of USEFOR, I have followed the registration template as written, and used 'standard' throughout."¶

Graham Klyne, the author of both [REG-PROC] and [RFC4021], took the other route, and explained why on 2004-05-17:¶

• "In preparing the mail header registration document, it seemed to be more appropriate (and more honest regarding some of the headers' actual status in the IETF process) to me to specify not-yet-standard headers as 'standards-track' rather than 'standard'. The wiggle room in the registry spec that allows me to justify this is 'or some other appropriate value according to the type and status of the primary document'."¶

[RFC4021] accordingly reserves "standard" for the fields that had reached full Internet Standard through RFC 822, and uses "standards-track" for the rest. Lindsey replied on 2004-05-21 that "standards-track" throughout would be better, "or 'standard' if it is understood to mean the same thing".¶

That is why [NETNEWS-FMT]'s netnews fields all read "standard" while [RFC4021]'s mail and MIME fields do not. The two documents used different vocabularies for the same thing, and only one of those vocabularies is in the [REG-PROC] list. This document treats both [RFC4021] values, "standard" and "standards-track", as the registry's "standard", which is what Klyne and Lindsey each took them to mean.¶

1.3. The Trace Column Is Unfinished

Section 6.1 of [MAIL] asked IANA to add the "Trace" column and to leave it "empty for existing registrations except for those specified in section 6.2". Pete Resnick, the editor of [MAIL], reported to the emailcore list on 2024-03-20 that IANA was content with¶

• "'Yes' or 'No' for the entries that 5322bis specifies and empty (i.e., not yet specified) for the rest of the entries in the registry with the intention of them being filled in later."¶

A blank Trace cell therefore means "not yet specified". It does not mean "not a trace field". The column was left unfinished by design, and this document supplies the material to finish it.¶

1.4. What This Document Does

This document reviews the initial definition of, and every subsequent update to, each registered header field, and provides IANA with an instruction for each entry. The recommendations are derived from the registration instructions in, and the clear intent of, the documents in which each field was defined or modified. This document adds no opinion of its own about how the fields ought to behave. Where the intent is not obvious, this document explains its reasoning. Where an entry looks wrong but is correct, this document explains why it is left unchanged, so that the next reader does not have to repeat the analysis.¶

This document updates [RFC4021]. It changes none of that document's registrations. The update is the instruction in Section 8 to record the "Status" and "Specification document(s)" values from the templates in Section 2 of [RFC4021], and to add the documents those templates name to the Reference column, so that the registry reflects what [RFC4021] registered. The "Updates" header points a reader of [RFC4021] to the document that completed its registrations.¶

1.5. Scope

This document does not define, deprecate, or change the semantics of any header field. It changes only the metadata recorded about existing fields in the IANA registries. In every case the recommended metadata is the metadata that the field's own registering, defining, and updating documents already supply or imply.¶

1.6. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The terms "trace field" and "trace header field" are used as defined in Section 3.6.7 of [MAIL] and Section 4.4 of [SMTP].¶

2.1. draft-levine-trace-header-registry

In January 2012 John Levine, later with S. Moonesamy, published [TRACE-REG], "A Registry for Mail Trace Fields" (later "Mail Header Trace Fields"), which proposed the column that [MAIL] has since added, and proposed an initial set of trace fields. Section 3.2 of the -01 revision assembles per-document evidence for Received-SPF, DKIM-Signature, Authentication-Results, VBR-Info and Auto-Submitted that this document reached independently. That draft expired without publication.¶

This document differs from [TRACE-REG] in three ways. It does not propose to update the definition of trace fields in [MAIL-OLD], because [MAIL] has since done so. It records a yes/no flag, which is the column [MAIL] defined, where [TRACE-REG] proposed a richer "MTA/MUA/MSA/MDA" value. And it covers the Status and Reference columns as well as Trace.¶

Where the two agree, [TRACE-REG] stated the position first, and this document notes the overlap. In particular [TRACE-REG] identified both the Auto-Submitted trace designation and the incompleteness of that field's Reference column; see Section 6.2 and Section 7.¶

2.2. The emailcore Discussion of the Trace Column

The Trace column exists because Alexey Melnikov proposed it to the emailcore list on 2022-11-28, specified as containing "the value 'Yes' for each header field which is defined as a trace header field, as specified in Section 3.6.7 of rfc5322bis". Melnikov reported on 2023-02-27 that at IETF 115 the group had agreed to record trace status by adding a column to this registry, and that the remaining question was which document should carry the IANA Considerations text; it ended up in [MAIL].¶

Two exchanges in that discussion bear directly on the tests this document applies, and are cited where they arise: the confirmation by Melnikov and by Resnick that Section 3.6.7 of [MAIL] permits other specifications to designate additional trace fields (Section 6), and the caution from Melnikov and John Klensin against inferring trace status from a field's position in the header section (Section 6.3).¶

2.3. The Proposed Route for Retroactive Population

On 2024-03-18, in review of [MAIL], Murray Kucherawy raised the question this document answers:¶

• "Also with respect to the trace flag being added to the registry, and the current DE retiring from that role, I'm wondering if we should consider providing some lightweight process for retroactively adding that flag (set or otherwise) to registered header fields. For example, I registered Authentication-Results and at least one other with the intent that they be treated as trace fields, so do I need to publish an RFC to get this flag updated? Or do we want to get a small team to go through all of the current registrations to figure out which ones are supposed to be trace fields, and do a one-shot update...?"¶

Dave Crocker replied on 2024-03-19 that "the question of what it means to be a trace field has been sitting like an indigestible dumpling in the stomach, for many years", and suggested a route:¶

• "For retroactive assessments, it makes sense to create some sort of (rough) consensus process among folk with (some) background in this space. So I suggest creating a small group to make a collective recommendation for existing header field registrations. Documenting it as an RFC then permits a normal IESG approval process."¶

Klensin wrote that he "largely agree(d) with Dave"; Resnick called it "a fine way forward" and reported IANA's agreement to the blank-means-unspecified reading quoted in Section 1.3; Kucherawy wrote "I like this path forward". No consensus was declared on the point, and the question was referred to the IESG.¶

This document is intended as the recommendation Crocker described, extended to the Status and Reference columns because the same entries need the same kind of attention. Section 8 states the mechanism as well as the content.¶

3.1. Determining "Updates" for the Reference Column

The Reference column should point a reader at the document that defines the field and at every document still in force that modifies that definition. Three signals were combined:¶

1. The registration instruction. Where [RFC4021] names a specification document for a field, that document is the starting point.¶

2. The obsoletion chain. Where the named specification has been obsoleted, the document in force is the one at the end of the chain, unless that document drops the field, in which case the last document that defined it is cited and the field is treated as obsoleted. For example [RFC4021] names [RFC2298] for "Disposition-Notification-To"; [RFC2298] was obsoleted by [RFC3798], which was in turn obsoleted by [MDN], so [MDN] is the document in force.¶

3. The formal "Updates:" metadata. Every RFC that carries an "Updates: N" header was recorded as a candidate updater of RFC N. This yields an authoritative, machine-checkable graph. For example [RFC8301] and [RFC8463] each carry "Updates: 6376" and therefore update the definition of the "DKIM-Signature" field.¶

3.2. Formal Updaters That Are Not Added

Signal 3 above produces candidates only. Two classes of formal updater are deliberately not added to the Reference column, because they do not modify the definition of the header field:¶

• Documents that change a specification's use of the DNS rather than its header field. [RFC8553] carries "Updates:" for [DKIM], [SPF] and [RFC5518], but changes only underscored DNS node names. It is not added to "DKIM-Signature", "Received-SPF" or "VBR-Info".¶

• Documents that update a companion protocol carried in the same specification. [RFC8315] carries "Updates: 5537" but defines the Cancel-Lock and Cancel-Key fields and the cancel protocol; it is not added to "Original-Sender", the other field [NETNEWS-ARCH] defines.¶

This exclusion is recorded so that a reader who regenerates the reference sets from the "Updates:" graph alone, and finds three more entries than this document recommends, knows the difference is intentional.¶

3.3. The Historical Lineage Is Not Added

For the core mail fields ("Date", "From", "Sender", "Reply-To", "To", "Cc", "Bcc", "Message-ID", "In-Reply-To", "References", "Subject", "Comments", "Keywords", the "Resent-*" fields, "Return-Path", and "Received") the registry already cites the current defining document ([MAIL], with [RFC6854] where the group syntax applies, and [SMTP] for the two SMTP trace fields). The chain of obsoleted predecessors (RFC 822, RFC 2822, RFC 5322, and for some fields RFC 561, RFC 724, RFC 733, RFC 1036 and RFC 1123) is deliberately not added. The Reference column is meant to point a reader at the definition in force, and listing every obsoleted ancestor would make the entry harder to use.¶

The same reasoning applies to [RFC1049], which first defined a "Content-type" header field in 1988 and now carries status Historic. As Nathaniel Borenstein noted on the emailcore and ietf-dkim lists on 2026-07-24, [RFC1049] is the field's earliest definition. It is named here so that the omission is visible, but it is not added to the Reference column, because the definition in force is the MIME one in [MIME1].¶

A field whose only definition is in an obsoleted document is a different case, and is cited: see Section 4.2.¶

4.1. Completing the RFC 4021 Registrations

As set out in Section 1.1, [RFC4021] supplied a Status for each of the fields it registered, and none of those values reached the registry. This document recommends that they be recorded now, mapped into the [REG-PROC] vocabulary as described in Section 3.¶

The great majority resolve to "standard". [RFC4021] marked them "standards-track" and named a Standards Track specification, and in almost every case that specification, or the document that has since replaced it, is still in force at Proposed or Draft Standard. Appendix B tabulates the whole cohort; the substantive groups are:¶

• Thirty-three fields specified by [MIXER], the MIME/X.400 gateway mapping: the "X400-" family, "Discarded-X400-", "DL-Expansion-History", "Deferred-Delivery", "Latest-Delivery-Time", "Importance", "Priority", "Sensitivity", "Conversion", and the rest. [MIXER] remains a Proposed Standard and has not been obsoleted, so these fields are "standard". ("Expires" is in this group in [RFC4021], but has since been redefined by [I-D.ietf-mailmaint-expires] and already carries "standard"; it needs no change.)¶

  [RFC4021]'s templates settle the question, so no per-field judgement is required. These fields remain in use in the environments that rely on that gateway work, and nothing here deprecates them.¶

• The core MIME fields "MIME-Version", "Content-Type", "Content-Transfer-Encoding", "Content-ID" and "Content-Description", each specified by a named section of [MIME1], and the other MIME fields "Content-Disposition" ([RFC2183]), "Content-Language" ([RFC3282]), "Content-MD5" ([RFC1864]), "Content-features" ([RFC2912]), "Content-Location" ([RFC2557]), "Content-Duration" ([RFC3803]) and "Content-Alternative" ([RFC3297]). All are "standard". The peer field "Content-Translation-Type" ([RFC8255]) is already recorded as "standard", and the MIME fields it sits beside should be too.¶

• "Accept-Language" ([RFC3282]), "Original-Message-ID" ([RFC3297]), "Message-Context" ([RFC3458]), "Disposition-Notification-To" and "Disposition-Notification-Options" ([MDN]): "standard".¶

Three fields do not resolve to "standard":¶

• "Encoding" is specified by [RFC1505], which is Experimental, and [RFC4021] marked it "experimental". The status should be "experimental".¶

• "Content-Alternative" was marked "work-in-progress" by [RFC4021], but [RFC3297] had been published as a Proposed Standard three years earlier and Section 4 of it defines the field. The marking appears to be an authoring slip; the status should be "standard".¶

• "PICS-Label" is marked "standard" by [RFC4021], citing the W3C PICS label specification. Section 4.2.1 of [REG-PROC] directs that non-IETF specifications "formally approved by other standards bodies should be labelled as 'standard'", so the status should be "standard" and the Reference remains a non-RFC citation.¶

4.2. Fields Whose Only Definition Is in an Obsoleted Document

[RFC4021] marked six fields "obsolete". Five of them are the fields whose specification was dropped when the document defining them was replaced:¶

• "Content-Return", "Obsoletes", "Expiry-Date" and "Content-Identifier" were specified by [RFC1327], which [MIXER] obsoleted without carrying these fields forward.¶

• "Encrypted" was specified by RFC 822 and dropped by RFC 2822. Klyne proposed the "obsolete" marking on the ietf-822 list on 2004-04-30 ("Defined by RFC 822, but removed in RFC 2822"), and Keith Moore agreed ("The Encrypted field never was adequately specified ... so yes it's obsolete").¶

For all five the Status should be "obsoleted". For these fields, and unlike the case in Section 3.3, the obsoleted document is the only definition, so it is cited: [RFC1327] for the first four, RFC 822 for "Encrypted".¶

The sixth, "Resent-Reply-To", already carries "obsoleted" by way of its re-registration in [MAIL]. A seventh field of the same shape, "Content-Base", was marked "standards-track" by [RFC4021] citing [RFC2110], but [RFC2557] obsoleted that document and dropped the field; the registry already records "obsoleted" and cites both documents, and needs no change.¶

4.3. MT-Priority: "standard" to "informational"

The "MT-Priority" mail field is registered with Status "standard", citing [RFC6758]. RFC 6758 is an Informational document; its front page states "This document is not an Internet Standards Track specification", and Section 4 of that document is the sole definition of the header field. The Standards Track work on message-transfer priorities, [RFC6710], defines an SMTP service extension keyword and no header field. The field's status should therefore be "informational", matching the only document that defines it.¶

4.4. Solicitation: Blank to "standard"

The "Solicitation" mail field is registered with a blank Status, citing [RFC3865]. RFC 3865 is a Standards Track document, and its Section 4 instructs IANA to add the "Solicitation" field to the permanent registry. A directly comparable field, "Auto-Submitted" (also defined by a Standards Track document, [RFC3834]), is registered as "standard". There is no basis in the source documents for treating the two differently; "Solicitation" should be "standard".¶

4.5. The List-* Family: Blank to "standard"

The six mailing-list fields "List-Help", "List-Subscribe", "List-Unsubscribe", "List-Post", "List-Owner", and "List-Archive" are registered with a blank Status and a Reference of [RFC4021] only, and "List-ID" likewise. They are part of the [RFC4021] cohort of Section 4.1: [RFC4021] marked all seven "standards-track" and named [LIST-URLS] for the first six and [LIST-ID] for "List-ID", both Standards Track documents, neither obsoleted nor updated.¶

For all seven the Status should be "standard" and the Reference should cite the specification document. These entries show the general problem plainly. The registry sends a reader to a registration document and records no status, although a Standards Track definition has existed since 1998 and was named in the registration instructions.¶

4.6. SIO-Label and SIO-Label-History: Blank to "informational"

The "SIO-Label" and "SIO-Label-History" mail fields are both registered with a blank Status, citing [RFC7444]. RFC 7444 is an Informational document in the Independent Submission stream, and it is the sole defining document for both fields ("SIO-Label" in its Section 4 and "SIO-Label-History" in its Section 5). Applying the methodology of Section 3, the Status of both fields should be "informational".¶

4.7. The MMHS-* Fields: Blank to "informational"

The fourteen "MMHS-*" fields registered by [RFC6477] ("MMHS-Exempted-Address", "MMHS-Extended-Authorisation-Info", "MMHS-Subject-Indicator-Codes", "MMHS-Handling-Instructions", "MMHS-Message-Instructions", "MMHS-Codress-Message-Indicator", "MMHS-Originator-Reference", "MMHS-Primary-Precedence", "MMHS-Copy-Precedence", "MMHS-Message-Type", "MMHS-Other-Recipients-Indicator-To", "MMHS-Other-Recipients-Indicator-CC", "MMHS-Acp127-Message-Identifier", and "MMHS-Originator-PLAD"), together with "MMHS-Authorizing-Users" registered by [RFC7912], are all registered with a blank Status. RFC 6477 and RFC 7912 are both Informational documents, and each is the document that registers the fields it covers for use in Internet Mail. Applying the methodology of Section 3, the Status of every one of these fields should be "informational".¶

4.8. Status in the Provisional Registry

Most entries in the provisional registry carry a blank Status, including entries whose defining document is an ordinary published RFC of a determinate category. Two readings of the column are possible.¶

Section 4.2.2 of [REG-PROC] gives the provisional registration template a Status of "provisional", "updated if and when the header registration is subsequently moved to the permanent registry". On that reading the column in the provisional registry records the standing of the registration, and the correct value for every entry is a constant.¶

The registry does not implement that reading. No entry says "provisional" (the provisionality is carried by which registry the entry is in), and "X-Archived-At" carries "deprecated", a value drawn from the vocabulary of Section 4.2.1. The column in practice records the standing of the document, as in the permanent registry, and is simply unpopulated.¶

This document recommends the second reading, and that it be applied consistently. Under it the following provisional entries take a status from their defining documents:¶

Recording "experimental" or "informational" for these entries carries no implication that they are endorsed; as the registry's own note says, "registration of a Provisional Message Header Field does not of itself imply any kind of endorsement by the IETF, IANA or any other body". The value records what the referenced document is.¶

If IANA or the designated expert prefers the first reading, then the recommendations in Section 4.6 and Section 4.7 for the provisional entries "SIO-Label", "SIO-Label-History" and "MMHS-Authorizing-Users" should be withdrawn along with the table above, and the whole column in that registry set to "provisional". The present position, in which three readings coexist, should not persist.¶

The remaining provisional entries are left blank, deliberately:¶

• "Face", "X-Face" and "X-PGP-Sig" cite informally published specifications that have not been approved by any standards body, so neither branch of Section 4.2.1 of [REG-PROC] supplies a value.¶

• "Form-Sub", "Privicon" and "Wrong-Recipient" cite Internet-Drafts that have expired. An expired draft has no standing from which to derive one.¶

4.9. Fields Deliberately Left Unchanged

The following entries look as though their status might be wrong but are, on inspection, correct; they are called out so the question need not be revisited.¶

• "Organization" is registered as "informational" for protocol "mail" (citing [RFC7681], an Informational document) and as "standard" for protocol "netnews" (citing [NETNEWS-FMT], Standards Track). The two rows are distinct registrations with distinct defining documents, and each reflects the standing of its own document.¶

• The "ARC-Seal", "ARC-Message-Signature", and "ARC-Authentication-Results" fields are registered as "experimental". Their defining document [ARC] is itself Experimental, so the status is correct and should not be changed merely because the fields are widely deployed.¶

• The "Downgraded-*" fields split between "standard" and "obsoleted". The split is correct. [RFC6857] (Standards Track) retained some of the fields first defined by the Experimental [RFC5504] and dropped others, and the registry records that outcome. Note that [RFC5504] was obsoleted by [RFC6530], which withdrew the in-transit downgrade mechanism, and that [RFC6857] lifted RFC 5504's prohibition on registering further "Downgraded-" fields, as the registry's own note records.¶

• "Expires" (mail) is registered as "standard" citing [I-D.ietf-mailmaint-expires]. [RFC4021] had named [MIXER]; the newer document supersedes that definition, and the entry needs no change.¶

6.1. The Test

Section 3.6.7 of [MAIL-OLD] described the trace fields of Internet Mail as an optional "Return-Path" and one or more "Received" fields, and nothing else. That is the text the Trace column is often read against, but [MAIL] has replaced it. Section 3.6.7 of [MAIL] reads:¶

• "The trace fields form a group of header fields that normally includes a 'Return-Path:' field and/or one or more 'Received:' fields or other trace-optional fields that are defined by other specifications as belonging within the trace fields grouping."¶

and continues that "other specifications ... describe the use of other fields that are to be interpreted as trace fields". Section 4.4.4 of [SMTP] is to the same effect: "'Received' and 'Return-path' ... are the only two trace fields that are part of SMTP. Additional trace fields ... may be defined and registered as described in" [MAIL].¶

Klensin asked on the emailcore list on 2022-11-30 whether "defined by other specifications" attached only to "other fields" or to the whole group. Melnikov answered "I thought the former (only 'other fields')", and Resnick, as editor of [MAIL], answered "I believe I intended the former as well, and I'll work on a clarification."¶

The question for the column is therefore whether a specification has designated the field as belonging within the trace fields grouping. Judged that way the column is under-populated, which Section 6.1 of [MAIL] anticipated.¶

Note that Section 6.1 of [MAIL] makes the column applicable only where the Protocol is "mail"; see Section 6.5.¶

6.2. Fields Whose Defining Documents Designate Them Trace Fields

For each of the following fields a specification states, in terms, that the field is a trace field. The Trace column for each should be "yes".¶

• "Received-SPF", Section 9.1 of [SPF]: "The Received-SPF header field is a trace field (see RFC 5322, Section 3.6.7) and SHOULD be prepended to the existing header, above the Received field".¶

• "Authentication-Results", Sections 2.1 and 4.1 of [AUTHRES]: 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". Kucherawy, who registered the field, confirmed the intent on the emailcore list on 2024-03-18: "I registered Authentication-Results and at least one other with the intent that they be treated as trace fields".¶

• "DKIM-Signature", Section 3.5 of [DKIM]: the field "SHOULD be treated as though it were a trace header field as defined in Section 3.6 of RFC 5322 and hence SHOULD NOT be reordered and SHOULD be prepended to the message".¶

• "VBR-Info", [RFC5518], Section 2: "in the terminology of RFC 5322, VBR-Info is a 'trace header field'".¶

• "Auto-Submitted", Section 2.7.1 of [RFC5436]: "The 'Auto-Submitted' header field is considered a 'trace field', similar to 'Received' header fields (see RFC 5321)", and "the 'Auto-Submitted' field MUST be placed above those 'Received' fields, serving as a boundary between the ones from the triggering message" and the notification's own.¶

• "SIO-Label-History", [RFC7444], Section 5: "The SIO-Label-History header field is considered to be a trace field as defined in Section 3.6.7 of RFC 5322". The field records label changes made as the message is handled and is "intended to provide trace information (only trace information)"; each new instance is "added immediately preceding any existing SIO-Label-History header fields", i.e. prepended within the SIO-Label-History group.¶

• "X400-Received", Section 5.3.7 of [MIXER]: "When generating an RFC 822 message all trace fields (X400-Received and Received) shall be at the beginning of the header, before any other fields. Trace shall be in chronological order, with the most recent element at the front of the message." Each "X400-Received" field carries one element of X.400 trace information, and Section 5.1.7 of [MIXER] maps the fields back to that trace information when a message returns to X.400.¶

• "X400-Trace" and "DL-Expansion-History", [RFC4021] and [MIXER]: registered with descriptions that are, respectively, "X400 Trace" and "Trace of distribution lists passed", and derived from the per-hop trace elements of [MIXER], which accumulates one entry per gateway traversal in order.¶

Note that "DKIM-Signature", "VBR-Info" and "Auto-Submitted" are typically added by the originating administrative domain or the responder rather than by a relay. Their authors nonetheless chose the "trace header field" designation for its positional guarantees, and the Trace column should record what the specifications say.¶

6.3. Fields That Behave as Trace Fields Without the Word

A field may be added by a handling agent in transit, at a defined position and with ordering significance, without its defining document using the word "trace". Whether such a field should be marked requires care, because the emailcore list considered and argued against the alternative test of inferring trace status from where a field appears. Klensin observed on 2022-12-02 that [MAIL] as drafted would "allow arbitrary additions to the list of what constitutes such a field with no criteria for such additions other than 'the registrant says it is'", so that "almost any sort of crud (or worse), even potentially undocumented crud, can end up at the top of the header field collection", and gave a real message in which 21 fields preceded the oldest "Received". Melnikov replied on 2022-12-03:¶

• "In general I don't think it is useful to assume that everything above the oldest Received header field is a trace header field. ... I think somebody still needs to initiate registration of a new trace header field. There is no need to register all header fields in your example just because they are above Received header fields."¶

This document accepts that position. Where a field appears in the header section is not evidence of trace status. A specification may, however, designate a field by imposing the positional rules of a trace field without using the word. On that narrower test three groups qualify:¶

• "ARC-Seal", "ARC-Message-Signature" and "ARC-Authentication-Results", [ARC]: added by each participating domain as the message transits, with "i=" instance tags that number the sets in handling order and constitute the "chain of custody"; a validator MUST evaluate them in that order. The ordering is the mechanism of these fields.¶

• "Delivered-To", [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". This is the trace field rule, and the document says as much.¶

• "Original-Recipient", Section 2.3 of [MDN]: "the delivering MTA SHOULD insert an Original-Recipient header field at the beginning of the message (along with the Return-Path header field)", a rule [MDN] carries forward unchanged from [RFC3798].¶

The Trace column for these five should be "yes".¶

6.4. A Field Whose Documented Behaviour Is Trace Behaviour

"Apparently-To" is added by a handling agent in transit, and a specification documents that behaviour, but no specification designates it as a trace field or imposes a positional rule. The caution recorded in Section 6.3 does not reach it. The objection there was to inferring trace status from where fields appear in observed messages, with "no criteria ... other than 'the registrant says it is'". Behaviour that a specification documents is the published record. It is also what a consumer of the Trace column needs to know, since that consumer is asking which fields a handling agent may add to a message in transit. The Trace column for this field should be "yes".¶

Section 3.4 of [RFC2076] records the field as "Inserted by Sendmail when there is no 'To:' recipient in the original message, listing recipients derived from the envelope into the message heading", marks it "Non-standard, discouraged", and adds that "This behavior is not quite proper, MTAs should not modify headings (except inserting Received lines)". The reference is an Informational survey of header fields in use, and it disapproves of the practice it records. Marking the field records what a mail transfer agent is documented to do with it, and does not endorse the practice.¶

6.5. The Trace Column and the Netnews Fields

Two netnews fields are designated as trace fields by their own documents:¶

• "Path", Section 3.1.5 of [NETNEWS-FMT] 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", Section 3.2.8 of [NETNEWS-FMT]: added only by the injecting agent, and existing to assist "in tracing the article's true origin"; [NETNEWS-ARCH] classes it as trace information.¶

The column cannot record this as it stands. Section 6.1 of [MAIL] defines the Trace field as "only applicable if the 'applicable protocol' is set 'mail' (in other cases, it should be set to ' ')".¶

This document therefore does not recommend a Trace value for "Path" or "Injection-Info". It records the evidence, and notes that if the column is to be meaningful for netnews the restriction in Section 6.1 of [MAIL] would have to be relaxed. That is a change to [MAIL] rather than to the registry, and belongs with the netnews and emailcore communities. Leaving the two cells blank is consistent with the reading in Section 1.3, under which blank means "not yet specified".¶

6.6. Fields Deliberately Not Marked Trace

The following fields are added or written by a party other than the original author and so might be mistaken for trace fields, but are correctly left un-marked.¶

• The "Resent-*" fields are recorded as Trace "no" by Section 6.2 of [MAIL]. They are prepended as a block and their order is significant, and [TRACE-REG] proposed marking seven of them as trace fields. [MAIL] nonetheless treats the resent block as distinct from the trace block (Section 3.6 gives them separate productions), and the registry records that choice. This document does not disturb it.¶

• "Solicitation" ([RFC3865]) is supplied by the sending client; Section 2.6 of RFC 3865 states it "is only available to the sending client" and contrasts it explicitly with "the sole exception of the 'Received:' trace field".¶

• "Original-From" and "Original-Subject" ([RFC5703]) are written by a Sieve processor purely to preserve the author's original values when it rewrites the corresponding fields; they carry no positional or ordering semantics.¶

• "Original-Sender" ([NETNEWS-ARCH]) is a gateway-written preservation copy of a "Sender" field, and [NETNEWS-ARCH] deliberately keeps it out of the trace set it defines.¶

• "Require-Recipient-Valid-Since" ([RFC7293]) is generated by the author's domain to carry a delivery request; RFC 7293 discourages the header form entirely.¶

• The "Downgraded-*" fields ([RFC6857]) are added in transit but only to preserve encoded copies of non-trace fields; RFC 6857 explicitly prohibits applying its downgrade procedure to the real trace field "Received".¶

7.1. Specification Documents Named by RFC 4021 but Not Recorded

These entries cite [RFC4021] but not the specification document [RFC4021] named for them. The specification document should be added. The full list is in Appendix B; the distinct documents involved are:¶

Note that [RFC4021] names [MIME1] only for the five core MIME fields, with a distinct section per field; [RFC2046] defines media types rather than these header fields and is not added.¶

7.2. Superseded References

These entries cite a document that has since been obsoleted. The document in force should be added; this document does not recommend removing the historical citation, which remains accurate as to where the field came from.¶

7.3. Missing Formal Updates

These entries fail to cite documents that carry a formal "Updates:" header targeting the field's defining document and that modify the definition of the field. See Section 3.2 for the updaters excluded.¶

8.1. Mechanism

The changes recommended here are a single retroactive update to existing entries, of the kind Crocker proposed and Kucherawy and Resnick supported in the exchange quoted in Section 2.3. They are a collective recommendation, documented and approved through the normal process, in place of a registration action or an RFC per field.¶

Appendix C states the requested end state. It lists every entry in both registries with the Status, Trace and Reference values this document recommends, marking each value that differs from the current registry. Where Appendix C and the prose of this document disagree, the prose governs and the table should be corrected.¶

8.2. Status Changes

• "MT-Priority": "standard" to "informational" (Section 4).¶

• "Solicitation": blank to "standard" (Section 4).¶

• The "List-*" family and "List-ID": blank to "standard" (Section 4.5).¶

• The [RFC4021] cohort: blank to the value [RFC4021] supplied, as tabulated in Appendix B. This is "standard" for the great majority, "experimental" for "Encoding", and "obsoleted" for "Content-Return", "Obsoletes", "Expiry-Date", "Content-Identifier" and "Encrypted" (Section 4.1, Section 4.2).¶

• "SIO-Label", "SIO-Label-History": blank to "informational" (Section 4.6).¶

• The "MMHS-*" fields and "MMHS-Authorizing-Users": blank to "informational" (Section 4.7).¶

• The provisional entries tabulated in Section 4.8: blank to "experimental" or "informational" as listed.¶

8.3. Trace Changes

Set Trace to "yes" for:¶

• "Received-SPF", "Authentication-Results", "DKIM-Signature", "VBR-Info", "Auto-Submitted", "SIO-Label-History", "X400-Received", "X400-Trace", "DL-Expansion-History" (Section 6.2).¶

• "ARC-Seal", "ARC-Message-Signature", "ARC-Authentication-Results", "Delivered-To", "Original-Recipient" (Section 6.3).¶

• "Apparently-To" (Section 6.4).¶

No other Trace value is changed. In particular the cells for "Path" and "Injection-Info" are left blank, because the column is defined only for Protocol "mail" (Section 6.5).¶

8.4. Reference Changes

As tabulated in Section 7, listed per field in Appendix B and Appendix C.¶

10.1. Normative References

[MAIL]

Resnick, P., "Internet Message Format", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis-12, 13 June 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5322bis-12>.

[REG-PROC]

Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/rfc/rfc3864>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4021]

Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, DOI 10.17487/RFC4021, March 2005, <https://www.rfc-editor.org/rfc/rfc4021>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[SMTP]

Klensin, J. C., "Simple Mail Transfer Protocol", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis-44, 31 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-44>.

10.2. Informative References

[ARC]

Andersen, K., Long, B., Ed., Blank, S., Ed., and M. Kucherawy, Ed., "The Authenticated Received Chain (ARC) Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, <https://www.rfc-editor.org/rfc/rfc8617>.

[AUTHRES]

Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, <https://www.rfc-editor.org/rfc/rfc8601>.

[DKIM]

Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/rfc/rfc6376>.

[I-D.ietf-mailmaint-expires]

BILLON, B. and J. R. Levine, "Updated Use of the Expires Message Header Field", Work in Progress, Internet-Draft, draft-ietf-mailmaint-expires-06, 30 April 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-mailmaint-expires-06>.

[LIST-ID]

Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, DOI 10.17487/RFC2919, March 2001, <https://www.rfc-editor.org/rfc/rfc2919>.

[LIST-URLS]

Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, DOI 10.17487/RFC2369, July 1998, <https://www.rfc-editor.org/rfc/rfc2369>.

[MAIL-OLD]

Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/rfc/rfc5322>.

[MDN]

Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, <https://www.rfc-editor.org/rfc/rfc8098>.

[MIME1]

Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/rfc/rfc2045>.

[MIXER]

Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, DOI 10.17487/RFC2156, January 1998, <https://www.rfc-editor.org/rfc/rfc2156>.

[NETNEWS-ARCH]

Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, <https://www.rfc-editor.org/rfc/rfc5537>.

[NETNEWS-FMT]

Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, DOI 10.17487/RFC5536, November 2009, <https://www.rfc-editor.org/rfc/rfc5536>.

[RFC1049]

Sirbu, M., "Content-type header field for Internet messages", RFC 1049, DOI 10.17487/RFC1049, March 1988, <https://www.rfc-editor.org/rfc/rfc1049>.

[RFC1327]

Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, DOI 10.17487/RFC1327, May 1992, <https://www.rfc-editor.org/rfc/rfc1327>.

[RFC1505]

Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1505, DOI 10.17487/RFC1505, August 1993, <https://www.rfc-editor.org/rfc/rfc1505>.

[RFC1864]

Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, DOI 10.17487/RFC1864, October 1995, <https://www.rfc-editor.org/rfc/rfc1864>.

[RFC2046]

Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/rfc/rfc2046>.

[RFC2068]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, DOI 10.17487/RFC2068, January 1997, <https://www.rfc-editor.org/rfc/rfc2068>.

[RFC2076]

Palme, J., "Common Internet Message Headers", RFC 2076, DOI 10.17487/RFC2076, February 1997, <https://www.rfc-editor.org/rfc/rfc2076>.

[RFC2110]

Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, DOI 10.17487/RFC2110, March 1997, <https://www.rfc-editor.org/rfc/rfc2110>.

[RFC2183]

Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, DOI 10.17487/RFC2183, August 1997, <https://www.rfc-editor.org/rfc/rfc2183>.

[RFC2231]

Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, <https://www.rfc-editor.org/rfc/rfc2231>.

[RFC2298]

Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, DOI 10.17487/RFC2298, March 1998, <https://www.rfc-editor.org/rfc/rfc2298>.

[RFC2557]

Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, <https://www.rfc-editor.org/rfc/rfc2557>.

[RFC2616]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <https://www.rfc-editor.org/rfc/rfc2616>.

[RFC2912]

Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, DOI 10.17487/RFC2912, September 2000, <https://www.rfc-editor.org/rfc/rfc2912>.

[RFC3282]

Alvestrand, H., "Content Language Headers", RFC 3282, DOI 10.17487/RFC3282, May 2002, <https://www.rfc-editor.org/rfc/rfc3282>.

[RFC3297]

Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, DOI 10.17487/RFC3297, July 2002, <https://www.rfc-editor.org/rfc/rfc3297>.

[RFC3458]

Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, DOI 10.17487/RFC3458, January 2003, <https://www.rfc-editor.org/rfc/rfc3458>.

[RFC3798]

Hansen, T., Ed. and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, DOI 10.17487/RFC3798, May 2004, <https://www.rfc-editor.org/rfc/rfc3798>.

[RFC3803]

Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, DOI 10.17487/RFC3803, June 2004, <https://www.rfc-editor.org/rfc/rfc3803>.

[RFC3834]

Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, DOI 10.17487/RFC3834, August 2004, <https://www.rfc-editor.org/rfc/rfc3834>.

[RFC3865]

Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, DOI 10.17487/RFC3865, September 2004, <https://www.rfc-editor.org/rfc/rfc3865>.

[RFC3938]

Hansen, T., "Video-Message Message-Context", RFC 3938, DOI 10.17487/RFC3938, October 2004, <https://www.rfc-editor.org/rfc/rfc3938>.

[RFC5436]

Leiba, B. and M. Haardt, "Sieve Notification Mechanism: mailto", RFC 5436, DOI 10.17487/RFC5436, January 2009, <https://www.rfc-editor.org/rfc/rfc5436>.

[RFC5504]

Fujiwara, K., Ed. and Y. Yoneya, Ed., "Downgrading Mechanism for Email Address Internationalization", RFC 5504, DOI 10.17487/RFC5504, March 2009, <https://www.rfc-editor.org/rfc/rfc5504>.

[RFC5518]

Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, <https://www.rfc-editor.org/rfc/rfc5518>.

[RFC5703]

Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", RFC 5703, DOI 10.17487/RFC5703, October 2009, <https://www.rfc-editor.org/rfc/rfc5703>.

[RFC6477]

Melnikov, A. and G. Lunt, "Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail", RFC 6477, DOI 10.17487/RFC6477, January 2012, <https://www.rfc-editor.org/rfc/rfc6477>.

[RFC6530]

Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, <https://www.rfc-editor.org/rfc/rfc6530>.

[RFC6532]

Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/rfc/rfc6532>.

[RFC6533]

Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, <https://www.rfc-editor.org/rfc/rfc6533>.

[RFC6710]

Melnikov, A. and K. Carlberg, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", RFC 6710, DOI 10.17487/RFC6710, August 2012, <https://www.rfc-editor.org/rfc/rfc6710>.

[RFC6758]

Melnikov, A. and K. Carlberg, "Tunneling of SMTP Message Transfer Priorities", RFC 6758, DOI 10.17487/RFC6758, October 2012, <https://www.rfc-editor.org/rfc/rfc6758>.

[RFC6854]

Leiba, B., "Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields", RFC 6854, DOI 10.17487/RFC6854, March 2013, <https://www.rfc-editor.org/rfc/rfc6854>.

[RFC6857]

Fujiwara, K., "Post-Delivery Message Downgrading for Internationalized Email Messages", RFC 6857, DOI 10.17487/RFC6857, March 2013, <https://www.rfc-editor.org/rfc/rfc6857>.

[RFC7293]

Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, July 2014, <https://www.rfc-editor.org/rfc/rfc7293>.

[RFC7444]

Zeilenga, K. and A. Melnikov, "Security Labels in Internet Email", RFC 7444, DOI 10.17487/RFC7444, February 2015, <https://www.rfc-editor.org/rfc/rfc7444>.

[RFC7681]

Davin, J., "Email Exchange of Secondary School Transcripts", RFC 7681, DOI 10.17487/RFC7681, October 2015, <https://www.rfc-editor.org/rfc/rfc7681>.

[RFC7912]

Melnikov, A., "Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure", RFC 7912, DOI 10.17487/RFC7912, June 2016, <https://www.rfc-editor.org/rfc/rfc7912>.

[RFC8255]

Tomkinson, N. and N. Borenstein, "Multiple Language Content Type", RFC 8255, DOI 10.17487/RFC8255, October 2017, <https://www.rfc-editor.org/rfc/rfc8255>.

[RFC8301]

Kitterman, S., "Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)", RFC 8301, DOI 10.17487/RFC8301, January 2018, <https://www.rfc-editor.org/rfc/rfc8301>.

[RFC8315]

Baeuerle, M., "Cancel-Locks in Netnews Articles", RFC 8315, DOI 10.17487/RFC8315, February 2018, <https://www.rfc-editor.org/rfc/rfc8315>.

[RFC8463]

Levine, J., "A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)", RFC 8463, DOI 10.17487/RFC8463, September 2018, <https://www.rfc-editor.org/rfc/rfc8463>.

[RFC8553]

Crocker, D., "DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names", BCP 222, RFC 8553, DOI 10.17487/RFC8553, March 2019, <https://www.rfc-editor.org/rfc/rfc8553>.

[RFC9228]

Crocker, D., Ed., "Delivered-To Email Header Field", RFC 9228, DOI 10.17487/RFC9228, April 2022, <https://www.rfc-editor.org/rfc/rfc9228>.

[SMTP-OLD]

Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/rfc/rfc5321>.

[SPF]

Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/rfc/rfc7208>.

[TRACE-REG]

Moonesamy, S. and J. R. Levine, "Mail Header Trace Fields", Work in Progress, Internet-Draft, draft-levine-trace-header-registry-01, 22 January 2012, <https://datatracker.ietf.org/doc/html/draft-levine-trace-header-registry-01>.

D.1. Since -02

• Section 6.3: "Original-Recipient" added. Section 2.3 of [MDN] retains the placement rule of [RFC3798] unchanged: "the delivering MTA SHOULD insert an Original-Recipient header field at the beginning of the message (along with the Return-Path header field)". -02 treated the rule as confined to [RFC3798] and not carried into the document in force; that was wrong.¶

• Section 6.2: "X400-Received" added. Section 5.3.7 of [MIXER] names it a trace field in terms ("all trace fields (X400-Received and Received)") and places the group at the beginning of the header in chronological order. -02 withdrew the recommendation on the ground that no specification designated the field; the designation was missed.¶

• Section 6.4: the recommendation of Trace "yes" for "Apparently-To", withdrawn in -02, is restored. The emailcore caution recorded in Section 6.3 is against inferring trace status from where fields appear in observed messages; behaviour documented in a specification is the published record, and is what the column's consumers act on. The section quotes Section 3.4 of [RFC2076], including its disapproval of the practice.¶

• Abstract and Section 1.4: state that this document updates [RFC4021], and what the update consists of.¶

• Section 6.2: bracketed citations inside quoted text are rendered as plain RFC numbers, so that they are not read as references of this document.¶

• Editorial: revision-history narration removed from the body text throughout; this change log is the record of what earlier revisions did. The "Auto-Submitted" subsection, which was entirely such narration, is removed.¶

• Editorial: section headings, section citations and back matter follow RFC style, and the prose is simplified throughout. Acknowledgements moved after the appendices.¶

D.2. Since -01

Findings from a systematic re-scan of the RFC series, the two registry exports, and the ietf-822, ietf-smtp, emailcore and ietf-dkim list archives.¶

Corrections to -01:¶

• Section 6.2: "Auto-Submitted" moved there from the not-trace list. Section 2.7.1 of [RFC5436] designates it a trace field in terms and gives it an explicit ordering requirement; -01's reasoning that it "has no positional significance" was wrong.¶

• Section 6.5: the recommendations of Trace "yes" for "Path" and "Injection-Info" are withdrawn. Section 6.1 of [MAIL] makes the column applicable only where Protocol is "mail".¶

• The recommendation of Trace "yes" for "Apparently-To", "Original-Recipient" and "X400-Received" is withdrawn, following the caution against inferring trace status from position recorded in Section 6.3 (restored in -03; see Section 6.2, Section 6.3 and Section 6.4).¶

• Section 7: [RFC2046] is no longer proposed for the five core MIME fields; [RFC4021] names [MIME1] alone. [RFC2231] and [RFC6532] are added instead, being the formal updaters of [MIME1].¶

• Section 7: the proposal to add [RFC3798] to "Disposition-Notification-To" and "-Options" is replaced by [MDN], which obsoletes it. Likewise "Original-Recipient" gains [MDN] as well as [RFC6533]; -01 did not note that both of its current references are obsolete.¶

• Section 1.3: a blank Trace cell means "not yet specified", per [MAIL] Section 6.1 and IANA's agreement as reported by Resnick. -01 described the column as reading "not a trace field", which overstated the problem.¶

• Section 4.9: [RFC5504] was obsoleted by [RFC6530], not by [RFC6857].¶

Additions:¶

• Section 1.1, Section 4.1, Appendix B (new): [RFC4021] supplied an explicit Status and Specification document for every field it registered, and neither reached the registry. -01 stated that [RFC4021] "set out to record the existence of these historical fields, not to rule on their standing"; that was wrong. The whole cohort is now covered, including the X.400/MIXER fields that -01 left alone as too large an undertaking.¶

• Section 4.2 (new): the five fields [RFC4021] marked "obsolete" whose only definition is in an obsoleted document.¶

• Section 1.2 (new): the documented origin of the "standard" versus "standards-track" divergence between [RFC4021] and [NETNEWS-FMT], from the ietf-822 discussion of 2004.¶

• Section 2 (new): [TRACE-REG], the emailcore discussion that created the Trace column, and the 2024 exchange establishing the route this document follows.¶

• Section 4.8 (new): a consistent rule for Status in the provisional registry, applied to fifteen further entries, with the conflicting reading in Section 4.2.2 of [REG-PROC] set out.¶

• Section 3: the Status test is now anchored in Section 4.2.1 of [REG-PROC], and the Trace test in Section 3.6.7 of [MAIL] and Section 4.4.4 of [SMTP], rather than argued from first principles.¶

• Section 3.2 (new): [RFC8553] and [RFC8315] are formal updaters that are deliberately not added, with the reason recorded.¶

• Section 7: reference additions for "Content-Disposition" ([RFC2183], [RFC2231]) and "Message-Context" ([RFC3938]), missed in -01.¶

• Section 3.3: [RFC1049] named explicitly.¶

• Section 6.6: the "Resent-*" fields, recorded as "no" by [MAIL] although [TRACE-REG] proposed otherwise.¶

• Section 8: a Mechanism subsection.¶

• Normative references changed from [MAIL-OLD] and [SMTP-OLD] to [MAIL] and [SMTP], which are the documents that now govern the registries.¶

D.3. Since -00

• Section 4.1: removed the suggestion that the X.400/MIXER gateway fields might be better recorded as "obsoleted". These fields remain in use in the environments that rely on that gateway work.¶

• Section 4.6 (new): "SIO-Label" and "SIO-Label-History" Status corrected from blank to "informational".¶

• Section 4.7 (new): the fourteen "MMHS-*" fields (RFC 6477) and "MMHS-Authorizing-Users" (RFC 7912) Status corrected from blank to "informational".¶

• Section 6.2: added "SIO-Label-History".¶

• Added "Apparently-To" as a trace field (withdrawn in -02, restored in -03).¶