]> Fastmail

brong@fastmailteam.com

Internet-Draft 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.

Introduction The IANA "Message Headers" registry group contains three registries: "Permanent Message Header Field Names", "Provisional Message Header Field Names", and "Content-Translation-Type Header Field Values". For each entry the permanent and provisional registries record five pieces of metadata beyond the field name: an optional registration template, the "Protocol" the field belongs to (for example "mail", "MIME", "netnews", or "none"), a "Status" (for example "standard", "informational", "experimental", "obsoleted", "deprecated", or blank), a "Trace" flag, and a "Reference" listing the specifying document(s). Both registries name two governing documents: , which created them, and , which added the "Trace" column. The registration procedures in 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.

Metadata that was supplied but not recorded registered roughly ninety mail and MIME header fields in a single Standards Track document. Section 2 of that document contains a complete 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 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 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 , where told IANA that the field is standards-track and is specified by . 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 .

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 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 , Charles Lindsey read that list as lumping the standards-track maturity levels together, and said so on the ietf-822 list on 2004-05-14: the template "seems to suggest that all the varieties of standard-track document are to be lumped together and assigned the status 'standard'", adding "in the IANA Considerations section of USEFOR, I have followed the registration template as written, and used 'standard' throughout." Graham Klyne, the author of both and , 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'."

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 's netnews fields all read "standard" while '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 list. This document treats both values, "standard" and "standards-track", as the registry's "standard", which is what Klyne and Lindsey each took them to mean.

The Trace column is unfinished, not wrong , 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 , 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.

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.

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.

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 when, and only when, they appear in all capitals, as shown here. The terms "trace field" and "trace header field" are used as defined in , Section 3.6.7 and , Section 4.4.

Prior and Related Work

draft-levine-trace-header-registry In January 2012 John Levine, later with S. Moonesamy, published , "A Registry for Mail Trace Fields" (later "Mail Header Trace Fields"), which proposed exactly the column that has since added, and proposed an initial set of trace fields. Section 3.2 of the -01 revision assembles per-document evidence for Received-SPF, DKIM-Signature, Authentication-Results, VBR-Info and Auto-Submitted that this document reached independently. That draft expired without publication. The present document differs from in three ways. It does not propose to update the definition of trace fields in , because has since done so. It records a binary flag, because that is the column defined, rather than 's richer "MTA/MUA/MSA/MDA" value. And it covers the Status and Reference columns as well as Trace. Where the two agree, is the earlier statement of the position, and this document notes the overlap rather than claiming novelty. In particular identified both the Auto-Submitted trace designation and the incompleteness of that field's Reference column; see .

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 . 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 permits other specifications to designate additional trace fields (), and the caution from Melnikov and John Klensin against inferring trace status from a field's position in the header section ().

The proposed route for retroactive population On 2024-03-18, in review of , Murray Kucherawy raised the question this document answers:

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

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

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

Klensin wrote that he "largely agree(d) with Dave"; Resnick called it "a fine way forward" and reported IANA's agreement to the blank-means-unspecified reading quoted in ; 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. states the mechanism as well as the content.

Methodology Three questions were asked of every registry entry, corresponding to the three classification columns. Where 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 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 , 's "standards-track" is treated as the registry's "standard".

Trace:

