RFC 7001
Message Header Field for Indicating Message Authentication Status
Message Header Field for Indicating Message Authentication Status 💌✨
- RFC 7001 🎀 Request for Comments: 7001
- Author: M. Kucherawy 🫶
- Category: Standards Track 🔥
- Date: September 2013 🌸
- Obsoletes:
5451, 6577💀 - ISSN: 2070-1721 🦋
- Publisher: Internet Engineering Task Force (IETF) 👑
Abstract 🌈
okay so this doc defines a header field called Authentication-Results for email messages. it's where you stash the results of message authentication checks, so the info is right there in the message 💅 any receiver-side software, like mail filters or Mail User Agents (MUAs), can read it and show it to people in a handy way, or use it to make sorting and filtering choices. it's giving organized inbox energy 🧚
Status of This Memo 🍓
this is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF). it reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 📚
for info about the current status of this doc, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7001 🦋
Copyright Notice 🔒
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. please read these carefully, because they explain your rights and restrictions for this doc 🙈 any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⭐
Table of Contents 📖
1. Introduction ....................................................3
1.1. Purpose ....................................................4
1.2. Trust Boundary .............................................5
1.3. Processing Scope ...........................................6
1.4. Requirements ...............................................6
1.5. Definitions ................................................6
1.5.1. Key Words ...........................................6
1.5.2. Security ............................................6
1.5.3. Email Architecture ..................................7
1.5.4. Other Terms .........................................8
1.6. Trust Environment ..........................................8
2. Definition and Format of the Header Field .......................9
2.1. General Description ........................................9
2.2. Formal Definition ..........................................9
2.3. The "policy" ptype ........................................12
2.4. Authentication Identifier Field ...........................13
2.5. Version Tokens ............................................14
2.6. Defined Methods and Result Values .........................14
2.6.1. DKIM and DomainKeys ................................14
2.6.2. SPF and Sender ID ..................................15
2.6.3. "iprev" ............................................17
2.6.4. SMTP AUTH ..........................................17
2.6.5. Other Registered Codes .............................18
2.6.6. Extension Methods ..................................18
2.6.7. Extension Result Codes .............................19
3. The "iprev" Authentication Method ..............................19
4. Adding the Header Field to a Message ...........................20
4.1. Header Field Position and Interpretation ..................22
4.2. Local Policy Enforcement ..................................23
5. Removing Existing Header Fields ................................23
6. IANA Considerations ............................................24
6.1. The Authentication-Results Header Field ...................25
6.2. "Email Authentication Methods" Registry ...................25
6.3. "Email Authentication Result Names" Registry ..............26
7. Security Considerations ........................................26
7.1. Forged Header Fields ......................................26
7.2. Misleading Results ........................................28
7.3. Header Field Position .....................................28
7.4. Reverse IP Query Denial-of-Service Attacks ................28
7.5. Mitigation of Backscatter .................................29
7.6. Internal MTA Lists ........................................29
7.7. Attacks against Authentication Methods ....................29
7.8. Intentionally Malformed Header Fields .....................29
7.9. Compromised Internal Hosts ................................29
7.10. Encapsulated Instances ...................................30
7.11. Reverse Mapping ..........................................30
8. References .....................................................30
8.1. Normative References ......................................30
8.2. Informative References ....................................31
Appendix A. Acknowledgements .....................................33
Appendix B. Legacy MUAs ..........................................33
Appendix C. Authentication-Results Examples ......................33
C.1. Trivial Case; Header Field Not Present ....................34
C.2. Nearly Trivial Case; Service Provided, but No
Authentication Done .......................................34
C.3. Service Provided, Authentication Done .....................35
C.4. Service Provided, Several Authentications Done, Single
MTA .......................................................36
C.5. Service Provided, Several Authentications Done,
Different MTAs ............................................37
C.6. Service Provided, Multi-Tiered Authentication Done ........38
C.7. Comment-Heavy Example .....................................40
Appendix D. Operational Considerations about Message
Authentication .......................................40
Appendix E. Changes since RFC 5451 ...............................421. Introduction ✨
this doc describes a header field called Authentication-Results for email messages. it shows the results of a message authentication effort in a machine-readable format 🤖 the whole point is to have a place to collect that data whenever message authentication mechanisms are in use, so an MUA and downstream filters can make filtering decisions, and/or give the user a recommendation about how valid the message's origin is and maybe how safe and intact its content is 💖
this doc revises the original definition found in [RFC5451], based on various authentication protocols in current use. it also picks up errata logged since the original spec came out 🧹
end users aren't expected to be the direct consumers of this header field. it's meant for programs that will either use the data or render it in a human-usable form, so you don't have to read it raw 🙈
this doc specifies the format of the header field and talks about what it means when the field is present or absent. it does not cover how the data should be used, like which filtering decisions are right or how an MUA should display results, because those are local policy and/or user interface design questions that don't belong here 💅
at the time of publication, these are the published, domain-level email authentication methods in common use:
- Author Domain Signing Practices ([ADSP])
- SMTP Service Extension for Authentication ([AUTH])
- DomainKeys Identified Mail Signatures ([DKIM])
- Sender Policy Framework ([SPF])
- Vouch By Reference ([VBR])
- reverse IP address name validation ("iprev", defined in Section 3)
on top of that, this spec recognizes these non-standard methods that aren't common anymore:
- DomainKeys ([DOMAINKEYS]) (Historic)
- Sender ID ([SENDERID]) (Experimental)
this spec isn't meant to be limited to domain-based authentication schemes 🌸 the existing schemes in that family have been a good starting point for implementations, though. the goal is to give current and future schemes one shared framework to deliver their results to downstream agents, and to discourage making a brand-new header field for every single scheme 🦋
SPF defined a header field called "Received-SPF", and the historic DomainKeys defined one called "DomainKey-Status". both were made for this exact purpose, but they only carry their own respective results, so they aren't enough for the requirements listed below. also, lots of 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 doc is expected to do a few things:
- Convey the results of various message authentication checks. Upstream filters and Mail Transfer Agents (MTAs) apply these checks, then pass them along to MUAs and downstream filters within the same "trust domain". those agents might want to show the results to end users, or use the data to apply stricter or looser content checks based on authentication results 🔥
- Provide a common location within a message for this data 📬
- Create an extensible framework for reporting new authentication methods as they come out 🌈
here's the big catch 🚨 the mere presence of this header field does not mean its contents are valid. it's just reporting assertions made by one or more authentication schemes that were (supposedly) applied somewhere upstream. for an MUA or downstream filter to actually treat those assertions as valid, there must be an assessment of the trust relationship among those agents, the validating MTA, and the mechanism used to convey the information. trust, but verify, bestie 🫶✨
1.2. Trust Boundary 🛡️
okay so this doc keeps bringing up the "trust boundary" of an administrative management domain (ADMD), and it's giving vague on purpose 💅 because mail setups are sooo different from each other that one precise definition just isn't possible.
the big idea: info passed from whoever made the header field over to whoever reads it has to happen in a setting where the reader can treat the producer's claims as reliable and accurate (trustworthy) ✨. how you get that trust is outside this doc. it's entirely a local matter, bestie 🫶
so this doc defines a "trust boundary" as the line between "external" and "internal" entities 🧱. internal services are the ones the ADMD's infrastructure provides for its users. external stuff is outside the ADMD's authority. hosts inside a trust boundary are under the ADMD's authority and policies, no matter where they physically sit or who physically runs them 🌸. for example, a host inside a trust boundary could be operated by a remote service provider and still be sitting in that provider's data center. wild, right? 🙈
a message can get checked inside a trust boundary and then leave and come back in 🔄. one example is a forwarded message, like a message/rfc822 attachment (see Multipurpose Internet Mail Extensions [MIME]) or something inside a multipart/digest. the details in this field can't be trusted in that situation 💀. so a field found inside one of those media types is typically ignored.
1.3. Processing Scope 🎀
this header field is basically saying "hey, auth work was already done inside my trust boundary, and here are the results" 📬. it is NOT meant to hand consumers message parameters so they can run auth protocols on their own. not its job, periodt 💖
1.4. Requirements 📋
this doc doesn't add any new requirements to existing protocols or servers 🌈
and to be super clear, it does NOT put any requirement on MTAs to reject or filter incoming messages that fail auth checks 🙅♀️. the data in this field is for MUAs and filters to look at, and they get to decide what to do with it at their own discretion 👑
1.5. Definitions 🧠
this section defines the terms used all through the doc, so grab a snack and let's go ☕
1.5.1. Key Words 🔑
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. these are the official vibes-check words for how strict each rule is 💜
1.5.2. Security 🔐
"Guidelines for Writing RFC Text on Security Considerations" ([SECURITY]) talks about authentication and authorization and how people keep mixing those two up 😭. message security work has made the definitions a little different lately, and this doc follows those current usages, like so:
- "Authorization" is the establishment of permission to use a resource or represent an identity. in this context, authorization means a message from a particular ADMD arrived via a route the ADMD has explicitly approved 🛣️.
- "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 and Sender ID are authorization mechanisms 🚪. they give a result showing whether the ADMD that seemingly sent the message has explicitly authorized the connecting Simple Mail Transfer Protocol ([SMTP]) client to relay messages on its behalf. but they don't actually validate any other property of the message itself 🤷♀️. DKIM is different 💅. it doesn't care about how a message was routed, but it uses cryptographic signatures to authenticate agents, assign (some) responsibility for the message (which implies authorization), and ensure the listed parts of the message weren't modified in transit 🔏. since the signatures aren't tied to SMTP connections, they can be added by the ADMD of origin, intermediate ADMDs (like a mailing list server), other handling agents, or any combo of those 🧩.
rather than make a separate header field for each class of solution, this proposal groups them all into one single header field 🎁
1.5.3. Email Architecture 🏗️
- A "border MTA" is an MTA that acts as a gateway between the general Internet and the users inside an organizational boundary 🚧. (See also Section 1.2.)
- A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that actually delivers a message to a user's inbox or other final destination 📥.
- An "intermediate MTA" is any MTA that is not a delivery MTA and is also not the first MTA to handle the message 🔁.
here's how mail flows between these components. for more on general email system architecture, including detailed descriptions of these parts, check Internet Mail Architecture [EMAIL-ARCH]. and see Appendix D of this document for the common aspects of email authentication in current environments 📚
+-----+ +-----+ +------------+
| MUA |-->| MSA |-->| Border MTA |
+-----+ +-----+ +------------+
|
|
V
+----------+
| Internet |
+----------+
|
|
V
+-----+ +-----+ +------------------+ +------------+
| MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA |
+-----+ +-----+ +------------------+ +------------+generally, the message auth schemes are assumed to be applied at a border MTA or a delivery MTA, and this spec is written with that in mind 🎯. but some sites run their whole mail infrastructure on a single host 🖥️. in those cases, "border MTA" and "delivery MTA" might totally refer to the same machine, or even the very same agent. it's also possible some message auth tests happen on an intermediate MTA ✨. this doc doesn't spell out those cases, but they aren't meant to be excluded either 🙌
1.5.4. Other Terms 🏷️
in this doc, a "producer" is any component that adds this header field to the messages it handles 🏭. a "consumer" is any component that identifies, extracts, and parses the header field to use in a handling decision 🍽️
1.6. Trust Environment 🌐
this header field lets one or more message validation mechanisms pass their output along to one or more separate assessment mechanisms 📨. all of these work inside a unified trust boundary that defines an Administrative Management Domain (ADMD) 🏰. an ADMD has one or more entities that validate and generate the header field, plus one or more that consume it for some kind of assessment 🎀
the field usually has no integrity or validation mechanism of its own, so its presence has to be trusted implicitly 😬. that's why valid use of the header field requires removing any copies of it that are already there when the message enters the ADMD 🧹. this makes sure later copies were added inside the ADMD's trust boundary, which is the whole point 💅
the authserv-id token defined in Section 2.2 can reference an entire ADMD or one specific validation engine inside an ADMD 🪪. the labeling scheme is an operational choice, but some guidance for picking a token shows up in later sections of this doc 🔖
2. Definition and Format of the Header Field 🎀
this section gives a general overview of the header field's format and then gets into the formal specs 🤓
2.1. General Description 📝
the header field here is called Authentication-Results 💖. it's a Structured Header Field as defined in Internet Message Format ([MAIL]), so all the related definitions in that doc apply too 🧚
this field gets added to the top of the message as it moves through MTAs that do auth checks, so you can kind of tell how far away the checks happened 🛰️. that makes it a trace field as defined in [MAIL], and again, all the related definitions in that doc apply 🦋
the value of the field (after comments are removed) has an authentication identifier, an optional version, and then a series of statements and supporting data 🧃. the statements look like "method=result" and show which auth method(s) got applied and what each one returned 📊. for each statement, the supporting data can include a "reason" string and one or more "property=value" statements that say which message properties were checked to reach that conclusion 🔍
the header field can show up more than once in a single message, one field can hold more than one result, or you can mix both of those things together 🌈
2.2. Formal Definition ✨
okay so, this is the grammar section and it's giving precise 💅. The header field is written out formally in Augmented Backus-Naur Form ([ABNF]), so here's the whole thing:
authres-header = "Authentication-Results:" [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 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
method = Keyword [ [CFWS] "/" [CFWS] method-version ]
; a method indicates which method's result is
; represented by "result", and 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 = "smtp" / "header" / "body" / "policy"
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, 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
property = special-smtp-verb / Keyword
; if "ptype" is "smtp", this indicates which [SMTP]
; command provided the value that was evaluated by the
; authentication scheme being applied; if "ptype" is
; "header", this indicates from which header field the
; value being evaluated was extracted; if "ptype" is
; "body", this indicates where in the message body
; a value being evaluated can be found (e.g., a specific
; offset into the message or a reference to a MIME part);
; if "ptype" is "policy", then this indicates the name
; of the policy that caused this header field to be
; added (see below)
special-smtp-verb = "mailfrom" / "rcptto"
; special cases of [SMTP] commands 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], and "CFWS" is defined in Section 3.2.2 of [MAIL]. 🎀
"Keyword" is defined in Section 4.1.2 of [SMTP]. 🦋
The "value" is as defined in Section 5.1 of [MIME]. 🌸
The "domain-name" is as defined in Section 3.5 of [DKIM]. 🌈
The "Keyword" used in "result" above is further constrained by the necessity of being enumerated in Section 2.6. 🫶
See Section 2.4 for a description of the authserv-id element. ✨
If the value portion of a "pvalue" construction identifies something intended to be an e-mail identity, then it MUST use the right hand portion of that ABNF definition. 💖 That one's a must, bestie, no notes. 😭
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 has a result to report. 🙈
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.3 for details. 👑
Examples of complete messages using this header field can be found in Appendix C. 🧚
2.3. The "policy" ptype 🦋
A special ptype value of "policy" is 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-Result field:
... dkim=fail policy.dkim-rules=unsigned-subject ...In this case, the property is "dkim-rules", indicating 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, 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.4. Authentication 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. 🤖
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 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; these 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:
- Changes to the identifier impose a large, centralized administrative burden. 😩
- 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 re-assessment of the header field's contents. 🕰️
Examples of valid authentication identifiers are "example.com", "mail.example.org", "ms1.newyork.example.com", and "example-auth". ✨
2.5. 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.6. 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.6.1. DKIM and DomainKeys ✨
okay so DKIM gets the dkim method name and it's defined over in [DKIM] 💅 DomainKeys is defined in [DOMAINKEYS] and goes by domainkeys. both are giving main character energy 🦋
a signature counts as "acceptable to the ADMD" if it gets through the local policy checks, or if there aren't any specific local checks to get through 🫶 for example, an ADMD policy could insist that the signatures on a message were added using the DNS domain in the From header field. that makes third-party signatures unacceptable, even when they verify 🙈
DKIM and DomainKeys share the same result set, and it goes like this:
none: the message wasn't signed 💤pass: the message was signed, the signature or signatures were acceptable to the ADMD, and they passed verification ✅fail: the message was signed and the signatures were acceptable to the ADMD, but they failed the verification test(s) 💔policy: the message was signed, but some part of the signature or signatures wasn't acceptable to the ADMD 🚫neutral: the message was signed, but the signature or signatures had syntax errors or just couldn't be processed. this one also covers other failures that aren't listed anywhere else in this list 🌀temperror: the message couldn't be verified because of an error that's probably temporary, like not being able to fetch a public key right now. a later attempt might give a final result ⏳permerror: the message couldn't be verified because of an error that won't fix itself, like a required header field being missing. a later attempt probably won't give a final result either 💀
[DKIM] says that if a message fails verification, it should be treated as an unsigned message. a fail report lets the receiver of the report decide what to do about the failure 🤷♀️ but a neutral or none report takes that choice away, so the message gets treated as if it was never signed 🔒
2.6.2. SPF and Sender ID
spf and sender-id are the method names for SPF and Sender ID, respectively 🌸 the result values for SPF are defined in Section 2.5 of [SPF], and we're just pulling those definitions in by reference, bestie 📚
+-----------+----------------------------+
| Code | Meaning |
+-----------+----------------------------+
| none | [SPF], Section 2.5.1 |
+-----------+----------------------------+
| pass | [SPF], Section 2.5.3 |
+-----------+----------------------------+
| fail | [SPF], Section 2.5.4 |
+-----------+----------------------------+
| softfail | [SPF], Section 2.5.5 |
+-----------+----------------------------+
| policy | [RFC7001], Section 2.6.2 |
+-----------+----------------------------+
| neutral | [SPF], Section 2.5.2 |
+-----------+----------------------------+
| temperror | [SPF], Section 2.5.6 |
+-----------+----------------------------+
| permerror | [SPF], Section 2.5.7 |
+-----------+----------------------------+these result codes are used here to show what the component doing the SPF evaluation returned 🎀
Sender ID's results are listed and described in Section 4.2 of [SENDERID], and that section leans on the SPF definitions too 🔁
heads up: both of those docs use mixed case for their result codes, but in this context they're usually written all lowercase ✨
both methods also get an extra result, policy 👑 it means the client was allowed to inject or relay mail for the sender's DNS domain according to the authentication method's algorithm, but local policy says the result isn't acceptable. for example, policy might show up when SPF returns pass, but a local policy check finds the sending DNS domain on an explicit list of unacceptable DNS domains (like spammers) 🚫
if the sender policies that were retrieved to evaluate SPF and Sender ID don't have any explicit provisions for authenticating the local-part (see Section 3.4.1 of [MAIL]) of an address, then the pvalue reported with these results SHOULD NOT include the local-part. 🙈
2.6.3. "iprev"
the result values for the iprev method, defined in Section 3, go like this:
pass: the DNS evaluation worked out, meaning the "reverse" and "forward" lookup results both came back and agreed with each other ✅fail: the DNS evaluation failed 💔 this happens when the "reverse" and "forward" lookups each returned results but didn't agree, or when the "forward" query finished without producing a result. that includes a DNS RCODE of 3 (commonly known as NXDOMAIN), or an RCODE of 0 (NOERROR) in a reply that has no answers 🫠temperror: the DNS evaluation couldn't be finished because of an error that's probably temporary, like a temporary DNS error (for example, a DNS RCODE of 2, commonly known as SERVFAIL), or some other error condition. a later attempt might give a final result ⏳permerror: the DNS evaluation couldn't be finished because no PTR data is published for the connecting IP address. this happens with a DNS RCODE of 3 (commonly known as NXDOMAIN), or an RCODE of 0 (NOERROR) in a reply with no answers, and it stopped the evaluation from finishing. a later attempt probably won't give a final result 💀
there's no none for this method 🙅♀️ every TCP connection that delivers email has an IP address attached, so some kind of evaluation is always possible ✨
if you want to learn about the format of DNS replies, check out "Domain Names - Implementation and Specification" ([DNS]) 📖
2.6.4. SMTP AUTH
SMTP AUTH (defined in [AUTH]) goes by the auth method, and its result values are:
none: SMTP authentication wasn't attempted 😶pass: the SMTP client authenticated to the server reporting the result, using the protocol described in [AUTH] 🔐fail: the SMTP client tried to authenticate to the server using the protocol described in [AUTH] but didn't succeed. it still kept going and sent the message that the result is being reported on 😬temperror: the SMTP client tried to authenticate using the protocol described in [AUTH] but couldn't finish, because of an error that's probably temporary, like a temporary directory service lookup error. a later attempt may give a final result ⏳permerror: the SMTP client tried to authenticate using the protocol described in [AUTH] but couldn't finish, because of an error that's probably not temporary, like a permanent directory service lookup error. a later attempt probably won't give a final result 💀
an agent using the data from this header field SHOULD consider fail and temperror to mean the same thing for message authentication, since the client didn't authenticate in either case 🫶
2.6.5. Other Registered Codes
more result codes were registered in other RFCs too 🌈 there's Vouch By Reference (in [AR-VBR], represented by vbr), Authorized Third-Party Signatures (in [ATPS], represented by dkim-atps), and the DKIM-related Author Domain Signing Practices (in [ADSP], represented by dkim-adsp) 🎀
2.6.6. Extension Methods
more authentication method identifiers (extension methods) might get defined later, by future revisions or extensions to this spec 🔮 these identifiers get registered with the Internet Assigned Numbers Authority (IANA) and, ideally, published in an RFC. see Section 6 for the details 📚
extension methods can be defined for these reasons:
- to let new authentication systems pass extra info along to MUAs or downstream filters 📬 the names should reflect the method being defined, but they ought not be needlessly long 💅
- to make "sub-identifiers" that show different levels of authentication and tell apart how strong they are, like "auth1-weak" and "auth1-strong" 💪
authentication method implementers are encouraged to give enough info, using message header field comments if needed, so an MUA developer can understand or pass along the extra details of the authentication results 🫶 for example, if it'd be interesting to relay what data got used for an evaluation, that could go in a comment in the header field, like this:
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 identifiers and their parameters aren't documented in RFCs, so they can change at any time and they're not suitable for production use 💀 any MTA, MUA, or downstream filter meant for production use SHOULD ignore or delete any Authentication-Results header field that includes an experimental (unknown) method identifier 🗑️
2.6.7. Extension Result Codes
extra result codes might get defined later too, by future revisions or extensions to this spec ✨ result codes MUST be registered with the Internet Assigned Numbers Authority (IANA) and preferably published in an RFC. see Section 6 for further details 📚
extension results MUST only be used within ADMDs that have explicitly consented to use them 🚨 these results and their parameters aren't formally documented, so they can change at any time and they're not suitable for production use 💀 any MTA, MUA, or downstream filter meant for production use SHOULD ignore or delete any Authentication-Results header field that includes an extension result 🗑️
3. The "iprev" Authentication Method ✨
okay so this section is about a method called "iprev" 🦋 It's basically checking whether a client's IP address actually matches a domain name that points back to it. Think of it like a double-check, bestie 💅
Here's how it goes. When a client starts some kind of session with you, you take its IP address and ask DNS what names it maps to. That's the reverse lookup, aka a PTR record query 🔍 Then you look up every name you got back, using an A or AAAA record query, which goes name to number. If at least one of those comes back to the client's IP address, the vibe checks out 🌸
Here's the algorithm, spelled out. Say the client peer's IP address is I. The list of names I maps to after a PTR query is the set N. The union of IP addresses that each member of N maps to, after the matching A and AAAA queries, is L. The test succeeds if I is an element of L ✨
The response to a PTR query could contain multiple names, though. So to keep DNS from getting overloaded 😭, agents doing these queries MUST be implemented so the number of names they turn into A or AAAA queries is limited. The limit shouldn't be unduly taxing on the DNS infrastructure, though it MAY be configurable by an administrator 🎀 As an example, Section 5.5 of [SPF] picked a limit of 10 for its version of this algorithm.
"DNS Extensions to Support IP Version 6" ([DNS-IP6]) covers the query formats for the IPv6 case 🧚
Now for the tea ☕ There's some contention about how wise and reliable this test really is. In some regions it can be super hard for it to ever pass, because matching forward and reverse DNS is rarely done. So the exact details of how a verifier runs an "iprev" test are not specified here 💀 The verifier MAY report a successful or failed "iprev" test at its own discretion, as long as it did some kind of check on the connection's identity using DNS. It's on any agent using the reported "iprev" result to figure out what that particular verifier is actually trying to say 👑
If you want the full drama on reverse DNS mapping and what it means, check out "Considerations for the use of DNS Reverse Mapping" ([DNSOP-REVERSE]). It specifically recommends that applications avoid using this test as a means of authentication or security 🙈 Its presence in this document isn't an endorsement. It's just an acknowledgement that the method is still common and gives a way to relay the results of that test 🫶
4. Adding the Header Field to a Message ✨
So this spec doesn't even try to rank the strengths of the different message authentication methods that might show up later 🌈 The methods listed are an order-independent set, so their order doesn't tell you anything about which one matters more. Instead, the MUA or downstream filter reading this header field has to interpret each method's result using its own knowledge of what that method checks 💜
Each "method" MUST refer to an authentication method declared in the IANA registry, or an extension method as described in Section 2.6.6. Each "result" MUST refer to a result code declared in the IANA registry, or an extension result code as defined in Section 2.6.7. See Section 6 for more info on the registered methods and result codes 📚
An MTA that follows this spec adds this header field after running one or more message authentication tests 🔥 It shows which MTA or ADMD ran the test, which test got applied, and what the result was. If an MTA runs more than one test, it can add this header field once per test, or once with all the results together. An MTA MUST NOT add a result to an existing header field 🙅♀️
An MTA MAY add this header field with only the authentication identifier portion and the "none" token (see Section 2.2). That tells everyone, explicitly, that no message authentication schemes were applied before the message was delivered 🦋
An MTA adding this header field has to take steps to prove to the MUAs or downstream filters that will eventually read it that it's legit 🔐 One way to do that is described in Section 5. Some environments might need extra measures, and some possible solutions are listed in Section 7.1. This document doesn't force any specific solution, since every environment has its own tools and limits 🎀
Most known message authentication methods focus on one particular identifier. SPF and Sender ID are different, though, because they can give a result based on more than one identifier. Specifically, SPF can evaluate the RFC5321.HELO parameter or the RFC5321.MailFrom parameter, and Sender ID can evaluate the RFC5321.MailFrom parameter or the Purported Responsible Address (PRA) identity. When you generate this field to report those results, only the parameter that actually produced the result gets included 💅
For MTAs that add this header field, adding header fields in order (at the top), per Section 3.6 of [MAIL], is super important ✨ On top of that, this header field SHOULD be inserted above any other trace header fields those MTAs might prepend. That placement makes it easy to spot which header fields can be trusted 🧚
Now the warning part 🚨 End users who use this header field directly might accidentally trust information that hasn't been properly vetted. For example, if a basic SPF result gets relayed that claims an authenticated addr-spec, the local-part of that addr-spec has actually not been authenticated 😭 So an MTA adding this header field SHOULD NOT include any data that hasn't been authenticated by the method(s) being applied. Also, MUAs SHOULD NOT render that kind of info to users if it's presented by a method that's known not to authenticate it 🙈
4.1. Header Field Position and Interpretation
Okay this part is about keeping results unambiguous and not getting fooled by fake header fields 🕵️♀️ MUAs and downstream filters SHOULD NOT interpret this header field unless the user or administrator specifically configures them to. It should NOT be "on by default" 🎀 Users or administrators ought not turn that feature on unless they're certain the header field will be validly added by an agent inside the ADMD that accepts the mail which the MUA eventually reads. Any header fields that look like they came from inside the ADMD but were 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 it carries appears to be one used within their own ADMD, as configured by the user or administrator 🦋
MUAs and downstream filters MUST ignore any result reported using a "result" that isn't specified in the IANA "Result Code" registry, or a "ptype" that isn't listed in the corresponding registry for those values, as defined in Section 6. On top of that, those agents MUST ignore a result indicated for any "method" they don't specifically support 🚫
An MUA SHOULD NOT reveal these results to end users, unless careful human factors design and testing has gone into presenting trust-related stuff 💅 Why? Because an attacker could register examp1e.com (note the digit "one") and send signed mail to intended victims. A verifier would detect that the signature was valid and report a "pass", even though it's super clear the DNS domain name was meant to mislead 😭 See Section 7.2 for more on that.
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]. That means it MUST NOT be reordered and MUST be prepended to the message, so there's usually some sign at delivery of where in the chain of MTAs the message authentication happened 🧚
Note that a few message handlers can only append new header fields to a message. Strictly speaking, those handlers aren't compliant with this spec. They can still add the header field to carry authentication details, but any signal about where in the handling chain the work was done might get lost 💀 Consumers SHOULD be designed so they can tolerate this, especially from a producer known to have this limitation 🫶
MUAs SHOULD ignore instances of this header field found inside message/rfc822 MIME attachments 🙈
For more on all of this, check out Section 7 below 💜
4.2. Local Policy Enforcement
Some sites have a local policy that treats any authentication policy's non-recoverable failure results (typically "fail" or something similar) as a reason to reject the message 🔥 In those cases, the border MTA SHOULD issue an SMTP rejection response for the message, instead of adding this header field and letting the message keep going toward delivery. That's way more desirable than letting the message reach an internal host's MTA or spam filter, which could end up generating a local rejection like a Delivery Status Notification (DSN) [DSN] to a forged originator 😭 Those generated rejections are colloquially known as "backscatter" 🌈
The same MAY also be done for local policy decisions that override the results of the authentication methods, like the "policy" result codes described in Section 2.6 ✨
Rejections at the SMTP protocol level aren't possible if local policy is enforced at the MUA and not the MTA 💅
5. Removing Existing Header Fields ✨
okay bestie, this part is lowkey the most important bit 🔒 for security reasons, any MTA conforming to this specification MUST delete any header field it finds that claims, through its authentication service identifier, to have been added inside its trust boundary, but that did not come directly from another trusted MTA. 💀 For example, an MTA for example.com that receives a message MUST delete or otherwise obscure any instance of this header field whose authentication service identifier says it was added inside example.com before the MTA adds its own header fields. 🧚 This could mean every MTA has to carry a list of internal MTAs that are known to be compliant (and so trustworthy).
For simplicity and maximum security, a border MTA could nuke every instance of this header field on mail crossing into its trust boundary 💅 but ngl, that might clash with wanting to read authentication results from trusted outside service providers 🥲 It could also break signed messages whose signatures cover external copies of the header field. A more robust border MTA could allow a specific list of authenticating MTAs whose information is admitted, and remove the header field from everyone else 🦋
As stated in Section 1.2, a formal definition of "trust boundary" is deliberately not made here 🤷♀️ It's totally possible that a border MTA for example.com explicitly trusts authentication results asserted by upstream host example.net, even though they sit in completely separate administrative boundaries 👑 In that case, the border MTA MAY elect not to delete those results. Also, the upstream host doing the 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 C ✨
Similarly, for messages signed using [DKIM] or other message-signing methods that sign header fields, this removal could invalidate one or more signatures if they covered the header field being removed 😭 This can actually 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 🫶
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 relaying the message is not from a trusted internal MTA. 🚫 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 🌸
okay so IANA has registered the defined header field and created two tables 📋 These registry actions were originally defined by [RFC5451] and are repeated here so there's one single, current reference 💜
6.1. The Authentication-Results Header Field 🎀
[RFC5451] added the Authentication-Results header field to the IANA "Permanent Message Header Field Names" registry, following the procedure found in [IANA-HEADERS]. That entry has been updated to reference this document ✨ Here's the registration template:
Header field name: Authentication-Results
Applicable protocol: mail ([MAIL])
Status: Standard
Author/Change controller: IETF
Specification document(s): RFC 7001
Related information:
Requesting review of any proposed changes and additions to
this field is recommended.6.2. "Email Authentication Methods" Registry 📚
names of message authentication methods supported by this specification are to be registered with IANA, with the exception of experimental names as described in Section 2.6.6 🧪 A registry was created by [RFC5451] for this purpose, and this document changes the rules governing it 💅
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 can't 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" 🙌
Each method must register a name, the specification that defines it, a version number associated with the method being registered (preferably starting at "1"), zero or more "ptype" values appropriate for use with that method, which "property" value(s) should be reported by that method, and a description of the "value" to be used with each 📝
All existing registry entries that reference [RFC5451] have been updated to reference this document, except where entries have already been deprecated.
IANA has also added a "version" field to all existing registry entries. All current methods are recorded as version "1" 🔢
6.3. "Email Authentication Result Names" Registry 🏷️
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.6.7 🧪 A registry was created by [RFC5451] for this purpose, and this document changes the rules governing that registry too.
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 can't 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" 🙌
All existing registry entries that reference [RFC5451] have been updated to reference this document.
The definitions for the SPF and Sender ID authentication methods are updated using the references found in Section 2.6.2 🔄
7. Security Considerations 🔐
okay, this part is serious, so read carefully 👀 The following security considerations apply when adding or processing the Authentication-Results header field:
7.1. Forged Header Fields 👻
An MUA or filter that accesses a mailbox whose messages are handled by a non-conformant MTA, and that understands Authentication-Results header fields, could potentially make 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 theAuthentication-Resultsheader 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 whoseAuthentication-Resultsheader 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 they are documented here in case the information is useful at some point in the future 🗂️
- Possibly the simplest is a digital signature protecting the header field, such as using [DKIM], that can be verified by an MUA 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
Fromheader 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 theauthserv-idis the ADMD's domain name, theauthserv-idmatching this valid internal signature'sd=DKIM value is sufficient. 🔏 - 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. 😬
- Yet another might be a method to interrogate the internal MTAs that apparently handled the message (based on
Receivedheader fields) to determine whether any of them conform to Section 5 of this memo. This, too, has potentially high barriers to entry. 🚧 - Extensions to [IMAP], [SMTP], and [POP3] could be defined to allow an MUA or filtering agent to acquire the
authserv-idin use within an ADMD, thus allowing it to identify whichAuthentication-Resultsheader fields it can trust. 📬 - 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-idtoken, the header field proposed here should always appear above aReceivedheader 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 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 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 💅
Okay bestie, real talk: until some kind of reputation lookup for sending agents is widely deployed, seeing a "pass" in this header does NOT make the message trustworthy 🙅♀️. A piece of spam can totally pass several of the methods listed above, like spam signed with [DKIM] by the spammer themselves or by a compromised system 💀. Removing forged header fields, as discussed above, doesn't fix this part either 😭.
So MUAs and downstream filters need to stay careful with this header even after any sketchy headers have been scrubbed 🫶.
7.3. Header Field Position 🦋
Despite what [MAIL] says, intermediate MTAs can sometimes reorder header fields on the way through, which is lowkey annoying 🙄. The rule that this header field only gets added at the top of a message is basically an acknowledgement that some MTAs reorder things, but most don't ✨. So in the general case, there will be some indication of which MTAs (if any) handled the message after this header field was added 🔍.
7.4. Reverse IP Query Denial-of-Service Attacks 🌪️
Section 5.5 of [SPF] describes a DNS-based denial-of-service attack aimed at verifiers that do DNS-based identity checks on arriving client connections 😬. A verifier that wants to do this check and report it needs to be careful not to go to unbounded lengths resolving "A" and "PTR" queries 🙅. MUAs or other filters using an "iprev" result from this document need to know which algorithm the reporting verifier used and, especially, its limitations 🧐.
7.5. Mitigation of Backscatter 🌙
If you don't follow the instructions in Section 4.2, you can end up with a denial-of-service attack caused by generating [DSN] messages (or equivalent) sent to addresses that never sent 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 has to include, at each MTA, a list of other MTAs known to be compliant and trustworthy 🤝. If you don't keep that list current as your internal infrastructure changes, an ADMD may be exposed to attack 🚨.
7.7. Attacks against Authentication Methods ⚔️
If an attack becomes known against an authentication method, then the agent verifying that method can be fooled into thinking an inauthentic message is authentic 😵. That means the value of this header field can be misleading 🙃. So any attack against the authentication methods supported by this document is also a security consideration here 🔐.
7.8. Intentionally Malformed Header Fields 🧨
An attacker can add an Authentication-Results header field that is extraordinarily large or otherwise malformed, trying 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 😈. Honestly, it's clearly a bigger concern to have compromised internal machines than it is to prove the value of this header field 🥲. This risk can be mitigated by arranging for internal MTAs to remove this header field if it claims to have been added by a trusted border MTA (as described above), yet the [SMTP] connection isn't coming from an internal machine known to be running an authorized MTA ✅. The catch is that, 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 🙈. The processing of these is outside the intended scope of this document (see Section 1.3), but some early guidance for MUA developers is still appropriate here 💜.
Since MTAs are unlikely to strip Authentication-Results header fields after mailbox delivery, MUAs are advised in Section 4.1 to ignore such instances within MIME attachments 🙅. Also, when you extract a message digest to separate mail store messages or other media, those header fields should be removed so they will never be interpreted improperly by MUAs that might later consume them 🧹.
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 this proposal, 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. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
- [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
- [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
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, August 2009.
- [AR-VBR] Kucherawy, M., "Authentication-Results Registration for Vouch by Reference Results", RFC 6212, April 2011.
- [ATPS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures", RFC 6541, February 2012.
- [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
- [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011.
- [DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
- [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
- [DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for the use of DNS Reverse Mapping", Work in Progress, March 2008.
- [DOMAINKEYS] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
- [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
- [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
- [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
- [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
- [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
- [SECURITY] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
- [SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
- [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
- [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, April 2009.
Appendix A. Acknowledgements 🎀
The author wants to shout out the following individuals for their review and constructive criticism of this document 🫶: Dave Cridland, Dave Crocker, Bjoern Hoehrmann, Scott Kitterman, John Levine, Alexey Melnikov, S. Moonesamy, and Alessandro Vesely 👑.
Appendix B. Legacy MUAs 🕰️
Implementers of this protocol should be aware that many MUAs are unlikely to be retrofitted to support the new header field and its semantics 😭. For convenience and quicker adoption, a delivery MTA might want to consider adding things that existing MUAs already process, in addition to the Authentication-Results header field 🧠. One suggestion is to include a Priority header field, on messages that don't already have one, containing a value that reflects the strength of the authentication that was accomplished. For example, "low" for weak or no authentication, and "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 visible to end users 🌈. Until that capability is added, other interim means of conveying authentication results may be necessary while this proposal and its successors are adopted ✨.
Appendix C. Authentication-Results Examples 🍓
This section shows some examples of using this header field to indicate authentication results 🧚.
C.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: Trivial CaseThe 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 the message authentication services weren't available at the time of delivery, or no service is provided, or the MTA isn't in compliance with this specification 🙈.
C.2. Nearly Trivial Case; Service Provided, but No Authentication Done 💅
Okay so this one is a message delivered by an MTA that follows this spec but doesn't actually do any message authentication. Lowkey the most chill example ever 🌸
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 there, which shows the delivering MTA follows this spec 💖 It used its DNS domain name as the authserv-id. The none token (and the fact that there are no method and result tokens after it) means no message authentication happened at all 🙈 The spec version the field's content follows is spelled out right there too, so nobody has to guess ✨
C.3. Service Provided, Authentication Done 🦋
This message was delivered by an MTA that follows this spec and actually applied some message authentication. Main character energy 👑
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, which says the border MTA follows this spec 🫶 The authserv-id is the DNS domain name again. The message got checked by that MTA using the method from [SPF], and ngl, that method can't authenticate the local-part, so it's left out of the result's value 💀 An MUA could pull that extra info out and pass it along if it wants to 💜
C.4. Service Provided, Several Authentications Done, Single MTA 🍓
Okay this one is so iconic 😭 A message came in through one MTA that follows this spec, and that MTA ran three different message authentication checks at once.
Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.net;
spf=pass smtp.mailfrom=example.net
Authentication-Results: example.com;
sender-id=pass header.from=example.net
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 ESMTP 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, which says the delivering MTA follows this spec 🔥 The receiving DNS domain name is the authserv-id, once again. The sender proved who they are to the MTA using a method from [AUTH], and both the SPF and Sender ID checks ran and passed ✅ An MUA can grab that extra info and relay it if it wants 🦋
Two Authentication-Results header fields aren't required here, since the same host did all of the checking. The authenticating agent could've mashed all the results into one header field instead 🧠
This is a scenario where a remote user on a dialup connection (example.net) sends mail to a border MTA (example.com) and uses SMTP authentication to prove who they are 🔐 The dialup provider has been explicitly authorized to relay mail as example.com, so the SPF and Sender ID checks both pass. Iykyk 😌
C.5. Service Provided, Several Authentications Done, Different MTAs 💜
Okay this is the most real one of all 😭 A message got relayed inbound by two different MTAs that both follow this spec, and they ran multiple message authentication checks between them.
Authentication-Results: example.com;
sender-id=fail header.from=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 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.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, showing it follows this spec ✨ The authserv-id is the recipient's DNS domain name, once again. The header field shows up twice because two different MTAs in the delivery chain did authentication tests 👯 The first one, mail-router.example.com, says SMTP AUTH and SPF were both used. SMTP AUTH passed and SPF failed. For SMTP AUTH, there's extra info in the comment field, which the MUA can show if it wants 💅
The second MTA, auth-checker.example.com, says it ran a Sender ID test (which failed) and a DKIM test (which passed) 🔑 Again, there's extra data about one of the tests in a comment, and the MUA may choose to render it. Also, highkey important: example.com added a DKIM signature that vouches for the integrity of the lower Authentication-Results field 🛡️
Since different hosts ran the two sets of checks, the header fields can't be combined in this example 🙅♀️
This one is a more typical case of mail coming into example.com from a user on a dialup connection at example.net 📬 The user seems legit, since they had a valid password and authenticated at the border MTA with SMTP AUTH. The SPF and Sender ID tests failed because example.com hasn't given example.net permission to relay mail for it. But the DKIM test passed, because the sending user had a private key that matched one of example.com's published public keys and used it to sign the message. Bestie, that's how you do it 🫶💖
C.6. Service Provided, Multi-Tiered Authentication Done 🦋
okay so this one is giving layers 🧅 A message got authenticated at a bunch of different stages, and one of those stages happened outside the receiving ADMD (the organization's own mail domain) 👀
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 sampleExample 6: Headers Reporting Results from Multiple MTAs in Different ADMDs 🎀
In this example, we get to see multi-tiered authentication with an extended trust boundary, and it's honestly so cool ✨
The message was sent by someone at example.com's New York office (newyork.example.com) to a mailing list managed at an intermediary. It was signed at the origin using DKIM 🔏
The message then went to a mailing list service provider called example.net, which example.com uses. Over there, meetings@example.net gets expanded into a long list of recipients, and one of them is at the Chicago office. For this example, we'll assume the trust boundary for chicago.example.com includes the mailing list server at example.net 🧚
The mailing list server there authenticated the message first and added an Authentication-Results header field saying so. It used its DNS domain name for the authserv-id. Then it altered the message by adding some footer text to the body, including administrivia like unsubscription instructions 📝 Finally, the mailing list server adds a second DKIM signature and starts distributing 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 evaluates both signatures and finds that the first (most recent) one is a "pass". The second one is a "fail", but that's because of the modifications we just talked about 🙈 Here's the plot twist though: the first signature covered the Authentication-Results header that mail-router.example.net added, and that header validated the second signature. So, indirectly, you can tell that the authentications claimed by both signatures are actually valid. Iconic 💅
Two styles of presenting metadata about the result are in use here, and I'm obsessed with the contrast. In one case there's a "reason=" clause, which is meant for easy extraction by parsers. In the other case, the CFWS production of the ABNF is used to include that data as a header field comment. The latter can be harder for parsers to pull out, since mail header fields support a bunch of different syntaxes 🤓
C.7. Comment-Heavy Example 💬
The formal syntax lets comments show up inside the content in a bunch of places. Just to show it off, 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) 1362471462Example 7: A Very Comment-Heavy but Perfectly Legal Example 🌈
Appendix D. Operational Considerations about Message Authentication 🧠
Okay, bestie, this part is about the why 🫶 The whole protocol is built on the idea that authentication (and presumably, in the future, reputation) work is usually done by border MTAs, not MUAs or intermediate MTAs. The latter just use the results the border MTAs figured out. Is this mandatory for taking part in electronic mail or message authentication? Nope, not at all. But this protocol and how it's been deployed so far are based on that model. The assumption covers several common ADMD requirements:
- Service operators want to handle problem messages as close to the border of the ADMD as they can. That lets them do things like rejecting messages at the SMTP level instead of generating a DSN internally. So if you do any of the authentication or reputation work only at the MUA or intermediate MTA, that goal just isn't reachable 🚪
- Border MTAs are more likely to have direct access to external sources of authentication or reputation information, since modern MUAs tend to be heavily firewalled 🧱 So some MUAs might not even be able to finish authentication or reputation evaluations without complicated proxy configurations or similar hassle.
- MUAs rely on the upstream MTAs inside their trust boundaries to make correct (as much as is possible) evaluations about the message's envelope, header, and content. So MUAs don't need to know how to do the work the upstream MTAs do. They only need the results 💁♀️
- Evaluations about the quality of a message are a little bit expensive, anywhere from simple token matching (like a list of preferred DNS domains) to cryptanalysis (like public/private key work). So they need to be minimized 💸 Doing those tests at the border MTA is way better than doing them at every MUA that handles a message. If an ADMD's environment sticks to common messaging protocols, a reputation query or authentication check done by a border MTA would return the same result as the same query done by an MUA. But if the MUA does the work, a message arriving for multiple recipients would cause authentication or reputation evaluation to happen more than once for the same message (once at each MUA). That's needless amplification of resource use, and it creates a possible denial-of-service attack vector 😬
- Minimizing change is good 🌸 As new authentication and reputation methods show up, the list of methods supported by this header field would presumably get extended. If MUAs just consume the contents of this header field instead of trying to do authentication and/or reputation work themselves, then MUAs only have to learn to parse this header field once. A new method then only needs a configuration change at the MUAs and software changes at the MTAs, which are presumably fewer in number. When you're deciding whether to put these functions in MTAs or MUAs, you have to consider individual flexibility, infrastructure inertia, and scale of effort. It's 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.
- For decisions that affect message delivery and display, assessment based on authentication and reputation works best close to the time of message transit, as a message makes its journey toward a user's inbox, not afterwards ⏳ DKIM keys and IP address reputations, etc., can change over time or even become invalid, and users can take a long time to read a message once it's delivered. So the value of this work degrades, maybe quickly, once delivery has completed. This seriously diminishes the value of the work when it's done anywhere other than at MTAs 📉
Many operational choices are possible within an ADMD, including where authentication and/or reputation assessment happens. The current specification doesn't dictate any of those choices. What it does do is support the cases where information produced by one stage of analysis needs to be carried along with the message to the next stage 📦
Appendix E. Changes since RFC 5451 📜
- Erratum #2617 was addressed in RFC 6577 and was incorporated here.
- Requested Internet Standard status.
- Changed IANA rules from "IETF Review" to "designated expert".
- Updated existing IANA registries from the old RFC to this one.
- Added references to ADSP, ATPS, and VBR.
- Removed all the "X-" stuff, per BCP 178.
- Adjusted language to indicate that this header field was already defined and that we're just refreshing and revising.
- In a few places, RFC 2119 language had been used in lowercase terms; fixed here.
- Erratum #2818 addressed.
- Erratum #3195 addressed.
- Performed some minor wordsmithing and removed odd prose.
- ABNF: changed "dot-atom" to "Keyword" since "dot-atom" allows "=", which leads to ambiguous productions.
- ABNF: the authserv-id can be a "value", not a "dot-atom".
- ABNF: separated the spec version from the method version; they're syntactically the same but semantically different. Added a section discussing them.
- Called out the SMTP verb exceptions ("mailfrom" and "rcptto"); the previous RFC didn't do this, leading to interoperability problems.
- Rather than deleting suspect header fields, they could also be renamed to something harmless; there is at least one implementation of this.
- Updated IANA "Email Authentication Methods" registry to include version numbers.
- Rather than repeating what RFC 4408 says the SPF results are, just referred to those documents.
- To avoid confusing consumers, constrained inclusion of unnecessary properties.
- Reviewed usage of
"should" vs. "SHOULD". - Updated prose around authserv-id (Section 2.4).
Author's Address 💌
Murray S. Kucherawy
270 Upland Drive
San Francisco, CA 94127
US
EMail: superuser@gmail.comThat's the whole spec, bestie 🎀✨ Go forth and authenticate responsibly 💅💖
📦 where this page comes from
- ietf: rfc7001 2013-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms