diff options
Diffstat (limited to 'doc/rfc/rfc8601.txt')
| -rw-r--r-- | doc/rfc/rfc8601.txt | 3027 |
1 files changed, 3027 insertions, 0 deletions
diff --git a/doc/rfc/rfc8601.txt b/doc/rfc/rfc8601.txt new file mode 100644 index 0000000..08da3bc --- /dev/null +++ b/doc/rfc/rfc8601.txt @@ -0,0 +1,3027 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Kucherawy +Request for Comments: 8601 May 2019 +Obsoletes: 7601 +Category: Standards Track +ISSN: 2070-1721 + + + Message Header Field for Indicating Message Authentication Status + +Abstract + + 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8601. + + + + + + + + + + + + + + + + + +Kucherawy Standards Track [Page 1] + +RFC 8601 Authentication-Results Header Field May 2019 + + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Purpose ....................................................5 + 1.2. Trust Boundary .............................................6 + 1.3. Processing Scope ...........................................7 + 1.4. Requirements ...............................................7 + 1.5. Definitions ................................................7 + 1.5.1. Key Words ...........................................7 + 1.5.2. Internationalized Email .............................7 + 1.5.3. Security ............................................8 + 1.5.4. Email Architecture ..................................8 + 1.5.5. Other Terms .........................................9 + 1.6. Trust Environment .........................................10 + 2. Definition and Format of the Header Field ......................10 + 2.1. General Description .......................................10 + 2.2. Formal Definition .........................................11 + 2.3. Property Types (ptypes) and Properties ....................13 + 2.4. The "policy" ptype ........................................15 + 2.5. Authentication Service Identifier Field ...................15 + 2.6. Version Tokens ............................................17 + 2.7. Defined Methods and Result Values .........................17 + 2.7.1. DKIM ...............................................17 + 2.7.2. SPF ................................................19 + 2.7.3. "iprev" ............................................20 + 2.7.4. SMTP AUTH ..........................................21 + 2.7.5. Other Registered Codes .............................22 + 2.7.6. Extension Methods ..................................22 + 2.7.7. Extension Result Codes .............................23 + 3. The "iprev" Authentication Method ..............................23 + 4. Adding the Header Field to a Message ...........................25 + 4.1. Header Field Position and Interpretation ..................26 + 4.2. Local Policy Enforcement ..................................27 + + + +Kucherawy Standards Track [Page 2] + +RFC 8601 Authentication-Results Header Field May 2019 + + + 5. Removing Existing Header Fields ................................28 + 6. IANA Considerations ............................................29 + 6.1. The Authentication-Results Header Field ...................29 + 6.2. "Email Authentication Methods" Registry Description .......30 + 6.3. "Email Authentication Methods" Registry Update ............31 + 6.3.1. "header.a" for DKIM ................................32 + 6.3.2. "header.s" for DKIM ................................32 + 6.4. "Email Authentication Property Types" Registry + Description ...............................................32 + 6.5. "Email Authentication Property Types" Registry Update .....33 + 6.6. "Email Authentication Result Names" Registry Description ..33 + 6.7. "Email Authentication Result Names" Registry Update .......34 + 6.8. SMTP Enhanced Status Codes ................................34 + 7. Security Considerations ........................................35 + 7.1. Forged Header Fields ......................................35 + 7.2. Misleading Results ........................................36 + 7.3. Header Field Position .....................................37 + 7.4. Reverse IP Query Denial-of-Service Attacks ................37 + 7.5. Mitigation of Backscatter .................................37 + 7.6. Internal MTA Lists ........................................37 + 7.7. Attacks against Authentication Methods ....................38 + 7.8. Intentionally Malformed Header Fields .....................38 + 7.9. Compromised Internal Hosts ................................38 + 7.10. Encapsulated Instances ...................................38 + 7.11. Reverse Mapping ..........................................39 + 8. References .....................................................39 + 8.1. Normative References ......................................39 + 8.2. Informative References ....................................40 + Appendix A. Legacy MUAs ...........................................44 + Appendix B. Authentication-Results Examples .......................44 + B.1. Trivial Case: Header Field Not Present .....................44 + B.2. Nearly Trivial Case: Service Provided, but No + Authentication Done ........................................45 + B.3. Service Provided, Authentication Done ......................46 + B.4. Service Provided, Several Authentications Done, Single + MTA ........................................................47 + B.5. Service Provided, Several Authentications Done, Different + MTAs .......................................................48 + B.6. Service Provided, Multi-tiered Authentication Done .........50 + B.7. Comment-Heavy Example ......................................51 + Appendix C. Operational Considerations about Message + Authentication ........................................52 + Appendix D. Changes since RFC 7601 ................................53 + Acknowledgments ...................................................54 + Author's Address ..................................................54 + + + + + + +Kucherawy Standards Track [Page 3] + +RFC 8601 Authentication-Results Header Field May 2019 + + +1. Introduction + + This document describes a header field called "Authentication- + Results" for electronic mail messages that presents the results of a + message authentication effort in a machine-readable format. The + intent of the header field is to create a place to collect such data + when message authentication mechanisms are in use so that a Mail User + Agent (MUA) and downstream filters can make filtering decisions + and/or provide a recommendation to the user as to the validity of the + message's origin and possibly the safety and integrity of its + content. + + End users are not expected to be direct consumers of this header + field. This header field is intended for consumption by programs + that will then use such data or render it in a human-usable form. + + This document specifies the format of this header field and discusses + the implications of its presence or absence. However, it does not + discuss how the data contained in the header field ought to be used, + such as what filtering decisions are appropriate or how an MUA might + render those results, as these are local policy and/or user interface + design questions that are not appropriate for this document. + + At the time of publication of this document, the following are + published email authentication methods: + + o SMTP Service Extension for Authentication [AUTH] + + o DomainKeys Identified Mail Signatures [DKIM] + + o Domain-based Message Authentication, Reporting, and Conformance + [DMARC] + + o Sender Policy Framework [SPF] + + o reverse IP address name validation ("iprev", defined in Section 3) + + o Require-Recipient-Valid-Since Header Field and SMTP Service + Extension [RRVS] + + o S/MIME Signature Verification [SMIME-REG] + + o Vouch By Reference [VBR] + + + + + + + + +Kucherawy Standards Track [Page 4] + +RFC 8601 Authentication-Results Header Field May 2019 + + + The following Historic specifications were previously supported by + this framework but have since become obsolete: + + o Author Domain Signing Practices [ADSP] (Historic) + + o DomainKeys [DOMAINKEYS] (Historic) + + Note that at the time of publication of this document the Sender ID + specification [SENDERID] (Experimental) is no longer supported by + this framework. Discussion regarding moving it to Historic status is + underway. + + There exist registries for tokens used within this header field that + refer to the specifications listed above. Section 6 describes the + registries and their contents and specifies the process by which + entries are added or updated. It also updates the existing contents + to match the current states of these specifications. + + The goal of this work is to give current and future authentication + schemes a common framework within which to deliver their results to + downstream agents and discourage the creation of unique header fields + for each. + + Although SPF defined a header field called "Received-SPF" and the + historic DomainKeys defined one called "DomainKey-Status" for this + purpose, those header fields are specific to the conveyance of their + respective results only and thus are insufficient to satisfy the + requirements enumerated below. In addition, many SPF implementations + have adopted the header field specified here at least as an option, + and DomainKeys has been obsoleted by DKIM. + +1.1. Purpose + + The header field defined in this document is expected to serve + several purposes: + + 1. Convey the results of various message authentication checks, + which are applied by upstream filters and Mail Transfer Agents + (MTAs) and then passed to MUAs and downstream filters within the + same "trust domain". Such agents might wish to render those + results to end users or to use those data to apply more or less + stringent content checks based on authentication results. + + 2. Provide a common location within a message for such data. + + 3. Create an extensible framework for reporting new authentication + methods as they emerge. + + + + +Kucherawy Standards Track [Page 5] + +RFC 8601 Authentication-Results Header Field May 2019 + + + In particular, the mere presence of this header field does not mean + its contents are valid. Rather, the header field is reporting + assertions made by one or more authentication schemes applied + somewhere upstream. For an MUA or downstream filter to treat the + assertions as actually valid, there must be an assessment of the + trust relationship among such agents, the validating MTA, the paths + between them, and the mechanism for conveying the information. + +1.2. Trust Boundary + + This document makes several references to the "trust boundary" of an + Administrative Management Domain (ADMD). Given the diversity among + existing mail environments, a precise definition of this term isn't + possible. + + Simply put, a transfer from the producer of the header field to the + consumer must occur within a context that permits the consumer to + treat assertions by the producer as being reliable and accurate + (trustworthy). How this trust is obtained is outside the scope of + this document. It is entirely a local matter. + + Thus, this document defines a "trust boundary" as the delineation + between "external" and "internal" entities. Services that are + internal -- within the trust boundary -- are provided by the ADMD's + infrastructure for its users. Those that are external are outside of + the authority of the ADMD. By this definition, hosts that are within + a trust boundary are subject to the ADMD's authority and policies, + independent of their physical placement or their physical operation. + For example, a host within a trust boundary might actually be + operated by a remote service provider and reside physically within + its data center. + + It is possible for a message to be evaluated inside a trust boundary + but then depart and re-enter the trust boundary. An example might be + a forwarded message such as a message/rfc822 attachment (see + "Multipurpose Internet Mail Extensions" [MIME]) or one that is part + of a multipart/digest. The details reported by this field cannot be + trusted in that case. Thus, if found within one of those media + types, this field is typically ignored. + + Note that an MUA could be configured to retrieve messages from a + receiver yet not be within the receiver's ADMD. In this case, for + the purposes of this work, that MUA is considered to be within the + receiver's ADMD if it is configured to identify and ascribe value to + authentication results recorded by that ADMD. + + + + + + +Kucherawy Standards Track [Page 6] + +RFC 8601 Authentication-Results Header Field May 2019 + + +1.3. Processing Scope + + The content of this header field is meant to convey to message + consumers that authentication work on the message was already done + within its trust boundary, and those results are being presented. It + is not intended to provide message parameters to consumers so that + they can perform authentication protocols on their own. + +1.4. Requirements + + This document establishes no new requirements on existing protocols, + insofar as a non-participating service will continue to interoperate + with the deployed messaging infrastructure. + + In particular, this document establishes no requirement on MTAs to + reject or filter arriving messages that do not pass authentication + checks. The data conveyed by the specified header field's contents + are for the information of MUAs and filters and are to be used at + their discretion. + + A participating ADMD does undertake some filtering and message + modification obligations as described in Section 5. + +1.5. Definitions + + This section defines various terms used throughout this document. + +1.5.1. Key Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +1.5.2. Internationalized Email + + In this document, there are references to messages formatted to + support Email Address Internationalization (EAI). Reference material + for this can be found in [RFC6530], [RFC6531], and [RFC6532]. + Generally speaking, these documents allow UTF-8 in most places that + free-form text can be found and U-labels where domain names can be + used, and this document extends Authentication-Results accordingly. + + + + + + + + +Kucherawy Standards Track [Page 7] + +RFC 8601 Authentication-Results Header Field May 2019 + + +1.5.3. Security + + "Guidelines for Writing RFC Text on Security Considerations" + [SECURITY] discusses authentication and authorization and the + conflation of the two concepts. The use of those terms within the + context of recent message security work has given rise to slightly + different definitions, and this document reflects those current + usages, as follows: + + o "Authorization" is the establishment of permission to use a + resource or represent an identity. In this context, authorization + indicates that a message from a particular ADMD arrived via a + route the ADMD has explicitly approved. + + o "Authentication" is the assertion of validity of a piece of data + about a message (such as the sender's identity) or the message in + its entirety. + + As examples: SPF is an authorization mechanism in that it expresses a + result that shows whether the ADMD that apparently sent the message + has explicitly authorized the connecting Simple Mail Transfer + Protocol (SMTP) client [SMTP] to relay messages on its behalf, but it + does not actually validate any other property of the message itself. + By contrast, DKIM is agnostic as to the routing of a message but uses + cryptographic signatures to authenticate agents, assign (some) + responsibility for the message (which implies authorization), and + ensure that the listed portions of the message were not modified in + transit. Since the signatures are not tied to SMTP connections, they + can be added by the ADMD of origin, intermediate ADMDs (such as a + mailing list server), other handling agents, or any combination of + these. + + Rather than create a separate header field for each class of + solution, this specification groups them both into a single header + field. + +1.5.4. Email Architecture + + o A "border MTA" is an MTA that acts as a gateway between the + general Internet and the users within an organizational boundary. + (See also Section 1.2.) + + o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that + actually enacts delivery of a message to a user's inbox or other + final delivery. + + + + + + +Kucherawy Standards Track [Page 8] + +RFC 8601 Authentication-Results Header Field May 2019 + + + o An "intermediate MTA" is any MTA that is not a delivery MTA and is + also not the first MTA to handle the message. + + o A Message Submission Agent (MSA) is an agent that accepts a + message from an MUA, introducing it to the mail-handling stream. + + The following diagram illustrates the flow of mail among these + defined components. See "Internet Mail Architecture" [EMAIL-ARCH] + for further discussion on general email system architecture, which + includes detailed descriptions of these components, and Appendix C of + this document for discussion about the common aspects of email + authentication in current environments. + + +-----+ +-----+ +------------+ + | MUA |-->| MSA |-->| Border MTA | + +-----+ +-----+ +------------+ + | + | + V + +----------+ + | Internet | + +----------+ + | + | + V + +-----+ +-----+ +------------------+ +------------+ + | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | + +-----+ +-----+ +------------------+ +------------+ + + Generally, it is assumed that the work of applying message + authentication schemes takes place at a border MTA or a delivery MTA. + This specification is written with that assumption in mind. However, + there are some sites at which the entire mail infrastructure consists + of a single host. In such cases, such terms as "border MTA" and + "delivery MTA" might well apply to the same machine or even the very + same agent. It is also possible that some message authentication + tests could take place on an intermediate MTA. Although this + document doesn't specifically describe such cases, they are not meant + to be excluded. + +1.5.5. Other Terms + + In this document, the term "producer" refers to any component that + adds this header field to messages it is handling, and "consumer" + refers to any component that identifies, extracts, and parses the + header field to use as part of a handling decision. + + + + + +Kucherawy Standards Track [Page 9] + +RFC 8601 Authentication-Results Header Field May 2019 + + +1.6. Trust Environment + + This header field permits one or more message validation mechanisms + to communicate output to one or more separate assessment mechanisms. + These mechanisms operate within a unified trust boundary that defines + an ADMD. An ADMD contains one or more entities that perform + validation and generate the header field and one or more that consume + it for some type of assessment. The field often contains no + integrity or validation mechanism of its own, so its presence must be + trusted implicitly. Hence, valid use of the header field requires + removing any occurrences of it that claim to be associated with the + ADMD when the message enters the ADMD. This ensures that later + occurrences have been added within the trust boundary of the ADMD. + + The authserv-id token defined in Section 2.2 can be used to reference + an entire ADMD or a specific validation engine within an ADMD. + Although the labeling scheme is left as an operational choice, some + guidance for selecting a token is provided in later sections of this + document. + +2. Definition and Format of the Header Field + + This section gives a general overview of the format of the header + field being defined and then provides a formal specification. + +2.1. General Description + + The header field specified here is called "Authentication-Results". + It is a structured header field as defined in "Internet Message + Format" [MAIL], and thus all of the related definitions in that + document apply. + + This header field is added at the top of the message as it transits + MTAs that do authentication checks, so some idea of how far away the + checks were done can be inferred. It is therefore considered to be a + trace field as defined in [MAIL], and thus all of the related + definitions in that document apply. + + The value of the header field (after removing comments) consists of + an authentication service identifier, an optional version, and then a + series of statements and supporting data. The statements are of the + form "method=result" and indicate which authentication method or + methods were applied and their respective results. For each such + statement, the supporting data can include a "reason" string and one + or more "property=value" statements indicating which message + properties were evaluated to reach that conclusion. + + + + + +Kucherawy Standards Track [Page 10] + +RFC 8601 Authentication-Results Header Field May 2019 + + + The header field can appear more than once in a single message, more + than one result can be represented in a single header field, or a + combination of these can be applied. + +2.2. Formal Definition + + Formally, the header field is specified as shown below using + Augmented Backus-Naur Form [ABNF]. Examples of valid header fields + with explanations of their semantics can be found in Appendix B. + + authres-header-field = "Authentication-Results:" authres-payload + + authres-payload = [CFWS] authserv-id + [ CFWS authres-version ] + ( no-result / 1*resinfo ) [CFWS] CRLF + + authserv-id = value + ; see below for a description of this element + + authres-version = 1*DIGIT [CFWS] + ; indicates which version of this specification is in use; + ; this specification is version "1", and the absence of a + ; version implies this version of the specification + + no-result = [CFWS] ";" [CFWS] "none" + ; the special case of "none" is used to indicate that no + ; message authentication was performed + + resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] + [ CFWS 1*propspec ] + + methodspec = [CFWS] method [CFWS] "=" [CFWS] result + ; indicates which authentication method was evaluated + ; and what its output was + + reasonspec = "reason" [CFWS] "=" [CFWS] value + ; a free-form comment on the reason the given result + ; was returned + + propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue + ; an indication of which properties of the message + ; were evaluated by the authentication scheme being + ; applied to yield the reported result + + + + + + + + +Kucherawy Standards Track [Page 11] + +RFC 8601 Authentication-Results Header Field May 2019 + + + method = Keyword [ [CFWS] "/" [CFWS] method-version ] + ; a method indicates which method's result is + ; represented by "result"; it is one of the methods + ; explicitly defined as valid in this document + ; or is an extension method as defined below + + method-version = 1*DIGIT [CFWS] + ; indicates which version of the method specification is + ; in use, corresponding to the matching entry in the IANA + ; "Email Authentication Methods" registry; a value of "1" + ; is assumed if this version string is absent + + result = Keyword + ; indicates the results of the attempt to authenticate + ; the message; see below for details + + ptype = Keyword + ; indicates whether the property being evaluated was + ; a parameter to an SMTP command [SMTP], was a value taken + ; from a message header field, was some property of + ; the message body, or was some other property evaluated by + ; the receiving MTA; expected to be one of the "property + ; types" explicitly defined as valid, or an extension + ; ptype, as defined below + + property = special-smtp-verb / Keyword + ; indicates more specifically than "ptype" what the + ; source of the evaluated property is; the exact meaning + ; is specific to the method whose result is being reported + ; and is defined more clearly below + + special-smtp-verb = "mailfrom" / "rcptto" + ; special cases of SMTP commands [SMTP] that are made up + ; of multiple words + + pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) + [CFWS] + ; the value extracted from the message property defined + ; by the "ptype.property" construction + + "local-part" is defined in Section 3.4.1 of [MAIL], as modified by + [RFC6531]. + + "CFWS" is defined in Section 3.2.2 of [MAIL]. + + + + + + + +Kucherawy Standards Track [Page 12] + +RFC 8601 Authentication-Results Header Field May 2019 + + + "Keyword" is defined in Section 4.1.2 of [SMTP]. It is further + constrained by the necessity of being registered in the Internet + Assigned Numbers Authority (IANA) registry relevant to the context in + which it is used. See Sections 2.3, 2.7, and 6. + + The "value" is as defined in Section 5.1 of [MIME], with + "quoted-string" updated as specified in [RFC6532]. + + The "domain-name" is as defined in Section 3.5 of [DKIM]. + + See Section 2.5 for a description of the authserv-id element. + + If the value portion of a "pvalue" construction identifies something + intended to be an email identity, then it MUST use the right-hand + portion of that ABNF definition. + + The list of commands eligible for use with the "smtp" ptype can be + found in Section 4.1 of [SMTP]. + + The "propspec" may be omitted if, for example, the method was unable + to extract any properties to do its evaluation yet still has a result + to report. It may also be omitted if the agent generating this + result wishes not to reveal such properties to downstream agents. + + Where an SMTP command name is being reported as a "property", the + agent generating the header field represents that command by + converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" + becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). + + A "ptype" value of "policy" indicates a policy decision about the + message not specific to a property of the message that could be + extracted. See Section 2.4 for details. + + Examples of complete messages using this header field can be found in + Appendix B. + +2.3. Property Types (ptypes) and Properties + + The "ptype" in the ABNF above indicates the general type of property + being described by the result being reported, upon which the reported + result was based. Coupled with the "property", which is more + specific, it indicates from where the reported "pvalue" was + extracted. This can include a particular part of the message header + or body, some part of the SMTP session, a secondary output of an + authentication method (apart from its pure result), or some other + aspect of the message's handling. + + + + + +Kucherawy Standards Track [Page 13] + +RFC 8601 Authentication-Results Header Field May 2019 + + + Combinations of ptypes and properties are registered and described in + the "Email Authentication Methods" registry, coupled with the + authentication methods with which they are used. This is further + described in Section 6. + + Legal values of "ptype" are as defined in the IANA "Email + Authentication Property Types" registry, created by [RFC7410]. The + initial values and what they typically indicate are as follows, based + on [RFC7001]: + + body: Information that was extracted from the body of the message. + This might be an arbitrary string of bytes, a hash of a string of + bytes, a Uniform Resource Identifier, or some other content of + interest. The "property" is an indication of where within the + message body the extracted content was found and can indicate an + offset, identify a MIME part, etc. (At the time of this revision, + no properties matching this ptype have been registered. + Accordingly, this ptype may be deprecated in the future.) + + header: Indicates information that was extracted from the header of + the message. This might be the value of a header field or some + portion of a header field. The "property" gives a more precise + indication of the place in the header from which the extraction + took place. + + policy: A local policy mechanism was applied that augments or + overrides the result returned by the authentication mechanism. + (See Section 2.4.) + + smtp: Indicates information that was extracted from an SMTP command + that was used to relay the message. The "property" indicates + which SMTP command included the extracted content as a parameter. + + Results reported using unknown ptypes MUST NOT be used in making + handling decisions. They can be safely ignored by consumers. + + Entries in the "Email Authentication Methods" registry can define + properties that deviate from these definitions when appropriate. + Such deviations need to be clear in the registry and/or in the + defining document. See Section 2.7.1 for an example. + + + + + + + + + + + +Kucherawy Standards Track [Page 14] + +RFC 8601 Authentication-Results Header Field May 2019 + + +2.4. The "policy" ptype + + A special ptype value of "policy" is also defined. This ptype is + provided to indicate that some local policy mechanism was applied + that augments or even replaces (i.e., overrides) the result returned + by the authentication mechanism. The property and value in this case + identify the local policy that was applied and the result it + returned. + + For example, a DKIM signature is not required to include the Subject + header field in the set of fields that are signed. An ADMD receiving + such a message might decide that such a signature is unacceptable, + even if it passes, because the content of the Subject header field + could be altered post-signing without invalidating the signature. + Such an ADMD could replace the DKIM "pass" result with a "policy" + result and then also include the following in the corresponding + Authentication-Results field: + + ... dkim=policy policy.dkim-rules=unsigned-subject ... + + In this case, the property is "dkim-rules", indicating that some + local check by that name took place and that check returned a result + of "unsigned-subject". These are arbitrary names selected by (and + presumably used within) the ADMD making use of them, so they are not + normally registered with IANA or otherwise specified apart from + setting syntax restrictions that allow for easy parsing within the + rest of the header field. + + This ptype existed in the original specification for this header + field [RFC5451], but without a complete description or example of + intended use. As a result, it has not seen any practical use to date + that matches its intended purpose. These added details are provided + to guide implementers toward proper use. + +2.5. Authentication Service Identifier Field + + Every Authentication-Results header field has an authentication + service identifier field (authserv-id above). Specifically, this is + any string intended to identify the authentication service within the + ADMD that conducted authentication checks on the message. This + identifier is intended to be machine-readable and not necessarily + meaningful to users. + + Note that in an EAI-formatted message, this identifier may be + expressed in UTF-8. + + + + + + +Kucherawy Standards Track [Page 15] + +RFC 8601 Authentication-Results Header Field May 2019 + + + Since agents consuming this field will use this identifier to + determine whether its contents are of interest (and are safe to use), + the uniqueness of the identifier MUST be guaranteed by the ADMD that + generates it and MUST pertain to that ADMD. MUAs or downstream + filters SHOULD use this identifier to determine whether or not the + data contained in an Authentication-Results header field ought to be + used or ignored. + + For simplicity and scalability, the authentication service identifier + SHOULD be a common token used throughout the ADMD. Common practice + is to use the DNS domain name used by or within that ADMD, sometimes + called the "organizational domain", but this is not strictly + necessary. + + For tracing and debugging purposes, the authentication service + identifier can instead be the specific hostname of the MTA performing + the authentication check whose result is being reported. Moreover, + some implementations define a substructure to the identifier; such + structures are outside of the scope of this specification. + + Note, however, that using a local, relative identifier like a flat + hostname, rather than a hierarchical and globally unique ADMD + identifier like a DNS domain name, makes configuration more difficult + for large sites. The hierarchical identifier permits aggregating + related, trusted systems together under a single, parent identifier, + which in turn permits assessing the trust relationship with a single + reference. The alternative is a flat namespace requiring + individually listing each trusted system. Since consumers will use + the identifier to determine whether to use the contents of the header + field: + + o Changes to the identifier impose a large, centralized + administrative burden. + + o Ongoing administrative changes require constantly updating this + centralized table, making it difficult to ensure that an MUA or + downstream filter will have access to accurate information for + assessing the usability of the header field's content. In + particular, consumers of the header field will need to know not + only the current identifier(s) in use but previous ones as well to + account for delivery latency or later reassessment of the header + field's content. + + Examples of valid authentication service identifiers are + "example.com", "mail.example.org", "ms1.newyork.example.com", and + "example-auth". + + + + + +Kucherawy Standards Track [Page 16] + +RFC 8601 Authentication-Results Header Field May 2019 + + +2.6. Version Tokens + + The grammar above provides for the optional inclusion of versions on + both the header field itself (attached to the authserv-id token) and + on each of the methods being reported. The method version refers to + the method itself, which is specified in the documents describing + those methods, while the authserv-id version refers to this document + and thus the syntax of this header field. + + The purpose of including these is to avoid misinterpretation of the + results. That is, if a parser finds a version after an authserv-id + that it does not explicitly know, it can immediately discontinue + trying to parse, since what follows might not be in an expected + format. For a method version, the parser SHOULD ignore a method + result if the version is not supported in case the semantics of the + result have a different meaning than what is expected. For example, + if a hypothetical DKIM version 2 yielded a "pass" result for + different reasons than version 1 does, a consumer of this field might + not want to use the altered semantics. Allowing versions in the + syntax is a way to indicate this and let the consumer of the header + field decide. + +2.7. Defined Methods and Result Values + + Each individual authentication method returns one of a set of + specific result values. The subsections below provide references to + the documents defining the authentication methods specifically + supported by this document, and their corresponding result values. + Verifiers SHOULD use these values as described below. New methods + not specified in this document, but intended to be supported by the + header field defined here, MUST include a similar result table either + in their defining documents or in supplementary ones. + +2.7.1. DKIM + + DKIM is represented by the "dkim" method and is defined in [DKIM]. + + A signature is "acceptable to the ADMD" if it passes local policy + checks (or there are no specific local policy checks). For example, + an ADMD policy might require that the signature(s) on the message be + added using the DNS domain present in the From header field of the + message, thus making third-party signatures unacceptable even if they + verify. + + + + + + + + +Kucherawy Standards Track [Page 17] + +RFC 8601 Authentication-Results Header Field May 2019 + + + The DKIM result set is as follows: + + none: The message was not signed. + + pass: The message was signed, the signature or signatures were + acceptable to the ADMD, and the signature(s) passed verification + tests. + + fail: The message was signed and the signature or signatures were + acceptable to the ADMD, but they failed the verification test(s). + + policy: The message was signed, but some aspect of the signature or + signatures was not acceptable to the ADMD. + + neutral: The message was signed, but the signature or signatures + contained syntax errors or were not otherwise able to be + processed. This result is also used for other failures not + covered elsewhere in this list. + + temperror: The message could not be verified due to some error that + is likely transient in nature, such as a temporary inability to + retrieve a public key. A later attempt may produce a final + result. + + permerror: The message could not be verified due to some error that + is unrecoverable, such as a required header field being absent. A + later attempt is unlikely to produce a final result. + + DKIM results are reported using a ptype of "header". The property, + however, represents one of the tags found in the DKIM-Signature + header field rather than a distinct header field. For example, the + ptype-property combination "header.d" refers to the content of the + "d" (signing domain) tag from within the signature header field, and + not a distinct header field called "d". + + Note that in an EAI-formatted message, the values of the "d" and "i" + properties can be expressed in UTF-8. + + In addition to previous registrations, this document registers the + DKIM tags "a" (cryptographic algorithm used to sign the message) and + "s" (selector) as reportable properties. These can be used to aid + receivers during post-verification processing. In particular, + [RFC8301] obsoleted use of the "rsa-sha1" algorithm in DKIM, so it is + important to be able to distinguish such signatures from those using + preferred algorithms. + + The ability to report different DKIM results for a message with + multiple signatures is described in [RFC6008]. + + + +Kucherawy Standards Track [Page 18] + +RFC 8601 Authentication-Results Header Field May 2019 + + + [DKIM] advises that if a message fails verification, it is to be + treated as an unsigned message. A report of "fail" here permits the + receiver of the report to decide how to handle the failure. A report + of "neutral" or "none" preempts that choice, ensuring that the + message will be treated as if it had not been signed. + +2.7.2. SPF + + SPF uses the "spf" method name. The result values for SPF are + defined in Section 2.6 of [SPF], and those definitions are included + here by reference: + + +-----------+------------------------------+ + | Code | Meaning | + +-----------+------------------------------+ + | none | [SPF], Section 2.6.1 | + +-----------+------------------------------+ + | pass | [SPF], Section 2.6.3 | + +-----------+------------------------------+ + | fail | [SPF], Section 2.6.4 | + +-----------+------------------------------+ + | softfail | [SPF], Section 2.6.5 | + +-----------+------------------------------+ + | policy | RFC 8601, Section 2.4 | + +-----------+------------------------------+ + | neutral | [SPF], Section 2.6.2 | + +-----------+------------------------------+ + | temperror | [SPF], Section 2.6.6 | + +-----------+------------------------------+ + | permerror | [SPF], Section 2.6.7 | + +-----------+------------------------------+ + + These result codes are used in the context of this specification to + reflect the result returned by the component conducting SPF + evaluation. + + For SPF, the ptype used is "smtp", and the property is either + "mailfrom" or "helo", since those values are the ones SPF can + evaluate. (If the SMTP client issued the EHLO command instead of + HELO, the property used is "helo".) + + Note that in an EAI-formatted message, the local-part of the + "mailfrom" can be expressed in UTF-8 and the domain part can be + expressed as a U-label. + + For this method, an additional result of "policy" is defined, which + means the client was authorized to inject or relay mail on behalf of + the sender's DNS domain according to the authentication method's + + + +Kucherawy Standards Track [Page 19] + +RFC 8601 Authentication-Results Header Field May 2019 + + + algorithm, but local policy dictates that the result is unacceptable. + For example, "policy" might be used if SPF returns a "pass" result, + but a local policy check matches the sending DNS domain to one found + in an explicit list of unacceptable DNS domains (e.g., spammers). + + If the retrieved sender policies used to evaluate SPF do not contain + explicit provisions for authenticating the local-part (see + Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported along + with results for this mechanism SHOULD NOT include the local-part or + the following "@" character. + +2.7.3. "iprev" + + The result values used by the "iprev" method, defined in Section 3, + are as follows: + + pass: The DNS evaluation succeeded, i.e., the "reverse" and + "forward" lookup results were returned and were in agreement. + + fail: The DNS evaluation failed. In particular, the "reverse" and + "forward" lookups each produced results, but they were not in + agreement, or the "forward" query completed but produced no + result, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN, or an + RCODE of 0 (NOERROR) in a reply containing no answers, was + returned. + + temperror: The DNS evaluation could not be completed due to some + error that is likely transient in nature, such as a temporary DNS + error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or + other error condition resulted. A later attempt may produce a + final result. + + permerror: The DNS evaluation could not be completed because no PTR + data are published for the connecting IP address, e.g., a DNS + RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) + in a reply containing no answers, was returned. This prevented + completion of the evaluation. A later attempt is unlikely to + produce a final result. + + There is no "none" for this method, since any TCP connection + delivering email has an IP address associated with it, so some kind + of evaluation will always be possible. + + The result is reported using a ptype of "policy" (as this is not part + of any established protocol) and a property of "iprev". + + For discussion of the format of DNS replies, see "Domain names - + implementation and specification" [DNS]. + + + +Kucherawy Standards Track [Page 20] + +RFC 8601 Authentication-Results Header Field May 2019 + + +2.7.4. SMTP AUTH + + SMTP AUTH (defined in [AUTH]) is represented by the "auth" method. + Its result values are as follows: + + none: SMTP authentication was not attempted. + + pass: The SMTP client authenticated to the server reporting the + result using the protocol described in [AUTH]. + + fail: The SMTP client attempted to authenticate to the server using + the protocol described in [AUTH] but was not successful (such as + providing a valid identity but an incorrect password). + + temperror: The SMTP client attempted to authenticate using the + protocol described in [AUTH] but was not able to complete the + attempt due to some error that is likely transient in nature, such + as a temporary directory service lookup error. A later attempt + may produce a final result. + + permerror: The SMTP client attempted to authenticate using the + protocol described in [AUTH] but was not able to complete the + attempt due to some error that is likely not transient in nature, + such as a permanent directory service lookup error. A later + attempt is not likely to produce a final result. + + The result of AUTH is reported using a ptype of "smtp" and a property + of either: + + o "auth", in which case the value is the authorization identity + generated by the exchange initiated by the AUTH command; or + + o "mailfrom", in which case the value is the mailbox identified by + the AUTH parameter used with the MAIL FROM command. + + Note that in an EAI-formatted message, the local-part can be + expressed in UTF-8 and the domain can be expressed as a U-label. + + If both identities are available, both can be reported. For example, + consider this command issued by a client that has completed session + authentication with the AUTH command resulting in an authorized + identity of "client@c.example": + + MAIL FROM:<alice@a.example> AUTH=<bob@b.example> + + This could result in a "resinfo" construction like so: + + ; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example + + + +Kucherawy Standards Track [Page 21] + +RFC 8601 Authentication-Results Header Field May 2019 + + + Note that in all cases other than "pass", the message was sent by an + unauthenticated client. All non-"pass" cases SHOULD thus be treated + as equivalent with respect to this method. + +2.7.5. Other Registered Codes + + Result codes were also registered in other RFCs as follows: + + o Vouch By Reference (in [AR-VBR], represented by "vbr"). + + o Authorized Third-Party Signatures (in [ATPS], represented by + "dkim-atps"). + + o Author Domain Signing Practices (in [ADSP], represented by + "dkim-adsp"). + + o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs"). + + o S/MIME (in [SMIME-REG], represented by "smime"). + + Note that in an EAI-formatted message, "vbr.mv" and "vbr.md", which + are already registered, can be expressed as U-labels. + +2.7.6. Extension Methods + + Additional authentication method identifiers (extension methods) may + be defined in the future by later revisions or extensions to this + specification. These method identifiers are registered with IANA + and, preferably, published in an RFC. See Section 6 for further + details. + + Extension methods can be defined for the following reasons: + + 1. To allow additional information from new authentication systems + to be communicated to MUAs or downstream filters. The names of + such identifiers ought to reflect the name of the method being + defined but ought not be needlessly long. + + 2. To allow the creation of "sub-identifiers" that indicate + different levels of authentication and differentiate between + their relative strengths, e.g., "auth1-weak" and "auth1-strong". + + + + + + + + + + +Kucherawy Standards Track [Page 22] + +RFC 8601 Authentication-Results Header Field May 2019 + + + Authentication method implementers are encouraged to provide adequate + information, via message header field comments if necessary, to allow + an MUA developer to understand or relay ancillary details of + authentication results. For example, if it might be of interest to + relay what data were used to perform an evaluation, such information + could be relayed as a comment in the header field, such as: + + Authentication-Results: example.com; + foo=pass bar.baz=blob (2 of 3 tests OK) + + Experimental method identifiers MUST only be used within ADMDs that + have explicitly consented to use them. These method identifiers and + the parameters associated with them are not documented formally. + Therefore, they are subject to change at any time and not suitable + for production use. Any MTA, MUA, or downstream filter intended for + production use SHOULD ignore or delete any Authentication-Results + header field that includes an experimental (unknown) method + identifier. + +2.7.7. Extension Result Codes + + Additional result codes (extension results) might be defined in the + future by later revisions or extensions to this specification. + Non-experimental result codes MUST be registered with IANA (and, + preferably, published in an RFC). See Section 6 for further details. + + Experimental results MUST only be used within ADMDs that have + explicitly consented to use them. These results and the parameters + associated with them are not formally documented. Therefore, they + are subject to change at any time and not suitable for production + use. Any MTA, MUA, or downstream filter intended for production use + SHOULD ignore or delete any Authentication-Results header field that + includes an extension result. + +3. The "iprev" Authentication Method + + This section defines an additional authentication method called + "iprev". + + "iprev" is an attempt to verify that a client appears to be valid + based on some DNS queries, which is to say that the IP address is + explicitly associated with a domain name. Upon receiving a session + initiation of some kind from a client, the IP address of the client + peer is queried for matching names (i.e., a number-to-name + translation, also known as a "reverse lookup" or a "PTR" record + query). Once that result is acquired, a lookup of each of the names + (i.e., a name-to-number translation, or an "A" or "AAAA" record + + + + +Kucherawy Standards Track [Page 23] + +RFC 8601 Authentication-Results Header Field May 2019 + + + query) thus retrieved is done. The response to this second check + will typically result in at least one mapping back to the client's IP + address. + + Expressed as an algorithm: If the client peer's IP address is I, the + list of names to which I maps (after a "PTR" query) is the set N, and + the union of IP addresses to which each member of N maps (after + corresponding "A" and "AAAA" queries) is L, then this test is + successful if I is an element of L. + + Often an MTA receiving a connection that fails this test will simply + reject the connection using the enhanced status code defined in + [AUTH-ESC]. If an operator instead wishes to make this information + available to downstream agents as a factor in handling decisions, it + records a result in accordance with Section 2.7.3. + + The response to a "PTR" query could contain multiple names. To + prevent heavy DNS loads, agents performing these queries MUST be + implemented such that the number of names evaluated by generation of + corresponding "A" or "AAAA" queries is limited so as not to be unduly + taxing to the DNS infrastructure, though it MAY be configurable by an + administrator. As an example, Section 4.6.4 of [SPF] chose a limit + of 10 for its implementation of this algorithm. + + "DNS Extensions to Support IP Version 6" [DNS-IP6] discusses the + query formats for the IPv6 case. + + There is some contention regarding the wisdom and reliability of this + test. For example, in some regions, it can be difficult for this + test ever to pass because the practice of arranging to match the + forward and reverse DNS is infrequently observed. Therefore, the + precise implementation details of how a verifier performs an "iprev" + test are not specified here. The verifier MAY report a successful or + failed "iprev" test at its discretion having done some kind of check + of the validity of the connection's identity using DNS. It is + incumbent upon an agent making use of the reported "iprev" result to + understand what exactly that particular verifier is attempting to + report. + + Extensive discussion of reverse DNS mapping and its implications can + be found in "Considerations for the use of DNS Reverse Mapping" + [DNSOP-REVERSE]. In particular, it recommends that applications + avoid using this test as a means of authentication or security. Its + presence in this document is not an endorsement but is merely + acknowledgment that the method remains common and provides the means + to relay the results of that test. + + + + + +Kucherawy Standards Track [Page 24] + +RFC 8601 Authentication-Results Header Field May 2019 + + +4. Adding the Header Field to a Message + + This specification makes no attempt to evaluate the relative + strengths of various message authentication methods that may become + available. The methods listed are an order-independent set; their + sequence does not indicate relative strength or importance of one + method over another. Instead, the MUA or downstream filter consuming + this header field is to interpret the result of each method based on + its own knowledge of what that method evaluates. + + Each "method" MUST refer to an authentication method declared in the + IANA registry or an extension method as described in Section 2.7.6, + and each "result" MUST refer to a result code declared in the IANA + registry or an extension result code as defined in Section 2.7.7. + See Section 6 for further information about the registered methods + and result codes. + + An MTA compliant with this specification adds this header field + (after performing one or more message authentication tests) to + indicate which MTA or ADMD performed the test, which test was + applied, and what the result was. If an MTA applies more than one + such test, it adds this header field either once per test or once + indicating all of the results. An MTA MUST NOT add a result to an + existing header field. + + An MTA MAY add this header field containing only the authentication + service identifier portion and the "none" token (see Section 2.2) to + indicate explicitly that no message authentication schemes were + applied prior to delivery of this message. + + An MTA adding this header field has to take steps to identify it as + legitimate to the MUAs or downstream filters that will ultimately + consume its content. One process to do so is described in Section 5. + Further measures may be necessary in some environments. Some + possible solutions are enumerated in Section 7.1. This document does + not mandate any specific solution to this issue, as each environment + has its own facilities and limitations. + + Most known message authentication methods focus on a particular + identifier to evaluate. SPF differs in that it can yield a result + based on more than one identifier; specifically, SPF can evaluate the + RFC5321.HELO parameter or the RFC5321.MailFrom parameter. When + generating this field to report those results, only the parameter + that yielded the result is included. + + + + + + + +Kucherawy Standards Track [Page 25] + +RFC 8601 Authentication-Results Header Field May 2019 + + + For MTAs that add this header field, adding header fields in order + (at the top), per Section 3.6 of [MAIL], is particularly important. + Moreover, this header field SHOULD be inserted above any other trace + header fields such MTAs might prepend. This placement allows easy + detection of header fields that can be trusted. + + End users making direct use of this header field might inadvertently + trust information that has not been properly vetted. If, for + example, a basic SPF result were to be relayed that claims an + authenticated addr-spec, the local-part of that addr-spec has + actually not been authenticated. Thus, an MTA adding this header + field SHOULD NOT include any data that have not been authenticated by + the method(s) being applied. Moreover, MUAs SHOULD NOT render to + users such information if it is presented by a method known not to + authenticate it. + +4.1. Header Field Position and Interpretation + + In order to ensure non-ambiguous results and avoid the impact of + false header fields, MUAs and downstream filters SHOULD NOT interpret + this header field unless specifically configured to do so by the user + or administrator. That is, this interpretation should not be "on by + default". Naturally then, users or administrators ought not activate + such a feature unless (1) they are certain the header field will be + validly added by an agent within the ADMD that accepts the mail that + is ultimately read by the MUA, and (2) instances of the header field + that appear to originate within the ADMD but are actually added by + foreign MTAs will be removed before delivery. + + Furthermore, MUAs and downstream filters SHOULD NOT interpret this + header field unless the authentication service identifier of the + header field is used within the ADMD as configured by the user or + administrator. + + MUAs and downstream filters MUST ignore any result reported using a + "result" not specified in the IANA "Result Code" registry or a + "ptype" not listed in the "Email Authentication Property Types" + registry for such values as defined in Section 6. Moreover, such + agents MUST ignore a result indicated for any "method" they do not + specifically support. The exception to this is experimental methods + as discussed in Section 2.7.6. + + An MUA SHOULD NOT reveal these results to end users, absent careful + "human factors" design considerations and testing, for the + presentation of trust-related materials. For example, an attacker + could register examp1e.com (note the digit "1" (one)) and send signed + mail to intended victims; a verifier would detect that the signature + + + + +Kucherawy Standards Track [Page 26] + +RFC 8601 Authentication-Results Header Field May 2019 + + + was valid and report a "pass" even though it's clear the DNS domain + name was intended to mislead. See Section 7.2 for further + discussion. + + As stated in Section 2.1, this header field MUST be treated as though + it were a trace header field as defined in Section 3.6.7 of [MAIL] + and hence MUST NOT be reordered and MUST be prepended to the message, + so that there is generally some indication upon delivery of where in + the chain of handling MTAs the message authentication was done. + + Note that there are a few message handlers that are only capable of + appending new header fields to a message. Strictly speaking, these + handlers are not compliant with this specification. They can still + add the header field to carry authentication details, but any signal + about where in the handling chain the work was done may be lost. + Consumers SHOULD be designed such that this can be tolerated, + especially from a producer known to have this limitation. + + MUAs SHOULD ignore instances of this header field discovered within + message/rfc822 MIME attachments. They are likely to contain the + results of authentication checks done in the past, possibly long ago, + and have no contemporary value. Due caution therefore needs to be + taken when choosing to consume them. + + Further discussion of these topics can be found in Section 7 below. + +4.2. Local Policy Enforcement + + Some sites have a local policy that considers any particular + authentication policy's non-recoverable failure results (typically + "fail" or similar) as justification for rejecting the message. In + such cases, the border MTA SHOULD issue an SMTP rejection response to + the message, rather than adding this header field and allowing the + message to proceed toward delivery. This is more desirable than + allowing the message to reach an internal host's MTA or spam filter, + thus possibly generating a local rejection such as a Delivery Status + Notification (DSN) [DSN] to a forged originator. Such generated + rejections are colloquially known as "backscatter". + + The same MAY also be done for local policy decisions overriding the + results of the authentication methods (e.g., the "policy" result + codes described in Section 2.7). + + Such rejections at the SMTP protocol level are not possible if local + policy is enforced at the MUA and not the MTA. + + + + + + +Kucherawy Standards Track [Page 27] + +RFC 8601 Authentication-Results Header Field May 2019 + + +5. Removing Existing Header Fields + + To mitigate the impact of forged header fields, any MTA conforming to + this specification MUST delete any discovered instance of this header + field that claims, by virtue of its authentication service + identifier, to have been added within its trust boundary but that did + not come directly from another trusted MTA. For example, an MTA for + example.com receiving a message MUST delete or otherwise obscure any + instance of this header field bearing an authentication service + identifier indicating that the header field was added within + example.com prior to adding its own header fields. This could mean + each internal MTA will need to be configured with a list of other + known, trusted MTAs that are thus expected to be using that same + identifier. + + In the case of EAI-formatted messages, this test is done after + converting A-labels into U-labels. + + For simplicity and maximum security, a border MTA could remove all + instances of this header field on mail crossing into its trust + boundary. However, this may conflict with the desire to access + authentication results performed by trusted external service + providers. It may also invalidate signed messages whose signatures + cover external instances of this header field. A more robust border + MTA could allow a specific list of authenticating MTAs whose + information is to be admitted, removing the header field originating + from all others. + + As stated in Section 1.2, a formal definition of "trust boundary" is + deliberately not made here. It is entirely possible that a border + MTA for example.com will explicitly trust authentication results + asserted by upstream host example.net even though they exist in + completely disjoint administrative boundaries. In that case, the + border MTA MAY elect not to delete those results; moreover, the + upstream host doing some authentication work could apply a signing + technology such as [DKIM] on its own results to assure downstream + hosts of their authenticity. An example of this is provided in + Appendix B. + + Similarly, in the case of messages signed using [DKIM] or other + message-signing methods that sign header fields, this removal action + could invalidate one or more signatures on the message if they + covered the header field to be removed. This behavior can be + desirable, since there's little value in validating the signature on + a message with forged header fields. However, signing agents MAY + therefore elect to omit these header fields from signing to avoid + this situation. + + + + +Kucherawy Standards Track [Page 28] + +RFC 8601 Authentication-Results Header Field May 2019 + + + An MTA SHOULD remove any instance of this header field bearing a + version (express or implied) that it does not support. However, an + MTA MUST remove such a header field if the SMTP connection [SMTP] + relaying the message is not from a trusted internal MTA. (As + discussed above, this too can result in invalidation of signatures.) + This means the MTA needs to be able to understand versions of this + header field at least as late as the ones understood by the MUAs or + other consumers within its ADMD. + +6. IANA Considerations + + IANA has registered the defined header field and created registries + as described below. These registry actions were originally defined + by [RFC5451] and updated by [RFC6577] and [RFC7001]. The created + registries were further updated in [RFC7601] to make them more + complete. + + Each registry has two related sections below. The first describes + the registry and its update procedures, which are unchanged from + [RFC7601]. The second enumerates changes to entries that are + relevant to this document. + +6.1. The Authentication-Results Header Field + + The Authentication-Results header field was added to the IANA + "Permanent Message Header Field Names" registry, per the procedure + found in [IANA-HEADERS]. That entry has been updated to reference + this document. The following is the registration template: + + Header field name: Authentication-Results + Applicable protocol: mail [MAIL] + Status: standard + Author/Change controller: IETF + Specification document(s): RFC 8601 + Related information: none + + + + + + + + + + + + + + + + +Kucherawy Standards Track [Page 29] + +RFC 8601 Authentication-Results Header Field May 2019 + + +6.2. "Email Authentication Methods" Registry Description + + Names of message authentication methods supported by this + specification have been registered with IANA, with the exception of + experimental names as described in Section 2.7.6. Along with each + method are recorded the properties that accompany the method's + result. + + The "Email Authentication Parameters" group, and within it the "Email + Authentication Methods" registry, were created by [RFC5451] for this + purpose. [RFC6577] added a "Status" field for each entry. [RFC7001] + amended the rules governing that registry and also added a "Version" + field to the registry. + + The reference for that registry has been updated to reference this + document. + + New entries are assigned only for values that have received Expert + Review, per [IANA-CONSIDERATIONS]. The designated expert shall be + appointed by the IESG. The designated expert has discretion to + request that a publication be referenced if a clear, concise + definition of the authentication method cannot be provided, such that + interoperability is assured. Registrations should otherwise be + permitted. The designated expert can also handle requests to mark + any current registration as "deprecated". + + No two entries can have the same combination of method, ptype, and + property. + + An entry in this registry contains the following: + + Method: the name of the method. + + Definition: a reference to the document that created this entry, if + any (see below). + + ptype: a "ptype" value appropriate for use with that method. + + Property: a "property" value matching that "ptype" also appropriate + for use with that method. + + Value: a brief description of the value to be supplied with that + method/ptype/property tuple. + + + + + + + + +Kucherawy Standards Track [Page 30] + +RFC 8601 Authentication-Results Header Field May 2019 + + + Status: the status of this entry, which is one of the following: + + active: The entry is in current use. + + deprecated: The entry is no longer in current use. + + Version: a version number associated with the method (preferably + starting at "1"). + + The "Definition" field will typically refer to a permanent document, + or at least some descriptive text, where additional information about + the entry being added can be found. This might in turn reference the + document where the method is defined so that all of the semantics + around creating or interpreting an Authentication-Results header + field using this method, ptype, and property can be understood. + +6.3. "Email Authentication Methods" Registry Update + + The following entries in this registry have been updated to replace + [RFC7601] with this document: + + +------------+--------+----------------------------------+ + | Method | ptype | Property | + +------------+--------+----------------------------------+ + | auth | smtp | auth | + +------------+--------+----------------------------------+ + | auth | smtp | mailfrom | + +------------+--------+----------------------------------+ + | dkim | header | d | + +------------+--------+----------------------------------+ + | dkim | header | i | + +------------+--------+----------------------------------+ + | iprev | policy | iprev | + +------------+--------+----------------------------------+ + | spf | smtp | mailfrom | + +------------+--------+----------------------------------+ + | spf | smtp | helo | + +------------+--------+----------------------------------+ + + Notably, the DomainKeys and Sender ID entries are not updated to + refer to this revised specification, as they are considered obsolete. + Accordingly, IANA has changed the "Status" field of the "sender-id" + entry in this table to "deprecated". + + + + + + + + +Kucherawy Standards Track [Page 31] + +RFC 8601 Authentication-Results Header Field May 2019 + + + Finally, two new entries have been added to this registry, as + follows: + +6.3.1. "header.a" for DKIM + + Method: dkim + + Definition: RFC 8601 + + ptype: header + + Property: a + + Value: value of signature "a" tag + + Status: active + + Version: 1 + +6.3.2. "header.s" for DKIM + + Method: dkim + + Definition: RFC 8601 + + ptype: header + + Property: s + + Value: value of signature "s" tag + + Status: active + + Version: 1 + +6.4. "Email Authentication Property Types" Registry Description + + [RFC7410] created the "Email Authentication Property Types" registry. + + Entries in this registry are subject to the Expert Review rules as + described in [IANA-CONSIDERATIONS]. Each entry in the registry + requires the following values: + + ptype: the name of the ptype being registered, which must fit within + the ABNF described in Section 2.2. + + Definition: an optional reference to a defining specification. + + + + +Kucherawy Standards Track [Page 32] + +RFC 8601 Authentication-Results Header Field May 2019 + + + Description: a brief description of what sort of information this + "ptype" is meant to cover. + + For new entries, the designated expert needs to ensure that the + description provided for the new entry adequately describes the + intended use. An example would be helpful to include in the entry's + defining document (if any), although entries in the "Email + Authentication Methods" registry or the "Email Authentication Result + Names" registry might also serve as examples of intended use. + + As this is a complete restatement of the definition and rules for + this registry, IANA has updated this registry to show Section 2.3 of + this document as the current definitions for the "body", "header", + "policy", and "smtp" entries of that registry. + +6.5. "Email Authentication Property Types" Registry Update + + All current entries in this registry have been updated to replace + [RFC7601] with this document. + +6.6. "Email Authentication Result Names" Registry Description + + Names of message authentication result codes supported by this + specification must be registered with IANA, with the exception of + experimental codes as described in Section 2.7.7. + + New entries are assigned only for values that have received Expert + Review, per [IANA-CONSIDERATIONS]. The designated expert shall be + appointed by the IESG. The designated expert has discretion to + request that a publication be referenced if a clear, concise + definition of the authentication result cannot be provided, such that + interoperability is assured. Registrations should otherwise be + permitted. The designated expert can also handle requests to mark + any current registration as "deprecated". + + No two entries can have the same combination of method and code. + + An entry in this registry contains the following: + + Auth Method: an authentication method for which results are being + returned using the header field defined in this document. + + Code: a result code that can be returned for this authentication + method. + + Specification: either free-form text explaining the meaning of this + method-code combination or a reference to such a definition. + + + + +Kucherawy Standards Track [Page 33] + +RFC 8601 Authentication-Results Header Field May 2019 + + + Status: the status of this entry, which is one of the following: + + active: The entry is in current use. + + deprecated: The entry is no longer in current use. + +6.7. "Email Authentication Result Names" Registry Update + + For the following entries in this registry, the new "Specification" + field has been set as follows: + + o All "auth" method result codes ("fail", "none", "pass", + "permerror", and "temperror") are now specified in Section 2.7.4 + of this document. + + o All "dkim" method result names ("fail", "neutral", "none", "pass", + "permerror", "policy", and "temperror") are now specified in + Section 2.7.1 of this document. + + o All "iprev" method result names ("fail", "pass", "permerror", and + "temperror") are now specified in Section 2.7.3 of this document. + + o The "spf" method result names "fail", "neutral", "none", "pass", + "permerror", "policy", "softfail", and "temperror" are now + specified in Section 2.7.2 of this document. The registration for + result name "hardfail" is not updated. + + The following entries in this registry have been updated with a new + "Status" field set to "deprecated", and with no change to the + "Specification" field as they reference historic protocols: + + o All "domainkeys" method result names ("fail", "neutral", "none", + "pass", "permerror", "policy", and "temperror"). + + o All "sender-id" method result names ("fail", "neutral", "none", + "pass", "permerror", "policy", "softfail", and "temperror"). + +6.8. SMTP Enhanced Status Codes + + The entry for X.7.25 in the "Enumerated Status Codes" subregistry of + the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes + Registry" has been updated to refer only to Section 3.3 of + [AUTH-ESC], as that is where that registration was done. + + + + + + + + +Kucherawy Standards Track [Page 34] + +RFC 8601 Authentication-Results Header Field May 2019 + + +7. Security Considerations + + The following security considerations apply when adding or processing + the Authentication-Results header field: + +7.1. Forged Header Fields + + An MTA not applying the filtering discussed in Section 5 exposes MUAs + to false conclusions based on forged header fields. A malicious user + or agent could forge a header field using the DNS domain of a + receiving ADMD as the authserv-id token in the value of the header + field and, with the rest of the value, claim that the message was + properly authenticated. The non-conformant MTA would fail to strip + the forged header field, and the MUA could inappropriately trust it. + + For this reason, it is best not to have processing of the + Authentication-Results header field enabled by default; instead, it + should be ignored, at least for the purposes of enacting filtering + decisions, unless specifically enabled by the user or administrator + after verifying that the border MTA is compliant. It is acceptable + to have an MUA aware of this specification but have an explicit list + of hostnames whose Authentication-Results header fields are + trustworthy; however, this list should initially be empty. + + Proposed alternative solutions to this problem were made some time + ago and are listed below. To date, they have not been developed due + to lack of demand but are documented here should the information be + useful at some point in the future: + + 1. Possibly the simplest is a digital signature protecting the + header field, such as using [DKIM], that can be verified by an + MUA by using a posted public key. Although one of the main + purposes of this document is to relieve the burden of doing + message authentication work at the MUA, this only requires that + the MUA learn a single authentication scheme even if a number of + them are in use at the border MTA. Note that [DKIM] requires + that the From header field be signed, although in this + application, the signing agent (a trusted MTA) likely cannot + authenticate that value, so the fact that it is signed should be + ignored. Where the authserv-id is the ADMD's domain name, the + authserv-id matching this valid internal signature's "d=" DKIM + value is sufficient. + + 2. Another would be a means to interrogate the MTA that added the + header field to see if it is actually providing any message + authentication services and saw the message in question, but this + isn't especially palatable given the work required to craft and + implement such a scheme. + + + +Kucherawy Standards Track [Page 35] + +RFC 8601 Authentication-Results Header Field May 2019 + + + 3. Yet another might be a method to interrogate the internal MTAs + that apparently handled the message (based on Received header + fields) to determine whether any of them conform to Section 5 of + this memo. This, too, has potentially high barriers to entry. + + 4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to + allow an MUA or filtering agent to acquire the authserv-id in use + within an ADMD, thus allowing it to identify which + Authentication-Results header fields it can trust. + + 5. On the presumption that internal MTAs are fully compliant with + Section 3.6 of [MAIL] and the compliant internal MTAs are using + their own hostnames or the ADMD's DNS domain name as the + authserv-id token, this header field should always appear above a + Received header added by a trusted MTA. This can be used as a + test for header field validity. + + Support for some of these is being considered for future work. + + In any case, a mechanism needs to exist for an MUA or filter to + verify that the host that appears to have added the header field + (a) actually did so and (b) is legitimately adding that header field + for this delivery. Given the variety of messaging environments + deployed today, consensus appears to be that specifying a particular + mechanism for doing so is not appropriate for this document. + + Mitigation of the forged header field attack can also be accomplished + by moving the authentication results data into metadata associated + with the message. In particular, an SMTP extension [SMTP] could be + established to communicate authentication results from the border MTA + to intermediate and delivery MTAs; the latter of these could arrange + to store the authentication results as metadata retrieved and + rendered along with the message by an IMAP client [IMAP] aware of a + similar extension in that protocol. The delivery MTA would be told + to trust data via this extension only from MTAs it trusts, and border + MTAs would not accept data via this extension from any source. There + is no vector in such an arrangement for forgery of authentication + data by an outside agent. + +7.2. Misleading Results + + Until some form of service for querying the reputation of a sending + agent is widely deployed, the existence of this header field + indicating a "pass" does not render the message trustworthy. It is + possible for an arriving piece of spam or other undesirable mail to + pass checks by several of the methods enumerated above (e.g., a piece + of spam signed using [DKIM] by the originator of the spam, which + + + + +Kucherawy Standards Track [Page 36] + +RFC 8601 Authentication-Results Header Field May 2019 + + + might be a spammer or a compromised system). In particular, this + issue is not resolved by forged header field removal (discussed + above). + + Hence, MUAs and downstream filters must take some care with use of + this header even after possibly malicious headers are scrubbed. + +7.3. Header Field Position + + Despite the requirements of [MAIL], header fields can sometimes be + reordered en route by intermediate MTAs. The goal of requiring + header field addition only at the top of a message is an + acknowledgment that some MTAs do reorder header fields, but most do + not. Thus, in the general case, there will be some indication of + which MTAs (if any) handled the message after the addition of the + header field defined here. + +7.4. Reverse IP Query Denial-of-Service Attacks + + Section 4.6.4 of [SPF] observes that limits are necessary on + recursive evaluations of SPF records in order to avoid abuse of or + attacks on the DNS when verifying arriving client connections. A + verifier wishing to do this check and report this information needs + to take care not to go to unbounded lengths to resolve "A" and "PTR" + queries. MUAs or other filters making use of an "iprev" result + specified by this document need to be aware of the algorithm used by + the verifier reporting the result and, especially, its limitations. + +7.5. Mitigation of Backscatter + + Failing to follow the instructions of Section 4.2 can result in a + denial-of-service attack caused by the generation of DSN messages + [DSN] (or equivalent) to addresses that did not send the messages + being rejected. + +7.6. Internal MTA Lists + + Section 5 describes a procedure for scrubbing header fields that may + contain forged authentication results about a message. A compliant + installation will have to include, at each MTA, a list of other MTAs + known to be compliant and trustworthy. Failing to keep this list + current as internal infrastructure changes may expose an ADMD to + attack. + + + + + + + + +Kucherawy Standards Track [Page 37] + +RFC 8601 Authentication-Results Header Field May 2019 + + +7.7. Attacks against Authentication Methods + + If an attack against an authentication method becomes known, clearly + then the agent verifying that method can be fooled into thinking an + inauthentic message is authentic, and thus the value of this header + field can be misleading. It follows that any attack against the + authentication methods supported by this document is also a security + consideration here. + +7.8. Intentionally Malformed Header Fields + + As with any other header field found in the message, it is possible + for an attacker to add an Authentication-Results header field that is + extraordinarily large or otherwise malformed in an attempt to + discover or exploit weaknesses in header field parsing code. + Implementers must thoroughly verify all such header fields received + from MTAs and be robust against intentionally as well as + unintentionally malformed header fields. + +7.9. Compromised Internal Hosts + + An internal MUA or MTA that has been compromised could generate mail + with a forged From header field and a forged Authentication-Results + header field that endorses it. Although it is clearly a larger + concern to have compromised internal machines than it is to prove the + value of this header field, this risk can be mitigated by arranging + that internal MTAs will remove this header field if it claims to have + been added by a trusted border MTA (as described above), yet the SMTP + connection [SMTP] is not coming from an internal machine known to be + running an authorized MTA. However, in such a configuration, + legitimate MTAs will have to add this header field when legitimate + internal-only messages are generated. This is also covered in + Section 5. + +7.10. Encapsulated Instances + + MIME messages can contain attachments of type "message/rfc822", which + contain other messages. Such an encapsulated message can also + contain an Authentication-Results header field. Although the + processing of these is outside of the intended scope of this document + (see Section 1.3), some simple guidance to MUA developers is + appropriate here. + + Since MTAs are generally unlikely to strip Authentication-Results + header fields during mailbox delivery, normative language exists in + Section 4.1 cautioning MUAs to ignore such instances within MIME + attachments, as might be included when a message is forwarded. + Moreover, when extracting a message digest to separate mail store + + + +Kucherawy Standards Track [Page 38] + +RFC 8601 Authentication-Results Header Field May 2019 + + + messages or other media, such header fields should be removed so that + they will never be interpreted improperly by MUAs that might later + consume them. + + There can be cases where these header fields included as part of + encapsulated messages might actually be of value, such as when they + are taken from messages within the same ADMD where they will be + consumed. Caution must be taken to ensure that the consumer fully + understands the semantics of what the header field is indicating and + the message's handling history before ascribing any value, positive + or negative, to such data. + +7.11. Reverse Mapping + + Although Section 3 of this memo includes explicit support for the + "iprev" method, its value as an authentication mechanism is limited. + Implementers of both this specification and agents that use the data + it relays are encouraged to become familiar with the issues raised by + [DNSOP-REVERSE] when deciding whether or not to include support for + "iprev". + +8. References + +8.1. Normative References + + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <https://www.rfc-editor.org/info/rfc5234>. + + [IANA-HEADERS] + Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + DOI 10.17487/RFC3864, September 2004, + <https://www.rfc-editor.org/info/rfc3864>. + + [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + <https://www.rfc-editor.org/info/rfc5322>. + + [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, + <https://www.rfc-editor.org/info/rfc2045>. + + + + + + + +Kucherawy Standards Track [Page 39] + +RFC 8601 Authentication-Results Header Field May 2019 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for + Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, + February 2012, <https://www.rfc-editor.org/info/rfc6530>. + + [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized + Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, + <https://www.rfc-editor.org/info/rfc6531>. + + [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized + Email Headers", RFC 6532, DOI 10.17487/RFC6532, + February 2012, <https://www.rfc-editor.org/info/rfc6532>. + + [RFC7601] Kucherawy, M., "Message Header Field for Indicating + Message Authentication Status", RFC 7601, + DOI 10.17487/RFC7601, August 2015, + <https://www.rfc-editor.org/info/rfc7601>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + <https://www.rfc-editor.org/info/rfc8174>. + + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + <https://www.rfc-editor.org/info/rfc5321>. + +8.2. Informative References + + [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, + "DomainKeys Identified Mail (DKIM) Author Domain Signing + Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, + August 2009, <https://www.rfc-editor.org/info/rfc5617>. + + [AR-VBR] Kucherawy, M., "Authentication-Results Registration for + Vouch by Reference Results", RFC 6212, + DOI 10.17487/RFC6212, April 2011, + <https://www.rfc-editor.org/info/rfc6212>. + + [ATPS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) + Authorized Third-Party Signatures", RFC 6541, + DOI 10.17487/RFC6541, February 2012, + <https://www.rfc-editor.org/info/rfc6541>. + + + + +Kucherawy Standards Track [Page 40] + +RFC 8601 Authentication-Results Header Field May 2019 + + + [AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service + Extension for Authentication", RFC 4954, + DOI 10.17487/RFC4954, July 2007, + <https://www.rfc-editor.org/info/rfc4954>. + + [AUTH-ESC] Kucherawy, M., "Email Authentication Status Codes", + RFC 7372, DOI 10.17487/RFC7372, September 2014, + <https://www.rfc-editor.org/info/rfc7372>. + + [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", STD 76, + RFC 6376, DOI 10.17487/RFC6376, September 2011, + <https://www.rfc-editor.org/info/rfc6376>. + + [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based + Message Authentication, Reporting, and Conformance + (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, + <https://www.rfc-editor.org/info/rfc7489>. + + [DNS] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, <https://www.rfc-editor.org/info/rfc1035>. + + [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", STD 88, + RFC 3596, DOI 10.17487/RFC3596, October 2003, + <https://www.rfc-editor.org/info/rfc3596>. + + [DNSOP-REVERSE] + Senie, D. and A. Sullivan, "Considerations for the use + of DNS Reverse Mapping", Work in Progress, + draft-ietf-dnsop-reverse-mapping-considerations-06, + March 2008. + + [DOMAINKEYS] + Delany, M., "Domain-Based Email Authentication Using + Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, + DOI 10.17487/RFC4870, May 2007, + <https://www.rfc-editor.org/info/rfc4870>. + + [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format + for Delivery Status Notifications", RFC 3464, + DOI 10.17487/RFC3464, January 2003, + <https://www.rfc-editor.org/info/rfc3464>. + + + + + + + +Kucherawy Standards Track [Page 41] + +RFC 8601 Authentication-Results Header Field May 2019 + + + [EMAIL-ARCH] + Crocker, D., "Internet Mail Architecture", RFC 5598, + DOI 10.17487/RFC5598, July 2009, + <https://www.rfc-editor.org/info/rfc5598>. + + [IANA-CONSIDERATIONS] + Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, + <https://www.rfc-editor.org/info/rfc3501>. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, + <https://www.rfc-editor.org/info/rfc1939>. + + [RFC5451] Kucherawy, M., "Message Header Field for Indicating + Message Authentication Status", RFC 5451, + DOI 10.17487/RFC5451, April 2009, + <https://www.rfc-editor.org/info/rfc5451>. + + [RFC6008] Kucherawy, M., "Authentication-Results Registration for + Differentiating among Cryptographic Results", RFC 6008, + DOI 10.17487/RFC6008, September 2010, + <https://www.rfc-editor.org/info/rfc6008>. + + [RFC6577] Kucherawy, M., "Authentication-Results Registration Update + for Sender Policy Framework (SPF) Results", RFC 6577, + DOI 10.17487/RFC6577, March 2012, + <https://www.rfc-editor.org/info/rfc6577>. + + [RFC7001] Kucherawy, M., "Message Header Field for Indicating + Message Authentication Status", RFC 7001, + DOI 10.17487/RFC7001, September 2013, + <https://www.rfc-editor.org/info/rfc7001>. + + [RFC7410] Kucherawy, M., "A Property Types Registry for the + Authentication-Results Header Field", RFC 7410, + DOI 10.17487/RFC7410, December 2014, + <https://www.rfc-editor.org/info/rfc7410>. + + [RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage + Update to DomainKeys Identified Mail (DKIM)", RFC 8301, + DOI 10.17487/RFC8301, January 2018, + <https://www.rfc-editor.org/info/rfc8301>. + + + +Kucherawy Standards Track [Page 42] + +RFC 8601 Authentication-Results Header Field May 2019 + + + [RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- + Since Header Field and SMTP Service Extension", RFC 7293, + DOI 10.17487/RFC7293, July 2014, + <https://www.rfc-editor.org/info/rfc7293>. + + [SECURITY] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, + DOI 10.17487/RFC3552, July 2003, + <https://www.rfc-editor.org/info/rfc3552>. + + [SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", + RFC 4406, DOI 10.17487/RFC4406, April 2006, + <https://www.rfc-editor.org/info/rfc4406>. + + [SMIME-REG] + Melnikov, A., "Authentication-Results Registration for + S/MIME Signature Verification", RFC 7281, + DOI 10.17487/RFC7281, June 2014, + <https://www.rfc-editor.org/info/rfc7281>. + + [SPF] Kitterman, S., "Sender Policy Framework (SPF) for + Authorizing Use of Domains in Email, Version 1", RFC 7208, + DOI 10.17487/RFC7208, April 2014, + <https://www.rfc-editor.org/info/rfc7208>. + + [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By + Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, + <https://www.rfc-editor.org/info/rfc5518>. + + + + + + + + + + + + + + + + + + + + + + + +Kucherawy Standards Track [Page 43] + +RFC 8601 Authentication-Results Header Field May 2019 + + +Appendix A. Legacy MUAs + + Implementers of this specification should be aware that many MUAs are + unlikely to be retrofitted to support the Authentication-Results + header field and its semantics. In the interests of convenience and + quicker adoption, a delivery MTA might want to consider adding things + that are processed by existing MUAs in addition to the + Authentication-Results header field. One suggestion is to include a + Priority header field, on messages that don't already have such a + header field, containing a value that reflects the strength of the + authentication that was accomplished, e.g., "low" for weak or no + authentication, "normal" or "high" for good or strong authentication. + + Some modern MUAs can already filter based on the content of this + header field. However, there is keen interest in having MUAs make + some kind of graphical representation of this header field's meaning + to end users. Until this capability is added (i.e., while this + specification and its successors continue to be adopted), other + interim means of conveying authentication results may be necessary. + +Appendix B. Authentication-Results Examples + + This section presents some examples of the use of this header field + to indicate authentication results. + +B.1. Trivial Case: Header Field Not Present + + The trivial case: + + Received: from mail-router.example.com + (mail-router.example.com [192.0.2.1]) + by server.example.org (8.11.6/8.11.6) + with ESMTP id g1G0r1kA003489; + Fri, Feb 15 2002 17:19:07 -0800 + From: sender@example.com + Date: Fri, Feb 15 2002 16:54:30 -0800 + To: receiver@example.org + Message-Id: <12345.abc@example.com> + Subject: here's a sample + + Hello! Goodbye! + + Example 1: Header Field Not Present + + + + + + + + +Kucherawy Standards Track [Page 44] + +RFC 8601 Authentication-Results Header Field May 2019 + + + The Authentication-Results header field is completely absent. The + MUA may make no conclusion about the validity of the message. This + could be the case because (1) the message authentication services + were not available at the time of delivery, (2) no service is + provided, or (3) the MTA is not in compliance with this + specification. + +B.2. Nearly Trivial Case: Service Provided, but No Authentication Done + + A message that was delivered by an MTA that conforms to this + specification but provides no actual message authentication service: + + Authentication-Results: example.org 1; none + Received: from mail-router.example.com + (mail-router.example.com [192.0.2.1]) + by server.example.org (8.11.6/8.11.6) + with ESMTP id g1G0r1kA003489; + Fri, Feb 15 2002 17:19:07 -0800 + From: sender@example.com + Date: Fri, Feb 15 2002 16:54:30 -0800 + To: receiver@example.org + Message-Id: <12345.abc@example.com> + Subject: here's a sample + + Hello! Goodbye! + + Example 2: Header Present but No Authentication Done + + The Authentication-Results header field is present, showing that the + delivering MTA conforms to this specification. It used its DNS + domain name as the authserv-id. The presence of "none" (and the + absence of any method or result tokens) indicates that no message + authentication was done. The version number of the specification to + which the field's content conforms is explicitly provided. + + + + + + + + + + + + + + + + + +Kucherawy Standards Track [Page 45] + +RFC 8601 Authentication-Results Header Field May 2019 + + +B.3. Service Provided, Authentication Done + + A message that was delivered by an MTA that conforms to this + specification and applied some message authentication: + + Authentication-Results: example.com; + spf=pass smtp.mailfrom=example.net + Received: from dialup-1-2-3-4.example.net + (dialup-1-2-3-4.example.net [192.0.2.200]) + by mail-router.example.com (8.11.6/8.11.6) + with ESMTP id g1G0r1kA003489; + Fri, Feb 15 2002 17:19:07 -0800 + From: sender@example.net + Date: Fri, Feb 15 2002 16:54:30 -0800 + To: receiver@example.com + Message-Id: <12345.abc@example.net> + Subject: here's a sample + + Hello! Goodbye! + + Example 3: Header Reporting Results + + The Authentication-Results header field is present, indicating that + the border MTA conforms to this specification. The authserv-id is + once again the DNS domain name. Furthermore, the message was + authenticated by that MTA via the method specified in [SPF]. Note + that since that method cannot authenticate the local-part, it has + been omitted from the result's value. The MUA could extract and + relay this extra information if desired. + + + + + + + + + + + + + + + + + + + + + + +Kucherawy Standards Track [Page 46] + +RFC 8601 Authentication-Results Header Field May 2019 + + +B.4. Service Provided, Several Authentications Done, Single MTA + + A message that was relayed inbound via a single MTA that conforms to + this specification and applied three different message authentication + checks: + + Authentication-Results: example.com; + auth=pass (cram-md5) smtp.auth=sender@example.net; + spf=pass smtp.mailfrom=example.net + Authentication-Results: example.com; iprev=pass + policy.iprev=192.0.2.200 + Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) + (dialup-1-2-3-4.example.net [192.0.2.200]) + by mail-router.example.com (8.11.6/8.11.6) + with ESMTPA id g1G0r1kA003489; + Fri, Feb 15 2002 17:19:07 -0800 + Date: Fri, Feb 15 2002 16:54:30 -0800 + To: receiver@example.com + From: sender@example.net + Message-Id: <12345.abc@example.net> + Subject: here's a sample + + Hello! Goodbye! + + Example 4: Headers Reporting Results from One MTA + + The Authentication-Results header field is present, indicating that + the delivering MTA conforms to this specification. Once again, the + receiving DNS domain name is used as the authserv-id. Furthermore, + the sender authenticated themselves to the MTA via a method specified + in [AUTH], and both SPF and "iprev" checks were done and passed. The + MUA could extract and relay this extra information if desired. + + Two Authentication-Results header fields are not required, since the + same host did all of the checking. The authenticating agent could + have consolidated all the results into one header field. + + This example illustrates a scenario in which a remote user on a + dial-up connection (example.net) sends mail to a border MTA + (example.com) using SMTP authentication to prove identity. The + dial-up provider has been explicitly authorized to relay mail as + example.net, producing a "pass" result from the SPF check. + + + + + + + + + +Kucherawy Standards Track [Page 47] + +RFC 8601 Authentication-Results Header Field May 2019 + + +B.5. Service Provided, Several Authentications Done, Different MTAs + + A message that was relayed inbound by two different MTAs that conform + to this specification and applied multiple message authentication + checks: + + Authentication-Results: example.com; + dkim=pass (good signature) header.d=example.com + Received: from mail-router.example.com + (mail-router.example.com [192.0.2.1]) + by auth-checker.example.com (8.11.6/8.11.6) + with ESMTP id i7PK0sH7021929; + Fri, Feb 15 2002 17:19:22 -0800 + DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; + t=1188964191; c=simple/simple; h=From:Date:To:Subject: + Message-Id:Authentication-Results; + bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; + b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= + Authentication-Results: example.com; + auth=pass (cram-md5) smtp.auth=sender@example.com; + spf=fail smtp.mailfrom=example.com + Received: from dialup-1-2-3-4.example.net + (dialup-1-2-3-4.example.net [192.0.2.200]) + by mail-router.example.com (8.11.6/8.11.6) + with ESMTPA id g1G0r1kA003489; + Fri, Feb 15 2002 17:19:07 -0800 + From: sender@example.com + Date: Fri, Feb 15 2002 16:54:30 -0800 + To: receiver@example.com + Message-Id: <12345.abc@example.com> + Subject: here's a sample + + Hello! Goodbye! + + Example 5: Headers Reporting Results from Multiple MTAs + + The Authentication-Results header field is present, indicating + conformance to this specification. Once again, the authserv-id used + is the recipient's DNS domain name. The header field is present + twice because two different MTAs in the chain of delivery did + authentication tests. The first MTA, mail-router.example.com, + reports that SMTP AUTH and SPF were both used and that the former + passed while the latter failed. In the SMTP AUTH case, additional + information is provided in the comment field, which the MUA can + choose to render if desired. + + + + + + +Kucherawy Standards Track [Page 48] + +RFC 8601 Authentication-Results Header Field May 2019 + + + The second MTA, auth-checker.example.com, reports that it did a DKIM + test (which passed). Again, additional data about one of the tests + are provided as a comment, which the MUA may choose to render. Also + noteworthy here is the fact that there is a DKIM signature added by + example.com that assured the integrity of the lower Authentication- + Results field. + + Since different hosts did the two sets of authentication checks, the + header fields cannot be consolidated in this example. + + This example illustrates more typical transmission of a message into + example.com from a user on a dial-up connection example.net. The + user appears to be legitimate, as they had a valid password allowing + authentication at the border MTA using SMTP AUTH. The SPF test + failed, since example.com has not granted example.net's dial-up + network authority to relay mail on its behalf. The DKIM test passed + because the sending user had a private key matching one of + example.com's published public keys and mail-router.example.com used + it to sign the message. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kucherawy Standards Track [Page 49] + +RFC 8601 Authentication-Results Header Field May 2019 + + +B.6. Service Provided, Multi-tiered Authentication Done + + A message that had authentication done at various stages, one of + which was outside the receiving ADMD: + + Authentication-Results: example.com; + dkim=pass reason="good signature" + header.i=@mail-router.example.net; + dkim=fail reason="bad signature" + header.i=@newyork.example.com + Received: from mail-router.example.net + (mail-router.example.net [192.0.2.250]) + by chicago.example.com (8.11.6/8.11.6) + for <recipient@chicago.example.com> + with ESMTP id i7PK0sH7021929; + Fri, Feb 15 2002 17:19:22 -0800 + DKIM-Signature: v=1; a=rsa-sha256; s=furble; + d=mail-router.example.net; t=1188964198; c=relaxed/simple; + h=From:Date:To:Message-Id:Subject:Authentication-Results; + bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; + b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= + Authentication-Results: example.net; + dkim=pass (good signature) header.i=@newyork.example.com + Received: from smtp.newyork.example.com + (smtp.newyork.example.com [192.0.2.220]) + by mail-router.example.net (8.11.6/8.11.6) + with ESMTP id g1G0r1kA003489; + Fri, Feb 15 2002 17:19:07 -0800 + DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; + d=newyork.example.com; + t=1188964191; c=simple/simple; + h=From:Date:To:Message-Id:Subject; + bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; + b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= + From: sender@newyork.example.com + Date: Fri, Feb 15 2002 16:54:30 -0800 + To: meetings@example.net + Message-Id: <12345.abc@newyork.example.com> + Subject: here's a sample + + Example 6: Headers Reporting Results from Multiple MTAs in + Different ADMDs + + In this example, we see multi-tiered authentication with an extended + trust boundary. + + + + + + +Kucherawy Standards Track [Page 50] + +RFC 8601 Authentication-Results Header Field May 2019 + + + The message was sent from someone at example.com's New York office + (newyork.example.com) to a mailing list managed at an intermediary. + The message was signed at the origin using DKIM. + + The message was sent to a mailing list service provider called + "example.net", which is used by example.com. There, + meetings@example.net is expanded to a long list of recipients, one of + whom is at the Chicago office. In this example, we will assume that + the trust boundary for chicago.example.com includes the mailing list + server at example.net. + + The mailing list server there first authenticated the message and + affixed an Authentication-Results header field indicating such using + its DNS domain name for the authserv-id. It then altered the message + by affixing some footer text to the body, including some + administrivia such as unsubscription instructions. Finally, the + mailing list server affixes a second DKIM signature and begins + distribution of the message. + + The border MTA for chicago.example.com explicitly trusts results from + mail-router.example.net, so that header field is not removed. It + performs evaluation of both signatures and determines that the first + (most recent) is a "pass" but, because of the aforementioned + modifications, the second is a "fail". However, the first signature + included the Authentication-Results header added at + mail-router.example.net that validated the second signature. Thus, + indirectly, it can be determined that the authentications claimed by + both signatures are indeed valid. + + Note that two styles of presenting metadata about the result are in + use here. In one case, the "reason=" clause is present, which is + intended for easy extraction by parsers; in the other case, the CFWS + production of the ABNF is used to include such data as a header field + comment. The latter can be harder for parsers to extract given the + varied supported syntaxes of mail header fields. + +B.7. Comment-Heavy Example + + The formal syntax permits comments within the content in a number of + places. For the sake of illustration, this example is also legal: + + Authentication-Results: foo.example.net (foobar) 1 (baz); + dkim (Because I like it) / 1 (One yay) = (wait for it) fail + policy (A dot can go here) . (like that) expired + (this surprised me) = (as I wasn't expecting it) 1362471462 + + Example 7: A Very Comment-Heavy but Perfectly Legal Example + + + + +Kucherawy Standards Track [Page 51] + +RFC 8601 Authentication-Results Header Field May 2019 + + +Appendix C. Operational Considerations about Message Authentication + + Implementation of the Authentication-Results header field is + predicated on the idea that authentication (and presumably in the + future, reputation) work is typically done by border MTAs rather than + MUAs or intermediate MTAs; the latter merely make use of the results + determined by the former. Certainly this is not mandatory for + participation in electronic mail or message authentication, but this + header field and its deployment to date are based on that model. The + assumption satisfies several common ADMD requirements: + + 1. Service operators prefer to resolve the handling of problem + messages as close to the border of the ADMD as possible. This + enables, for example, rejection of messages at the SMTP level + rather than generating a DSN internally. Thus, doing any of the + authentication or reputation work exclusively at the MUA or + intermediate MTA renders this desire unattainable. + + 2. Border MTAs are more likely to have direct access to external + sources of authentication or reputation information, since modern + MUAs inside of an ADMD are more likely to be heavily firewalled. + Thus, some MUAs might not even be able to complete the task of + performing authentication or reputation evaluations without + complex proxy configurations or similar burdens. + + 3. MUAs rely upon the upstream MTAs within their trust boundaries to + make correct (as much as is possible) evaluations about the + message's envelope, header, and content. Thus, MUAs don't need + to know how to do the work that upstream MTAs do; they only need + the results of that work. + + 4. Evaluations about the quality of a message, from simple token + matching (e.g., a list of preferred DNS domains) to cryptographic + verification (e.g., public/private key work), do have a cost and + thus need to be minimized. To that end, performing those tests + at the border MTA is far preferred to doing that work at each MUA + that handles a message. If an ADMD's environment adheres to + common messaging protocols, a reputation query or an + authentication check performed by a border MTA would return the + same result as the same query performed by an MUA. By contrast, + in an environment where the MUA does the work, a message arriving + for multiple recipients would thus cause authentication or + reputation evaluation to be done more than once for the same + message (i.e., at each MUA), causing needless amplification of + resource use and creating a possible denial-of-service attack + vector. + + + + + +Kucherawy Standards Track [Page 52] + +RFC 8601 Authentication-Results Header Field May 2019 + + + 5. Minimizing change is good. As new authentication and reputation + methods emerge, the list of methods supported by this header + field would presumably be extended. If MUAs simply consume the + contents of this header field rather than actually attempt to do + authentication and/or reputation work, then MUAs only need to + learn to parse this header field once; emergence of new methods + requires only a configuration change at the MUAs and software + changes at the MTAs (which are presumably fewer in number). When + choosing to implement these functions in MTAs vs. MUAs, the + issues of individual flexibility, infrastructure inertia, and + scale of effort must be considered. It is typically easier to + change a single MUA than an MTA because the modification affects + fewer users and can be pursued with less care. However, changing + many MUAs is more effort than changing a smaller number of MTAs. + + 6. For decisions affecting message delivery and display, assessment + based on authentication and reputation is best performed close to + the time of message transit, as a message makes its journey + toward a user's inbox, not afterwards. DKIM keys, IP address + reputations, etc., can change over time or even become invalid, + and users can take a long time to read a message once delivered. + The value of this work thus degrades, perhaps quickly, once the + delivery process has completed. This seriously diminishes the + value of this work when done elsewhere than at MTAs. + + Many operational choices are possible within an ADMD, including the + venue for performing authentication and/or reputation assessment. + The current specification does not dictate any of those choices. + Rather, it facilitates those cases in which information produced by + one stage of analysis needs to be transported with the message to the + next stage. + +Appendix D. Changes since RFC 7601 + + o Added IANA registration for DKIM "a" and "s" properties. + + o Included EAI guidance. + + o Adjusted some ABNF tokens and names for easier inclusion by other + documents. + + o Made minor editorial adjustments. + + o Deprecated entries from RFCs that are now Historic. + + o Erratum 4671 resolved. + + o Erratum 5435 resolved. + + + +Kucherawy Standards Track [Page 53] + +RFC 8601 Authentication-Results Header Field May 2019 + + +Acknowledgments + + The author wishes to acknowledge the following individuals for their + review and constructive criticism of this document: Kurt Andersen, + Seth Blank, Tim Draegen, Scott Kitterman, John Levine, and Alessandro + Vesely. + +Author's Address + + Murray S. Kucherawy + 270 Upland Drive + San Francisco, CA 94127 + United States of America + + Email: superuser@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kucherawy Standards Track [Page 54] + |