| Internet-Draft | Header Field Registry Maintenance | July 2026 |
| Gondwana | Expires 23 January 2027 | [Page] |
The IANA "Message Headers" registries record, for each registered header field, the protocol it belongs to, its status, whether it is a trace field, and the document(s) that specify it. These registries were populated incrementally by many documents over more than two decades, and the instructions those documents gave to IANA were not consistent with one another. As a result the registries no longer present a reliable picture of the relative status or usage of the fields they contain: fields of equal standing carry different status values, foundational fields appear less classified than minor ones, the "trace" property is recorded for only a fraction of the fields whose defining documents describe them as trace fields, and the reference column frequently points at a later registration document rather than at the document that actually defines or updates the field. This reduces the value of the metadata to the point where a reader cannot use it to reason about a field with confidence.¶
This document reviews the initial definition of, and every subsequent update to, each registered header field, and gives IANA a single, coherent set of instructions for correcting each registry entry. Every recommended change, and every deliberate decision to leave a non-obvious entry unchanged, is justified by reference to the clear intent of the authors of the source documents in which the field was defined or modified.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The IANA "Message Headers" registry group [REG-PROC] contains three registries: "Permanent Message Header Field Names", "Provisional Message Header Field Names", and "Content-Translation-Type Header Field Values". For each entry the permanent and provisional registries record five pieces of metadata beyond the field name: an optional registration template, the "Protocol" the field belongs to (for example "mail", "MIME", "netnews", or "none"), a "Status" (for example "standard", "informational", "experimental", "obsoleted", "deprecated", or blank), a "Trace" flag, and a "Reference" listing the specifying document(s).¶
The registration procedures in [REG-PROC] were designed so that this metadata would let a reader assess, at a glance, what a field is for, how authoritative it is, and where to read about it. In practice that promise has not been kept. The registries were populated incrementally by a long series of documents, each of which supplied its own registration instructions, and those instructions were not consistent with one another:¶
The "Status" column is applied unevenly. Foundational fields imported in bulk by [RFC4021] were registered with no status at all, while later fields of equal or lesser standing were registered as "standard". A reader comparing two entries cannot tell whether a blank status means "not standards track", "status not asserted", or simply "registered before anyone recorded a status".¶
At least one field records a status that contradicts the standing of the document that defines it.¶
The "Trace" column was populated only for the fields re-registered by the ongoing revision of [MAIL]. Fields whose own defining documents describe them, in terms, as trace fields carry a blank Trace column, so the column reads as "not a trace field" for fields that their authors plainly intended to be trace fields.¶
The "Reference" column frequently cites the document that most recently registered a field rather than the document that defines it, and rarely reflects later documents that formally update the definition. A reader who follows the reference is sent to a registration stub instead of to the specification.¶
The cumulative effect is that the metadata cannot be relied upon. Two entries that look different may be equivalent, and two that look equivalent may not be. The registries still serve as a name-collision-avoidance list, which is their irreducible function, but the additional metadata that was meant to make them useful has lost most of its value.¶
This document reviews the initial definition of, and every subsequent update to, each registered header field, and provides IANA with a clear instruction for each entry. The recommendations are derived from the clear intent of the authors of the source documents in which each field was defined or modified, not from any new opinion of this document's author about how the fields ought to behave. Where the intent of the source documents is not abundantly obvious, this document explains its reasoning for the change; and where an entry looks wrong but is on inspection correct, this document explains its reasoning for leaving it unchanged, so that the analysis need not be repeated by the next reader.¶
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 defining and updating documents already imply.¶
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 [MAIL], Section 3.6.7 and [SMTP], Section 4.4, extended as described in Section 5.¶
Three questions were asked of every registry entry, corresponding to the three classification columns.¶
In which protocol's messages is the field defined to appear? This was taken from the section of the defining document in which the field is registered, not inferred from the field's name.¶
What is the standing of the field? A field is treated as "standard" when it is defined by a document on the Standards Track (or an equivalent IESG-approved specification) that is the current definition; "informational" or "experimental" when its current defining document is of that category; "obsoleted" or "deprecated" when a later document in force says so. The controlling fact is the category and standing of the defining document, as stated on that document's own front page.¶
Did the authors of the defining document intend the field to be a trace field -- that is, a field added to a message by a handling agent as the message is processed, placed at a defined position (normally prepended), and not reordered? The strongest evidence is a document that says so in terms; the next strongest is a document that imports the trace-field rules of [MAIL] or [SMTP] without using the word. See Section 5.¶
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. Two independent signals were combined to find these documents exhaustively across the entire published RFC series:¶
The formal "Updates:" metadata. Every RFC that carries an "Updates: N" header in its front matter was recorded as an updater of RFC N. This yields an authoritative, machine-checkable graph of which documents the community has formally declared to modify which others. For example, RFC 8301, RFC 8463, and RFC 8616 each carry "Updates: 6376" and therefore update the definition of the "DKIM-Signature" field, none of which the registry currently cites.¶
A header-field mention scan. Every RFC in the series was scanned for use of each registered field name in header-field position. This locates documents that specify or extend a field without a formal "Updates:" relationship (for example the document that originally defined a field later re-registered by [RFC4021]).¶
A reference addition is proposed where a document either formally updates a field's defining document, or is the original defining document that the registry fails to cite.¶
The mention scan is reliable for fields whose names are distinctive (hyphenated names, or names that are not ordinary English words): for these, the set of documents using the name is small and almost entirely relevant. It is not reliable for fields whose names are common words or common protocol tokens. "Comments", "To", "From", "Subject", "Received", "Content-Type", and similar names appear in thousands of documents, overwhelmingly in examples or in unrelated prose, and no purely textual filter separates a genuine specification from an incidental mention. For those fields the reference set was determined from the known specification lineage and confirmed against the formal "Updates:" graph, which does not suffer from this ambiguity. This limitation is called out because it bears directly on any attempt to regenerate the registries mechanically: the "Updates:" graph can be trusted; an unfiltered text search cannot.¶
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, not a header field. The field's status should therefore be "informational", matching the standing of the only document that defines it.¶
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".¶
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. RFC 4021 did not define these fields; it re-registered them. They are defined by [LIST-URLS], a Standards Track document whose title is "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields" and whose Section 3 specifies each field. Likewise "List-ID" is registered with blank Status and Reference [RFC4021], but is defined by [LIST-ID], the Standards Track "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists".¶
For all seven fields the Status should be "standard" and the Reference should cite the true defining document ([LIST-URLS] or [LIST-ID] respectively) in addition to [RFC4021]. This is the clearest illustration of the general problem: the registry currently sends a reader to a registration stub and records no status, when a Standards Track definition exists and has done since 1998.¶
[RFC4021] imported roughly sixty mail and MIME fields into the permanent registry in a single Standards Track document, and registered every one of them with a blank Status. The blank was, at the time, a reasonable choice: RFC 4021 set out to record the existence of these historical fields, not to rule on their standing. Two decades later the blanks are actively misleading, because many of the imported fields are core elements of full Internet Standards while others are vestigial X.400 gateway fields, and the registry gives the reader no way to tell them apart.¶
This document does not recommend mechanically stamping the entire cohort "standard". Many of these fields (the "X400-" family, "Discarded-X400-", "DL-Expansion-History", "Deferred-Delivery", "Latest-Delivery-Time", and similar) derive from the X.400/MIXER mapping work [RFC2156] and are specialised gateway fields rather than general-use Internet Mail fields. They remain in use in the environments that rely on that gateway work, so this document does not recommend changing their status; settling an appropriate status for each on its individual merits is a larger undertaking than this revision attempts, and the entries are left unchanged.¶
It does recommend correcting the core MIME fields, whose standing is not in doubt. "MIME-Version", "Content-Type", "Content-Transfer-Encoding", "Content-ID", and "Content-Description" are defined by [MIME1] and [MIME2] -- long-standing Internet Standards-track documents -- yet are registered with blank Status and with a Reference that cites only the registration document [RFC4021] (and, for "Content-Type", [RFC9788]). These five fields should be Status "standard", and their References should cite [MIME1] and [MIME2] as their defining documents. Leaving a peer field such as "Content-Translation-Type" ([RFC8255]) recorded as "standard" while the MIME fields it sits beside are blank is precisely the inconsistency this document exists to remove.¶
The "SIO-Label" and "SIO-Label-History" mail fields are both registered with a blank Status, citing [RFC7444]. RFC 7444 is an Informational document -- its front page states it is not an Internet Standards Track specification -- 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 2, the Status of both fields should be "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, each stating on its front page that it is not an Internet Standards Track specification, and each is the document that registers the fields it covers for use in Internet Mail. Applying the methodology of Section 2, the Status of every one of these fields should be "informational".¶
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). This is not an inconsistency: the two rows are distinct registrations with distinct defining documents, and each row correctly 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 MUST NOT be "promoted" merely because the fields are widely deployed.¶
The "Downgraded-*" fields split between "standard" and "obsoleted". This split is deliberate and correct: [RFC6857] (Standards Track) retained some of the fields first defined by the Experimental [RFC5504] and dropped others, and the registry records exactly that outcome.¶
Review of the defining documents found no header field recorded under the wrong protocol. Two entries that appear misfiled are in fact correct, and are documented here to forestall future "corrections".¶
"Content-Return" and "Content-Identifier" are registered under protocol "mail", although every other "Content-*" field is registered under "MIME". This is correct. [RFC4021] places both fields in its Section 2.1, "Permanent Mail Header Field Registrations", not in its Section 2.2 for MIME fields, because they are X.400 IPMS heading fields carried in the message header, not MIME body-part fields. The registry faithfully mirrors the defining document's own division.¶
"User-Agent" (netnews) cites [RFC2616] and "Base" (MIME) cites [RFC2068], both of which are HTTP specifications. These citations are for syntax heritage only and do not indicate a protocol misclassification; the fields are correctly filed under "netnews" and "MIME" respectively.¶
[MAIL], Section 3.6.7 defines the trace fields of Internet Mail as an optional "Return-Path" and one or more "Received" fields. The IANA "Trace" column, however, is a per-field property, and several later documents explicitly designate their own fields as trace fields by importing the rules of [MAIL] or [SMTP]. The controlling question for the column is therefore not "is this one of the two fields listed in Section 3.6.7" but "did the field's defining document designate it a trace field". Judged that way, the column is substantially under-populated: it is set only for the fields re-registered by the revision of [MAIL], and blank for every field whose trace nature is stated in a different document.¶
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].¶
"SIO-Label-History" (mail), [RFC7444], Section 5: "The SIO-Label-History header field is considered to be a trace field as defined in Section 3.6.7 of [RFC5322]". 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.¶
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.¶
The following fields are added by handling agents in transit, typically at a defined position and 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)".¶
"X400-Received" (mail), [RFC4021]: the X.400/MIXER gateway equivalent of "Received".¶
"Apparently-To" (mail), [RFC2076], Section 3.4: inserted by a mail transfer agent on delivery, when the original message carries no "To" recipient ("Inserted by Sendmail when there is no 'To:' recipient in the original message, listing recipients derived from the envelope into the message heading"). A field added by a handling agent as the message is delivered is a trace field in the sense used here, so the Trace column should be "yes". It is listed in this section rather than in Section 5.1 only because its sole reference, the [RFC2076] survey, does not itself use the word "trace" (and in fact records the behaviour as non-standard).¶
The following fields are added by a party other than the original author and so might be mistaken for trace fields, but are correctly left un-marked because they are content-preservation or originator-supplied fields, not transit-inserted positional fields:¶
"Solicitation" ([RFC3865]) is supplied by the sending client; RFC 3865 Section 2.6 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.¶
"Auto-Submitted" ([RFC3834]) is set by the automatic responder that originates the message, may appear at most once, and has no positional significance.¶
"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".¶
Applying the methodology of Section 2 field by field, the reference corrections fall into two groups.¶
These entries cite a later registration document but not the document that defines the field. The defining document SHOULD be added (and, as noted in Section 3, the Status corrected to match its standing):¶
| Field(s) | Currently cites | Add defining document |
|---|---|---|
| List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner, List-Archive | RFC 4021 | RFC 2369 |
| List-ID | RFC 4021 | RFC 2919 |
| MIME-Version, Content-Type, Content-Transfer-Encoding, Content-ID, Content-Description | RFC 4021 (+ RFC 9788) | RFC 2045, RFC 2046 |
These entries fail to cite documents that carry a formal "Updates:" header targeting the field's defining document. Each addition below was confirmed from the "Updates:" graph:¶
| Field | Cites | Add (formal updaters) |
|---|---|---|
| DKIM-Signature | RFC 6376 | RFC 8301, RFC 8463, RFC 8616 |
| Received-SPF | RFC 7208 | RFC 7372, RFC 8616 |
| Original-Recipient | RFC 3798, RFC 5337 | RFC 6533 |
| Disposition-Notification-To, Disposition-Notification-Options | RFC 4021 | RFC 3798, RFC 8098 |
| Auto-Submitted | RFC 3834 | RFC 5436 |
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 (the revision of [MAIL], with [RFC6854] where the group syntax applies, and [SMTP] for the two SMTP trace fields). The long chain of obsoleted predecessors -- RFC 822, RFC 2822, and for some fields RFC 561, RFC 724, RFC 733, RFC 1036, RFC 1123 -- is deliberately *not added. The Reference column is meant to point a reader at the definition in force, and a registry entry that listed every obsoleted ancestor would be less useful, not more. This is the one place where "every RFC that ever touched the field" is the wrong answer, and it is recorded here so the omission is understood to be intentional.¶
Appendix C records, for every registered field, the reference set that results from applying Section 2. Where that set differs from the current registry Reference column, the difference is one of the corrections tabulated above; where it does not differ, the current Reference is confirmed as complete.¶
IANA is requested to update the "Permanent Message Header Field Names" and "Provisional Message Header Field Names" registries as follows. The changes are metadata only; no field is added, removed, or renamed.¶
Status changes:¶
"MT-Priority": change Status from "standard" to "informational" (Section 3).¶
"Solicitation": change Status from blank to "standard" (Section 3).¶
"List-Help", "List-Subscribe", "List-Unsubscribe", "List-Post", "List-Owner", "List-Archive", "List-ID": change Status from blank to "standard" (Section 3.3).¶
"MIME-Version", "Content-Type", "Content-Transfer-Encoding", "Content-ID", "Content-Description": change Status from blank to "standard" (Section 3.4).¶
"SIO-Label", "SIO-Label-History": change Status from blank to "informational" (Section 3.5).¶
The "MMHS-*" fields and "MMHS-Authorizing-Users": change Status from blank to "informational" (Section 3.6).¶
Trace changes (set Trace to "yes"):¶
"Received-SPF", "Authentication-Results", "DKIM-Signature", "VBR-Info", "Path", "Injection-Info", "X400-Trace", "DL-Expansion-History", "SIO-Label-History" (Section 5.1).¶
Subject to the interpretation discussed in Section 5.2: the "ARC-*" fields, "Delivered-To", "Original-Recipient", "X400-Received", and "Apparently-To".¶
Reference changes: as tabulated in Section 6 and detailed per field in Appendix C.¶
This document changes registry metadata only and introduces no protocol behaviour. Accurate metadata has a modest positive security effect: several of the fields whose Trace status is corrected here ("Received-SPF", "Authentication-Results", "DKIM-Signature", "ARC-*") carry the results of message authentication checks, and a reader or implementer who consults the registry benefits from an accurate record that these are trace fields whose position in the header is significant and must be preserved. No new information is disclosed by any change in this document.¶
Thanks to Alexey Melnikov for reviewing this work and for feedback on the classification of several fields -- including the X.400 gateway fields, the "MMHS-*" family, and "SIO-Label" and "SIO-Label-History" -- drawing in part on his direct knowledge as an author of several of the documents on whose intent this memo relies.¶
The determinations in this document were produced from the published RFC series by two mechanical passes whose results were then reviewed by hand:¶
An "Updates:" graph built from the front-matter "Updates:" line of every RFC, giving an authoritative list of which documents formally modify which others.¶
A header-field mention index built by scanning every RFC for each registered field name in header-field position.¶
The reference set for a field is its current defining document(s) together with every document that formally updates a defining document. As noted in Section 2, the mention index is authoritative only for fields with distinctive names; for common-word field names the reference set was taken from the known specification lineage and cross-checked against the "Updates:" graph, which is unaffected by the ambiguity of common words.¶
This appendix lists every entry in the permanent and provisional registries in the state recommended by this document. In the Status, Trace, and Reference columns, bold marks a value that differs from the current registry: a bold Status or Trace is a recommended change from Section 3 or Section 5, and a bold reference is an addition per Section 6. A non-bold value is confirmed unchanged.¶
As set out in Section 2, reference additions were derived from the formal "Updates:" graph and the header-field mention index; for common-word field names the mention index is unreliable and the reference set was confirmed against the "Updates:" graph and the known specification lineage. Entries whose only specification is a non-RFC document (for example the "Face" and "X-Face" fields) are shown as "(non-RFC ref)".¶
| Field | Proto | Status | Trace | Reference (bold = added) |
|---|---|---|---|---|
| Accept-Language | — | — | RFC 4021 | |
| Also-Control | netnews | obsoleted | — | RFC 1849, RFC 5536 |
| Alternate-Recipient | — | — | RFC 4021 | |
| Approved | netnews | standard | — | RFC 5536 |
| ARC-Authentication-Results | experimental | yes | RFC 8617 | |
| ARC-Message-Signature | experimental | yes | RFC 8617 | |
| ARC-Seal | experimental | yes | RFC 8617 | |
| Archive | netnews | standard | — | RFC 5536 |
| Archived-At | standard | — | RFC 5064 | |
| Archived-At | netnews | standard | — | RFC 5064 |
| Article-Names | netnews | obsoleted | — | RFC 1849, RFC 5536 |
| Article-Updates | netnews | obsoleted | — | RFC 1849, RFC 5536 |
| Authentication-Results | standard | yes | RFC 8601 | |
| Auto-Submitted | standard | — | RFC 3834, RFC 5436 | |
| Autoforwarded | — | — | RFC 4021 | |
| Autosubmitted | — | — | RFC 4021 | |
| Base | MIME | obsoleted | — | RFC 1808, RFC 2068 |
| Bcc | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Body | none | reserved | — | RFC 6068 |
| Cancel-Key | netnews | standard | — | RFC 8315 |
| Cancel-Lock | netnews | standard | — | RFC 8315 |
| Cc | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Comments | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Comments | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Content-Alternative | MIME | — | — | RFC 4021 |
| Content-Base | MIME | obsoleted | — | RFC 2110, RFC 2557 |
| Content-Description | MIME | standard | — | RFC 4021, RFC 2045, RFC 2046 |
| Content-Disposition | MIME | — | — | RFC 4021 |
| Content-Duration | MIME | — | — | RFC 4021 |
| Content-features | MIME | — | — | RFC 4021 |
| Content-ID | MIME | standard | — | RFC 4021, RFC 2045, RFC 2046 |
| Content-Identifier | — | — | RFC 4021 | |
| Content-Language | MIME | — | — | RFC 4021 |
| Content-Location | MIME | — | — | RFC 4021 |
| Content-MD5 | MIME | — | — | RFC 4021 |
| Content-Return | — | — | RFC 4021 | |
| Content-Transfer-Encoding | MIME | standard | — | RFC 4021, RFC 2045, RFC 2046 |
| Content-Translation-Type | MIME | standard | — | RFC 8255 |
| Content-Type | MIME | standard | — | RFC 4021, RFC 9788, RFC 2045, RFC 2046 |
| Control | netnews | standard | — | RFC 5536 |
| Conversion | — | — | RFC 4021 | |
| Conversion-With-Loss | — | — | RFC 4021 | |
| DL-Expansion-History | — | yes | RFC 4021 | |
| Date | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Date | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Date-Received | netnews | obsoleted | — | RFC 850, RFC 5536 |
| Deferred-Delivery | — | — | RFC 4021 | |
| Delivery-Date | — | — | RFC 4021 | |
| Discarded-X400-IPMS-Extensions | — | — | RFC 4021 | |
| Discarded-X400-MTS-Extensions | — | — | RFC 4021 | |
| Disclose-Recipients | — | — | RFC 4021 | |
| Disposition-Notification-Options | — | — | RFC 4021, RFC 3798, RFC 8098 | |
| Disposition-Notification-To | — | — | RFC 4021, RFC 3798, RFC 8098 | |
| Distribution | netnews | standard | — | RFC 5536 |
| DKIM-Signature | standard | yes | RFC 6376, RFC 8301, RFC 8463, RFC 8616 | |
| Downgraded-Bcc | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Cc | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Disposition-Notification-To | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Final-Recipient | standard | — | RFC 6857 | |
| Downgraded-From | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-In-Reply-To | standard | — | RFC 6857 | |
| Downgraded-Mail-From | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Message-Id | standard | — | RFC 6857 | |
| Downgraded-Original-Recipient | standard | — | RFC 6857 | |
| Downgraded-Rcpt-To | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-References | standard | — | RFC 6857 | |
| Downgraded-Reply-To | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-Bcc | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-Cc | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-From | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-Reply-To | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-Sender | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-To | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Return-Path | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Sender | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-To | obsoleted | — | RFC 5504, RFC 6857 | |
| Encoding | — | — | RFC 4021 | |
| Encrypted | — | — | RFC 4021 | |
| Expires | standard | — | draft-ietf-mailmaint-expires | |
| Expires | netnews | standard | — | RFC 5536 |
| Expiry-Date | — | — | RFC 4021 | |
| Followup-To | netnews | standard | — | RFC 5536 |
| From | standard | no | RFC 6854, draft-ietf-emailcore-rfc5322bis | |
| From | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Generate-Delivery-Report | — | — | RFC 4021 | |
| HP-Outer | standard | — | RFC 9788 | |
| Importance | — | — | RFC 4021 | |
| In-Reply-To | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Incomplete-Copy | — | — | RFC 4021 | |
| Injection-Date | netnews | standard | — | RFC 5536 |
| Injection-Info | netnews | standard | yes | RFC 5536 |
| Keywords | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Keywords | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Language | — | — | RFC 4021 | |
| Latest-Delivery-Time | — | — | RFC 4021 | |
| Lines | netnews | deprecated | — | RFC 5536, RFC 3977 |
| List-Archive | standard | — | RFC 4021, RFC 2369 | |
| List-Help | standard | — | RFC 4021, RFC 2369 | |
| List-ID | standard | — | RFC 4021, RFC 2919 | |
| List-Owner | standard | — | RFC 4021, RFC 2369 | |
| List-Post | standard | — | RFC 4021, RFC 2369 | |
| List-Subscribe | standard | — | RFC 4021, RFC 2369 | |
| List-Unsubscribe | standard | — | RFC 4021, RFC 2369 | |
| List-Unsubscribe-Post | standard | — | RFC 8058 | |
| Message-Context | — | — | RFC 4021 | |
| Message-ID | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Message-ID | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Message-Type | — | — | RFC 4021 | |
| MIME-Version | MIME | standard | — | RFC 4021, RFC 2045, RFC 2046 |
| MMHS-Exempted-Address | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Extended-Authorisation-Info | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Subject-Indicator-Codes | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Handling-Instructions | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Message-Instructions | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Codress-Message-Indicator | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Originator-Reference | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Primary-Precedence | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Copy-Precedence | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Message-Type | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Other-Recipients-Indicator-To | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Other-Recipients-Indicator-CC | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Acp127-Message-Identifier | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Originator-PLAD | informational | — | RFC 6477, (non-RFC ref) | |
| MT-Priority | informational | — | RFC 6758 | |
| Newsgroups | netnews | standard | — | RFC 5536 |
| NNTP-Posting-Date | netnews | obsoleted | — | RFC 5536 |
| NNTP-Posting-Host | netnews | obsoleted | — | RFC 2980, RFC 5536 |
| Obsoletes | — | — | RFC 4021 | |
| Organization | informational | — | RFC 7681 | |
| Organization | netnews | standard | — | RFC 5536 |
| Original-Encoded-Information-Types | — | — | RFC 4021 | |
| Original-From | standard | — | RFC 5703 | |
| Original-Message-ID | — | — | RFC 4021 | |
| Original-Recipient | standard | yes | RFC 3798, RFC 5337, RFC 6533 | |
| Original-Sender | netnews | standard | — | RFC 5537 |
| Originator-Return-Address | — | — | RFC 4021 | |
| Original-Subject | standard | — | RFC 5703 | |
| Path | netnews | standard | yes | RFC 5536 |
| PICS-Label | — | — | RFC 4021 | |
| Posting-Version | netnews | obsoleted | — | RFC 850, RFC 5536 |
| Prevent-NonDelivery-Report | — | — | RFC 4021 | |
| Priority | — | — | RFC 4021 | |
| Received | standard | yes | draft-ietf-emailcore-rfc5322bis, draft-ietf-emailcore-rfc5321bis | |
| Received-SPF | standard | yes | RFC 7208, RFC 7372, RFC 8616 | |
| References | standard | no | draft-ietf-emailcore-rfc5322bis | |
| References | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Relay-Version | netnews | obsoleted | — | RFC 850, RFC 5536 |
| Reply-By | — | — | RFC 4021 | |
| Reply-To | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Reply-To | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Require-Recipient-Valid-Since | standard | — | RFC 7293 | |
| Resent-Bcc | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-Cc | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-Date | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-From | standard | no | RFC 6854, draft-ietf-emailcore-rfc5322bis | |
| Resent-Message-ID | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-Reply-To | obsoleted | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-Sender | standard | no | RFC 6854, draft-ietf-emailcore-rfc5322bis | |
| Resent-To | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Return-Path | standard | yes | draft-ietf-emailcore-rfc5322bis, draft-ietf-emailcore-rfc5321bis | |
| See-Also | netnews | obsoleted | — | RFC 1849, RFC 5536 |
| Sender | standard | no | RFC 6854, draft-ietf-emailcore-rfc5322bis | |
| Sender | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Sensitivity | — | — | RFC 4021 | |
| Solicitation | standard | — | RFC 3865 | |
| Subject | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Subject | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Summary | netnews | standard | — | RFC 5536 |
| Supersedes | — | — | RFC 4021 | |
| Supersedes | netnews | standard | — | RFC 5536, RFC 2156 |
| TLS-Report-Domain | standard | — | RFC 8460 | |
| TLS-Report-Submitter | standard | — | RFC 8460 | |
| TLS-Required | standard | — | RFC 8689 | |
| To | standard | no | draft-ietf-emailcore-rfc5322bis | |
| User-Agent | netnews | standard | — | RFC 5536, RFC 2616 |
| VBR-Info | standard | yes | RFC 5518 | |
| X400-Content-Identifier | — | — | RFC 4021 | |
| X400-Content-Return | — | — | RFC 4021 | |
| X400-Content-Type | — | — | RFC 4021 | |
| X400-MTS-Identifier | — | — | RFC 4021 | |
| X400-Originator | — | — | RFC 4021 | |
| X400-Received | — | yes | RFC 4021 | |
| X400-Recipients | — | — | RFC 4021 | |
| X400-Trace | — | yes | RFC 4021 | |
| Xref | netnews | standard | — | RFC 5536 |
| Apparently-To | — | yes | RFC 2076 | |
| Author | — | — | RFC 9057 | |
| CFBL-Address | — | — | RFC 9477 | |
| CFBL-Feedback-ID | — | — | RFC 9477 | |
| Delivered-To | — | yes | RFC 9228 | |
| EDIINT-Features | — | — | RFC 6017 | |
| Eesst-Version | — | — | RFC 7681 | |
| Errors-To | — | — | RFC 2076 | |
| Face | — | — | (non-RFC ref) | |
| Face | netnews | — | — | (non-RFC ref) |
| Form-Sub | — | — | draft-levine-mailbomb-header-00 | |
| Jabber-ID | — | — | RFC 7259 | |
| Jabber-ID | netnews | — | — | RFC 7259 |
| MMHS-Authorizing-Users | informational | — | RFC 7912 | |
| Privicon | — | — | draft-koenig-privicons-01 | |
| SIO-Label | informational | — | RFC 7444 | |
| SIO-Label-History | informational | yes | RFC 7444 | |
| Wrong-Recipient | — | — | draft-ietf-mailmaint-wrong-recipient-00 | |
| X-Archived-At | deprecated | — | RFC 5064 | |
| X-Archived-At | netnews | deprecated | — | RFC 5064 |
| X-Face | — | — | (non-RFC ref) | |
| X-Face | netnews | — | — | (non-RFC ref) |
| X-Mittente | — | — | RFC 6109 | |
| X-PGP-Sig | netnews | — | — | (non-RFC ref), (non-RFC ref) |
| X-Ricevuta | — | — | RFC 6109 | |
| X-Riferimento-Message-ID | — | — | RFC 6109 | |
| X-TipoRicevuta | — | — | RFC 6109 | |
| X-Trasporto | — | — | RFC 6109 | |
| X-VerificaSicurezza | — | — | RFC 6109 |
Section 3.4: removed the suggestion that the X.400/MIXER gateway fields (the "X400-" family, "Discarded-X400-", "DL-Expansion-History", and similar) might be better recorded as "obsoleted". These fields remain in use in the environments that rely on that gateway work, and their status is left unchanged.¶
Section 3.5 (new): "SIO-Label" and "SIO-Label-History" Status corrected from blank to "informational", matching their Informational defining document RFC 7444.¶
Section 3.6 (new): the fourteen "MMHS-*" fields (RFC 6477) and "MMHS-Authorizing-Users" (RFC 7912) Status corrected from blank to "informational", matching their Informational defining documents.¶
Section 5.1: added "SIO-Label-History", whose defining document (RFC 7444, Section 5) states in terms that it is a trace field.¶
Section 5.2: added "Apparently-To", inserted by a mail transfer agent on delivery (RFC 2076, Section 3.4).¶