| Internet-Draft | Header Field Registry Maintenance | July 2026 |
| Gondwana | Expires 30 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 metadata that reached the registries is in several respects less complete than the metadata the registering documents supplied. Most notably, the document that performed the single largest bulk registration, RFC 4021, gave IANA an explicit status and an explicit specification document for every one of the roughly ninety fields it registered, and neither was recorded: those entries carry a blank status and cite RFC 4021 itself rather than the specification. Separately, the "Trace" column added to both registries by the ongoing revision of RFC 5322 was deliberately left empty for pre-existing entries, to be filled in later.¶
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 completing and correcting each registry entry. Every recommended change, and every deliberate decision to leave a non-obvious entry unchanged, is justified by reference to the instructions already given by, or 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 30 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).¶
Both registries name two governing documents: [REG-PROC], which created them, and [MAIL], which added the "Trace" column.¶
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 the registries do not yet deliver that, for two quite different reasons.¶
[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 single largest source of missing metadata in either registry, and it is not a matter of judgement: the values are recoverable verbatim from [RFC4021].¶
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.¶
[MAIL], Section 6.1 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", not "not a trace field". The column is unfinished by design, and this document supplies the material to finish it.¶
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 registration instructions already given by, and 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 that intent is not abundantly obvious, this document explains its reasoning; 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 registering, defining, and updating documents already supply or 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.¶
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 exactly 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.¶
The present 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 binary flag, because that is the column [MAIL] defined, rather than [TRACE-REG]'s richer "MTA/MUA/MSA/MDA" value. And it covers the Status and Reference columns as well as Trace.¶
Where the two agree, [TRACE-REG] is the earlier statement of the position, and this document notes the overlap rather than claiming novelty. In particular [TRACE-REG] identified both the Auto-Submitted trace designation and the incompleteness of that field's Reference column; see Section 6.3.¶
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.4).¶
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.¶
Three questions were asked of every registry entry, corresponding to the three classification columns. Where [RFC4021] registered the field, its template answers the first two directly, and the template is preferred to any inference.¶
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? Section 4.2.1 of [REG-PROC] settles the rule: the value follows "the type and status of the primary document in which it is defined". A field is therefore "standard" when the document that currently defines it is on the Standards Track at any maturity level (or is an equivalent IESG-approved specification, or a specification formally approved by another standards body); "informational" or "experimental" when its current defining document is of that category; and "obsoleted" when a later document in force says so, or when the document that defined it has been replaced by one that drops it. As set out in Section 1.2, [RFC4021]'s "standards-track" is treated as the registry's "standard".¶
Did the field's defining document designate it as belonging within the trace fields grouping? Section 3.6.7 of [MAIL] provides for fields "defined by other specifications as belonging within the trace fields grouping", and Section 4.4.4 of [SMTP] provides that "additional trace fields ... may be defined and registered as described in" [MAIL]. The test is designation by a specification, not observed behaviour; see Section 6.¶
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:¶
The registration instruction. Where [RFC4021] names a specification document for a field, that document is the starting point.¶
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.¶
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.¶
Signal 3 above is a candidate list, not a conclusion. 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.¶
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 long 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 a registry entry that listed every obsoleted ancestor would be less useful, not more.¶
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 rather than silently omitted, but it is not added to the Reference column, because the field in force is the MIME one defined by [MIME1].¶
A field whose only definition is in an obsoleted document is a different case, and is cited: see Section 4.2.¶
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 C 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.)¶
The previous revision of this document left these entries alone, on the view that settling a status for each on its individual merits was a larger undertaking than a metadata revision should attempt. With [RFC4021]'s own templates in hand that is no longer so: the question was settled in 2005 and simply not transcribed. Recording "standard" also correctly reflects that these fields remain in use in the environments that rely on that gateway work; 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". 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.¶
"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.¶
[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.¶
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, 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. This is the clearest single illustration of the general problem: the registry sends a reader to a registration document and records no status, when a Standards Track definition exists, has done since 1998, and was named in the registration instructions.¶
The "SIO-Label" and "SIO-Label-History" mail fields are both registered with a blank Status, citing [RFC7444]. RFC 7444 is an Informational document of the Independent stream -- 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 3, 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 3, the Status of every one of these fields should be "informational".¶
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, and they need to be separated.¶
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.¶
But 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, exactly 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:¶
| Field(s) | Defining document | Category | Status |
|---|---|---|---|
| Author | RFC 9057 | Experimental (Independent) | experimental |
| Delivered-To | RFC 9228 | Experimental (Independent) | experimental |
| CFBL-Address, CFBL-Feedback-ID | RFC 9477 | Experimental (Independent) | experimental |
| Apparently-To, Errors-To | RFC 2076 | Informational | informational |
| EDIINT-Features | RFC 6017 | Informational (Independent) | informational |
| Eesst-Version | RFC 7681 | Informational (Independent) | informational |
| Jabber-ID (mail and netnews) | RFC 7259 | Informational (Independent) | informational |
| X-Mittente, X-Ricevuta, X-Riferimento-Message-ID, X-TipoRicevuta, X-Trasporto, X-VerificaSicurezza | RFC 6109 | Informational | informational |
| MMHS-Authorizing-Users | RFC 7912 | Informational (Independent) | informational |
| SIO-Label, SIO-Label-History | RFC 7444 | Informational (Independent) | informational |
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". What should not persist is the present position, in which three readings coexist.¶
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.¶
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. 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.¶
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-OLD], Section 3.6.7 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 registry's Trace column is often read against, but it is not the text now in force. 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 controlling question for the column is therefore not "is this one of the two fields listed in Section 3.6.7" but "has a specification designated this field as belonging within the trace fields grouping". Judged that way the column is substantially under-populated, which is what [MAIL], Section 6.1 intended pending exactly this exercise.¶
Note that [MAIL], Section 6.1 makes the column applicable only where the Protocol is "mail"; see Section 6.6.¶
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", [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", [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". 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", [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", [RFC5518], Section 2: "in the terminology of RFC 5322, VBR-Info is a 'trace header field'".¶
"Auto-Submitted", [RFC5436], Section 2.7.1: "The 'Auto-Submitted' header field is considered a 'trace field', similar to 'Received' header fields (see [RFC5321])", 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. See Section 6.3.¶
"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 [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.¶
"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, yet their authors deliberately chose the "trace header field" designation to obtain its positional guarantees. The Trace column should record what the specifications say; the "yes" value reflects that designation.¶
The previous revision of this document listed "Auto-Submitted" among the fields deliberately not marked as trace, reasoning that it is set by the responder that originates the message, may appear at most once, and has no positional significance. That was wrong on all three counts as against [RFC5436], which designates it a trace field in terms and gives it an explicit ordering requirement. [TRACE-REG] had identified both this and the fact that the field's Reference column cites only [RFC3834] when [RFC5436] is the later and more detailed description; Section 7 adds [RFC5436].¶
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 alternative test -- inferring trace status from where a field appears -- was put to the emailcore list and argued against. 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. Position in the header section is not evidence of trace status. What counts is designation by a specification, and a specification may designate a field by imposing the positional rules of a trace field without using the word. On that narrower test two 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 not incidental to these fields, it is their mechanism.¶
"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 stated without the label, and the document says as much.¶
The Trace column for these four should be "yes".¶
The following fields are added by a handling agent in transit, but no specification designates them as trace fields, and the evidence for them is behavioural. Under the test of Section 6.4 that is not enough. The evidence is recorded here so that the question need not be researched again, and so that anyone who wishes to see these fields marked knows what is required: an update to the defining document, or a specification that designates them.¶
"Original-Recipient", [RFC3798], Section 2.3: inserted by the delivering MTA "at the beginning of the message (along with the Return-Path header)". This is close to designation, but the field's document in force is now [MDN], which describes the field's contents and use without placing it in the trace grouping.¶
"X400-Received", [RFC4021] and [MIXER]: the X.400/MIXER gateway equivalent of "Received". Its sibling "X400-Trace" is designated by its own registered description; "X400-Received" is not, and the analogy to "Received" is not a designation.¶
"Apparently-To", [RFC2076], Section 3.4: inserted by a mail transfer agent on delivery when the original message carries no "To" recipient. Its only reference is an Informational survey of headers in use, which records the behaviour as non-standard rather than specifying it. The previous revision of this document recommended "yes" for this field; on the test of Section 6.4 that recommendation is withdrawn.¶
Two netnews fields are designated as trace fields by their own documents:¶
"Path", [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-FMT] Section 3.2.8: 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. [MAIL], Section 6.1 defines the Trace field as "only applicable if the 'applicable protocol' is set 'mail' (in other cases, it should be set to ' ')". The previous revision of this document recommended "yes" for both fields without noticing that restriction.¶
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 [MAIL], Section 6.1 would have to be relaxed -- a change to [MAIL], not to the registry, and one properly raised with the netnews and emailcore communities rather than settled here. Leaving the two cells blank is consistent with the reading in Section 1.3: blank means "not yet specified".¶
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 [MAIL], Section 6.2. 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; 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.¶
"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 3, the reference corrections fall into three groups. Appendix D gives the resulting reference set for every entry.¶
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 C; the distinct documents involved are:¶
| Specification document | Fields |
|---|---|
| RFC 2156 ([MIXER]) | the 33 X.400/MIXER fields, incl. the "X400-" family and "Discarded-X400-" |
| RFC 1327 | Content-Return, Obsoletes, Expiry-Date, Content-Identifier |
| RFC 822 | Encrypted |
| RFC 2045 ([MIME1]) | MIME-Version (§4), Content-Type (§5), Content-Transfer-Encoding (§6), Content-ID (§7), Content-Description (§8) |
| RFC 2183 | Content-Disposition |
| RFC 3282 | Accept-Language, Content-Language |
| RFC 3297 | Original-Message-ID, Content-Alternative |
| RFC 3458 | Message-Context |
| RFC 1864 | Content-MD5 |
| RFC 2912 | Content-features |
| RFC 2557 | Content-Location |
| RFC 3803 | Content-Duration (RFC 4021 named RFC 2424, since obsoleted) |
| RFC 2369 ([LIST-URLS]) | List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner, List-Archive |
| RFC 2919 ([LIST-ID]) | List-ID |
| RFC 8098 ([MDN]) | Disposition-Notification-To, Disposition-Notification-Options (RFC 4021 named RFC 2298, since obsoleted twice) |
| RFC 1505 | Encoding |
Note that the previous revision of this document proposed adding both [MIME1] and [RFC2046] to the five core MIME fields. [RFC4021] names [MIME1] only, with a distinct section per field, and [RFC2046] defines media types rather than these header fields. [RFC2046] is not added.¶
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.¶
| Field | Cites | Obsoleted by | Add |
|---|---|---|---|
| Original-Recipient | RFC 3798, RFC 5337 | RFC 8098, RFC 6533 respectively | RFC 8098, RFC 6533 |
| Disposition-Notification-To, Disposition-Notification-Options | RFC 4021 (naming RFC 2298) | RFC 3798, then RFC 8098 | RFC 8098, RFC 6533 |
These entries fail to cite documents that carry a formal "Updates:" header targeting the field's defining document and modify the definition of the field. See Section 3.2 for the updaters excluded.¶
| Field | Cites | Add (formal updaters) |
|---|---|---|
| DKIM-Signature | RFC 6376 | RFC 8301, RFC 8463, RFC 8616 |
| Received-SPF | RFC 7208 | RFC 7372, RFC 8616 |
| Auto-Submitted | RFC 3834 | RFC 5436 |
| MIME-Version, Content-Type, Content-Transfer-Encoding, Content-ID, Content-Description | RFC 4021 | RFC 2231, RFC 6532 |
| Content-Disposition | RFC 4021 | RFC 2231 |
| Message-Context | RFC 4021 | RFC 3938 |
IANA is requested to update the "Permanent Message Header Field Names" and "Provisional Message Header Field Names" registries as set out below. The changes are metadata only; no field is added, removed, or renamed, and no field's syntax or semantics is affected.¶
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: a collective recommendation, documented, and approved through the normal process, rather than one registration action per field or an RFC per field.¶
Appendix D is the authoritative statement of 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 D and the prose of this document disagree, the prose governs and the table should be corrected.¶
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 C -- "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.¶
Set Trace to "yes" for:¶
"Received-SPF", "Authentication-Results", "DKIM-Signature", "VBR-Info", "Auto-Submitted", "SIO-Label-History", "X400-Trace", "DL-Expansion-History" (Section 6.2).¶
"ARC-Seal", "ARC-Message-Signature", "ARC-Authentication-Results", "Delivered-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.6), and the cells for "Original-Recipient", "X400-Received" and "Apparently-To" are left blank for the reasons in Section 6.5.¶
As tabulated in Section 7, listed per field in Appendix C and Appendix D.¶
This document changes registry metadata only and introduces no protocol behaviour. No new information is disclosed by any change in this document.¶
Accurate metadata has a modest positive security effect. Several of the fields whose Trace status is completed here ("Received-SPF", "Authentication-Results", "DKIM-Signature", the "ARC-*" fields) 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 section is significant and must be preserved.¶
The Trace column also has a concrete consumer. A signing protocol that must decide which header fields to cover needs to know which fields a handling agent may legitimately prepend in transit; signing such a field breaks the signature at the next hop. Where that decision is driven from the registry, an unpopulated Trace column means the decision is being made from a hard-coded list instead, and hard-coded lists diverge.¶
Conversely, marking a field as trace on weak evidence has a cost: it tells implementers that the field may be added by any handling agent, which is an invitation to do so. That is the reason for the narrower test adopted in Section 6.4 and for the withdrawals in Section 6.5.¶
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.¶
Thanks to Nathaniel Borenstein for pointing out the role of [RFC1049] in the history of the "Content-Type" field, to Rob Sayre for finding [TRACE-REG], and to John Levine both for that earlier draft and for encouragement to finish the job.¶
This document rests heavily on the record left by others: on Graham Klyne's and Jacob Palme's work in [REG-PROC] and [RFC4021] and the ietf-822 discussion around them, on Charles Lindsey's parallel work in the netnews registrations, and on the emailcore discussion of the Trace column involving Alexey Melnikov, John Klensin, Pete Resnick, Murray Kucherawy and Dave Crocker. The recommendations here are largely an attempt to finish what those documents started.¶
The determinations in this document were produced from the published RFC series and the live registries by mechanical passes whose results were then reviewed by hand:¶
The two registry CSV exports were compared, entry by entry, against the table in Appendix D, to confirm that the table covers every entry in both registries and no others.¶
The registration templates in Section 2 of [RFC4021] were parsed to extract, for each field, the "Applicable protocol", "Status" and "Specification document(s)" values that document supplied. This is the source of Appendix C.¶
A status, obsoletes and updates graph was built from the RFC Editor's
rfc-index.xml, giving for every RFC its category, what it obsoletes and
is obsoleted by, and what it updates and is updated by. This supplies the
category of each defining document and the candidate updater lists, and is
the basis for following an obsoletion chain to the document in force.¶
Candidate updaters were then reviewed individually against the text of the updating document, to determine whether they modify the definition of the header field or something else in the updated document; see Section 3.2.¶
Steps 1 to 3 are reproducible from public sources and should give identical results. Step 4 is a judgement, and the judgements made are recorded in Section 3.2 so that they can be checked.¶
The previous revision of this document also used a scan of the RFC series for each registered field name in header-field position. That pass has been dropped. It was unreliable for fields whose names are common words or common protocol tokens -- "Comments", "To", "From", "Subject", "Received", "Content-Type" and the like appear in thousands of documents, overwhelmingly in examples or unrelated prose -- and everything it contributed is now obtained more reliably from [RFC4021]'s own templates and from the obsoletes/updates graph, neither of which suffers from that ambiguity.¶
This appendix reproduces, for each field registered by [RFC4021], the "Status" and "Specification document(s)" values from that document's own registration template, alongside the document in force today and the Status this document recommends. It is the evidence for Section 4.1 and Section 4.2.¶
Fields re-registered since by [MAIL] (the RFC 2822 core fields) are omitted: their registry entries already carry a status and cite [MAIL].¶
| Field | RFC 4021 Status | RFC 4021 spec doc | Document in force | Recommended | Registry now |
|---|---|---|---|---|---|
| Accept-Language | standards-track | RFC 3282 | RFC 3282 | standard | (blank) |
| Alternate-Recipient | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Autoforwarded | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Autosubmitted | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Content-Alternative | work-in-progress | RFC 3297 | RFC 3297 | standard | (blank) |
| Content-Base | standards-track | RFC 2110 | RFC 2110 (dropped by successor) | obsoleted | obsoleted |
| Content-Description | standards-track | RFC 2045 §8 | RFC 2045 | standard | (blank) |
| Content-Disposition | standards-track | RFC 2183 | RFC 2183 | standard | (blank) |
| Content-Duration | standards-track | RFC 2424 | RFC 3803 (obsoletes RFC 2424) | standard | (blank) |
| Content-features | standards-track | RFC 2912 §3 | RFC 2912 | standard | (blank) |
| Content-ID | standards-track | RFC 2045 §7 | RFC 2045 | standard | (blank) |
| Content-Identifier | obsolete | RFC 1327 | RFC 1327 (dropped by successor) | obsoleted | (blank) |
| Content-Language | standards-track | RFC 3282 | RFC 3282 | standard | (blank) |
| Content-Location | standards-track | RFC 2557 | RFC 2557 | standard | (blank) |
| Content-MD5 | standards-track | RFC 1864 | RFC 1864 | standard | (blank) |
| Content-Return | obsolete | RFC 1327 | RFC 1327 (dropped by successor) | obsoleted | (blank) |
| Content-Transfer-Encoding | standards-track | RFC 2045 §6 | RFC 2045 | standard | (blank) |
| Content-Type | standards-track | RFC 2045 §5 | RFC 2045 | standard | (blank) |
| Conversion | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Conversion-With-Loss | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Deferred-Delivery | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Delivery-Date | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Discarded-X400-IPMS-Extensions | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Discarded-X400-MTS-Extensions | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Disclose-Recipients | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Disposition-Notification-Options | standards-track | RFC 2298 | RFC 8098 (obsoletes RFC 2298) | standard | (blank) |
| Disposition-Notification-To | standards-track | RFC 2298 | RFC 8098 (obsoletes RFC 2298) | standard | (blank) |
| DL-Expansion-History | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Encoding | experimental | RFC 1505 | RFC 1505 | experimental | (blank) |
| Encrypted | obsolete | RFC 822 | RFC 822 (dropped by successor) | obsoleted | (blank) |
| Expires | standards-track | RFC 2156 | RFC 2156 | standard | standard |
| Expiry-Date | obsolete | RFC 1327 | RFC 1327 (dropped by successor) | obsoleted | (blank) |
| Generate-Delivery-Report | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Importance | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Incomplete-Copy | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Language | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Latest-Delivery-Time | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| List-Archive | standards-track | RFC 2369 | RFC 2369 | standard | (blank) |
| List-Help | standards-track | RFC 2369 | RFC 2369 | standard | (blank) |
| List-ID | standards-track | RFC 2919 | RFC 2919 | standard | (blank) |
| List-Owner | standards-track | RFC 2369 | RFC 2369 | standard | (blank) |
| List-Post | standards-track | RFC 2369 | RFC 2369 | standard | (blank) |
| List-Subscribe | standards-track | RFC 2369 | RFC 2369 | standard | (blank) |
| List-Unsubscribe | standards-track | RFC 2369 | RFC 2369 | standard | (blank) |
| Message-Context | standards-track | RFC 3458 | RFC 3458 | standard | (blank) |
| Message-Type | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| MIME-Version | standards-track | RFC 2045 §4 | RFC 2045 | standard | (blank) |
| Obsoletes | obsolete | RFC 1327 | RFC 1327 (dropped by successor) | obsoleted | (blank) |
| Original-Encoded-Information-Types | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Original-Message-ID | standards-track | RFC 3297 | RFC 3297 | standard | (blank) |
| Originator-Return-Address | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| PICS-Label | standard | W3C PICS | W3C PICS Rec. | standard | (blank) |
| Prevent-NonDelivery-Report | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Priority | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Reply-By | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Sensitivity | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| Supersedes | standards-track | RFC 2156 | RFC 2156 | standard | standard |
| X400-Content-Identifier | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| X400-Content-Return | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| X400-Content-Type | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| X400-MTS-Identifier | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| X400-Originator | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| X400-Received | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| X400-Recipients | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
| X400-Trace | standards-track | RFC 2156 | RFC 2156 | standard | (blank) |
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, and a bold reference is an addition. A non-bold value is confirmed unchanged. The "Reg" column gives the registry: "perm" or "prov".¶
Entries whose only specification is a non-RFC document (for example the "Face" and "X-Face" fields) are shown as "(non-RFC ref)". References to work-in-progress are shown by draft name without a version number.¶
| Field | Reg | Proto | Status | Trace | Reference (bold = added) |
|---|---|---|---|---|---|
| Accept-Language | perm | standard | — | RFC 4021, RFC 3282 | |
| Also-Control | perm | netnews | obsoleted | — | RFC 1849, RFC 5536 |
| Alternate-Recipient | perm | standard | — | RFC 4021, RFC 2156 | |
| Apparently-To | prov | informational | — | RFC 2076 | |
| Approved | perm | netnews | standard | — | RFC 5536 |
| ARC-Authentication-Results | perm | experimental | yes | RFC 8617 | |
| ARC-Message-Signature | perm | experimental | yes | RFC 8617 | |
| ARC-Seal | perm | experimental | yes | RFC 8617 | |
| Archive | perm | netnews | standard | — | RFC 5536 |
| Archived-At | perm | standard | — | RFC 5064 | |
| Archived-At | perm | netnews | standard | — | RFC 5064 |
| Article-Names | perm | netnews | obsoleted | — | RFC 1849, RFC 5536 |
| Article-Updates | perm | netnews | obsoleted | — | RFC 1849, RFC 5536 |
| Authentication-Results | perm | standard | yes | RFC 8601 | |
| Author | prov | experimental | — | RFC 9057 | |
| Auto-Submitted | perm | standard | yes | RFC 3834, RFC 5436 | |
| Autoforwarded | perm | standard | — | RFC 4021, RFC 2156 | |
| Autosubmitted | perm | standard | — | RFC 4021, RFC 2156 | |
| Base | perm | MIME | obsoleted | — | RFC 1808, RFC 2068 |
| Bcc | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Body | perm | none | reserved | — | RFC 6068 |
| Cancel-Key | perm | netnews | standard | — | RFC 8315 |
| Cancel-Lock | perm | netnews | standard | — | RFC 8315 |
| Cc | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| CFBL-Address | prov | experimental | — | RFC 9477 | |
| CFBL-Feedback-ID | prov | experimental | — | RFC 9477 | |
| Comments | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Comments | perm | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Content-Alternative | perm | MIME | standard | — | RFC 4021, RFC 3297 |
| Content-Base | perm | MIME | obsoleted | — | RFC 2110, RFC 2557 |
| Content-Description | perm | MIME | standard | — | RFC 4021, RFC 2045, RFC 2231, RFC 6532 |
| Content-Disposition | perm | MIME | standard | — | RFC 4021, RFC 2183, RFC 2231 |
| Content-Duration | perm | MIME | standard | — | RFC 4021, RFC 3803 |
| Content-features | perm | MIME | standard | — | RFC 4021, RFC 2912 |
| Content-ID | perm | MIME | standard | — | RFC 4021, RFC 2045, RFC 2231, RFC 6532 |
| Content-Identifier | perm | obsoleted | — | RFC 4021, RFC 1327 | |
| Content-Language | perm | MIME | standard | — | RFC 4021, RFC 3282 |
| Content-Location | perm | MIME | standard | — | RFC 4021, RFC 2557 |
| Content-MD5 | perm | MIME | standard | — | RFC 4021, RFC 1864 |
| Content-Return | perm | obsoleted | — | RFC 4021, RFC 1327 | |
| Content-Transfer-Encoding | perm | MIME | standard | — | RFC 4021, RFC 2045, RFC 2231, RFC 6532 |
| Content-Translation-Type | perm | MIME | standard | — | RFC 8255 |
| Content-Type | perm | MIME | standard | — | RFC 4021, RFC 9788, RFC 2045, RFC 2231, RFC 6532 |
| Control | perm | netnews | standard | — | RFC 5536 |
| Conversion | perm | standard | — | RFC 4021, RFC 2156 | |
| Conversion-With-Loss | perm | standard | — | RFC 4021, RFC 2156 | |
| Date | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Date | perm | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Date-Received | perm | netnews | obsoleted | — | RFC 850, RFC 5536 |
| Deferred-Delivery | perm | standard | — | RFC 4021, RFC 2156 | |
| Delivered-To | prov | experimental | yes | RFC 9228 | |
| Delivery-Date | perm | standard | — | RFC 4021, RFC 2156 | |
| Discarded-X400-IPMS-Extensions | perm | standard | — | RFC 4021, RFC 2156 | |
| Discarded-X400-MTS-Extensions | perm | standard | — | RFC 4021, RFC 2156 | |
| Disclose-Recipients | perm | standard | — | RFC 4021, RFC 2156 | |
| Disposition-Notification-Options | perm | standard | — | RFC 4021, RFC 8098, RFC 6533 | |
| Disposition-Notification-To | perm | standard | — | RFC 4021, RFC 8098, RFC 6533 | |
| Distribution | perm | netnews | standard | — | RFC 5536 |
| DKIM-Signature | perm | standard | yes | RFC 6376, RFC 8301, RFC 8463, RFC 8616 | |
| DL-Expansion-History | perm | standard | yes | RFC 4021, RFC 2156 | |
| Downgraded-Bcc | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Cc | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Disposition-Notification-To | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Final-Recipient | perm | standard | — | RFC 6857 | |
| Downgraded-From | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-In-Reply-To | perm | standard | — | RFC 6857 | |
| Downgraded-Mail-From | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Message-Id | perm | standard | — | RFC 6857 | |
| Downgraded-Original-Recipient | perm | standard | — | RFC 6857 | |
| Downgraded-Rcpt-To | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-References | perm | standard | — | RFC 6857 | |
| Downgraded-Reply-To | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-Bcc | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-Cc | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-From | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-Reply-To | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-Sender | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Resent-To | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Return-Path | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-Sender | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| Downgraded-To | perm | obsoleted | — | RFC 5504, RFC 6857 | |
| EDIINT-Features | prov | informational | — | RFC 6017 | |
| Eesst-Version | prov | informational | — | RFC 7681 | |
| Encoding | perm | experimental | — | RFC 4021, RFC 1505 | |
| Encrypted | perm | obsoleted | — | RFC 4021, RFC 822 | |
| Errors-To | prov | informational | — | RFC 2076 | |
| Expires | perm | standard | — | draft-ietf-mailmaint-expires | |
| Expires | perm | netnews | standard | — | RFC 5536 |
| Expiry-Date | perm | obsoleted | — | RFC 4021, RFC 1327 | |
| Face | prov | — | — | (non-RFC ref) | |
| Face | prov | netnews | — | — | (non-RFC ref) |
| Followup-To | perm | netnews | standard | — | RFC 5536 |
| Form-Sub | prov | — | — | draft-levine-mailbomb-header-00 | |
| From | perm | standard | no | RFC 6854, draft-ietf-emailcore-rfc5322bis | |
| From | perm | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Generate-Delivery-Report | perm | standard | — | RFC 4021, RFC 2156 | |
| HP-Outer | perm | standard | — | RFC 9788 | |
| Importance | perm | standard | — | RFC 4021, RFC 2156 | |
| In-Reply-To | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Incomplete-Copy | perm | standard | — | RFC 4021, RFC 2156 | |
| Injection-Date | perm | netnews | standard | — | RFC 5536 |
| Injection-Info | perm | netnews | standard | — | RFC 5536 |
| Jabber-ID | prov | informational | — | RFC 7259 | |
| Jabber-ID | prov | netnews | informational | — | RFC 7259 |
| Keywords | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Keywords | perm | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Language | perm | standard | — | RFC 4021, RFC 2156 | |
| Latest-Delivery-Time | perm | standard | — | RFC 4021, RFC 2156 | |
| Lines | perm | netnews | deprecated | — | RFC 5536, RFC 3977 |
| List-Archive | perm | standard | — | RFC 4021, RFC 2369 | |
| List-Help | perm | standard | — | RFC 4021, RFC 2369 | |
| List-ID | perm | standard | — | RFC 4021, RFC 2919 | |
| List-Owner | perm | standard | — | RFC 4021, RFC 2369 | |
| List-Post | perm | standard | — | RFC 4021, RFC 2369 | |
| List-Subscribe | perm | standard | — | RFC 4021, RFC 2369 | |
| List-Unsubscribe | perm | standard | — | RFC 4021, RFC 2369 | |
| List-Unsubscribe-Post | perm | standard | — | RFC 8058 | |
| Message-Context | perm | standard | — | RFC 4021, RFC 3458, RFC 3938 | |
| Message-ID | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Message-ID | perm | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Message-Type | perm | standard | — | RFC 4021, RFC 2156 | |
| MIME-Version | perm | MIME | standard | — | RFC 4021, RFC 2045, RFC 2231, RFC 6532 |
| MMHS-Acp127-Message-Identifier | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Authorizing-Users | prov | informational | — | RFC 7912 | |
| MMHS-Codress-Message-Indicator | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Copy-Precedence | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Exempted-Address | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Extended-Authorisation-Info | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Handling-Instructions | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Message-Instructions | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Message-Type | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Originator-PLAD | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Originator-Reference | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Other-Recipients-Indicator-CC | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Other-Recipients-Indicator-To | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Primary-Precedence | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MMHS-Subject-Indicator-Codes | perm | informational | — | RFC 6477, (non-RFC ref) | |
| MT-Priority | perm | informational | — | RFC 6758 | |
| Newsgroups | perm | netnews | standard | — | RFC 5536 |
| NNTP-Posting-Date | perm | netnews | obsoleted | — | RFC 5536 |
| NNTP-Posting-Host | perm | netnews | obsoleted | — | RFC 2980, RFC 5536 |
| Obsoletes | perm | obsoleted | — | RFC 4021, RFC 1327 | |
| Organization | perm | informational | — | RFC 7681 | |
| Organization | perm | netnews | standard | — | RFC 5536 |
| Original-Encoded-Information-Types | perm | standard | — | RFC 4021, RFC 2156 | |
| Original-From | perm | standard | — | RFC 5703 | |
| Original-Message-ID | perm | standard | — | RFC 4021, RFC 3297 | |
| Original-Recipient | perm | standard | — | RFC 3798, RFC 5337, RFC 8098, RFC 6533 | |
| Original-Sender | perm | netnews | standard | — | RFC 5537 |
| Original-Subject | perm | standard | — | RFC 5703 | |
| Originator-Return-Address | perm | standard | — | RFC 4021, RFC 2156 | |
| Path | perm | netnews | standard | — | RFC 5536 |
| PICS-Label | perm | standard | — | RFC 4021 | |
| Posting-Version | perm | netnews | obsoleted | — | RFC 850, RFC 5536 |
| Prevent-NonDelivery-Report | perm | standard | — | RFC 4021, RFC 2156 | |
| Priority | perm | standard | — | RFC 4021, RFC 2156 | |
| Privicon | prov | — | — | draft-koenig-privicons-01 | |
| Received | perm | standard | yes | draft-ietf-emailcore-rfc5322bis, draft-ietf-emailcore-rfc5321bis | |
| Received-SPF | perm | standard | yes | RFC 7208, RFC 7372, RFC 8616 | |
| References | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| References | perm | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Relay-Version | perm | netnews | obsoleted | — | RFC 850, RFC 5536 |
| Reply-By | perm | standard | — | RFC 4021, RFC 2156 | |
| Reply-To | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Reply-To | perm | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Require-Recipient-Valid-Since | perm | standard | — | RFC 7293 | |
| Resent-Bcc | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-Cc | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-Date | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-From | perm | standard | no | RFC 6854, draft-ietf-emailcore-rfc5322bis | |
| Resent-Message-ID | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-Reply-To | perm | obsoleted | no | draft-ietf-emailcore-rfc5322bis | |
| Resent-Sender | perm | standard | no | RFC 6854, draft-ietf-emailcore-rfc5322bis | |
| Resent-To | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Return-Path | perm | standard | yes | draft-ietf-emailcore-rfc5322bis, draft-ietf-emailcore-rfc5321bis | |
| See-Also | perm | netnews | obsoleted | — | RFC 1849, RFC 5536 |
| Sender | perm | standard | no | RFC 6854, draft-ietf-emailcore-rfc5322bis | |
| Sender | perm | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Sensitivity | perm | standard | — | RFC 4021, RFC 2156 | |
| SIO-Label | prov | informational | — | RFC 7444 | |
| SIO-Label-History | prov | informational | yes | RFC 7444 | |
| Solicitation | perm | standard | — | RFC 3865 | |
| Subject | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| Subject | perm | netnews | standard | — | RFC 5536, draft-ietf-emailcore-rfc5322bis |
| Summary | perm | netnews | standard | — | RFC 5536 |
| Supersedes | perm | standard | — | RFC 4021, RFC 2156 | |
| Supersedes | perm | netnews | standard | — | RFC 5536, RFC 2156 |
| TLS-Report-Domain | perm | standard | — | RFC 8460 | |
| TLS-Report-Submitter | perm | standard | — | RFC 8460 | |
| TLS-Required | perm | standard | — | RFC 8689 | |
| To | perm | standard | no | draft-ietf-emailcore-rfc5322bis | |
| User-Agent | perm | netnews | standard | — | RFC 5536, RFC 2616 |
| VBR-Info | perm | standard | yes | RFC 5518 | |
| Wrong-Recipient | prov | — | — | draft-ietf-mailmaint-wrong-recipient-00 | |
| X-Archived-At | prov | deprecated | — | RFC 5064 | |
| X-Archived-At | prov | netnews | deprecated | — | RFC 5064 |
| X-Face | prov | — | — | (non-RFC ref) | |
| X-Face | prov | netnews | — | — | (non-RFC ref) |
| X-Mittente | prov | informational | — | RFC 6109 | |
| X-PGP-Sig | prov | netnews | — | — | (non-RFC ref), (non-RFC ref) |
| X-Ricevuta | prov | informational | — | RFC 6109 | |
| X-Riferimento-Message-ID | prov | informational | — | RFC 6109 | |
| X-TipoRicevuta | prov | informational | — | RFC 6109 | |
| X-Trasporto | prov | informational | — | RFC 6109 | |
| X-VerificaSicurezza | prov | informational | — | RFC 6109 | |
| X400-Content-Identifier | perm | standard | — | RFC 4021, RFC 2156 | |
| X400-Content-Return | perm | standard | — | RFC 4021, RFC 2156 | |
| X400-Content-Type | perm | standard | — | RFC 4021, RFC 2156 | |
| X400-MTS-Identifier | perm | standard | — | RFC 4021, RFC 2156 | |
| X400-Originator | perm | standard | — | RFC 4021, RFC 2156 | |
| X400-Received | perm | standard | — | RFC 4021, RFC 2156 | |
| X400-Recipients | perm | standard | — | RFC 4021, RFC 2156 | |
| X400-Trace | perm | standard | yes | RFC 4021, RFC 2156 | |
| Xref | perm | netnews | standard | — | RFC 5536 |
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.3: "Auto-Submitted" moved from the not-trace list to Section 6.2. [RFC5436], Section 2.7.1 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.6: the recommendations of Trace "yes" for "Path" and "Injection-Info" are withdrawn. [MAIL], Section 6.1 makes the column applicable only where Protocol is "mail".¶
Section 6.5: 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.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 C (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.7: the "Resent-*" fields, recorded as "no" by [MAIL] although [TRACE-REG] proposed otherwise.¶
Normative references changed from [MAIL-OLD] and [SMTP-OLD] to [MAIL] and [SMTP], which are the documents that now govern the registries.¶
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).¶