]> 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 instructions those documents gave to IANA were not consistent with one another. As a result the registries no longer present a reliable picture of the relative status or usage of the fields they contain: fields of equal standing carry different status values, foundational fields appear less classified than minor ones, the "trace" property is recorded for only a fraction of the fields whose defining documents describe them as trace fields, and the reference column frequently points at a later registration document rather than at the document that actually defines or updates the field. This reduces the value of the metadata to the point where a reader cannot use it to reason about a field with confidence. This document reviews the initial definition of, and every subsequent update to, each registered header field, and gives IANA a single, coherent set of instructions for correcting each registry entry. Every recommended change, and every deliberate decision to leave a non-obvious entry unchanged, is justified by reference to the clear intent of the authors of the source documents in which the field was defined or modified.

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). 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 that promise has not been kept. The registries were populated incrementally by a long series of documents, each of which supplied its own registration instructions, and those instructions were not consistent with one another: The "Status" column is applied unevenly. Foundational fields imported in bulk by were registered with no status at all, while later fields of equal or lesser standing were registered as "standard". A reader comparing two entries cannot tell whether a blank status means "not standards track", "status not asserted", or simply "registered before anyone recorded a status". At least one field records a status that contradicts the standing of the document that defines it. The "Trace" column was populated only for the fields re-registered by the ongoing revision of . Fields whose own defining documents describe them, in terms, as trace fields carry a blank Trace column, so the column reads as "not a trace field" for fields that their authors plainly intended to be trace fields. The "Reference" column frequently cites the document that most recently registered a field rather than the document that defines it, and rarely reflects later documents that formally update the definition. A reader who follows the reference is sent to a registration stub instead of to the specification. The cumulative effect is that the metadata cannot be relied upon. Two entries that look different may be equivalent, and two that look equivalent may not be. The registries still serve as a name-collision-avoidance list, which is their irreducible function, but the additional metadata that was meant to make them useful has lost most of its value. This document reviews the initial definition of, and every subsequent update to, each registered header field, and provides IANA with a clear instruction for each entry. The recommendations are derived from the clear intent of the authors of the source documents in which each field was defined or modified, not from any new opinion of this document's author about how the fields ought to behave. Where the intent of the source documents is not abundantly obvious, this document explains its reasoning for the change; and where an entry looks wrong but is on inspection correct, this document explains its reasoning for leaving it unchanged, so that the analysis need not be repeated by the next reader.

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 defining and updating documents already 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, extended as described in .

Methodology Three questions were asked of every registry entry, corresponding to the three classification columns.

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? A field is treated as "standard" when it is defined by a document on the Standards Track (or an equivalent IESG-approved specification) that is the current definition; "informational" or "experimental" when its current defining document is of that category; "obsoleted" or "deprecated" when a later document in force says so. The controlling fact is the category and standing of the defining document, as stated on that document's own front page.

Trace:

Did the authors of the defining document intend the field to be a trace field -- that is, a field added to a message by a handling agent as the message is processed, placed at a defined position (normally prepended), and not reordered? The strongest evidence is a document that says so in terms; the next strongest is a document that imports the trace-field rules of or without using the word. 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. Two independent signals were combined to find these documents exhaustively across the entire published RFC series: The formal "Updates:" metadata. Every RFC that carries an "Updates: N" header in its front matter was recorded as an updater of RFC N. This yields an authoritative, machine-checkable graph of which documents the community has formally declared to modify which others. For example, RFC 8301, RFC 8463, and RFC 8616 each carry "Updates: 6376" and therefore update the definition of the "DKIM-Signature" field, none of which the registry currently cites. A header-field mention scan. Every RFC in the series was scanned for use of each registered field name in header-field position. This locates documents that specify or extend a field without a formal "Updates:" relationship (for example the document that originally defined a field later re-registered by ). A reference addition is proposed where a document either formally updates a field's defining document, or is the original defining document that the registry fails to cite.

