RFC 8601
Message Header Field for Indicating Message Authentication Status
3. The "iprev" Authentication Method
This section defines an additional authentication method called "iprev". "iprev" is an attempt to verify that a client appears to be valid based on some DNS queries, which is to say that the IP address is explicitly associated with a domain name. Upon receiving a session initiation of some kind from a client, the IP address of the client peer is queried for matching names (i.e., a number-to-name translation, also known as a "reverse lookup" or a "PTR" record query). Once that result is acquired, a lookup of each of the names (i.e., a name-to-number translation, or an "A" or "AAAA" record
query) thus retrieved is done. The response to this second check will typically result in at least one mapping back to the client's IP address. Expressed as an algorithm: If the client peer's IP address is I, the list of names to which I maps (after a "PTR" query) is the set N, and the union of IP addresses to which each member of N maps (after corresponding "A" and "AAAA" queries) is L, then this test is successful if I is an element of L. Often an MTA receiving a connection that fails this test will simply reject the connection using the enhanced status code defined in [AUTH-ESC]. If an operator instead wishes to make this information available to downstream agents as a factor in handling decisions, it records a result in accordance with Section 2.7.3. The response to a "PTR" query could contain multiple names. To prevent heavy DNS loads, agents performing these queries MUST be implemented such that the number of names evaluated by generation of corresponding "A" or "AAAA" queries is limited so as not to be unduly taxing to the DNS infrastructure, though it MAY be configurable by an administrator. As an example, Section 4.6.4 of [SPF] chose a limit of 10 for its implementation of this algorithm. "DNS Extensions to Support IP Version 6" [DNS-IP6] discusses the query formats for the IPv6 case. There is some contention regarding the wisdom and reliability of this test. For example, in some regions, it can be difficult for this test ever to pass because the practice of arranging to match the forward and reverse DNS is infrequently observed. Therefore, the precise implementation details of how a verifier performs an "iprev" test are not specified here. The verifier MAY report a successful or failed "iprev" test at its discretion having done some kind of check of the validity of the connection's identity using DNS. It is incumbent upon an agent making use of the reported "iprev" result to understand what exactly that particular verifier is attempting to report. Extensive discussion of reverse DNS mapping and its implications can be found in "Considerations for the use of DNS Reverse Mapping" [DNSOP-REVERSE]. In particular, it recommends that applications avoid using this test as a means of authentication or security. Its presence in this document is not an endorsement but is merely acknowledgment that the method remains common and provides the means to relay the results of that test.
4. Adding the Header Field to a Message
This specification makes no attempt to evaluate the relative strengths of various message authentication methods that may become available. The methods listed are an order-independent set; their sequence does not indicate relative strength or importance of one method over another. Instead, the MUA or downstream filter consuming this header field is to interpret the result of each method based on its own knowledge of what that method evaluates. Each "method" MUST refer to an authentication method declared in the IANA registry or an extension method as described in Section 2.7.6, and each "result" MUST refer to a result code declared in the IANA registry or an extension result code as defined in Section 2.7.7. See Section 6 for further information about the registered methods and result codes. An MTA compliant with this specification adds this header field (after performing one or more message authentication tests) to indicate which MTA or ADMD performed the test, which test was applied, and what the result was. If an MTA applies more than one such test, it adds this header field either once per test or once indicating all of the results. An MTA MUST NOT add a result to an existing header field. An MTA MAY add this header field containing only the authentication service identifier portion and the "none" token (see Section 2.2) to indicate explicitly that no message authentication schemes were applied prior to delivery of this message. An MTA adding this header field has to take steps to identify it as legitimate to the MUAs or downstream filters that will ultimately consume its content. One process to do so is described in Section 5. Further measures may be necessary in some environments. Some possible solutions are enumerated in Section 7.1. This document does not mandate any specific solution to this issue, as each environment has its own facilities and limitations. Most known message authentication methods focus on a particular identifier to evaluate. SPF differs in that it can yield a result based on more than one identifier; specifically, SPF can evaluate the RFC5321.HELO parameter or the RFC5321.MailFrom parameter. When generating this field to report those results, only the parameter that yielded the result is included.
For MTAs that add this header field, adding header fields in order (at the top), per Section 3.6 of [MAIL], is particularly important. Moreover, this header field SHOULD be inserted above any other trace header fields such MTAs might prepend. This placement allows easy detection of header fields that can be trusted. End users making direct use of this header field might inadvertently trust information that has not been properly vetted. If, for example, a basic SPF result were to be relayed that claims an authenticated addr-spec, the local-part of that addr-spec has actually not been authenticated. Thus, an MTA adding this header field SHOULD NOT include any data that have not been authenticated by the method(s) being applied. Moreover, MUAs SHOULD NOT render to users such information if it is presented by a method known not to authenticate it.4.1. Header Field Position and Interpretation
In order to ensure non-ambiguous results and avoid the impact of false header fields, MUAs and downstream filters SHOULD NOT interpret this header field unless specifically configured to do so by the user or administrator. That is, this interpretation should not be "on by default". Naturally then, users or administrators ought not activate such a feature unless (1) they are certain the header field will be validly added by an agent within the ADMD that accepts the mail that is ultimately read by the MUA, and (2) instances of the header field that appear to originate within the ADMD but are actually added by foreign MTAs will be removed before delivery. Furthermore, MUAs and downstream filters SHOULD NOT interpret this header field unless the authentication service identifier of the header field is used within the ADMD as configured by the user or administrator. MUAs and downstream filters MUST ignore any result reported using a "result" not specified in the IANA "Result Code" registry or a "ptype" not listed in the "Email Authentication Property Types" registry for such values as defined in Section 6. Moreover, such agents MUST ignore a result indicated for any "method" they do not specifically support. The exception to this is experimental methods as discussed in Section 2.7.6. An MUA SHOULD NOT reveal these results to end users, absent careful "human factors" design considerations and testing, for the presentation of trust-related materials. For example, an attacker could register examp1e.com (note the digit "1" (one)) and send signed mail to intended victims; a verifier would detect that the signature
was valid and report a "pass" even though it's clear the DNS domain name was intended to mislead. See Section 7.2 for further discussion. As stated in Section 2.1, this header field MUST be treated as though it were a trace header field as defined in Section 3.6.7 of [MAIL] and hence MUST NOT be reordered and MUST be prepended to the message, so that there is generally some indication upon delivery of where in the chain of handling MTAs the message authentication was done. Note that there are a few message handlers that are only capable of appending new header fields to a message. Strictly speaking, these handlers are not compliant with this specification. They can still add the header field to carry authentication details, but any signal about where in the handling chain the work was done may be lost. Consumers SHOULD be designed such that this can be tolerated, especially from a producer known to have this limitation. MUAs SHOULD ignore instances of this header field discovered within message/rfc822 MIME attachments. They are likely to contain the results of authentication checks done in the past, possibly long ago, and have no contemporary value. Due caution therefore needs to be taken when choosing to consume them. Further discussion of these topics can be found in Section 7 below.4.2. Local Policy Enforcement
Some sites have a local policy that considers any particular authentication policy's non-recoverable failure results (typically "fail" or similar) as justification for rejecting the message. In such cases, the border MTA SHOULD issue an SMTP rejection response to the message, rather than adding this header field and allowing the message to proceed toward delivery. This is more desirable than allowing the message to reach an internal host's MTA or spam filter, thus possibly generating a local rejection such as a Delivery Status Notification (DSN) [DSN] to a forged originator. Such generated rejections are colloquially known as "backscatter". The same MAY also be done for local policy decisions overriding the results of the authentication methods (e.g., the "policy" result codes described in Section 2.7). Such rejections at the SMTP protocol level are not possible if local policy is enforced at the MUA and not the MTA.
5. Removing Existing Header Fields
To mitigate the impact of forged header fields, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary but that did not come directly from another trusted MTA. For example, an MTA for example.com receiving a message MUST delete or otherwise obscure any instance of this header field bearing an authentication service identifier indicating that the header field was added within example.com prior to adding its own header fields. This could mean each internal MTA will need to be configured with a list of other known, trusted MTAs that are thus expected to be using that same identifier. In the case of EAI-formatted messages, this test is done after converting A-labels into U-labels. For simplicity and maximum security, a border MTA could remove all instances of this header field on mail crossing into its trust boundary. However, this may conflict with the desire to access authentication results performed by trusted external service providers. It may also invalidate signed messages whose signatures cover external instances of this header field. A more robust border MTA could allow a specific list of authenticating MTAs whose information is to be admitted, removing the header field originating from all others. As stated in Section 1.2, a formal definition of "trust boundary" is deliberately not made here. It is entirely possible that a border MTA for example.com will explicitly trust authentication results asserted by upstream host example.net even though they exist in completely disjoint administrative boundaries. In that case, the border MTA MAY elect not to delete those results; moreover, the upstream host doing some authentication work could apply a signing technology such as [DKIM] on its own results to assure downstream hosts of their authenticity. An example of this is provided in Appendix B. Similarly, in the case of messages signed using [DKIM] or other message-signing methods that sign header fields, this removal action could invalidate one or more signatures on the message if they covered the header field to be removed. This behavior can be desirable, since there's little value in validating the signature on a message with forged header fields. However, signing agents MAY therefore elect to omit these header fields from signing to avoid this situation.
An MTA SHOULD remove any instance of this header field bearing a version (express or implied) that it does not support. However, an MTA MUST remove such a header field if the SMTP connection [SMTP] relaying the message is not from a trusted internal MTA. (As discussed above, this too can result in invalidation of signatures.) This means the MTA needs to be able to understand versions of this header field at least as late as the ones understood by the MUAs or other consumers within its ADMD.6. IANA Considerations
IANA has registered the defined header field and created registries as described below. These registry actions were originally defined by [RFC5451] and updated by [RFC6577] and [RFC7001]. The created registries were further updated in [RFC7601] to make them more complete. Each registry has two related sections below. The first describes the registry and its update procedures, which are unchanged from [RFC7601]. The second enumerates changes to entries that are relevant to this document.6.1. The Authentication-Results Header Field
The Authentication-Results header field was added to the IANA "Permanent Message Header Field Names" registry, per the procedure found in [IANA-HEADERS]. That entry has been updated to reference this document. The following is the registration template: Header field name: Authentication-Results Applicable protocol: mail [MAIL] Status: standard Author/Change controller: IETF Specification document(s): RFC 8601 Related information: none
6.2. "Email Authentication Methods" Registry Description
Names of message authentication methods supported by this specification have been registered with IANA, with the exception of experimental names as described in Section 2.7.6. Along with each method are recorded the properties that accompany the method's result. The "Email Authentication Parameters" group, and within it the "Email Authentication Methods" registry, were created by [RFC5451] for this purpose. [RFC6577] added a "Status" field for each entry. [RFC7001] amended the rules governing that registry and also added a "Version" field to the registry. The reference for that registry has been updated to reference this document. New entries are assigned only for values that have received Expert Review, per [IANA-CONSIDERATIONS]. The designated expert shall be appointed by the IESG. The designated expert has discretion to request that a publication be referenced if a clear, concise definition of the authentication method cannot be provided, such that interoperability is assured. Registrations should otherwise be permitted. The designated expert can also handle requests to mark any current registration as "deprecated". No two entries can have the same combination of method, ptype, and property. An entry in this registry contains the following: Method: the name of the method. Definition: a reference to the document that created this entry, if any (see below). ptype: a "ptype" value appropriate for use with that method. Property: a "property" value matching that "ptype" also appropriate for use with that method. Value: a brief description of the value to be supplied with that method/ptype/property tuple.
Status: the status of this entry, which is one of the following:
active: The entry is in current use.
deprecated: The entry is no longer in current use.
Version: a version number associated with the method (preferably
starting at "1").
The "Definition" field will typically refer to a permanent document,
or at least some descriptive text, where additional information about
the entry being added can be found. This might in turn reference the
document where the method is defined so that all of the semantics
around creating or interpreting an Authentication-Results header
field using this method, ptype, and property can be understood.
6.3. "Email Authentication Methods" Registry Update
The following entries in this registry have been updated to replace
[RFC7601] with this document:
+------------+--------+----------------------------------+
| Method | ptype | Property |
+------------+--------+----------------------------------+
| auth | smtp | auth |
+------------+--------+----------------------------------+
| auth | smtp | mailfrom |
+------------+--------+----------------------------------+
| dkim | header | d |
+------------+--------+----------------------------------+
| dkim | header | i |
+------------+--------+----------------------------------+
| iprev | policy | iprev |
+------------+--------+----------------------------------+
| spf | smtp | mailfrom |
+------------+--------+----------------------------------+
| spf | smtp | helo |
+------------+--------+----------------------------------+
Notably, the DomainKeys and Sender ID entries are not updated to
refer to this revised specification, as they are considered obsolete.
Accordingly, IANA has changed the "Status" field of the "sender-id"
entry in this table to "deprecated".
Finally, two new entries have been added to this registry, as follows:6.3.1. "header.a" for DKIM
Method: dkim Definition: RFC 8601 ptype: header Property: a Value: value of signature "a" tag Status: active Version: 16.3.2. "header.s" for DKIM
Method: dkim Definition: RFC 8601 ptype: header Property: s Value: value of signature "s" tag Status: active Version: 16.4. "Email Authentication Property Types" Registry Description
[RFC7410] created the "Email Authentication Property Types" registry. Entries in this registry are subject to the Expert Review rules as described in [IANA-CONSIDERATIONS]. Each entry in the registry requires the following values: ptype: the name of the ptype being registered, which must fit within the ABNF described in Section 2.2. Definition: an optional reference to a defining specification.
Description: a brief description of what sort of information this
"ptype" is meant to cover.
For new entries, the designated expert needs to ensure that the
description provided for the new entry adequately describes the
intended use. An example would be helpful to include in the entry's
defining document (if any), although entries in the "Email
Authentication Methods" registry or the "Email Authentication Result
Names" registry might also serve as examples of intended use.
As this is a complete restatement of the definition and rules for
this registry, IANA has updated this registry to show Section 2.3 of
this document as the current definitions for the "body", "header",
"policy", and "smtp" entries of that registry.
6.5. "Email Authentication Property Types" Registry Update
All current entries in this registry have been updated to replace
[RFC7601] with this document.
6.6. "Email Authentication Result Names" Registry Description
Names of message authentication result codes supported by this
specification must be registered with IANA, with the exception of
experimental codes as described in Section 2.7.7.
New entries are assigned only for values that have received Expert
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be
appointed by the IESG. The designated expert has discretion to
request that a publication be referenced if a clear, concise
definition of the authentication result cannot be provided, such that
interoperability is assured. Registrations should otherwise be
permitted. The designated expert can also handle requests to mark
any current registration as "deprecated".
No two entries can have the same combination of method and code.
An entry in this registry contains the following:
Auth Method: an authentication method for which results are being
returned using the header field defined in this document.
Code: a result code that can be returned for this authentication
method.
Specification: either free-form text explaining the meaning of this
method-code combination or a reference to such a definition.
Status: the status of this entry, which is one of the following:
active: The entry is in current use.
deprecated: The entry is no longer in current use.
6.7. "Email Authentication Result Names" Registry Update
For the following entries in this registry, the new "Specification"
field has been set as follows:
o All "auth" method result codes ("fail", "none", "pass",
"permerror", and "temperror") are now specified in Section 2.7.4
of this document.
o All "dkim" method result names ("fail", "neutral", "none", "pass",
"permerror", "policy", and "temperror") are now specified in
Section 2.7.1 of this document.
o All "iprev" method result names ("fail", "pass", "permerror", and
"temperror") are now specified in Section 2.7.3 of this document.
o The "spf" method result names "fail", "neutral", "none", "pass",
"permerror", "policy", "softfail", and "temperror" are now
specified in Section 2.7.2 of this document. The registration for
result name "hardfail" is not updated.
The following entries in this registry have been updated with a new
"Status" field set to "deprecated", and with no change to the
"Specification" field as they reference historic protocols:
o All "domainkeys" method result names ("fail", "neutral", "none",
"pass", "permerror", "policy", and "temperror").
o All "sender-id" method result names ("fail", "neutral", "none",
"pass", "permerror", "policy", "softfail", and "temperror").
6.8. SMTP Enhanced Status Codes
The entry for X.7.25 in the "Enumerated Status Codes" subregistry of
the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes
Registry" has been updated to refer only to Section 3.3 of
[AUTH-ESC], as that is where that registration was done.
7. Security Considerations
The following security considerations apply when adding or processing the Authentication-Results header field:7.1. Forged Header Fields
An MTA not applying the filtering discussed in Section 5 exposes MUAs to false conclusions based on forged header fields. A malicious user or agent could forge a header field using the DNS domain of a receiving ADMD as the authserv-id token in the value of the header field and, with the rest of the value, claim that the message was properly authenticated. The non-conformant MTA would fail to strip the forged header field, and the MUA could inappropriately trust it. For this reason, it is best not to have processing of the Authentication-Results header field enabled by default; instead, it should be ignored, at least for the purposes of enacting filtering decisions, unless specifically enabled by the user or administrator after verifying that the border MTA is compliant. It is acceptable to have an MUA aware of this specification but have an explicit list of hostnames whose Authentication-Results header fields are trustworthy; however, this list should initially be empty. Proposed alternative solutions to this problem were made some time ago and are listed below. To date, they have not been developed due to lack of demand but are documented here should the information be useful at some point in the future: 1. Possibly the simplest is a digital signature protecting the header field, such as using [DKIM], that can be verified by an MUA by using a posted public key. Although one of the main purposes of this document is to relieve the burden of doing message authentication work at the MUA, this only requires that the MUA learn a single authentication scheme even if a number of them are in use at the border MTA. Note that [DKIM] requires that the From header field be signed, although in this application, the signing agent (a trusted MTA) likely cannot authenticate that value, so the fact that it is signed should be ignored. Where the authserv-id is the ADMD's domain name, the authserv-id matching this valid internal signature's "d=" DKIM value is sufficient. 2. Another would be a means to interrogate the MTA that added the header field to see if it is actually providing any message authentication services and saw the message in question, but this isn't especially palatable given the work required to craft and implement such a scheme.
3. Yet another might be a method to interrogate the internal MTAs
that apparently handled the message (based on Received header
fields) to determine whether any of them conform to Section 5 of
this memo. This, too, has potentially high barriers to entry.
4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to
allow an MUA or filtering agent to acquire the authserv-id in use
within an ADMD, thus allowing it to identify which
Authentication-Results header fields it can trust.
5. On the presumption that internal MTAs are fully compliant with
Section 3.6 of [MAIL] and the compliant internal MTAs are using
their own hostnames or the ADMD's DNS domain name as the
authserv-id token, this header field should always appear above a
Received header added by a trusted MTA. This can be used as a
test for header field validity.
Support for some of these is being considered for future work.
In any case, a mechanism needs to exist for an MUA or filter to
verify that the host that appears to have added the header field
(a) actually did so and (b) is legitimately adding that header field
for this delivery. Given the variety of messaging environments
deployed today, consensus appears to be that specifying a particular
mechanism for doing so is not appropriate for this document.
Mitigation of the forged header field attack can also be accomplished
by moving the authentication results data into metadata associated
with the message. In particular, an SMTP extension [SMTP] could be
established to communicate authentication results from the border MTA
to intermediate and delivery MTAs; the latter of these could arrange
to store the authentication results as metadata retrieved and
rendered along with the message by an IMAP client [IMAP] aware of a
similar extension in that protocol. The delivery MTA would be told
to trust data via this extension only from MTAs it trusts, and border
MTAs would not accept data via this extension from any source. There
is no vector in such an arrangement for forgery of authentication
data by an outside agent.
7.2. Misleading Results
Until some form of service for querying the reputation of a sending
agent is widely deployed, the existence of this header field
indicating a "pass" does not render the message trustworthy. It is
possible for an arriving piece of spam or other undesirable mail to
pass checks by several of the methods enumerated above (e.g., a piece
of spam signed using [DKIM] by the originator of the spam, which
might be a spammer or a compromised system). In particular, this issue is not resolved by forged header field removal (discussed above). Hence, MUAs and downstream filters must take some care with use of this header even after possibly malicious headers are scrubbed.7.3. Header Field Position
Despite the requirements of [MAIL], header fields can sometimes be reordered en route by intermediate MTAs. The goal of requiring header field addition only at the top of a message is an acknowledgment that some MTAs do reorder header fields, but most do not. Thus, in the general case, there will be some indication of which MTAs (if any) handled the message after the addition of the header field defined here.7.4. Reverse IP Query Denial-of-Service Attacks
Section 4.6.4 of [SPF] observes that limits are necessary on recursive evaluations of SPF records in order to avoid abuse of or attacks on the DNS when verifying arriving client connections. A verifier wishing to do this check and report this information needs to take care not to go to unbounded lengths to resolve "A" and "PTR" queries. MUAs or other filters making use of an "iprev" result specified by this document need to be aware of the algorithm used by the verifier reporting the result and, especially, its limitations.7.5. Mitigation of Backscatter
Failing to follow the instructions of Section 4.2 can result in a denial-of-service attack caused by the generation of DSN messages [DSN] (or equivalent) to addresses that did not send the messages being rejected.7.6. Internal MTA Lists
Section 5 describes a procedure for scrubbing header fields that may contain forged authentication results about a message. A compliant installation will have to include, at each MTA, a list of other MTAs known to be compliant and trustworthy. Failing to keep this list current as internal infrastructure changes may expose an ADMD to attack.
7.7. Attacks against Authentication Methods
If an attack against an authentication method becomes known, clearly then the agent verifying that method can be fooled into thinking an inauthentic message is authentic, and thus the value of this header field can be misleading. It follows that any attack against the authentication methods supported by this document is also a security consideration here.7.8. Intentionally Malformed Header Fields
As with any other header field found in the message, it is possible for an attacker to add an Authentication-Results header field that is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in header field parsing code. Implementers must thoroughly verify all such header fields received from MTAs and be robust against intentionally as well as unintentionally malformed header fields.7.9. Compromised Internal Hosts
An internal MUA or MTA that has been compromised could generate mail with a forged From header field and a forged Authentication-Results header field that endorses it. Although it is clearly a larger concern to have compromised internal machines than it is to prove the value of this header field, this risk can be mitigated by arranging that internal MTAs will remove this header field if it claims to have been added by a trusted border MTA (as described above), yet the SMTP connection [SMTP] is not coming from an internal machine known to be running an authorized MTA. However, in such a configuration, legitimate MTAs will have to add this header field when legitimate internal-only messages are generated. This is also covered in Section 5.7.10. Encapsulated Instances
MIME messages can contain attachments of type "message/rfc822", which contain other messages. Such an encapsulated message can also contain an Authentication-Results header field. Although the processing of these is outside of the intended scope of this document (see Section 1.3), some simple guidance to MUA developers is appropriate here. Since MTAs are generally unlikely to strip Authentication-Results header fields during mailbox delivery, normative language exists in Section 4.1 cautioning MUAs to ignore such instances within MIME attachments, as might be included when a message is forwarded. Moreover, when extracting a message digest to separate mail store
messages or other media, such header fields should be removed so that they will never be interpreted improperly by MUAs that might later consume them. There can be cases where these header fields included as part of encapsulated messages might actually be of value, such as when they are taken from messages within the same ADMD where they will be consumed. Caution must be taken to ensure that the consumer fully understands the semantics of what the header field is indicating and the message's handling history before ascribing any value, positive or negative, to such data.7.11. Reverse Mapping
Although Section 3 of this memo includes explicit support for the "iprev" method, its value as an authentication mechanism is limited. Implementers of both this specification and agents that use the data it relays are encouraged to become familiar with the issues raised by [DNSOP-REVERSE] when deciding whether or not to include support for "iprev".
(page 39 continued on part 4)