Did the field's defining document designate it as belonging within the trace fields grouping? Section 3.6.7 of provides for fields "defined by other specifications as belonging within the trace fields grouping", and Section 4.4.4 of provides that "additional trace fields ... may be defined and registered as described in" . The test is designation by a specification, not observed behaviour; see .

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: The registration instruction. Where names a specification document for a field, that document is the starting point. The obsoletion chain. Where the named specification has been obsoleted, the document in force is the one at the end of the chain, unless that document drops the field, in which case the last document that defined it is cited and the field is treated as obsoleted. For example names for "Disposition-Notification-To"; was obsoleted by , which was in turn obsoleted by , so is the document in force. The formal "Updates:" metadata. Every RFC that carries an "Updates: N" header was recorded as a candidate updater of RFC N. This yields an authoritative, machine-checkable graph. For example and each carry "Updates: 6376" and therefore update the definition of the "DKIM-Signature" field.

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. carries "Updates:" for , and , 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. 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 defines. This exclusion is recorded so that a reader who regenerates the reference sets from the "Updates:" graph alone, and finds three more entries than this document recommends, knows the difference is intentional.

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 (, with where the group syntax applies, and 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 , 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, 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 . A field whose only definition is in an obsoleted document is a different case, and is cited: see .

Status Corrections

Completing the RFC 4021 registrations As set out in , 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 vocabulary as described in . The great majority resolve to "standard". 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. tabulates the whole cohort; the substantive groups are: Thirty-three fields specified by , the MIME/X.400 gateway mapping: the "X400-" family, "Discarded-X400-", "DL-Expansion-History", "Deferred-Delivery", "Latest-Delivery-Time", "Importance", "Priority", "Sensitivity", "Conversion", and the rest. remains a Proposed Standard and has not been obsoleted, so these fields are "standard". ("Expires" is in this group in , but has since been redefined by 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 '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 , and the other MIME fields "Content-Disposition" (), "Content-Language" (), "Content-MD5" (), "Content-features" (), "Content-Location" (), "Content-Duration" () and "Content-Alternative" (). All are "standard". Leaving a peer field such as "Content-Translation-Type" () recorded as "standard" while the MIME fields it sits beside are blank is precisely the inconsistency this document exists to remove. "Accept-Language" (), "Original-Message-ID" (), "Message-Context" (), "Disposition-Notification-To" and "Disposition-Notification-Options" (): "standard". Three fields do not resolve to "standard": "Encoding" is specified by , which is Experimental, and marked it "experimental". The status should be "experimental". "Content-Alternative" was marked "work-in-progress" by , but 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 , citing the W3C PICS label specification. Section 4.2.1 of 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.

Fields whose only definition is in an obsoleted document 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 , which 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 , the obsoleted document is the only definition, so it is cited: for the first four, RFC 822 for "Encrypted". The sixth, "Resent-Reply-To", already carries "obsoleted" by way of its re-registration in . A seventh field of the same shape, "Content-Base", was marked "standards-track" by citing , but obsoleted that document and dropped the field; the registry already records "obsoleted" and cites both documents, and needs no change.

MT-Priority: standard to informational The "MT-Priority" mail field is registered with Status "standard", citing . 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, , 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.

Solicitation: blank to standard The "Solicitation" mail field is registered with a blank Status, citing . 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, ), is registered as "standard". There is no basis in the source documents for treating the two differently; "Solicitation" should be "standard".

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 only, and "List-ID" likewise. They are part of the cohort of : marked all seven "standards-track" and named for the first six and 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.

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 . 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 , the Status of both fields should be "informational".

The MMHS-* fields: blank to informational The fourteen "MMHS-*" fields registered by ("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 , 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 , the Status of every one of these fields should be "informational".

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 gives the provisional registration template a Status of "provisional", "updated if and when the header registration is subsequently moved to the permanent registry". On that reading the column in the provisional registry records the standing of the registration, and the correct value for every entry is a constant. But the registry does not implement that reading: no entry says "provisional" -- the provisionality is carried by which registry the entry is in -- and "X-Archived-At" carries "deprecated", a value drawn from the vocabulary of Section 4.2.1. The column in practice records the standing of the document, exactly as in the permanent registry, and is simply unpopulated. This document recommends the second reading, and that it be applied consistently. Under it the following provisional entries take a status from their defining documents: Field(s) Defining document Category Status Author RFC 9057 Experimental (Independent) experimental Delivered-To RFC 9228 Experimental (Independent) experimental CFBL-Address, CFBL-Feedback-ID RFC 9477 Experimental (Independent) experimental Apparently-To, Errors-To RFC 2076 Informational informational EDIINT-Features RFC 6017 Informational (Independent) informational Eesst-Version RFC 7681 Informational (Independent) informational Jabber-ID (mail and netnews) RFC 7259 Informational (Independent) informational X-Mittente, X-Ricevuta, X-Riferimento-Message-ID, X-TipoRicevuta, X-Trasporto, X-VerificaSicurezza RFC 6109 Informational informational MMHS-Authorizing-Users RFC 7912 Informational (Independent) informational SIO-Label, SIO-Label-History RFC 7444 Informational (Independent) informational Recording "experimental" or "informational" for these entries carries no implication that they are endorsed; as the registry's own note says, "registration of a Provisional Message Header Field does not of itself imply any kind of endorsement by the IETF, IANA or any other body". The value records what the referenced document is. If IANA or the designated expert prefers the first reading, then the recommendations in and for the provisional entries "SIO-Label", "SIO-Label-History" and "MMHS-Authorizing-Users" should be withdrawn along with the table above, and the whole column in that registry set to "provisional". What should not persist is the present position, in which three readings coexist. The remaining provisional entries are left blank, deliberately: "Face", "X-Face" and "X-PGP-Sig" cite informally published specifications that have not been approved by any standards body, so neither branch of Section 4.2.1 of 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.

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 , an Informational document) and as "standard" for protocol "netnews" (citing , 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 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: (Standards Track) retained some of the fields first defined by the Experimental and dropped others, and the registry records exactly that outcome. Note that was obsoleted by , which withdrew the in-transit downgrade mechanism, and that lifted RFC 5504's prohibition on registering further "Downgraded-" fields, as the registry's own note records. "Expires" (mail) is registered as "standard" citing . had named ; the newer document supersedes that definition, and the entry needs no change.

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. 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 and "Base" (MIME) cites , 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.

Trace Corrections

The test , 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 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 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" . 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 , answered "I believe I intended the former as well, and I'll work on a clarification." The controlling question for the column is therefore not "is this one of the two fields listed in Section 3.6.7" but "has a specification designated this field as belonging within the trace fields grouping". Judged that way the column is substantially under-populated, which is what , Section 6.1 intended pending exactly this exercise. Note that , Section 6.1 makes the column applicable only where the Protocol is "mail"; see .

Fields whose defining documents designate them trace fields For each of the following fields a specification states, in terms, that the field is a trace field. The Trace column for each should be "yes". "Received-SPF", , Section 9.1: "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", , 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", , 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", , Section 2: "in the terminology of RFC 5322, VBR-Info is a 'trace header field'". "Auto-Submitted", , 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 . "SIO-Label-History", , 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", and : registered with descriptions that are, respectively, "X400 Trace" and "Trace of distribution lists passed", and derived from the per-hop trace elements of , 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.

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 , which designates it a trace field in terms and gives it an explicit ordering requirement. had identified both this and the fact that the field's Reference column cites only when is the later and more detailed description; adds .

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 as drafted would "allow arbitrary additions to the list of what constitutes such a field with no criteria for such additions other than 'the registrant says it is'", so that "almost any sort of crud (or worse), even potentially undocumented crud, can end up at the top of the header field collection", and gave a real message in which 21 fields preceded the oldest "Received". Melnikov replied on 2022-12-03:

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

This document accepts that position. Position in the header section is not evidence of trace status. What counts is designation by a specification, and a specification may designate a field by imposing the positional rules of a trace field without using the word. On that narrower test two groups qualify: "ARC-Seal", "ARC-Message-Signature" and "ARC-Authentication-Results", : 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", , 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".

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 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", , 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 , which describes the field's contents and use without placing it in the trace grouping. "X400-Received", and : the X.400/MIXER gateway equivalent of "Received". Its sibling "X400-Trace" is designated by its own registered description; "X400-Received" is not, and the analogy to "Received" is not a designation. "Apparently-To", , 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 that recommendation is withdrawn.

The Trace column and the netnews fields Two netnews fields are designated as trace fields by their own documents: "Path", Section 3.1.5 and : each processing agent prepends to the field, its order is significant, and names it a trace header field alongside "Received" ("trace header fields (like Received in Email or Path in Netnews)"). "Injection-Info", Section 3.2.8: added only by the injecting agent, and existing to assist "in tracing the article's true origin"; classes it as trace information. The column cannot record this as it stands. , 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 , Section 6.1 would have to be relaxed -- a change to , 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 : blank means "not yet specified".

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 , Section 6.2. They are prepended as a block and their order is significant, and proposed marking seven of them as trace fields. nonetheless treats the resent block as distinct from the trace block -- Section 3.6 gives them separate productions -- and the registry records that choice. This document does not disturb it. "Solicitation" () 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" () 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" () is a gateway-written preservation copy of a "Sender" field, and deliberately keeps it out of the trace set it defines. "Require-Recipient-Valid-Since" () is generated by the author's domain to carry a delivery request; RFC 7293 discourages the header form entirely. The "Downgraded-*" fields () 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".

Reference List Updates Applying the methodology of , the reference corrections fall into three groups. gives the resulting reference set for every entry.

Specification documents named by RFC 4021 but not recorded These entries cite but not the specification document named for them. The specification document should be added. The full list is in ; the distinct documents involved are: Specification document Fields RFC 2156 () the 33 X.400/MIXER fields, incl. the "X400-" family and "Discarded-X400-" RFC 1327 Content-Return, Obsoletes, Expiry-Date, Content-Identifier RFC 822 Encrypted RFC 2045 () MIME-Version (§4), Content-Type (§5), Content-Transfer-Encoding (§6), Content-ID (§7), Content-Description (§8) RFC 2183 Content-Disposition RFC 3282 Accept-Language, Content-Language RFC 3297 Original-Message-ID, Content-Alternative RFC 3458 Message-Context RFC 1864 Content-MD5 RFC 2912 Content-features RFC 2557 Content-Location RFC 3803 Content-Duration (RFC 4021 named RFC 2424, since obsoleted) RFC 2369 () List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner, List-Archive RFC 2919 () List-ID RFC 8098 () Disposition-Notification-To, Disposition-Notification-Options (RFC 4021 named RFC 2298, since obsoleted twice) RFC 1505 Encoding Note that the previous revision of this document proposed adding both and to the five core MIME fields. names only, with a distinct section per field, and defines media types rather than these header fields. is not added.

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 3798, RFC 5337 RFC 8098, RFC 6533 respectively RFC 8098, RFC 6533 Disposition-Notification-To, Disposition-Notification-Options RFC 4021 (naming RFC 2298) RFC 3798, then RFC 8098 RFC 8098, RFC 6533

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 for the updaters excluded. Field Cites Add (formal updaters) DKIM-Signature RFC 6376 RFC 8301, RFC 8463, RFC 8616 Received-SPF RFC 7208 RFC 7372, RFC 8616 Auto-Submitted RFC 3834 RFC 5436 MIME-Version, Content-Type, Content-Transfer-Encoding, Content-ID, Content-Description RFC 4021 RFC 2231, RFC 6532 Content-Disposition RFC 4021 RFC 2231 Message-Context RFC 4021 RFC 3938

IANA 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.

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 : a collective recommendation, documented, and approved through the normal process, rather than one registration action per field or an RFC per field. 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 and the prose of this document disagree, the prose governs and the table should be corrected.

Status changes "MT-Priority": "standard" to "informational" (). "Solicitation": blank to "standard" (). The "List-*" family and "List-ID": blank to "standard" (). The cohort: blank to the value supplied, as tabulated in -- "standard" for the great majority, "experimental" for "Encoding", and "obsoleted" for "Content-Return", "Obsoletes", "Expiry-Date", "Content-Identifier" and "Encrypted" (, ). "SIO-Label", "SIO-Label-History": blank to "informational" (). The "MMHS-*" fields and "MMHS-Authorizing-Users": blank to "informational" (). The provisional entries tabulated in : blank to "experimental" or "informational" as listed.

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" (). "ARC-Seal", "ARC-Message-Signature", "ARC-Authentication-Results", "Delivered-To" (). 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" (), and the cells for "Original-Recipient", "X400-Received" and "Apparently-To" are left blank for the reasons in .

Reference changes As tabulated in , listed per field in and .

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 and for the withdrawals in .

This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Episteme Technology Consulting LLC This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title, and supersedes RFCs 1846, 7504, and 7505, incorporating all the relevant information in them. This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK] This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. [STANDARDS-TRACK] This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK] The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. [STANDARDS-TRACK] Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes RFC 7601. The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries. Taughannock Networks SMTP mail software adds trace fields to messages as they pass through the mail system. This memo provides background information about trace fields in mail standards. It discusses the use of trace fields in mail-related specifications. It updates the definition of trace header fields, and adds trace field information to the relevant registries. This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and are often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement). This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). [STANDARDS-TRACK] This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. [STANDARDS-TRACK] This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. [STANDARDS-TRACK] The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm. Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry for these names has now been defined by RFC 8552. However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model. This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. [STANDARDS-TRACK] This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles. This document updates RFC 5537. The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations. This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements. Splio Standcore LLC This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message expires, while recipients would use this information to handle an expired message differently. This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS-TRACK] This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK] This memo defines a Multipurpose Internet Mail Extensions (MIME) ' Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. [STANDARDS-TRACK] This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. [STANDARDS-TRACK] This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). [STANDARDS-TRACK] This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS-TRACK] This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard. This content type makes it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK] This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK] This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. [STANDARDS-TRACK] This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. This document is not an Internet Standards Track specification; it is published for informational purposes. This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. [STANDARDS-TRACK] This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. [STANDARDS-TRACK] This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. [STANDARDS-TRACK] This document describes a header field, SIO-Label, for use in Internet email to convey the sensitivity of the message. This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label. A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 and ACP 123. This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes a procedure for when a Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more Authorizing Users authorize release of the message by adding the MMHS-Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures. A common format simplifies exchange of secondary school academic transcripts via electronic mail. Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice. The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements. Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. This memo defines an Experimental Protocol for the Internet community. Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK] HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK] This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. [STANDARDS-TRACK] The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations. It can be helpful for a message to have a common way to record each delivery in such a sequence, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) formulating the author's address in a reply message. This document defines a header field for this information. Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise privacy concerns. A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as an Experimental RFC, looking for constituency and for operational utility. This document was produced through the Independent Submission Stream and was not subject to the IETF's approval process. This memo contains a table of commonly occurring headers in headings of e-mail messages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. [STANDARDS-TRACK] This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called "Require-Recipient-Valid-Since" that can be used to tunnel the request through servers that do not support the extension. The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK] Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content. This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK] Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK] The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message". A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]

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 in the history of the "Content-Type" field, to Rob Sayre for finding , 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 and 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.

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: The two registry CSV exports were compared, entry by entry, against the table in , to confirm that the table covers every entry in both registries and no others. The registration templates in Section 2 of were parsed to extract, for each field, the "Applicable protocol", "Status" and "Specification document(s)" values that document supplied. This is the source of . A status, obsoletes and updates graph was built from the RFC Editor's rfc-index.xml, giving for every RFC its category, what it obsoletes and is obsoleted by, and what it updates and is updated by. This supplies the category of each defining document and the candidate updater lists, and is the basis for following an obsoletion chain to the document in force. Candidate updaters were then reviewed individually against the text of the updating document, to determine whether they modify the definition of the header field or something else in the updated document; see . 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 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 's own templates and from the obsoletes/updates graph, neither of which suffers from that ambiguity.

