Network Working Group B. Gondwana Internet-Draft Fastmail Updates: 4021 (if approved) 29 July 2026 Intended status: Informational Expires: 30 January 2027 Maintenance of the IANA Message Header Field Registries draft-gondwana-email-header-maintenance-02 Abstract 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. Status of This Memo 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/. Gondwana Expires 30 January 2027 [Page 1] Internet-Draft Header Field Registry Maintenance July 2026 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 Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Metadata that was supplied but not recorded . . . . . . . 4 1.2. Why "standard" appears unevenly . . . . . . . . . . . . . 4 1.3. The Trace column is unfinished, not wrong . . . . . . . . 5 1.4. What this document does . . . . . . . . . . . . . . . . . 6 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6. Conventions Used in This Document . . . . . . . . . . . . 6 2. Prior and Related Work . . . . . . . . . . . . . . . . . . . 6 2.1. draft-levine-trace-header-registry . . . . . . . . . . . 6 2.2. The emailcore discussion of the Trace column . . . . . . 7 2.3. The proposed route for retroactive population . . . . . . 7 3. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Determining "updates" for the Reference column . . . . . 9 3.2. Formal updaters that are not added . . . . . . . . . . . 9 3.3. The historical lineage is not added . . . . . . . . . . . 10 4. Status Corrections . . . . . . . . . . . . . . . . . . . . . 10 4.1. Completing the RFC 4021 registrations . . . . . . . . . . 10 4.2. Fields whose only definition is in an obsoleted document . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. MT-Priority: standard to informational . . . . . . . . . 12 4.4. Solicitation: blank to standard . . . . . . . . . . . . . 12 4.5. The List-* family: blank to standard . . . . . . . . . . 13 4.6. SIO-Label and SIO-Label-History: blank to informational . . . . . . . . . . . . . . . . . . . . . . 13 4.7. The MMHS-* fields: blank to informational . . . . . . . . 13 Gondwana Expires 30 January 2027 [Page 2] Internet-Draft Header Field Registry Maintenance July 2026 4.8. Status in the provisional registry . . . . . . . . . . . 14 4.9. Fields deliberately left unchanged (non-obvious cases) . 16 5. Protocol Corrections . . . . . . . . . . . . . . . . . . . . 17 6. Trace Corrections . . . . . . . . . . . . . . . . . . . . . . 17 6.1. The test . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Fields whose defining documents designate them trace fields . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Auto-Submitted . . . . . . . . . . . . . . . . . . . . . 19 6.4. Fields that behave as trace fields without the word . . . 19 6.5. Fields with trace-like behaviour that are not recommended . . . . . . . . . . . . . . . . . . . . . . . 20 6.6. The Trace column and the netnews fields . . . . . . . . . 21 6.7. Fields deliberately not marked trace (non-obvious cases) . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Reference List Updates . . . . . . . . . . . . . . . . . . . 22 7.1. Specification documents named by RFC 4021 but not recorded . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Superseded references . . . . . . . . . . . . . . . . . . 24 7.3. Missing formal updates . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Status changes . . . . . . . . . . . . . . . . . . . . . 26 8.3. Trace changes . . . . . . . . . . . . . . . . . . . . . . 26 8.4. Reference changes . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix B. Reproducing the analysis . . . . . . . . . . . . . . 34 Appendix C. What RFC 4021 told IANA . . . . . . . . . . . . . . 35 Appendix D. Per-field recommended state . . . . . . . . . . . . 40 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 55 E.1. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 55 E.2. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57 1. Introduction 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 Gondwana Expires 30 January 2027 [Page 3] Internet-Draft Header Field Registry Maintenance July 2026 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. 1.1. Metadata that was supplied but not recorded [RFC4021] registered roughly ninety mail and MIME header fields in a single Standards Track document. Section 2 of that document contains a complete [REG-PROC] registration template for each field, and each template carries both an explicit "Status:" line and an explicit "Specification document(s):" line naming the document that actually defines the field. Section 3 of [RFC4021] states that "Section 2 of this specification provides initial registrations"; the templates are therefore the registration instructions, and there is no separate, abbreviated table for IANA to work from. Neither the status nor the specification document reached the registry. Every one of those entries carries a blank Status, and cites [RFC4021] in the Reference column instead of the document named in its own template. So, for example, the registry records "Content- Disposition" with no status and a reference to [RFC4021], where [RFC4021] told IANA that the field is standards-track and is specified by [RFC2183]. This is the single largest source of missing metadata in either registry, and it is not a matter of judgement: the values are recoverable verbatim from [RFC4021]. 1.2. Why "standard" appears unevenly The unevenness of the Status column between the mail/MIME fields and the netnews fields has a documented origin. Section 4.2.1 of [REG-PROC] directs a registrant to specify "standard", "experimental", "informational", "historic", "obsoleted", or some other appropriate value according to the type and status of the primary document in which it is defined. Writing what became [NETNEWS-FMT], Charles Lindsey read that list as lumping the standards-track maturity levels together, and said so on the ietf-822 list on 2004-05-14: the template "seems to suggest that all the varieties of standard-track document are to be lumped Gondwana Expires 30 January 2027 [Page 4] Internet-Draft Header Field Registry Maintenance July 2026 together and assigned the status 'standard'", adding "in the IANA Considerations section of USEFOR, I have followed the registration template as written, and used 'standard' throughout." Graham Klyne, the author of both [REG-PROC] and [RFC4021], took the other route, and explained why on 2004-05-17: "In preparing the mail header registration document, it seemed to be more appropriate (and more honest regarding some of the headers' actual status in the IETF process) to me to specify not- yet-standard headers as 'standards-track' rather than 'standard'. The wiggle room in the registry spec that allows me to justify this is 'or some other appropriate value according to the type and status of the primary document'." [RFC4021] accordingly reserves "standard" for the fields that had reached full Internet Standard through RFC 822, and uses "standards- track" for the rest. Lindsey replied on 2004-05-21 that "standards- track" throughout would be better, "or 'standard' if it is understood to mean the same thing". That is why [NETNEWS-FMT]'s netnews fields all read "standard" while [RFC4021]'s mail and MIME fields do not. The two documents used different vocabularies for the same thing, and only one of those vocabularies is in the [REG-PROC] list. This document treats both [RFC4021] values, "standard" and "standards-track", as the registry's "standard", which is what Klyne and Lindsey each took them to mean. 1.3. The Trace column is unfinished, not wrong [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. Gondwana Expires 30 January 2027 [Page 5] Internet-Draft Header Field Registry Maintenance July 2026 1.4. What this document does This document reviews the initial definition of, and every subsequent update to, each registered header field, and provides IANA with 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. 1.5. Scope This document does not define, deprecate, or change the semantics of any header field. It changes only the _metadata_ recorded about existing fields in the IANA registries. In every case the recommended metadata is the metadata that the field's own registering, defining, and updating documents already supply or imply. 1.6. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The terms "trace field" and "trace header field" are used as defined in [MAIL], Section 3.6.7 and [SMTP], Section 4.4. 2. Prior and Related Work 2.1. draft-levine-trace-header-registry In January 2012 John Levine, later with S. Moonesamy, published [TRACE-REG], "A Registry for Mail Trace Fields" (later "Mail Header Trace Fields"), which proposed 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. Gondwana Expires 30 January 2027 [Page 6] Internet-Draft Header Field Registry Maintenance July 2026 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. 2.2. The emailcore discussion of the Trace column The Trace column exists because Alexey Melnikov proposed it to the emailcore list on 2022-11-28, specified as containing "the value 'Yes' for each header field which is defined as a trace header field, as specified in Section 3.6.7 of rfc5322bis". Melnikov reported on 2023-02-27 that at IETF 115 the group had agreed to record trace status by adding a column to this registry, and that the remaining question was which document should carry the IANA Considerations text; it ended up in [MAIL]. Two exchanges in that discussion bear directly on the tests this document applies, and are cited where they arise: the confirmation by Melnikov and by Resnick that Section 3.6.7 of [MAIL] permits other specifications to designate additional trace fields (Section 6), and the caution from Melnikov and John Klensin against inferring trace status from a field's position in the header section (Section 6.4). 2.3. The proposed route for retroactive population On 2024-03-18, in review of [MAIL], Murray Kucherawy raised the question this document answers: "Also with respect to the trace flag being added to the registry, and the current DE retiring from that role, I'm wondering if we should consider providing some lightweight process for retroactively adding that flag (set or otherwise) to registered header fields. For example, I registered Authentication-Results and at least one other with the intent that they be treated as trace fields, so do I need to publish an RFC to get this flag updated? Or do we want to get a small team to go through all of the current registrations to figure out which ones are supposed to be trace fields, and do a one-shot update...?" Gondwana Expires 30 January 2027 [Page 7] Internet-Draft Header Field Registry Maintenance July 2026 Dave Crocker replied on 2024-03-19 that "the question of what it means to be a trace field has been sitting like an indigestible dumpling in the stomach, for many years", and suggested a route: "For retroactive assessments, it makes sense to create some sort of (rough) consensus process among folk with (some) background in this space. So I suggest creating a small group to make a collective recommendation for existing header field registrations. Documenting it as an RFC then permits a normal IESG approval process." Klensin wrote that he "largely agree(d) with Dave"; Resnick called it "a fine way forward" and reported IANA's agreement to the blank- means-unspecified reading quoted in Section 1.3; Kucherawy wrote "I like this path forward". No consensus was declared on the point, and the question was referred to the IESG. This document is intended as the recommendation Crocker described, extended to the Status and Reference columns because the same entries need the same kind of attention. Section 8 states the mechanism as well as the content. 3. Methodology 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. Protocol: 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. Status: 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". Trace: Did the field's defining document designate it as belonging Gondwana Expires 30 January 2027 [Page 8] Internet-Draft Header Field Registry Maintenance July 2026 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. 3.1. Determining "updates" for the Reference column The Reference column should point a reader at the document that defines the field and at every document still in force that modifies that definition. Three signals were combined: 1. The registration instruction. Where [RFC4021] names a specification document for a field, that document is the starting point. 2. The obsoletion chain. Where the named specification has been obsoleted, the document in force is the one at the end of the chain, unless that document drops the field, in which case the last document that defined it is cited and the field is treated as obsoleted. For example [RFC4021] names [RFC2298] for "Disposition-Notification-To"; [RFC2298] was obsoleted by [RFC3798], which was in turn obsoleted by [MDN], so [MDN] is the document in force. 3. The formal "Updates:" metadata. Every RFC that carries an "Updates: N" header was recorded as a candidate updater of RFC N. This yields an authoritative, machine-checkable graph. For example [RFC8301] and [RFC8463] each carry "Updates: 6376" and therefore update the definition of the "DKIM-Signature" field. 3.2. Formal updaters that are not added Signal 3 above 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. Gondwana Expires 30 January 2027 [Page 9] Internet-Draft Header Field Registry Maintenance July 2026 This exclusion is recorded so that a reader who regenerates the reference sets from the "Updates:" graph alone, and finds three more entries than this document recommends, knows the difference is intentional. 3.3. The historical lineage is not added For the core mail fields ("Date", "From", "Sender", "Reply-To", "To", "Cc", "Bcc", "Message-ID", "In-Reply-To", "References", "Subject", "Comments", "Keywords", the "Resent-_" fields, "Return-Path", and "Received") the registry already cites the current defining document ([MAIL], with [RFC6854] where the group syntax applies, and [SMTP] for the two SMTP trace fields). The 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. 4. Status Corrections 4.1. Completing the RFC 4021 registrations As set out in Section 1.1, [RFC4021] supplied a Status for each of the fields it registered, and none of those values reached the registry. This document recommends that they be recorded now, mapped into the [REG-PROC] vocabulary as described in Section 3. The great majority resolve to "standard". [RFC4021] marked them "standards-track" and named a Standards Track specification, and in almost every case that specification, or the document that has since replaced it, is still in force at Proposed or Draft Standard. Appendix 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", Gondwana Expires 30 January 2027 [Page 10] Internet-Draft Header Field Registry Maintenance July 2026 "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. Gondwana Expires 30 January 2027 [Page 11] Internet-Draft Header Field Registry Maintenance July 2026 4.2. Fields whose only definition is in an obsoleted document [RFC4021] marked six fields "obsolete". Five of them are the fields whose specification was dropped when the document defining them was replaced: * "Content-Return", "Obsoletes", "Expiry-Date" and "Content- Identifier" were specified by [RFC1327], which [MIXER] obsoleted without carrying these fields forward. * "Encrypted" was specified by RFC 822 and dropped by RFC 2822. Klyne proposed the "obsolete" marking on the ietf-822 list on 2004-04-30 ("Defined by RFC 822, but removed in RFC 2822"), and Keith Moore agreed ("The Encrypted field never was adequately specified ... so yes it's obsolete"). For all five the Status should be "obsoleted". For these fields, and unlike the case in Section 3.3, the obsoleted document is the _only_ definition, so it is cited: [RFC1327] for the first four, RFC 822 for "Encrypted". The sixth, "Resent-Reply-To", already carries "obsoleted" by way of its re-registration in [MAIL]. A seventh field of the same shape, "Content-Base", was marked "standards-track" by [RFC4021] citing [RFC2110], but [RFC2557] obsoleted that document and dropped the field; the registry already records "obsoleted" and cites both documents, and needs no change. 4.3. MT-Priority: standard to informational The "MT-Priority" mail field is registered with Status "standard", citing [RFC6758]. RFC 6758 is an Informational document; its front page states "This document is not an Internet Standards Track specification", and Section 4 of that document is the sole definition of the header field. The Standards Track work on message-transfer priorities, [RFC6710], defines an SMTP service extension keyword, not a header field. The field's status should therefore be "informational", matching the standing of the only document that defines it. 4.4. Solicitation: blank to standard The "Solicitation" mail field is registered with a blank Status, citing [RFC3865]. RFC 3865 is a Standards Track document, and its Section 4 instructs IANA to add the "Solicitation" field to the permanent registry. A directly comparable field, "Auto-Submitted" (also defined by a Standards Track document, [RFC3834]), is registered as "standard". There is no basis in the source documents Gondwana Expires 30 January 2027 [Page 12] Internet-Draft Header Field Registry Maintenance July 2026 for treating the two differently; "Solicitation" should be "standard". 4.5. The List-* family: blank to standard The six mailing-list fields "List-Help", "List-Subscribe", "List- Unsubscribe", "List-Post", "List-Owner", and "List-Archive" are registered with a blank Status and a Reference of [RFC4021] only, and "List-ID" likewise. They are part of the [RFC4021] cohort of Section 4.1: [RFC4021] marked all seven "standards-track" and named [LIST-URLS] for the first six and [LIST-ID] for "List-ID", both Standards Track documents, neither obsoleted nor updated. For all seven the Status should be "standard" and the Reference should cite the specification document. 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. 4.6. SIO-Label and SIO-Label-History: blank to informational The "SIO-Label" and "SIO-Label-History" mail fields are both registered with a blank Status, citing [RFC7444]. RFC 7444 is an Informational document 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". 4.7. The MMHS-* fields: blank to informational The fourteen "MMHS-*" fields registered by [RFC6477] ("MMHS-Exempted- Address", "MMHS-Extended-Authorisation-Info", "MMHS-Subject- Indicator-Codes", "MMHS-Handling-Instructions", "MMHS-Message- Instructions", "MMHS-Codress-Message-Indicator", "MMHS-Originator- Reference", "MMHS-Primary-Precedence", "MMHS-Copy-Precedence", "MMHS- Message-Type", "MMHS-Other-Recipients-Indicator-To", "MMHS-Other- Recipients-Indicator-CC", "MMHS-Acp127-Message-Identifier", and "MMHS-Originator-PLAD"), together with "MMHS-Authorizing-Users" registered by [RFC7912], are all registered with a blank Status. RFC 6477 and RFC 7912 are both Informational documents, 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". Gondwana Expires 30 January 2027 [Page 13] Internet-Draft Header Field Registry Maintenance July 2026 4.8. Status in the provisional registry Most entries in the provisional registry carry a blank Status, including entries whose defining document is an ordinary published RFC of a determinate category. Two readings of the column are possible, 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: Gondwana Expires 30 January 2027 [Page 14] Internet-Draft Header Field Registry Maintenance July 2026 +===========================+========+=============+===============+ | Field(s) |Defining|Category | Status | | |document| | | +===========================+========+=============+===============+ | Author |RFC 9057|Experimental | experimental | | | |(Independent)| | +---------------------------+--------+-------------+---------------+ | Delivered-To |RFC 9228|Experimental | experimental | | | |(Independent)| | +---------------------------+--------+-------------+---------------+ | CFBL-Address, CFBL- |RFC 9477|Experimental | experimental | | Feedback-ID | |(Independent)| | +---------------------------+--------+-------------+---------------+ | Apparently-To, Errors-To |RFC 2076|Informational| informational | +---------------------------+--------+-------------+---------------+ | EDIINT-Features |RFC 6017|Informational| informational | | | |(Independent)| | +---------------------------+--------+-------------+---------------+ | Eesst-Version |RFC 7681|Informational| informational | | | |(Independent)| | +---------------------------+--------+-------------+---------------+ | Jabber-ID (mail and |RFC 7259|Informational| informational | | netnews) | |(Independent)| | +---------------------------+--------+-------------+---------------+ | X-Mittente, X-Ricevuta, |RFC 6109|Informational| informational | | X-Riferimento-Message-ID, | | | | | X-TipoRicevuta, | | | | | X-Trasporto, | | | | | X-VerificaSicurezza | | | | +---------------------------+--------+-------------+---------------+ | MMHS-Authorizing-Users |RFC 7912|Informational| informational | | | |(Independent)| | +---------------------------+--------+-------------+---------------+ | SIO-Label, SIO-Label- |RFC 7444|Informational| informational | | History | |(Independent)| | +---------------------------+--------+-------------+---------------+ Table 1: Status for provisional entries with RFC references 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" Gondwana Expires 30 January 2027 [Page 15] Internet-Draft Header Field Registry Maintenance July 2026 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. 4.9. Fields deliberately left unchanged (non-obvious cases) 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. Gondwana Expires 30 January 2027 [Page 16] Internet-Draft Header Field Registry Maintenance July 2026 5. Protocol Corrections 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. 6. Trace Corrections 6.1. The test [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." Gondwana Expires 30 January 2027 [Page 17] Internet-Draft Header Field Registry Maintenance July 2026 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. 6.2. Fields whose defining documents designate them trace fields For each of the following fields a specification states, in terms, that the field is a trace field. The Trace column for each should be "yes". * "Received-SPF", [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. Gondwana Expires 30 January 2027 [Page 18] Internet-Draft Header Field Registry Maintenance July 2026 * "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. 6.3. Auto-Submitted 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]. 6.4. Fields that behave as trace fields without the word A field may be added by a handling agent in transit, at a defined position and with ordering significance, without its defining document using the word "trace". Whether such a field should be marked requires care, because the 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: Gondwana Expires 30 January 2027 [Page 19] Internet-Draft Header Field Registry Maintenance July 2026 "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". 6.5. Fields with trace-like behaviour that are not recommended 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. Gondwana Expires 30 January 2027 [Page 20] Internet-Draft Header Field Registry Maintenance July 2026 * "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. 6.6. The Trace column and the netnews fields 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". 6.7. Fields deliberately not marked trace (non-obvious cases) 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 Gondwana Expires 30 January 2027 [Page 21] Internet-Draft Header Field Registry Maintenance July 2026 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". 7. Reference List Updates Applying the methodology of Section 3, the reference corrections fall into three groups. Appendix D gives the resulting reference set for every entry. 7.1. Specification documents named by RFC 4021 but not recorded These entries cite [RFC4021] but not the specification document [RFC4021] named for them. The specification document should be added. The full list is in Appendix C; the distinct documents involved are: +===============+===========================================+ | Specification | Fields | | document | | +===============+===========================================+ | RFC 2156 | the 33 X.400/MIXER fields, incl. the | | ([MIXER]) | "X400-_" family and "Discarded-X400-_" | +---------------+-------------------------------------------+ | RFC 1327 | Content-Return, Obsoletes, Expiry-Date, | Gondwana Expires 30 January 2027 [Page 22] Internet-Draft Header Field Registry Maintenance July 2026 | | Content-Identifier | +---------------+-------------------------------------------+ | RFC 822 | Encrypted | +---------------+-------------------------------------------+ | RFC 2045 | MIME-Version (§4), Content-Type (§5), | | ([MIME1]) | 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-Help, List-Subscribe, List- | | ([LIST-URLS]) | Unsubscribe, List-Post, List-Owner, List- | | | Archive | +---------------+-------------------------------------------+ | RFC 2919 | List-ID | | ([LIST-ID]) | | +---------------+-------------------------------------------+ | RFC 8098 | Disposition-Notification-To, Disposition- | | ([MDN]) | Notification-Options (RFC 4021 named RFC | | | 2298, since obsoleted twice) | +---------------+-------------------------------------------+ | RFC 1505 | Encoding | +---------------+-------------------------------------------+ Table 2: Specification documents named by RFC 4021 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. Gondwana Expires 30 January 2027 [Page 23] Internet-Draft Header Field Registry Maintenance July 2026 7.2. Superseded references These entries cite a document that has since been obsoleted. The document in force should be added; this document does not recommend removing the historical citation, which remains accurate as to where the field came from. +==================================+==========+==============+=====+ | Field | Cites | Obsoleted by |Add | +==================================+==========+==============+=====+ | Original-Recipient | RFC | RFC 8098, |RFC | | | 3798, | RFC 6533 |8098,| | | RFC 5337 | respectively |RFC | | | | |6533 | +----------------------------------+----------+--------------+-----+ | Disposition-Notification-To, | RFC 4021 | RFC 3798, |RFC | | Disposition-Notification-Options | (naming | then RFC |8098,| | | RFC | 8098 |RFC | | | 2298) | |6533 | +----------------------------------+----------+--------------+-----+ Table 3: Superseded references 7.3. Missing formal updates 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. Gondwana Expires 30 January 2027 [Page 24] Internet-Draft Header Field Registry Maintenance July 2026 +=================================+=======+================+ | Field | Cites | Add (formal | | | | updaters) | +=================================+=======+================+ | DKIM-Signature | RFC | RFC 8301, RFC | | | 6376 | 8463, RFC 8616 | +---------------------------------+-------+----------------+ | Received-SPF | RFC | RFC 7372, RFC | | | 7208 | 8616 | +---------------------------------+-------+----------------+ | Auto-Submitted | RFC | RFC 5436 | | | 3834 | | +---------------------------------+-------+----------------+ | MIME-Version, Content-Type, | RFC | RFC 2231, RFC | | Content-Transfer-Encoding, | 4021 | 6532 | | Content-ID, Content-Description | | | +---------------------------------+-------+----------------+ | Content-Disposition | RFC | RFC 2231 | | | 4021 | | +---------------------------------+-------+----------------+ | Message-Context | RFC | RFC 3938 | | | 4021 | | +---------------------------------+-------+----------------+ Table 4: Missing formal updates 8. IANA Considerations 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. 8.1. Mechanism The changes recommended here are a single retroactive update to existing entries, of the kind Crocker proposed and Kucherawy and Resnick supported in the exchange quoted in Section 2.3: 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. Gondwana Expires 30 January 2027 [Page 25] Internet-Draft Header Field Registry Maintenance July 2026 8.2. Status changes * "MT-Priority": "standard" to "informational" (Section 4). * "Solicitation": blank to "standard" (Section 4). * The "List-*" family and "List-ID": blank to "standard" (Section 4.5). * The [RFC4021] cohort: blank to the value [RFC4021] supplied, as tabulated in Appendix 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. 8.3. Trace changes 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. 8.4. Reference changes As tabulated in Section 7, listed per field in Appendix C and Appendix D. Gondwana Expires 30 January 2027 [Page 26] Internet-Draft Header Field Registry Maintenance July 2026 9. Security Considerations 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. 10. References 10.1. Normative References [MAIL] Resnick, P., "Internet Message Format", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis-12, 13 June 2024, . [REG-PROC] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Gondwana Expires 30 January 2027 [Page 27] Internet-Draft Header Field Registry Maintenance July 2026 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, DOI 10.17487/RFC4021, March 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SMTP] Klensin, J. C., "Simple Mail Transfer Protocol", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis- 44, 31 July 2025, . 10.2. Informative References [ARC] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. Kucherawy, Ed., "The Authenticated Received Chain (ARC) Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, . [AUTHRES] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, . [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [I-D.ietf-mailmaint-expires] BILLON, B. and J. R. Levine, "Updated Use of the Expires Message Header Field", Work in Progress, Internet-Draft, draft-ietf-mailmaint-expires-06, 30 April 2026, . [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, DOI 10.17487/RFC2919, March 2001, . [LIST-URLS] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, DOI 10.17487/RFC2369, July 1998, . Gondwana Expires 30 January 2027 [Page 28] Internet-Draft Header Field Registry Maintenance July 2026 [MAIL-OLD] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [MDN] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, . [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [MIXER] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, DOI 10.17487/RFC2156, January 1998, . [NETNEWS-ARCH] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, . [NETNEWS-FMT] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, DOI 10.17487/RFC5536, November 2009, . [RFC1049] Sirbu, M., "Content-type header field for Internet messages", RFC 1049, DOI 10.17487/RFC1049, March 1988, . [RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, DOI 10.17487/RFC1327, May 1992, . [RFC1505] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1505, DOI 10.17487/RFC1505, August 1993, . [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, DOI 10.17487/RFC1864, October 1995, . Gondwana Expires 30 January 2027 [Page 29] Internet-Draft Header Field Registry Maintenance July 2026 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, DOI 10.17487/RFC2068, January 1997, . [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, DOI 10.17487/RFC2076, February 1997, . [RFC2110] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, DOI 10.17487/RFC2110, March 1997, . [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, DOI 10.17487/RFC2183, August 1997, . [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, . [RFC2298] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, DOI 10.17487/RFC2298, March 1998, . [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, . [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, . Gondwana Expires 30 January 2027 [Page 30] Internet-Draft Header Field Registry Maintenance July 2026 [RFC2912] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, DOI 10.17487/RFC2912, September 2000, . [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, DOI 10.17487/RFC3282, May 2002, . [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, DOI 10.17487/RFC3297, July 2002, . [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, DOI 10.17487/RFC3458, January 2003, . [RFC3798] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, DOI 10.17487/RFC3798, May 2004, . [RFC3803] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, DOI 10.17487/RFC3803, June 2004, . [RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, DOI 10.17487/RFC3834, August 2004, . [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, DOI 10.17487/RFC3865, September 2004, . [RFC3938] Hansen, T., "Video-Message Message-Context", RFC 3938, DOI 10.17487/RFC3938, October 2004, . [RFC5436] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: mailto", RFC 5436, DOI 10.17487/RFC5436, January 2009, . [RFC5504] Fujiwara, K., Ed. and Y. Yoneya, Ed., "Downgrading Mechanism for Email Address Internationalization", RFC 5504, DOI 10.17487/RFC5504, March 2009, . Gondwana Expires 30 January 2027 [Page 31] Internet-Draft Header Field Registry Maintenance July 2026 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, . [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", RFC 5703, DOI 10.17487/RFC5703, October 2009, . [RFC6477] Melnikov, A. and G. Lunt, "Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail", RFC 6477, DOI 10.17487/RFC6477, January 2012, . [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, . [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, . [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, . [RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", RFC 6710, DOI 10.17487/RFC6710, August 2012, . [RFC6758] Melnikov, A. and K. Carlberg, "Tunneling of SMTP Message Transfer Priorities", RFC 6758, DOI 10.17487/RFC6758, October 2012, . [RFC6854] Leiba, B., "Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields", RFC 6854, DOI 10.17487/RFC6854, March 2013, . [RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for Internationalized Email Messages", RFC 6857, DOI 10.17487/RFC6857, March 2013, . Gondwana Expires 30 January 2027 [Page 32] Internet-Draft Header Field Registry Maintenance July 2026 [RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, July 2014, . [RFC7444] Zeilenga, K. and A. Melnikov, "Security Labels in Internet Email", RFC 7444, DOI 10.17487/RFC7444, February 2015, . [RFC7681] Davin, J., "Email Exchange of Secondary School Transcripts", RFC 7681, DOI 10.17487/RFC7681, October 2015, . [RFC7912] Melnikov, A., "Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure", RFC 7912, DOI 10.17487/RFC7912, June 2016, . [RFC8255] Tomkinson, N. and N. Borenstein, "Multiple Language Content Type", RFC 8255, DOI 10.17487/RFC8255, October 2017, . [RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)", RFC 8301, DOI 10.17487/RFC8301, January 2018, . [RFC8315] Baeuerle, M., "Cancel-Locks in Netnews Articles", RFC 8315, DOI 10.17487/RFC8315, February 2018, . [RFC8463] Levine, J., "A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)", RFC 8463, DOI 10.17487/RFC8463, September 2018, . [RFC8553] Crocker, D., "DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names", BCP 222, RFC 8553, DOI 10.17487/RFC8553, March 2019, . [RFC9228] Crocker, D., Ed., "Delivered-To Email Header Field", RFC 9228, DOI 10.17487/RFC9228, April 2022, . [SMTP-OLD] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . Gondwana Expires 30 January 2027 [Page 33] Internet-Draft Header Field Registry Maintenance July 2026 [SPF] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [TRACE-REG] Moonesamy, S. and J. R. Levine, "Mail Header Trace Fields", Work in Progress, Internet-Draft, draft-levine- trace-header-registry-01, 22 January 2012, . Appendix A. Acknowledgements 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. Appendix B. Reproducing the analysis 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: 1. 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. 2. 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. Gondwana Expires 30 January 2027 [Page 34] Internet-Draft Header Field Registry Maintenance July 2026 3. 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. 4. 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. Appendix C. What RFC 4021 told IANA 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 |RFC |Document |Recommended |Registry | | |Status |4021|in force | |now | | | |spec| | | | | | |doc | | | | +===============+============+====+==========+============+=========+ |Accept-Language|standards- |RFC |RFC 3282 |standard |(blank) | | |track |3282| | | | +---------------+------------+----+----------+------------+---------+ |Alternate- |standards- |RFC |RFC 2156 |standard |(blank) | Gondwana Expires 30 January 2027 [Page 35] Internet-Draft Header Field Registry Maintenance July 2026 |Recipient |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Autoforwarded |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Autosubmitted |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Content- |work-in- |RFC |RFC 3297 |standard |(blank) | |Alternative |progress |3297| | | | +---------------+------------+----+----------+------------+---------+ |Content-Base |standards- |RFC |RFC 2110 |obsoleted |obsoleted| | |track |2110|(dropped | | | | | | |by | | | | | | |successor)| | | +---------------+------------+----+----------+------------+---------+ |Content- |standards- |RFC |RFC 2045 |standard |(blank) | |Description |track |2045| | | | | | |§8 | | | | +---------------+------------+----+----------+------------+---------+ |Content- |standards- |RFC |RFC 2183 |standard |(blank) | |Disposition |track |2183| | | | +---------------+------------+----+----------+------------+---------+ |Content- |standards- |RFC |RFC 3803 |standard |(blank) | |Duration |track |2424|(obsoletes| | | | | | |RFC 2424) | | | +---------------+------------+----+----------+------------+---------+ |Content- |standards- |RFC |RFC 2912 |standard |(blank) | |features |track |2912| | | | | | |§3 | | | | +---------------+------------+----+----------+------------+---------+ |Content-ID |standards- |RFC |RFC 2045 |standard |(blank) | | |track |2045| | | | | | |§7 | | | | +---------------+------------+----+----------+------------+---------+ |Content- |obsolete |RFC |RFC 1327 |obsoleted |(blank) | |Identifier | |1327|(dropped | | | | | | |by | | | | | | |successor)| | | +---------------+------------+----+----------+------------+---------+ |Content- |standards- |RFC |RFC 3282 |standard |(blank) | |Language |track |3282| | | | +---------------+------------+----+----------+------------+---------+ |Content- |standards- |RFC |RFC 2557 |standard |(blank) | |Location |track |2557| | | | +---------------+------------+----+----------+------------+---------+ |Content-MD5 |standards- |RFC |RFC 1864 |standard |(blank) | | |track |1864| | | | Gondwana Expires 30 January 2027 [Page 36] Internet-Draft Header Field Registry Maintenance July 2026 +---------------+------------+----+----------+------------+---------+ |Content-Return |obsolete |RFC |RFC 1327 |obsoleted |(blank) | | | |1327|(dropped | | | | | | |by | | | | | | |successor)| | | +---------------+------------+----+----------+------------+---------+ |Content- |standards- |RFC |RFC 2045 |standard |(blank) | |Transfer- |track |2045| | | | |Encoding | |§6 | | | | +---------------+------------+----+----------+------------+---------+ |Content-Type |standards- |RFC |RFC 2045 |standard |(blank) | | |track |2045| | | | | | |§5 | | | | +---------------+------------+----+----------+------------+---------+ |Conversion |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Conversion- |standards- |RFC |RFC 2156 |standard |(blank) | |With-Loss |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Deferred- |standards- |RFC |RFC 2156 |standard |(blank) | |Delivery |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Delivery-Date |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Discarded-X400-|standards- |RFC |RFC 2156 |standard |(blank) | |IPMS-Extensions|track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Discarded-X400-|standards- |RFC |RFC 2156 |standard |(blank) | |MTS-Extensions |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Disclose- |standards- |RFC |RFC 2156 |standard |(blank) | |Recipients |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Disposition- |standards- |RFC |RFC 8098 |standard |(blank) | |Notification- |track |2298|(obsoletes| | | |Options | | |RFC 2298) | | | +---------------+------------+----+----------+------------+---------+ |Disposition- |standards- |RFC |RFC 8098 |standard |(blank) | |Notification-To|track |2298|(obsoletes| | | | | | |RFC 2298) | | | +---------------+------------+----+----------+------------+---------+ |DL-Expansion- |standards- |RFC |RFC 2156 |standard |(blank) | |History |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Encoding |experimental|RFC |RFC 1505 |experimental|(blank) | | | |1505| | | | Gondwana Expires 30 January 2027 [Page 37] Internet-Draft Header Field Registry Maintenance July 2026 +---------------+------------+----+----------+------------+---------+ |Encrypted |obsolete |RFC |RFC 822 |obsoleted |(blank) | | | |822 |(dropped | | | | | | |by | | | | | | |successor)| | | +---------------+------------+----+----------+------------+---------+ |Expires |standards- |RFC |RFC 2156 |standard |standard | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Expiry-Date |obsolete |RFC |RFC 1327 |obsoleted |(blank) | | | |1327|(dropped | | | | | | |by | | | | | | |successor)| | | +---------------+------------+----+----------+------------+---------+ |Generate- |standards- |RFC |RFC 2156 |standard |(blank) | |Delivery-Report|track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Importance |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Incomplete-Copy|standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Language |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Latest- |standards- |RFC |RFC 2156 |standard |(blank) | |Delivery-Time |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |List-Archive |standards- |RFC |RFC 2369 |standard |(blank) | | |track |2369| | | | +---------------+------------+----+----------+------------+---------+ |List-Help |standards- |RFC |RFC 2369 |standard |(blank) | | |track |2369| | | | +---------------+------------+----+----------+------------+---------+ |List-ID |standards- |RFC |RFC 2919 |standard |(blank) | | |track |2919| | | | +---------------+------------+----+----------+------------+---------+ |List-Owner |standards- |RFC |RFC 2369 |standard |(blank) | | |track |2369| | | | +---------------+------------+----+----------+------------+---------+ |List-Post |standards- |RFC |RFC 2369 |standard |(blank) | | |track |2369| | | | +---------------+------------+----+----------+------------+---------+ |List-Subscribe |standards- |RFC |RFC 2369 |standard |(blank) | | |track |2369| | | | +---------------+------------+----+----------+------------+---------+ |List- |standards- |RFC |RFC 2369 |standard |(blank) | Gondwana Expires 30 January 2027 [Page 38] Internet-Draft Header Field Registry Maintenance July 2026 |Unsubscribe |track |2369| | | | +---------------+------------+----+----------+------------+---------+ |Message-Context|standards- |RFC |RFC 3458 |standard |(blank) | | |track |3458| | | | +---------------+------------+----+----------+------------+---------+ |Message-Type |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |MIME-Version |standards- |RFC |RFC 2045 |standard |(blank) | | |track |2045| | | | | | |§4 | | | | +---------------+------------+----+----------+------------+---------+ |Obsoletes |obsolete |RFC |RFC 1327 |obsoleted |(blank) | | | |1327|(dropped | | | | | | |by | | | | | | |successor)| | | +---------------+------------+----+----------+------------+---------+ |Original- |standards- |RFC |RFC 2156 |standard |(blank) | |Encoded- |track |2156| | | | |Information- | | | | | | |Types | | | | | | +---------------+------------+----+----------+------------+---------+ |Original- |standards- |RFC |RFC 3297 |standard |(blank) | |Message-ID |track |3297| | | | +---------------+------------+----+----------+------------+---------+ |Originator- |standards- |RFC |RFC 2156 |standard |(blank) | |Return-Address |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |PICS-Label |standard |W3C |W3C PICS |standard |(blank) | | | |PICS|Rec. | | | +---------------+------------+----+----------+------------+---------+ |Prevent- |standards- |RFC |RFC 2156 |standard |(blank) | |NonDelivery- |track |2156| | | | |Report | | | | | | +---------------+------------+----+----------+------------+---------+ |Priority |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Reply-By |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Sensitivity |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |Supersedes |standards- |RFC |RFC 2156 |standard |standard | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |X400-Content- |standards- |RFC |RFC 2156 |standard |(blank) | Gondwana Expires 30 January 2027 [Page 39] Internet-Draft Header Field Registry Maintenance July 2026 |Identifier |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |X400-Content- |standards- |RFC |RFC 2156 |standard |(blank) | |Return |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |X400-Content- |standards- |RFC |RFC 2156 |standard |(blank) | |Type |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |X400-MTS- |standards- |RFC |RFC 2156 |standard |(blank) | |Identifier |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |X400-Originator|standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |X400-Received |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |X400-Recipients|standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ |X400-Trace |standards- |RFC |RFC 2156 |standard |(blank) | | |track |2156| | | | +---------------+------------+----+----------+------------+---------+ Table 5: Status and specification document supplied by RFC 4021 Appendix D. Per-field recommended state 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|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 3282* | +-------------------+----+-------+---------------+-----+-----------+ Gondwana Expires 30 January 2027 [Page 40] Internet-Draft Header Field Registry Maintenance July 2026 |Also-Control |perm|netnews|obsoleted |— |RFC 1849, | | | | | | |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Alternate-Recipient|perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Apparently-To |prov|mail |*informational*|— |RFC 2076 | +-------------------+----+-------+---------------+-----+-----------+ |Approved |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |ARC-Authentication-|perm|mail |experimental |*yes*|RFC 8617 | |Results | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |ARC-Message- |perm|mail |experimental |*yes*|RFC 8617 | |Signature | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |ARC-Seal |perm|mail |experimental |*yes*|RFC 8617 | +-------------------+----+-------+---------------+-----+-----------+ |Archive |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Archived-At |perm|mail |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- |perm|mail |standard |*yes*|RFC 8601 | |Results | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |Author |prov|mail |*experimental* |— |RFC 9057 | +-------------------+----+-------+---------------+-----+-----------+ |Auto-Submitted |perm|mail |standard |*yes*|RFC 3834, | | | | | | |*RFC 5436* | +-------------------+----+-------+---------------+-----+-----------+ |Autoforwarded |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Autosubmitted |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Base |perm|MIME |obsoleted |— |RFC 1808, | | | | | | |RFC 2068 | +-------------------+----+-------+---------------+-----+-----------+ |Bcc |perm|mail |standard |no |draft-ietf-| Gondwana Expires 30 January 2027 [Page 41] Internet-Draft Header Field Registry Maintenance July 2026 | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Body |perm|none |reserved |— |RFC 6068 | +-------------------+----+-------+---------------+-----+-----------+ |Cancel-Key |perm|netnews|standard |— |RFC 8315 | +-------------------+----+-------+---------------+-----+-----------+ |Cancel-Lock |perm|netnews|standard |— |RFC 8315 | +-------------------+----+-------+---------------+-----+-----------+ |Cc |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |CFBL-Address |prov|mail |*experimental* |— |RFC 9477 | +-------------------+----+-------+---------------+-----+-----------+ |CFBL-Feedback-ID |prov|mail |*experimental* |— |RFC 9477 | +-------------------+----+-------+---------------+-----+-----------+ |Comments |perm|mail |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, | Gondwana Expires 30 January 2027 [Page 42] Internet-Draft Header Field Registry Maintenance July 2026 | | | | | |*RFC 2045*,| | | | | | |*RFC 2231*,| | | | | | |*RFC 6532* | +-------------------+----+-------+---------------+-----+-----------+ |Content-Identifier |perm|mail |*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|mail |*obsoleted* |— |RFC 4021, | | | | | | |*RFC 1327* | +-------------------+----+-------+---------------+-----+-----------+ |Content-Transfer- |perm|MIME |*standard* |— |RFC 4021, | |Encoding | | | | |*RFC 2045*,| | | | | | |*RFC 2231*,| | | | | | |*RFC 6532* | +-------------------+----+-------+---------------+-----+-----------+ |Content- |perm|MIME |standard |— |RFC 8255 | |Translation-Type | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |Content-Type |perm|MIME |*standard* |— |RFC 4021, | | | | | | |RFC 9788, | | | | | | |*RFC 2045*,| | | | | | |*RFC 2231*,| | | | | | |*RFC 6532* | +-------------------+----+-------+---------------+-----+-----------+ |Control |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Conversion |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Conversion-With- |perm|mail |*standard* |— |RFC 4021, | |Loss | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Date |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Date |perm|netnews|standard |— |RFC 5536, | | | | | | |draft-ietf-| | | | | | |emailcore- | Gondwana Expires 30 January 2027 [Page 43] Internet-Draft Header Field Registry Maintenance July 2026 | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Date-Received |perm|netnews|obsoleted |— |RFC 850, | | | | | | |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Deferred-Delivery |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Delivered-To |prov|mail |*experimental* |*yes*|RFC 9228 | +-------------------+----+-------+---------------+-----+-----------+ |Delivery-Date |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Discarded-X400- |perm|mail |*standard* |— |RFC 4021, | |IPMS-Extensions | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Discarded-X400-MTS-|perm|mail |*standard* |— |RFC 4021, | |Extensions | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Disclose-Recipients|perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Disposition- |perm|mail |*standard* |— |RFC 4021, | |Notification- | | | | |*RFC 8098*,| |Options | | | | |*RFC 6533* | +-------------------+----+-------+---------------+-----+-----------+ |Disposition- |perm|mail |*standard* |— |RFC 4021, | |Notification-To | | | | |*RFC 8098*,| | | | | | |*RFC 6533* | +-------------------+----+-------+---------------+-----+-----------+ |Distribution |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |DKIM-Signature |perm|mail |standard |*yes*|RFC 6376, | | | | | | |*RFC 8301*,| | | | | | |*RFC 8463*,| | | | | | |*RFC 8616* | +-------------------+----+-------+---------------+-----+-----------+ |DL-Expansion- |perm|mail |*standard* |*yes*|RFC 4021, | |History | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Bcc |perm|mail |obsoleted |— |RFC 5504, | | | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Cc |perm|mail |obsoleted |— |RFC 5504, | | | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded- |perm|mail |obsoleted |— |RFC 5504, | |Disposition- | | | | |RFC 6857 | Gondwana Expires 30 January 2027 [Page 44] Internet-Draft Header Field Registry Maintenance July 2026 |Notification-To | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Final- |perm|mail |standard |— |RFC 6857 | |Recipient | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-From |perm|mail |obsoleted |— |RFC 5504, | | | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-In- |perm|mail |standard |— |RFC 6857 | |Reply-To | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Mail- |perm|mail |obsoleted |— |RFC 5504, | |From | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Message-|perm|mail |standard |— |RFC 6857 | |Id | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded- |perm|mail |standard |— |RFC 6857 | |Original-Recipient | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Rcpt-To |perm|mail |obsoleted |— |RFC 5504, | | | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded- |perm|mail |standard |— |RFC 6857 | |References | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Reply-To|perm|mail |obsoleted |— |RFC 5504, | | | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Resent- |perm|mail |obsoleted |— |RFC 5504, | |Bcc | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Resent- |perm|mail |obsoleted |— |RFC 5504, | |Cc | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Resent- |perm|mail |obsoleted |— |RFC 5504, | |From | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Resent- |perm|mail |obsoleted |— |RFC 5504, | |Reply-To | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Resent- |perm|mail |obsoleted |— |RFC 5504, | |Sender | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Resent- |perm|mail |obsoleted |— |RFC 5504, | |To | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Return- |perm|mail |obsoleted |— |RFC 5504, | Gondwana Expires 30 January 2027 [Page 45] Internet-Draft Header Field Registry Maintenance July 2026 |Path | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-Sender |perm|mail |obsoleted |— |RFC 5504, | | | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |Downgraded-To |perm|mail |obsoleted |— |RFC 5504, | | | | | | |RFC 6857 | +-------------------+----+-------+---------------+-----+-----------+ |EDIINT-Features |prov|mail |*informational*|— |RFC 6017 | +-------------------+----+-------+---------------+-----+-----------+ |Eesst-Version |prov|mail |*informational*|— |RFC 7681 | +-------------------+----+-------+---------------+-----+-----------+ |Encoding |perm|mail |*experimental* |— |RFC 4021, | | | | | | |*RFC 1505* | +-------------------+----+-------+---------------+-----+-----------+ |Encrypted |perm|mail |*obsoleted* |— |RFC 4021, | | | | | | |*RFC 822* | +-------------------+----+-------+---------------+-----+-----------+ |Errors-To |prov|mail |*informational*|— |RFC 2076 | +-------------------+----+-------+---------------+-----+-----------+ |Expires |perm|mail |standard |— |draft-ietf-| | | | | | |mailmaint- | | | | | | |expires | +-------------------+----+-------+---------------+-----+-----------+ |Expires |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Expiry-Date |perm|mail |*obsoleted* |— |RFC 4021, | | | | | | |*RFC 1327* | +-------------------+----+-------+---------------+-----+-----------+ |Face |prov|mail |— |— |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |Face |prov|netnews|— |— |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |Followup-To |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Form-Sub |prov|mail |— |— |draft- | | | | | | |levine- | | | | | | |mailbomb- | | | | | | |header-00 | +-------------------+----+-------+---------------+-----+-----------+ |From |perm|mail |standard |no |RFC 6854, | | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |From |perm|netnews|standard |— |RFC 5536, | Gondwana Expires 30 January 2027 [Page 46] Internet-Draft Header Field Registry Maintenance July 2026 | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Generate-Delivery- |perm|mail |*standard* |— |RFC 4021, | |Report | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |HP-Outer |perm|mail |standard |— |RFC 9788 | +-------------------+----+-------+---------------+-----+-----------+ |Importance |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |In-Reply-To |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Incomplete-Copy |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Injection-Date |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Injection-Info |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Jabber-ID |prov|mail |*informational*|— |RFC 7259 | +-------------------+----+-------+---------------+-----+-----------+ |Jabber-ID |prov|netnews|*informational*|— |RFC 7259 | +-------------------+----+-------+---------------+-----+-----------+ |Keywords |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Keywords |perm|netnews|standard |— |RFC 5536, | | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Language |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Latest-Delivery- |perm|mail |*standard* |— |RFC 4021, | |Time | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Lines |perm|netnews|deprecated |— |RFC 5536, | | | | | | |RFC 3977 | +-------------------+----+-------+---------------+-----+-----------+ |List-Archive |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2369* | +-------------------+----+-------+---------------+-----+-----------+ Gondwana Expires 30 January 2027 [Page 47] Internet-Draft Header Field Registry Maintenance July 2026 |List-Help |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2369* | +-------------------+----+-------+---------------+-----+-----------+ |List-ID |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2919* | +-------------------+----+-------+---------------+-----+-----------+ |List-Owner |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2369* | +-------------------+----+-------+---------------+-----+-----------+ |List-Post |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2369* | +-------------------+----+-------+---------------+-----+-----------+ |List-Subscribe |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2369* | +-------------------+----+-------+---------------+-----+-----------+ |List-Unsubscribe |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2369* | +-------------------+----+-------+---------------+-----+-----------+ |List-Unsubscribe- |perm|mail |standard |— |RFC 8058 | |Post | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |Message-Context |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 3458*,| | | | | | |*RFC 3938* | +-------------------+----+-------+---------------+-----+-----------+ |Message-ID |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Message-ID |perm|netnews|standard |— |RFC 5536, | | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Message-Type |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |MIME-Version |perm|MIME |*standard* |— |RFC 4021, | | | | | | |*RFC 2045*,| | | | | | |*RFC 2231*,| | | | | | |*RFC 6532* | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Acp127- |perm|mail |*informational*|— |RFC 6477, | |Message-Identifier | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Authorizing- |prov|mail |*informational*|— |RFC 7912 | |Users | | | | | | Gondwana Expires 30 January 2027 [Page 48] Internet-Draft Header Field Registry Maintenance July 2026 +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Codress- |perm|mail |*informational*|— |RFC 6477, | |Message-Indicator | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Copy- |perm|mail |*informational*|— |RFC 6477, | |Precedence | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Exempted- |perm|mail |*informational*|— |RFC 6477, | |Address | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Extended- |perm|mail |*informational*|— |RFC 6477, | |Authorisation-Info | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Handling- |perm|mail |*informational*|— |RFC 6477, | |Instructions | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Message- |perm|mail |*informational*|— |RFC 6477, | |Instructions | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Message-Type |perm|mail |*informational*|— |RFC 6477, | | | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Originator- |perm|mail |*informational*|— |RFC 6477, | |PLAD | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Originator- |perm|mail |*informational*|— |RFC 6477, | |Reference | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Other- |perm|mail |*informational*|— |RFC 6477, | |Recipients- | | | | |(non-RFC | |Indicator-CC | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Other- |perm|mail |*informational*|— |RFC 6477, | |Recipients- | | | | |(non-RFC | |Indicator-To | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Primary- |perm|mail |*informational*|— |RFC 6477, | |Precedence | | | | |(non-RFC | | | | | | |ref) | Gondwana Expires 30 January 2027 [Page 49] Internet-Draft Header Field Registry Maintenance July 2026 +-------------------+----+-------+---------------+-----+-----------+ |MMHS-Subject- |perm|mail |*informational*|— |RFC 6477, | |Indicator-Codes | | | | |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |MT-Priority |perm|mail |*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|mail |*obsoleted* |— |RFC 4021, | | | | | | |*RFC 1327* | +-------------------+----+-------+---------------+-----+-----------+ |Organization |perm|mail |informational |— |RFC 7681 | +-------------------+----+-------+---------------+-----+-----------+ |Organization |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Original-Encoded- |perm|mail |*standard* |— |RFC 4021, | |Information-Types | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Original-From |perm|mail |standard |— |RFC 5703 | +-------------------+----+-------+---------------+-----+-----------+ |Original-Message-ID|perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 3297* | +-------------------+----+-------+---------------+-----+-----------+ |Original-Recipient |perm|mail |standard |— |RFC 3798, | | | | | | |RFC 5337, | | | | | | |*RFC 8098*,| | | | | | |*RFC 6533* | +-------------------+----+-------+---------------+-----+-----------+ |Original-Sender |perm|netnews|standard |— |RFC 5537 | +-------------------+----+-------+---------------+-----+-----------+ |Original-Subject |perm|mail |standard |— |RFC 5703 | +-------------------+----+-------+---------------+-----+-----------+ |Originator-Return- |perm|mail |*standard* |— |RFC 4021, | |Address | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Path |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |PICS-Label |perm|mail |*standard* |— |RFC 4021 | +-------------------+----+-------+---------------+-----+-----------+ |Posting-Version |perm|netnews|obsoleted |— |RFC 850, | | | | | | |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ Gondwana Expires 30 January 2027 [Page 50] Internet-Draft Header Field Registry Maintenance July 2026 |Prevent- |perm|mail |*standard* |— |RFC 4021, | |NonDelivery-Report | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Priority |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Privicon |prov|mail |— |— |draft- | | | | | | |koenig- | | | | | | |privicons-01| +-------------------+----+-------+---------------+-----+-----------+ |Received |perm|mail |standard |yes |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis,| | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5321bis | +-------------------+----+-------+---------------+-----+-----------+ |Received-SPF |perm|mail |standard |*yes*|RFC 7208, | | | | | | |*RFC 7372*,| | | | | | |*RFC 8616* | +-------------------+----+-------+---------------+-----+-----------+ |References |perm|mail |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|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Reply-To |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Reply-To |perm|netnews|standard |— |RFC 5536, | | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Require-Recipient- |perm|mail |standard |— |RFC 7293 | |Valid-Since | | | | | | +-------------------+----+-------+---------------+-----+-----------+ Gondwana Expires 30 January 2027 [Page 51] Internet-Draft Header Field Registry Maintenance July 2026 |Resent-Bcc |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Resent-Cc |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Resent-Date |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Resent-From |perm|mail |standard |no |RFC 6854, | | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Resent-Message-ID |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Resent-Reply-To |perm|mail |obsoleted |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Resent-Sender |perm|mail |standard |no |RFC 6854, | | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Resent-To |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Return-Path |perm|mail |standard |yes |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis,| | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5321bis | +-------------------+----+-------+---------------+-----+-----------+ |See-Also |perm|netnews|obsoleted |— |RFC 1849, | | | | | | |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Sender |perm|mail |standard |no |RFC 6854, | | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | Gondwana Expires 30 January 2027 [Page 52] Internet-Draft Header Field Registry Maintenance July 2026 +-------------------+----+-------+---------------+-----+-----------+ |Sender |perm|netnews|standard |— |RFC 5536, | | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Sensitivity |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |SIO-Label |prov|mail |*informational*|— |RFC 7444 | +-------------------+----+-------+---------------+-----+-----------+ |SIO-Label-History |prov|mail |*informational*|*yes*|RFC 7444 | +-------------------+----+-------+---------------+-----+-----------+ |Solicitation |perm|mail |*standard* |— |RFC 3865 | +-------------------+----+-------+---------------+-----+-----------+ |Subject |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Subject |perm|netnews|standard |— |RFC 5536, | | | | | | |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |Summary |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ |Supersedes |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Supersedes |perm|netnews|standard |— |RFC 5536, | | | | | | |RFC 2156 | +-------------------+----+-------+---------------+-----+-----------+ |TLS-Report-Domain |perm|mail |standard |— |RFC 8460 | +-------------------+----+-------+---------------+-----+-----------+ |TLS-Report- |perm|mail |standard |— |RFC 8460 | |Submitter | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |TLS-Required |perm|mail |standard |— |RFC 8689 | +-------------------+----+-------+---------------+-----+-----------+ |To |perm|mail |standard |no |draft-ietf-| | | | | | |emailcore- | | | | | | |rfc5322bis | +-------------------+----+-------+---------------+-----+-----------+ |User-Agent |perm|netnews|standard |— |RFC 5536, | | | | | | |RFC 2616 | +-------------------+----+-------+---------------+-----+-----------+ |VBR-Info |perm|mail |standard |*yes*|RFC 5518 | +-------------------+----+-------+---------------+-----+-----------+ Gondwana Expires 30 January 2027 [Page 53] Internet-Draft Header Field Registry Maintenance July 2026 |Wrong-Recipient |prov|mail |— |— |draft-ietf-| | | | | | |mailmaint- | | | | | | |wrong- | | | | | | |recipient-00| +-------------------+----+-------+---------------+-----+-----------+ |X-Archived-At |prov|mail |deprecated |— |RFC 5064 | +-------------------+----+-------+---------------+-----+-----------+ |X-Archived-At |prov|netnews|deprecated |— |RFC 5064 | +-------------------+----+-------+---------------+-----+-----------+ |X-Face |prov|mail |— |— |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |X-Face |prov|netnews|— |— |(non-RFC | | | | | | |ref) | +-------------------+----+-------+---------------+-----+-----------+ |X-Mittente |prov|mail |*informational*|— |RFC 6109 | +-------------------+----+-------+---------------+-----+-----------+ |X-PGP-Sig |prov|netnews|— |— |(non-RFC | | | | | | |ref), (non-| | | | | | |RFC ref) | +-------------------+----+-------+---------------+-----+-----------+ |X-Ricevuta |prov|mail |*informational*|— |RFC 6109 | +-------------------+----+-------+---------------+-----+-----------+ |X-Riferimento- |prov|mail |*informational*|— |RFC 6109 | |Message-ID | | | | | | +-------------------+----+-------+---------------+-----+-----------+ |X-TipoRicevuta |prov|mail |*informational*|— |RFC 6109 | +-------------------+----+-------+---------------+-----+-----------+ |X-Trasporto |prov|mail |*informational*|— |RFC 6109 | +-------------------+----+-------+---------------+-----+-----------+ |X-VerificaSicurezza|prov|mail |*informational*|— |RFC 6109 | +-------------------+----+-------+---------------+-----+-----------+ |X400-Content- |perm|mail |*standard* |— |RFC 4021, | |Identifier | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |X400-Content-Return|perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |X400-Content-Type |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |X400-MTS-Identifier|perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |X400-Originator |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |X400-Received |perm|mail |*standard* |— |RFC 4021, | Gondwana Expires 30 January 2027 [Page 54] Internet-Draft Header Field Registry Maintenance July 2026 | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |X400-Recipients |perm|mail |*standard* |— |RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |X400-Trace |perm|mail |*standard* |*yes*|RFC 4021, | | | | | | |*RFC 2156* | +-------------------+----+-------+---------------+-----+-----------+ |Xref |perm|netnews|standard |— |RFC 5536 | +-------------------+----+-------+---------------+-----+-----------+ Table 6: Recommended state of every registry entry Appendix E. Change Log E.1. Since -01 Findings from a systematic re-scan of the RFC series, the two registry exports, and the ietf-822, ietf-smtp, emailcore and ietf- dkim list archives. Corrections to -01: * Section 6.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. Gondwana Expires 30 January 2027 [Page 55] Internet-Draft Header Field Registry Maintenance July 2026 * 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. Gondwana Expires 30 January 2027 [Page 56] Internet-Draft Header Field Registry Maintenance July 2026 * Section 8: a Mechanism subsection. * Normative references changed from [MAIL-OLD] and [SMTP-OLD] to [MAIL] and [SMTP], which are the documents that now govern the registries. E.2. Since -00 * Section 4.1: removed the suggestion that the X.400/MIXER gateway fields might be better recorded as "obsoleted". These fields remain in use in the environments that rely on that gateway work. * Section 4.6 (new): "SIO-Label" and "SIO-Label-History" Status corrected from blank to "informational". * Section 4.7 (new): the fourteen "MMHS-*" fields (RFC 6477) and "MMHS-Authorizing-Users" (RFC 7912) Status corrected from blank to "informational". * Section 6.2: added "SIO-Label-History". * Added "Apparently-To" as a trace field (withdrawn in -02). Author's Address Bron Gondwana Fastmail Email: brong@fastmailteam.com Gondwana Expires 30 January 2027 [Page 57]