Message Header Field for Indicating Message Authentication Status
obsoleted by
- rfc-7001 — Message Header Field for Indicating Message Authentication Status
updated by
- rfc-6577 — Authentication-Results Registration Update for Sender Policy Framework (SPF) Results
Extracted elements (27)
Rather than creating separate header fields for each authentication class (as SPF did with Received-SPF and DomainKeys did with DomainKey-Status), this proposal groups all authentication results into a single extensible header field to provide a common location and framework for reporting new methods as they emerge.
The authserv-id SHOULD be a hierarchical DNS domain name rather than a local hostname because a hierarchical identifier allows aggregating related trusted systems under a single parent identifier, whereas a flat namespace of hostnames requires maintaining a constantly-updated list of each trusted system individually.
An MTA SHOULD remove any instance of this header field bearing a version it does not support; however it MUST remove such a header if the SMTP connection relaying the message is not from a trusted internal MTA.
If the retrieved sender policies for SPF and Sender-ID do not contain explicit provisions for authenticating the local-part of an address, the 'pvalue' reported with results for these mechanisms SHOULD NOT include the local-part, since it was not actually authenticated.
An MTA compliant with this specification MUST add the Authentication-Results header field after performing one or more message authentication tests. If more than one test is applied, it MUST add the header field either once per test or once indicating all results. An MTA MUST NOT add a result to an existing header field.
Extension method identifiers and result codes not beginning with 'x-' MUST be registered with IANA and published in an RFC. Implementations MUST use the 'x-' prefix for new methods until registered. Experimental methods MUST only be used within ADMDs that have explicitly consented to use them.
For security, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims to have been added within its trust boundary but did not come from another trusted MTA, to prevent acceptance of forged authentication results.
MUAs and downstream filters MUST ignore any result reported using a 'result' not specified in the result code registry, a 'ptype' not in the corresponding registry, or a 'method' they do not specifically support.
MUAs and downstream filters SHOULD NOT interpret the Authentication-Results header field unless specifically instructed by the user or administrator, and SHOULD NOT interpret it unless the authserv-id appears to be one used within its own ADMD. This interpretation should not be 'on by default'.
MUAs SHOULD ignore instances of the Authentication-Results header field discovered within message/rfc822 MIME attachments, as the processing of encapsulated messages is outside the intended scope of this specification.
The Authentication-Results header field MUST NOT be reordered and MUST be prepended to the message, per the trace field requirements of RFC 5322 Section 3.6.7.
The Authentication-Results header field SHOULD be added at the top of the message and treated as a trace field per RFC 5322. It SHOULD be inserted above any other trace header fields the MTA might prepend.
To limit DNS load during iprev checks, agents performing PTR/A/AAAA queries MUST be implemented such that the number of names evaluated by generation of corresponding A or AAAA queries is finite, though it MAY be configurable by an administrator.
Result values for DKIM and DomainKeys are: none (not signed), pass (signature verified), fail (signature verification failed), policy (signature not acceptable), neutral (signature syntax errors or processing failure), temperror (transient error), permerror (unrecoverable error).
Result values for SMTP AUTH are: none (authentication not attempted), pass (client authenticated successfully), fail (authentication attempted but unsuccessful), temperror (transient error such as temporary LDAP lookup failure), permerror (permanent error such as permanent LDAP lookup failure).
Result values for SPF and Sender-ID are: none (no policy records), neutral (sender ADMD makes no assertion), pass (client authorized), policy (authorized but local policy rejects), hardfail (explicitly not authorized), softfail (likely not authorized), temperror (transient error), permerror (unrecoverable error).
The Authentication-Results header field conveys the results of message authentication checks (DKIM, SPF, Sender-ID, SMTP AUTH, iprev) in a machine-readable format. It consists of an authserv-id, optional version, and one or more method=result statements with optional reason and property=value pairs.
The authserv-id is a dot-atom uniquely identifying the authenticating service within an ADMD. It SHOULD be the DNS domain name of the ADMD. Its uniqueness MUST be guaranteed by the ADMD that generates it.
The 'iprev' method verifies that a connecting client's IP address has consistent forward and reverse DNS mappings. Result values are: pass (reverse and forward DNS agree), fail (results disagree or forward lookup returned no result), temperror (transient DNS error), permerror (no PTR data published). There is no 'none' result since any TCP connection has an IP address.
IANA created the Email Authentication Method Name Registry with initial entries for 'auth' (RFC 4954), 'dkim' (RFC 4871), 'domainkeys' (RFC 4870), 'iprev' (RFC 5451), 'sender-id' (RFC 4406), and 'spf' (RFC 4408). New entries require IETF Review and RFC publication.
IANA created the Email Authentication Result Name Registry with initial result codes: none, pass, fail, policy, neutral, temperror, permerror, hardfail, and softfail, mapped to applicable authentication methods. New entries require IETF Review and RFC publication.
IANA registered the 'Authentication-Results' header field in the Permanent Message Header Field Registry under the mail protocol, with status Standard and IETF as change controller.
A malicious sender can forge an Authentication-Results header field using a legitimate ADMD's authserv-id. A non-conformant MTA that fails to strip forged headers allows MUAs to incorrectly trust them. Mitigation requires MUAs to treat this header field as untrusted by default and border MTAs to strip inbound instances claiming to be from within the ADMD.
A 'pass' result does not imply the message is trustworthy. Spam or malicious mail can legitimately pass authentication checks (e.g., spam signed with DKIM by its sender). MUAs and filters SHOULD NOT render authentication results to users without associated reputation data about the authenticated identity.
Intentionally malformed or extraordinarily large Authentication-Results header fields may be used to exploit weaknesses in header parsing code. Implementors must thoroughly verify all such header fields and be robust against both intentional and unintentional malformation.
The 'iprev' method has limited value as an authentication mechanism. In some regions forward/reverse DNS consistency is rarely observed, making the test unreliable. Implementors and consumers of iprev results are encouraged to consult RFC considerations on reverse DNS mapping before relying on this method.
The header field is formally defined via ABNF as: 'Authentication-Results:' authserv-id [version] (';' 'none' | 1*resinfo). Each resinfo contains a methodspec (method '=' result), optional reasonspec, and zero or more propspec (ptype '.' property '=' pvalue) elements.