Limits of the automated analysis The mention scan is reliable for fields whose names are distinctive (hyphenated names, or names that are not ordinary English words): for these, the set of documents using the name is small and almost entirely relevant. It is not reliable for fields whose names are common words or common protocol tokens. "Comments", "To", "From", "Subject", "Received", "Content-Type", and similar names appear in thousands of documents, overwhelmingly in examples or in unrelated prose, and no purely textual filter separates a genuine specification from an incidental mention. For those fields the reference set was determined from the known specification lineage and confirmed against the formal "Updates:" graph, which does not suffer from this ambiguity. This limitation is called out because it bears directly on any attempt to regenerate the registries mechanically: the "Updates:" graph can be trusted; an unfiltered text search cannot.

Status Corrections

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, with a reference correction 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. RFC 4021 did not define these fields; it re-registered them. They are defined by , a Standards Track document whose title is "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields" and whose Section 3 specifies each field. Likewise "List-ID" is registered with blank Status and Reference , but is defined by , the Standards Track "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists". For all seven fields the Status should be "standard" and the Reference should cite the true defining document ( or respectively) in addition to . This is the clearest illustration of the general problem: the registry currently sends a reader to a registration stub and records no status, when a Standards Track definition exists and has done since 1998.

The RFC 4021 registration cohort imported roughly sixty mail and MIME fields into the permanent registry in a single Standards Track document, and registered every one of them with a blank Status. The blank was, at the time, a reasonable choice: RFC 4021 set out to record the existence of these historical fields, not to rule on their standing. Two decades later the blanks are actively misleading, because many of the imported fields are core elements of full Internet Standards while others are vestigial X.400 gateway fields, and the registry gives the reader no way to tell them apart. This document does not recommend mechanically stamping the entire cohort "standard". Many of these fields (the "X400-" family, "Discarded-X400-", "DL-Expansion-History", "Deferred-Delivery", "Latest-Delivery-Time", and similar) derive from the X.400/MIXER mapping work and are specialised gateway fields rather than general-use Internet Mail fields. They remain in use in the environments that rely on that gateway work, so this document does not recommend changing their status; settling an appropriate status for each on its individual merits is a larger undertaking than this revision attempts, and the entries are left unchanged. It does recommend correcting the core MIME fields, whose standing is not in doubt. "MIME-Version", "Content-Type", "Content-Transfer-Encoding", "Content-ID", and "Content-Description" are defined by and -- long-standing Internet Standards-track documents -- yet are registered with blank Status and with a Reference that cites only the registration document (and, for "Content-Type", ). These five fields should be Status "standard", and their References should cite and as their defining documents. 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.

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

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.

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 , Section 3.6.7 defines the trace fields of Internet Mail as an optional "Return-Path" and one or more "Received" fields. The IANA "Trace" column, however, is a per-field property, and several later documents explicitly designate their own fields as trace fields by importing the rules of or . The controlling question for the column is therefore not "is this one of the two fields listed in Section 3.6.7" but "did the field's defining document designate it a trace field". Judged that way, the column is substantially under-populated: it is set only for the fields re-registered by the revision of , and blank for every field whose trace nature is stated in a different document.

Fields whose defining documents call them trace fields For each of the following fields the defining document states, in terms, that the field is a trace field and is to be prepended and not reordered. The Trace column for each SHOULD be "yes". "Received-SPF" (mail), , Section 9.1: "The Received-SPF header field is a trace field (see [RFC5322], Section 3.6.7) and SHOULD be prepended to the existing header, above the Received field". "Authentication-Results" (mail), , Sections 2.1 and 4.1: the field "is therefore considered to be a trace field as defined in [MAIL]", and "MUST be treated as though it were a trace header field ... and hence MUST NOT be reordered and MUST be prepended to the message". "DKIM-Signature" (mail), , Section 3.5: the field "SHOULD be treated as though it were a trace header field as defined in Section 3.6 of [RFC5322] and hence SHOULD NOT be reordered and SHOULD be prepended to the message". "VBR-Info" (mail), , Section 2: "in the terminology of RFC 5322, VBR-Info is a 'trace header field'". "Path" (netnews), 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" (netnews), Section 3.2.8: it is added only by the injecting agent and exists to assist "in tracing the article's true origin"; classes it as trace information. "X400-Trace" and "DL-Expansion-History" (mail), : registered with descriptions that are, respectively, "X400 Trace" and "Trace of distribution lists passed"; both derive from the X.400 per-hop trace elements of . "SIO-Label-History" (mail), , Section 5: "The SIO-Label-History header field is considered to be a trace field as defined in Section 3.6.7 of [RFC5322]". The field records label changes made as the message is handled and is "intended to provide trace information (only trace information)"; each new instance is "added immediately preceding any existing SIO-Label-History header fields", i.e. prepended within the SIO-Label-History group. Note that "DKIM-Signature" and "VBR-Info" are typically added by the originating administrative domain rather than by a relay, yet their authors deliberately chose the "trace header field" designation to obtain its positional guarantees (prepend, do not reorder). The Trace column should record what the defining documents say; the "yes" value reflects that designation.