What RFC 4021 told IANA This appendix reproduces, for each field registered by , 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 and . Fields re-registered since by (the RFC 2822 core fields) are omitted: their registry entries already carry a status and cite . Field RFC 4021 Status RFC 4021 spec doc Document in force Recommended Registry now Accept-Language standards-track RFC 3282 RFC 3282 standard (blank) Alternate-Recipient standards-track RFC 2156 RFC 2156 standard (blank) Autoforwarded standards-track RFC 2156 RFC 2156 standard (blank) Autosubmitted standards-track RFC 2156 RFC 2156 standard (blank) Content-Alternative work-in-progress RFC 3297 RFC 3297 standard (blank) Content-Base standards-track RFC 2110 RFC 2110 (dropped by successor) obsoleted obsoleted Content-Description standards-track RFC 2045 §8 RFC 2045 standard (blank) Content-Disposition standards-track RFC 2183 RFC 2183 standard (blank) Content-Duration standards-track RFC 2424 RFC 3803 (obsoletes RFC 2424) standard (blank) Content-features standards-track RFC 2912 §3 RFC 2912 standard (blank) Content-ID standards-track RFC 2045 §7 RFC 2045 standard (blank) Content-Identifier obsolete RFC 1327 RFC 1327 (dropped by successor) obsoleted (blank) Content-Language standards-track RFC 3282 RFC 3282 standard (blank) Content-Location standards-track RFC 2557 RFC 2557 standard (blank) Content-MD5 standards-track RFC 1864 RFC 1864 standard (blank) Content-Return obsolete RFC 1327 RFC 1327 (dropped by successor) obsoleted (blank) Content-Transfer-Encoding standards-track RFC 2045 §6 RFC 2045 standard (blank) Content-Type standards-track RFC 2045 §5 RFC 2045 standard (blank) Conversion standards-track RFC 2156 RFC 2156 standard (blank) Conversion-With-Loss standards-track RFC 2156 RFC 2156 standard (blank) Deferred-Delivery standards-track RFC 2156 RFC 2156 standard (blank) Delivery-Date standards-track RFC 2156 RFC 2156 standard (blank) Discarded-X400-IPMS-Extensions standards-track RFC 2156 RFC 2156 standard (blank) Discarded-X400-MTS-Extensions standards-track RFC 2156 RFC 2156 standard (blank) Disclose-Recipients standards-track RFC 2156 RFC 2156 standard (blank) Disposition-Notification-Options standards-track RFC 2298 RFC 8098 (obsoletes RFC 2298) standard (blank) Disposition-Notification-To standards-track RFC 2298 RFC 8098 (obsoletes RFC 2298) standard (blank) DL-Expansion-History standards-track RFC 2156 RFC 2156 standard (blank) Encoding experimental RFC 1505 RFC 1505 experimental (blank) Encrypted obsolete RFC 822 RFC 822 (dropped by successor) obsoleted (blank) Expires standards-track RFC 2156 RFC 2156 standard standard Expiry-Date obsolete RFC 1327 RFC 1327 (dropped by successor) obsoleted (blank) Generate-Delivery-Report standards-track RFC 2156 RFC 2156 standard (blank) Importance standards-track RFC 2156 RFC 2156 standard (blank) Incomplete-Copy standards-track RFC 2156 RFC 2156 standard (blank) Language standards-track RFC 2156 RFC 2156 standard (blank) Latest-Delivery-Time standards-track RFC 2156 RFC 2156 standard (blank) List-Archive standards-track RFC 2369 RFC 2369 standard (blank) List-Help standards-track RFC 2369 RFC 2369 standard (blank) List-ID standards-track RFC 2919 RFC 2919 standard (blank) List-Owner standards-track RFC 2369 RFC 2369 standard (blank) List-Post standards-track RFC 2369 RFC 2369 standard (blank) List-Subscribe standards-track RFC 2369 RFC 2369 standard (blank) List-Unsubscribe standards-track RFC 2369 RFC 2369 standard (blank) Message-Context standards-track RFC 3458 RFC 3458 standard (blank) Message-Type standards-track RFC 2156 RFC 2156 standard (blank) MIME-Version standards-track RFC 2045 §4 RFC 2045 standard (blank) Obsoletes obsolete RFC 1327 RFC 1327 (dropped by successor) obsoleted (blank) Original-Encoded-Information-Types standards-track RFC 2156 RFC 2156 standard (blank) Original-Message-ID standards-track RFC 3297 RFC 3297 standard (blank) Originator-Return-Address standards-track RFC 2156 RFC 2156 standard (blank) PICS-Label standard W3C PICS W3C PICS Rec. standard (blank) Prevent-NonDelivery-Report standards-track RFC 2156 RFC 2156 standard (blank) Priority standards-track RFC 2156 RFC 2156 standard (blank) Reply-By standards-track RFC 2156 RFC 2156 standard (blank) Sensitivity standards-track RFC 2156 RFC 2156 standard (blank) Supersedes standards-track RFC 2156 RFC 2156 standard standard X400-Content-Identifier standards-track RFC 2156 RFC 2156 standard (blank) X400-Content-Return standards-track RFC 2156 RFC 2156 standard (blank) X400-Content-Type standards-track RFC 2156 RFC 2156 standard (blank) X400-MTS-Identifier standards-track RFC 2156 RFC 2156 standard (blank) X400-Originator standards-track RFC 2156 RFC 2156 standard (blank) X400-Received standards-track RFC 2156 RFC 2156 standard (blank) X400-Recipients standards-track RFC 2156 RFC 2156 standard (blank) X400-Trace standards-track RFC 2156 RFC 2156 standard (blank)

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 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-Results perm mail experimental yes RFC 8617 ARC-Message-Signature perm mail experimental yes RFC 8617 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-Results perm mail standard yes RFC 8601 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-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, 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-Encoding perm MIME standard — RFC 4021, RFC 2045, RFC 2231, RFC 6532 Content-Translation-Type perm MIME standard — RFC 8255 Content-Type perm MIME standard — RFC 4021, RFC 9788, RFC 2045, RFC 2231, RFC 6532 Control perm netnews standard — RFC 5536 Conversion perm mail standard — RFC 4021, RFC 2156 Conversion-With-Loss perm mail standard — RFC 4021, RFC 2156 Date perm mail standard no draft-ietf-emailcore-rfc5322bis Date perm netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Date-Received perm netnews obsoleted — RFC 850, RFC 5536 Deferred-Delivery perm 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-IPMS-Extensions perm mail standard — RFC 4021, RFC 2156 Discarded-X400-MTS-Extensions perm mail standard — RFC 4021, RFC 2156 Disclose-Recipients perm mail standard — RFC 4021, RFC 2156 Disposition-Notification-Options perm mail standard — RFC 4021, RFC 8098, RFC 6533 Disposition-Notification-To perm mail standard — RFC 4021, 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-History perm mail standard yes RFC 4021, RFC 2156 Downgraded-Bcc perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Cc perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Disposition-Notification-To perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Final-Recipient perm mail standard — RFC 6857 Downgraded-From perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-In-Reply-To perm mail standard — RFC 6857 Downgraded-Mail-From perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Message-Id perm mail standard — RFC 6857 Downgraded-Original-Recipient perm mail standard — RFC 6857 Downgraded-Rcpt-To perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-References perm mail standard — RFC 6857 Downgraded-Reply-To perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-Bcc perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-Cc perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-From perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-Reply-To perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-Sender perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-To perm mail obsoleted — RFC 5504, RFC 6857 Downgraded-Return-Path perm mail obsoleted — RFC 5504, 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, draft-ietf-emailcore-rfc5322bis Generate-Delivery-Report perm mail standard — RFC 4021, 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-Time perm mail standard — RFC 4021, RFC 2156 Lines perm netnews deprecated — RFC 5536, RFC 3977 List-Archive perm mail standard — RFC 4021, RFC 2369 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-Post perm mail standard — RFC 8058 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-Message-Identifier perm mail informational — RFC 6477, (non-RFC ref) MMHS-Authorizing-Users prov mail informational — RFC 7912 MMHS-Codress-Message-Indicator perm mail informational — RFC 6477, (non-RFC ref) MMHS-Copy-Precedence perm mail informational — RFC 6477, (non-RFC ref) MMHS-Exempted-Address perm mail informational — RFC 6477, (non-RFC ref) MMHS-Extended-Authorisation-Info perm mail informational — RFC 6477, (non-RFC ref) MMHS-Handling-Instructions perm mail informational — RFC 6477, (non-RFC ref) MMHS-Message-Instructions perm mail informational — RFC 6477, (non-RFC ref) MMHS-Message-Type perm mail informational — RFC 6477, (non-RFC ref) MMHS-Originator-PLAD perm mail informational — RFC 6477, (non-RFC ref) MMHS-Originator-Reference perm mail informational — RFC 6477, (non-RFC ref) MMHS-Other-Recipients-Indicator-CC perm mail informational — RFC 6477, (non-RFC ref) MMHS-Other-Recipients-Indicator-To perm mail informational — RFC 6477, (non-RFC ref) MMHS-Primary-Precedence perm mail informational — RFC 6477, (non-RFC ref) MMHS-Subject-Indicator-Codes perm mail informational — RFC 6477, (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-Information-Types perm mail standard — RFC 4021, 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-Address perm mail standard — RFC 4021, RFC 2156 Path perm netnews standard — RFC 5536 PICS-Label perm mail standard — RFC 4021 Posting-Version perm netnews obsoleted — RFC 850, RFC 5536 Prevent-NonDelivery-Report perm mail standard — RFC 4021, 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-Valid-Since perm mail standard — RFC 7293 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 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-Submitter perm mail standard — RFC 8460 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 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-Message-ID prov mail informational — RFC 6109 X-TipoRicevuta prov mail informational — RFC 6109 X-Trasporto prov mail informational — RFC 6109 X-VerificaSicurezza prov mail informational — RFC 6109 X400-Content-Identifier perm mail standard — RFC 4021, 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, 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

Change Log

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: : "Auto-Submitted" moved from the not-trace list to . , 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. : the recommendations of Trace "yes" for "Path" and "Injection-Info" are withdrawn. , Section 6.1 makes the column applicable only where Protocol is "mail". : the recommendation of Trace "yes" for "Apparently-To", "Original-Recipient" and "X400-Received" is withdrawn, following the caution against inferring trace status from position recorded in . : is no longer proposed for the five core MIME fields; names alone. and are added instead, being the formal updaters of . : the proposal to add to "Disposition-Notification-To" and "-Options" is replaced by , which obsoletes it. Likewise "Original-Recipient" gains as well as ; -01 did not note that both of its current references are obsolete. : a blank Trace cell means "not yet specified", per 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. : was obsoleted by , not by . Additions: , , (new): supplied an explicit Status and Specification document for every field it registered, and neither reached the registry. -01 stated that "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. (new): the five fields marked "obsolete" whose only definition is in an obsoleted document. (new): the documented origin of the "standard" versus "standards-track" divergence between and , from the ietf-822 discussion of 2004. (new): , the emailcore discussion that created the Trace column, and the 2024 exchange establishing the route this document follows. (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 set out. : the Status test is now anchored in Section 4.2.1 of , and the Trace test in Section 3.6.7 of and Section 4.4.4 of , rather than argued from first principles. (new): and are formal updaters that are deliberately not added, with the reason recorded. : reference additions for "Content-Disposition" (, ) and "Message-Context" (), missed in -01. : named explicitly. : the "Resent-*" fields, recorded as "no" by although proposed otherwise. : a Mechanism subsection. Normative references changed from and to and , which are the documents that now govern the registries.

Since -00 : 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. (new): "SIO-Label" and "SIO-Label-History" Status corrected from blank to "informational". (new): the fourteen "MMHS-*" fields (RFC 6477) and "MMHS-Authorizing-Users" (RFC 7912) Status corrected from blank to "informational". : added "SIO-Label-History". Added "Apparently-To" as a trace field (withdrawn in -02).