Message Header Field for Indicating Message Authentication Status
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.
Replaces RFC 5451: Message Header Field for Indicating Message Authentication Status, RFC 6577: Authentication-Results Registration Update for Sender Policy Framework (SPF) Results, RFC 7001: Message Header Field for Indicating Message Authentication Status, RFC 7410: A Property Types Registry for the Authentication-Results Header Field, RFC 7601: Message Header Field for Indicating Message Authentication Status.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 16 must, 18 should, 5 may.
2.2 Formal Definition
- MUSTIf 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.
2.3 Property Types (ptypes) and Properties
- MUST NOTResults reported using unknown ptypes MUST NOT be used in making handling decisions.
2.5 Authentication Service Identifier Field
- MUSTSince 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.
- SHOULDMUAs 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.
- SHOULDFor simplicity and scalability, the authentication service identifier SHOULD be a common token used throughout the ADMD.
2.6 Version Tokens
- SHOULDFor 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.
2.7 Defined Methods and Result Values
- SHOULDVerifiers SHOULD use these values as described below.
- MUSTNew 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.2 SPF
- SHOULD NOTIf 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.4 SMTP AUTH
- SHOULDAll non-"pass" cases SHOULD thus be treated as equivalent with respect to this method.
2.7.6 Extension Methods
- MUSTExperimental method identifiers MUST only be used within ADMDs that have explicitly consented to use them.
- SHOULDAny 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
- MUSTNon-experimental result codes MUST be registered with IANA (and, preferably, published in an RFC).
- MUSTExperimental results MUST only be used within ADMDs that have explicitly consented to use them.
- SHOULDAny 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
- MUSTTo 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.
- MAYThe 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.
4 Adding the Header Field to a Message
- MUSTEach "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.
- MUST NOTAn MTA MUST NOT add a result to an existing header field.
- MAYAn 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.
- SHOULDMoreover, this header field SHOULD be inserted above any other trace header fields such MTAs might prepend.
- SHOULD NOTThus, an MTA adding this header field SHOULD NOT include any data that have not been authenticated by the method(s) being applied.
- SHOULD NOTMoreover, 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
- SHOULD NOTIn 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.
- SHOULD NOTFurthermore, 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.
- MUSTMUAs 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.
- MUSTMoreover, such agents MUST ignore a result indicated for any "method" they do not specifically support.
- SHOULD NOTAn MUA SHOULD NOT reveal these results to end users, absent careful "human factors" design considerations and testing, for the presentation of trust-related materials.
- MUSTAs 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.
- SHOULDConsumers SHOULD be designed such that this can be tolerated, especially from a producer known to have this limitation.
- SHOULDMUAs SHOULD ignore instances of this header field discovered within message/rfc822 MIME attachments.
4.2 Local Policy Enforcement
- SHOULDIn 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.
- MAYThe 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).
5 Removing Existing Header Fields
- MUSTTo 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.
- MUSTFor 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.
- MAYIn 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.
- MAYHowever, signing agents MAY therefore elect to omit these header fields from signing to avoid this situation.
- SHOULDAn MTA SHOULD remove any instance of this header field bearing a version (express or implied) that it does not support.
- MUSTHowever, an MTA MUST remove such a header field if the SMTP connection [SMTP] relaying the message is not from a trusted internal MTA.