Fields that behave as trace fields without the label The following fields are added by handling agents in transit, typically at a defined position and with ordering significance, but their defining documents do not use the word "trace". Whether the Trace column should be "yes" for these depends on whether IANA reads the column in the strict sense of Section 3.6.7 or in the broader "designated by the defining document" sense used in . This document recommends "yes" and records the evidence so that IANA can decide with the facts in hand. "ARC-Seal", "ARC-Message-Signature", "ARC-Authentication-Results" (mail), : added by participating domains as the message transits, with "i=" instance tags that encode the order of handling ("chain of custody"). "Delivered-To" (mail, provisional), Section 4: "MUST be placed at the current 'top' of the message's set of header fields ... in a fashion similar to the trace fields", and "MUST NOT be reordered". "Original-Recipient" (mail), Section 2.3: inserted by the delivering MTA "at the beginning of the message (along with the Return-Path header)". "X400-Received" (mail), : the X.400/MIXER gateway equivalent of "Received". "Apparently-To" (mail), , Section 3.4: inserted by a mail transfer agent on delivery, when the original message carries no "To" recipient ("Inserted by Sendmail when there is no 'To:' recipient in the original message, listing recipients derived from the envelope into the message heading"). A field added by a handling agent as the message is delivered is a trace field in the sense used here, so the Trace column should be "yes". It is listed in this section rather than in only because its sole reference, the survey, does not itself use the word "trace" (and in fact records the behaviour as non-standard).

Fields deliberately not marked trace (non-obvious cases) The following fields are added by a party other than the original author and so might be mistaken for trace fields, but are correctly left un-marked because they are content-preservation or originator-supplied fields, not transit-inserted positional fields: "Solicitation" () 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. "Auto-Submitted" () is set by the automatic responder that originates the message, may appear at most once, and has no positional significance. "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 field by field, the reference corrections fall into two groups.

Missing defining documents These entries cite a later registration document but not the document that defines the field. The defining document SHOULD be added (and, as noted in , the Status corrected to match its standing): Field(s) Currently cites Add defining document List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner, List-Archive RFC 4021 RFC 2369 List-ID RFC 4021 RFC 2919 MIME-Version, Content-Type, Content-Transfer-Encoding, Content-ID, Content-Description RFC 4021 (+ RFC 9788) RFC 2045, RFC 2046

Missing formal updates These entries fail to cite documents that carry a formal "Updates:" header targeting the field's defining document. Each addition below was confirmed from the "Updates:" graph: Field Cites Add (formal updaters) DKIM-Signature RFC 6376 RFC 8301, RFC 8463, RFC 8616 Received-SPF RFC 7208 RFC 7372, RFC 8616 Original-Recipient RFC 3798, RFC 5337 RFC 6533 Disposition-Notification-To, Disposition-Notification-Options RFC 4021 RFC 3798, RFC 8098 Auto-Submitted RFC 3834 RFC 5436

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 (the revision of , with where the group syntax applies, and for the two SMTP trace fields). The long chain of obsoleted predecessors -- RFC 822, RFC 2822, and for some fields RFC 561, RFC 724, RFC 733, RFC 1036, RFC 1123 -- is deliberately *not added. The Reference column is meant to point a reader at the definition in force, and a registry entry that listed every obsoleted ancestor would be less useful, not more. This is the one place where "every RFC that ever touched the field" is the wrong answer, and it is recorded here so the omission is understood to be intentional.

Exhaustive per-field reference review records, for every registered field, the reference set that results from applying . Where that set differs from the current registry Reference column, the difference is one of the corrections tabulated above; where it does not differ, the current Reference is confirmed as complete.

IANA Considerations IANA is requested to update the "Permanent Message Header Field Names" and "Provisional Message Header Field Names" registries as follows. The changes are metadata only; no field is added, removed, or renamed. Status changes: "MT-Priority": change Status from "standard" to "informational" (). "Solicitation": change Status from blank to "standard" (). "List-Help", "List-Subscribe", "List-Unsubscribe", "List-Post", "List-Owner", "List-Archive", "List-ID": change Status from blank to "standard" (). "MIME-Version", "Content-Type", "Content-Transfer-Encoding", "Content-ID", "Content-Description": change Status from blank to "standard" (). "SIO-Label", "SIO-Label-History": change Status from blank to "informational" (). The "MMHS-*" fields and "MMHS-Authorizing-Users": change Status from blank to "informational" (). Trace changes (set Trace to "yes"): "Received-SPF", "Authentication-Results", "DKIM-Signature", "VBR-Info", "Path", "Injection-Info", "X400-Trace", "DL-Expansion-History", "SIO-Label-History" (). Subject to the interpretation discussed in : the "ARC-*" fields, "Delivered-To", "Original-Recipient", "X400-Received", and "Apparently-To". Reference changes: as tabulated in and detailed per field in .

Security Considerations This document changes registry metadata only and introduces no protocol behaviour. Accurate metadata has a modest positive security effect: several of the fields whose Trace status is corrected here ("Received-SPF", "Authentication-Results", "DKIM-Signature", "ARC-*") carry the results of message authentication checks, and a reader or implementer who consults the registry benefits from an accurate record that these are trace fields whose position in the header is significant and must be preserved. No new information is disclosed by any change in this document.

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. 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 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 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 second document defines the general structure of the MIME media typing system and defines an initial set of media types. [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. 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 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] S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of email message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification (RFC 8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling email messages with cryptographic protection of message headers. The Header Protection scheme defined here is also applicable to messages with PGP/MIME (Pretty Good Privacy with MIME) cryptographic protections. 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 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. 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 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] 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 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] 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. 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.

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.

Reproducing the analysis The determinations in this document were produced from the published RFC series by two mechanical passes whose results were then reviewed by hand: An "Updates:" graph built from the front-matter "Updates:" line of every RFC, giving an authoritative list of which documents formally modify which others. A header-field mention index built by scanning every RFC for each registered field name in header-field position. The reference set for a field is its current defining document(s) together with every document that formally updates a defining document. As noted in , the mention index is authoritative only for fields with distinctive names; for common-word field names the reference set was taken from the known specification lineage and cross-checked against the "Updates:" graph, which is unaffected by the ambiguity of common words.

Per-field reference review This appendix lists every entry in the permanent and provisional registries in the state recommended by this document. In the Status, Trace, and Reference columns, bold marks a value that differs from the current registry: a bold Status or Trace is a recommended change from or , and a bold reference is an addition per . A non-bold value is confirmed unchanged. As set out in , reference additions were derived from the formal "Updates:" graph and the header-field mention index; for common-word field names the mention index is unreliable and the reference set was confirmed against the "Updates:" graph and the known specification lineage. Entries whose only specification is a non-RFC document (for example the "Face" and "X-Face" fields) are shown as "(non-RFC ref)". Field Proto Status Trace Reference (bold = added) Accept-Language mail — — RFC 4021 Also-Control netnews obsoleted — RFC 1849, RFC 5536 Alternate-Recipient mail — — RFC 4021 Approved netnews standard — RFC 5536 ARC-Authentication-Results mail experimental yes RFC 8617 ARC-Message-Signature mail experimental yes RFC 8617 ARC-Seal mail experimental yes RFC 8617 Archive netnews standard — RFC 5536 Archived-At mail standard — RFC 5064 Archived-At netnews standard — RFC 5064 Article-Names netnews obsoleted — RFC 1849, RFC 5536 Article-Updates netnews obsoleted — RFC 1849, RFC 5536 Authentication-Results mail standard yes RFC 8601 Auto-Submitted mail standard — RFC 3834, RFC 5436 Autoforwarded mail — — RFC 4021 Autosubmitted mail — — RFC 4021 Base MIME obsoleted — RFC 1808, RFC 2068 Bcc mail standard no draft-ietf-emailcore-rfc5322bis Body none reserved — RFC 6068 Cancel-Key netnews standard — RFC 8315 Cancel-Lock netnews standard — RFC 8315 Cc mail standard no draft-ietf-emailcore-rfc5322bis Comments mail standard no draft-ietf-emailcore-rfc5322bis Comments netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Content-Alternative MIME — — RFC 4021 Content-Base MIME obsoleted — RFC 2110, RFC 2557 Content-Description MIME standard — RFC 4021, RFC 2045, RFC 2046 Content-Disposition MIME — — RFC 4021 Content-Duration MIME — — RFC 4021 Content-features MIME — — RFC 4021 Content-ID MIME standard — RFC 4021, RFC 2045, RFC 2046 Content-Identifier mail — — RFC 4021 Content-Language MIME — — RFC 4021 Content-Location MIME — — RFC 4021 Content-MD5 MIME — — RFC 4021 Content-Return mail — — RFC 4021 Content-Transfer-Encoding MIME standard — RFC 4021, RFC 2045, RFC 2046 Content-Translation-Type MIME standard — RFC 8255 Content-Type MIME standard — RFC 4021, RFC 9788, RFC 2045, RFC 2046 Control netnews standard — RFC 5536 Conversion mail — — RFC 4021 Conversion-With-Loss mail — — RFC 4021 DL-Expansion-History mail — yes RFC 4021 Date mail standard no draft-ietf-emailcore-rfc5322bis Date netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Date-Received netnews obsoleted — RFC 850, RFC 5536 Deferred-Delivery mail — — RFC 4021 Delivery-Date mail — — RFC 4021 Discarded-X400-IPMS-Extensions mail — — RFC 4021 Discarded-X400-MTS-Extensions mail — — RFC 4021 Disclose-Recipients mail — — RFC 4021 Disposition-Notification-Options mail — — RFC 4021, RFC 3798, RFC 8098 Disposition-Notification-To mail — — RFC 4021, RFC 3798, RFC 8098 Distribution netnews standard — RFC 5536 DKIM-Signature mail standard yes RFC 6376, RFC 8301, RFC 8463, RFC 8616 Downgraded-Bcc mail obsoleted — RFC 5504, RFC 6857 Downgraded-Cc mail obsoleted — RFC 5504, RFC 6857 Downgraded-Disposition-Notification-To mail obsoleted — RFC 5504, RFC 6857 Downgraded-Final-Recipient mail standard — RFC 6857 Downgraded-From mail obsoleted — RFC 5504, RFC 6857 Downgraded-In-Reply-To mail standard — RFC 6857 Downgraded-Mail-From mail obsoleted — RFC 5504, RFC 6857 Downgraded-Message-Id mail standard — RFC 6857 Downgraded-Original-Recipient mail standard — RFC 6857 Downgraded-Rcpt-To mail obsoleted — RFC 5504, RFC 6857 Downgraded-References mail standard — RFC 6857 Downgraded-Reply-To mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-Bcc mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-Cc mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-From mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-Reply-To mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-Sender mail obsoleted — RFC 5504, RFC 6857 Downgraded-Resent-To mail obsoleted — RFC 5504, RFC 6857 Downgraded-Return-Path mail obsoleted — RFC 5504, RFC 6857 Downgraded-Sender mail obsoleted — RFC 5504, RFC 6857 Downgraded-To mail obsoleted — RFC 5504, RFC 6857 Encoding mail — — RFC 4021 Encrypted mail — — RFC 4021 Expires mail standard — draft-ietf-mailmaint-expires Expires netnews standard — RFC 5536 Expiry-Date mail — — RFC 4021 Followup-To netnews standard — RFC 5536 From mail standard no RFC 6854, draft-ietf-emailcore-rfc5322bis From netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Generate-Delivery-Report mail — — RFC 4021 HP-Outer mail standard — RFC 9788 Importance mail — — RFC 4021 In-Reply-To mail standard no draft-ietf-emailcore-rfc5322bis Incomplete-Copy mail — — RFC 4021 Injection-Date netnews standard — RFC 5536 Injection-Info netnews standard yes RFC 5536 Keywords mail standard no draft-ietf-emailcore-rfc5322bis Keywords netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Language mail — — RFC 4021 Latest-Delivery-Time mail — — RFC 4021 Lines netnews deprecated — RFC 5536, RFC 3977 List-Archive mail standard — RFC 4021, RFC 2369 List-Help mail standard — RFC 4021, RFC 2369 List-ID mail standard — RFC 4021, RFC 2919 List-Owner mail standard — RFC 4021, RFC 2369 List-Post mail standard — RFC 4021, RFC 2369 List-Subscribe mail standard — RFC 4021, RFC 2369 List-Unsubscribe mail standard — RFC 4021, RFC 2369 List-Unsubscribe-Post mail standard — RFC 8058 Message-Context mail — — RFC 4021 Message-ID mail standard no draft-ietf-emailcore-rfc5322bis Message-ID netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Message-Type mail — — RFC 4021 MIME-Version MIME standard — RFC 4021, RFC 2045, RFC 2046 MMHS-Exempted-Address mail informational — RFC 6477, (non-RFC ref) MMHS-Extended-Authorisation-Info mail informational — RFC 6477, (non-RFC ref) MMHS-Subject-Indicator-Codes mail informational — RFC 6477, (non-RFC ref) MMHS-Handling-Instructions mail informational — RFC 6477, (non-RFC ref) MMHS-Message-Instructions mail informational — RFC 6477, (non-RFC ref) MMHS-Codress-Message-Indicator mail informational — RFC 6477, (non-RFC ref) MMHS-Originator-Reference mail informational — RFC 6477, (non-RFC ref) MMHS-Primary-Precedence mail informational — RFC 6477, (non-RFC ref) MMHS-Copy-Precedence mail informational — RFC 6477, (non-RFC ref) MMHS-Message-Type mail informational — RFC 6477, (non-RFC ref) MMHS-Other-Recipients-Indicator-To mail informational — RFC 6477, (non-RFC ref) MMHS-Other-Recipients-Indicator-CC mail informational — RFC 6477, (non-RFC ref) MMHS-Acp127-Message-Identifier mail informational — RFC 6477, (non-RFC ref) MMHS-Originator-PLAD mail informational — RFC 6477, (non-RFC ref) MT-Priority mail informational — RFC 6758 Newsgroups netnews standard — RFC 5536 NNTP-Posting-Date netnews obsoleted — RFC 5536 NNTP-Posting-Host netnews obsoleted — RFC 2980, RFC 5536 Obsoletes mail — — RFC 4021 Organization mail informational — RFC 7681 Organization netnews standard — RFC 5536 Original-Encoded-Information-Types mail — — RFC 4021 Original-From mail standard — RFC 5703 Original-Message-ID mail — — RFC 4021 Original-Recipient mail standard yes RFC 3798, RFC 5337, RFC 6533 Original-Sender netnews standard — RFC 5537 Originator-Return-Address mail — — RFC 4021 Original-Subject mail standard — RFC 5703 Path netnews standard yes RFC 5536 PICS-Label mail — — RFC 4021 Posting-Version netnews obsoleted — RFC 850, RFC 5536 Prevent-NonDelivery-Report mail — — RFC 4021 Priority mail — — RFC 4021 Received mail standard yes draft-ietf-emailcore-rfc5322bis, draft-ietf-emailcore-rfc5321bis Received-SPF mail standard yes RFC 7208, RFC 7372, RFC 8616 References mail standard no draft-ietf-emailcore-rfc5322bis References netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Relay-Version netnews obsoleted — RFC 850, RFC 5536 Reply-By mail — — RFC 4021 Reply-To mail standard no draft-ietf-emailcore-rfc5322bis Reply-To netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Require-Recipient-Valid-Since mail standard — RFC 7293 Resent-Bcc mail standard no draft-ietf-emailcore-rfc5322bis Resent-Cc mail standard no draft-ietf-emailcore-rfc5322bis Resent-Date mail standard no draft-ietf-emailcore-rfc5322bis Resent-From mail standard no RFC 6854, draft-ietf-emailcore-rfc5322bis Resent-Message-ID mail standard no draft-ietf-emailcore-rfc5322bis Resent-Reply-To mail obsoleted no draft-ietf-emailcore-rfc5322bis Resent-Sender mail standard no RFC 6854, draft-ietf-emailcore-rfc5322bis Resent-To mail standard no draft-ietf-emailcore-rfc5322bis Return-Path mail standard yes draft-ietf-emailcore-rfc5322bis, draft-ietf-emailcore-rfc5321bis See-Also netnews obsoleted — RFC 1849, RFC 5536 Sender mail standard no RFC 6854, draft-ietf-emailcore-rfc5322bis Sender netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Sensitivity mail — — RFC 4021 Solicitation mail standard — RFC 3865 Subject mail standard no draft-ietf-emailcore-rfc5322bis Subject netnews standard — RFC 5536, draft-ietf-emailcore-rfc5322bis Summary netnews standard — RFC 5536 Supersedes mail — — RFC 4021 Supersedes netnews standard — RFC 5536, RFC 2156 TLS-Report-Domain mail standard — RFC 8460 TLS-Report-Submitter mail standard — RFC 8460 TLS-Required mail standard — RFC 8689 To mail standard no draft-ietf-emailcore-rfc5322bis User-Agent netnews standard — RFC 5536, RFC 2616 VBR-Info mail standard yes RFC 5518 X400-Content-Identifier mail — — RFC 4021 X400-Content-Return mail — — RFC 4021 X400-Content-Type mail — — RFC 4021 X400-MTS-Identifier mail — — RFC 4021 X400-Originator mail — — RFC 4021 X400-Received mail — yes RFC 4021 X400-Recipients mail — — RFC 4021 X400-Trace mail — yes RFC 4021 Xref netnews standard — RFC 5536 Apparently-To mail — yes RFC 2076 Author mail — — RFC 9057 CFBL-Address mail — — RFC 9477 CFBL-Feedback-ID mail — — RFC 9477 Delivered-To mail — yes RFC 9228 EDIINT-Features mail — — RFC 6017 Eesst-Version mail — — RFC 7681 Errors-To mail — — RFC 2076 Face mail — — (non-RFC ref) Face netnews — — (non-RFC ref) Form-Sub mail — — draft-levine-mailbomb-header-00 Jabber-ID mail — — RFC 7259 Jabber-ID netnews — — RFC 7259 MMHS-Authorizing-Users mail informational — RFC 7912 Privicon mail — — draft-koenig-privicons-01 SIO-Label mail informational — RFC 7444 SIO-Label-History mail informational yes RFC 7444 Wrong-Recipient mail — — draft-ietf-mailmaint-wrong-recipient-00 X-Archived-At mail deprecated — RFC 5064 X-Archived-At netnews deprecated — RFC 5064 X-Face mail — — (non-RFC ref) X-Face netnews — — (non-RFC ref) X-Mittente mail — — RFC 6109 X-PGP-Sig netnews — — (non-RFC ref), (non-RFC ref) X-Ricevuta mail — — RFC 6109 X-Riferimento-Message-ID mail — — RFC 6109 X-TipoRicevuta mail — — RFC 6109 X-Trasporto mail — — RFC 6109 X-VerificaSicurezza mail — — RFC 6109

Change Log

Since -00 : removed the suggestion that the X.400/MIXER gateway fields (the "X400-" family, "Discarded-X400-", "DL-Expansion-History", and similar) might be better recorded as "obsoleted". These fields remain in use in the environments that rely on that gateway work, and their status is left unchanged. (new): "SIO-Label" and "SIO-Label-History" Status corrected from blank to "informational", matching their Informational defining document RFC 7444. (new): the fourteen "MMHS-*" fields (RFC 6477) and "MMHS-Authorizing-Users" (RFC 7912) Status corrected from blank to "informational", matching their Informational defining documents. : added "SIO-Label-History", whose defining document (RFC 7444, Section 5) states in terms that it is a trace field. : added "Apparently-To", inserted by a mail transfer agent on delivery (RFC 2076, Section 3.4).