Internet Engineering Task Force (IETF)                      M. Kucherawy
Request for Comments: 8601                                      May 2019
Obsoletes: 7601
Category: Standards Track
ISSN: 2070-1721


   Message Header Field for Indicating Message Authentication Status

Abstract

   This document specifies a message header field called
   "Authentication-Results" for use with electronic mail messages to
   indicate the results of message authentication efforts.  Any
   receiver-side software, such as mail filters or Mail User Agents
   (MUAs), can use this header field to relay that information in a
   convenient and meaningful way to users or to make sorting and
   filtering decisions.

   This document obsoletes RFC 7601.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8601.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................4
      1.1. Purpose ....................................................5
      1.2. Trust Boundary .............................................6
      1.3. Processing Scope ...........................................7
      1.4. Requirements ...............................................7
      1.5. Definitions ................................................7
           1.5.1. Key Words ...........................................7
           1.5.2. Internationalized Email .............................7
           1.5.3. Security ............................................8
           1.5.4. Email Architecture ..................................8
           1.5.5. Other Terms .........................................9
      1.6. Trust Environment .........................................10
   2. Definition and Format of the Header Field ......................10
      2.1. General Description .......................................10
      2.2. Formal Definition .........................................11
      2.3. Property Types (ptypes) and Properties ....................13
      2.4. The "policy" ptype ........................................15
      2.5. Authentication Service Identifier Field ...................15
      2.6. Version Tokens ............................................17
      2.7. Defined Methods and Result Values .........................17
           2.7.1. DKIM ...............................................17
           2.7.2. SPF ................................................19
           2.7.3. "iprev" ............................................20
           2.7.4. SMTP AUTH ..........................................21
           2.7.5. Other Registered Codes .............................22
           2.7.6. Extension Methods ..................................22
           2.7.7. Extension Result Codes .............................23
   3. The "iprev" Authentication Method ..............................23
   4. Adding the Header Field to a Message ...........................25
      4.1. Header Field Position and Interpretation ..................26
      4.2. Local Policy Enforcement ..................................27

   5. Removing Existing Header Fields ................................28
   6. IANA Considerations ............................................29
      6.1. The Authentication-Results Header Field ...................29
      6.2. "Email Authentication Methods" Registry Description .......30
      6.3. "Email Authentication Methods" Registry Update ............31
           6.3.1. "header.a" for DKIM ................................32
           6.3.2. "header.s" for DKIM ................................32
      6.4. "Email Authentication Property Types" Registry
           Description ...............................................32
      6.5. "Email Authentication Property Types" Registry Update .....33
      6.6. "Email Authentication Result Names" Registry Description ..33
      6.7. "Email Authentication Result Names" Registry Update .......34
      6.8. SMTP Enhanced Status Codes ................................34
   7. Security Considerations ........................................35
      7.1. Forged Header Fields ......................................35
      7.2. Misleading Results ........................................36
      7.3. Header Field Position .....................................37
      7.4. Reverse IP Query Denial-of-Service Attacks ................37
      7.5. Mitigation of Backscatter .................................37
      7.6. Internal MTA Lists ........................................37
      7.7. Attacks against Authentication Methods ....................38
      7.8. Intentionally Malformed Header Fields .....................38
      7.9. Compromised Internal Hosts ................................38
      7.10. Encapsulated Instances ...................................38
      7.11. Reverse Mapping ..........................................39
   8. References .....................................................39
      8.1. Normative References ......................................39
      8.2. Informative References ....................................40
   Appendix A. Legacy MUAs ...........................................44
   Appendix B. Authentication-Results Examples .......................44
     B.1. Trivial Case: Header Field Not Present .....................44
     B.2. Nearly Trivial Case: Service Provided, but No
          Authentication Done ........................................45
     B.3. Service Provided, Authentication Done ......................46
     B.4. Service Provided, Several Authentications Done, Single
          MTA ........................................................47
     B.5. Service Provided, Several Authentications Done, Different
          MTAs .......................................................48
     B.6. Service Provided, Multi-tiered Authentication Done .........50
     B.7. Comment-Heavy Example ......................................51
   Appendix C. Operational Considerations about Message
               Authentication ........................................52
   Appendix D. Changes since RFC 7601 ................................53
   Acknowledgments ...................................................54
   Author's Address ..................................................54

1.  Introduction

   This document describes a header field called "Authentication-
   Results" for electronic mail messages that presents the results of a
   message authentication effort in a machine-readable format.  The
   intent of the header field is to create a place to collect such data
   when message authentication mechanisms are in use so that a Mail User
   Agent (MUA) and downstream filters can make filtering decisions
   and/or provide a recommendation to the user as to the validity of the
   message's origin and possibly the safety and integrity of its
   content.

   End users are not expected to be direct consumers of this header
   field.  This header field is intended for consumption by programs
   that will then use such data or render it in a human-usable form.

   This document specifies the format of this header field and discusses
   the implications of its presence or absence.  However, it does not
   discuss how the data contained in the header field ought to be used,
   such as what filtering decisions are appropriate or how an MUA might
   render those results, as these are local policy and/or user interface
   design questions that are not appropriate for this document.

   At the time of publication of this document, the following are
   published email authentication methods:

   o  SMTP Service Extension for Authentication [AUTH]

   o  DomainKeys Identified Mail Signatures [DKIM]

   o  Domain-based Message Authentication, Reporting, and Conformance
      [DMARC]

   o  Sender Policy Framework [SPF]

   o  reverse IP address name validation ("iprev", defined in Section 3)

   o  Require-Recipient-Valid-Since Header Field and SMTP Service
      Extension [RRVS]

   o  S/MIME Signature Verification [SMIME-REG]

   o  Vouch By Reference [VBR]

   The following Historic specifications were previously supported by
   this framework but have since become obsolete:

   o  Author Domain Signing Practices [ADSP] (Historic)

   o  DomainKeys [DOMAINKEYS] (Historic)

   Note that at the time of publication of this document the Sender ID
   specification [SENDERID] (Experimental) is no longer supported by
   this framework.  Discussion regarding moving it to Historic status is
   underway.

   There exist registries for tokens used within this header field that
   refer to the specifications listed above.  Section 6 describes the
   registries and their contents and specifies the process by which
   entries are added or updated.  It also updates the existing contents
   to match the current states of these specifications.

   The goal of this work is to give current and future authentication
   schemes a common framework within which to deliver their results to
   downstream agents and discourage the creation of unique header fields
   for each.

   Although SPF defined a header field called "Received-SPF" and the
   historic DomainKeys defined one called "DomainKey-Status" for this
   purpose, those header fields are specific to the conveyance of their
   respective results only and thus are insufficient to satisfy the
   requirements enumerated below.  In addition, many SPF implementations
   have adopted the header field specified here at least as an option,
   and DomainKeys has been obsoleted by DKIM.

1.1.  Purpose

   The header field defined in this document is expected to serve
   several purposes:

   1.  Convey the results of various message authentication checks,
       which are applied by upstream filters and Mail Transfer Agents
       (MTAs) and then passed to MUAs and downstream filters within the
       same "trust domain".  Such agents might wish to render those
       results to end users or to use those data to apply more or less
       stringent content checks based on authentication results.

   2.  Provide a common location within a message for such data.

   3.  Create an extensible framework for reporting new authentication
       methods as they emerge.

   In particular, the mere presence of this header field does not mean
   its contents are valid.  Rather, the header field is reporting
   assertions made by one or more authentication schemes applied
   somewhere upstream.  For an MUA or downstream filter to treat the
   assertions as actually valid, there must be an assessment of the
   trust relationship among such agents, the validating MTA, the paths
   between them, and the mechanism for conveying the information.

1.2.  Trust Boundary

   This document makes several references to the "trust boundary" of an
   Administrative Management Domain (ADMD).  Given the diversity among
   existing mail environments, a precise definition of this term isn't
   possible.

   Simply put, a transfer from the producer of the header field to the
   consumer must occur within a context that permits the consumer to
   treat assertions by the producer as being reliable and accurate
   (trustworthy).  How this trust is obtained is outside the scope of
   this document.  It is entirely a local matter.

   Thus, this document defines a "trust boundary" as the delineation
   between "external" and "internal" entities.  Services that are
   internal -- within the trust boundary -- are provided by the ADMD's
   infrastructure for its users.  Those that are external are outside of
   the authority of the ADMD.  By this definition, hosts that are within
   a trust boundary are subject to the ADMD's authority and policies,
   independent of their physical placement or their physical operation.
   For example, a host within a trust boundary might actually be
   operated by a remote service provider and reside physically within
   its data center.

   It is possible for a message to be evaluated inside a trust boundary
   but then depart and re-enter the trust boundary.  An example might be
   a forwarded message such as a message/rfc822 attachment (see
   "Multipurpose Internet Mail Extensions" [MIME]) or one that is part
   of a multipart/digest.  The details reported by this field cannot be
   trusted in that case.  Thus, if found within one of those media
   types, this field is typically ignored.

   Note that an MUA could be configured to retrieve messages from a
   receiver yet not be within the receiver's ADMD.  In this case, for
   the purposes of this work, that MUA is considered to be within the
   receiver's ADMD if it is configured to identify and ascribe value to
   authentication results recorded by that ADMD.

1.3.  Processing Scope

   The content of this header field is meant to convey to message
   consumers that authentication work on the message was already done
   within its trust boundary, and those results are being presented.  It
   is not intended to provide message parameters to consumers so that
   they can perform authentication protocols on their own.

1.4.  Requirements

   This document establishes no new requirements on existing protocols,
   insofar as a non-participating service will continue to interoperate
   with the deployed messaging infrastructure.

   In particular, this document establishes no requirement on MTAs to
   reject or filter arriving messages that do not pass authentication
   checks.  The data conveyed by the specified header field's contents
   are for the information of MUAs and filters and are to be used at
   their discretion.

   A participating ADMD does undertake some filtering and message
   modification obligations as described in Section 5.

1.5.  Definitions

   This section defines various terms used throughout this document.

1.5.1.  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.5.2.  Internationalized Email

   In this document, there are references to messages formatted to
   support Email Address Internationalization (EAI).  Reference material
   for this can be found in [RFC6530], [RFC6531], and [RFC6532].
   Generally speaking, these documents allow UTF-8 in most places that
   free-form text can be found and U-labels where domain names can be
   used, and this document extends Authentication-Results accordingly.

1.5.3.  Security

   "Guidelines for Writing RFC Text on Security Considerations"
   [SECURITY] discusses authentication and authorization and the
   conflation of the two concepts.  The use of those terms within the
   context of recent message security work has given rise to slightly
   different definitions, and this document reflects those current
   usages, as follows:

   o  "Authorization" is the establishment of permission to use a
      resource or represent an identity.  In this context, authorization
      indicates that a message from a particular ADMD arrived via a
      route the ADMD has explicitly approved.

   o  "Authentication" is the assertion of validity of a piece of data
      about a message (such as the sender's identity) or the message in
      its entirety.

   As examples: SPF is an authorization mechanism in that it expresses a
   result that shows whether the ADMD that apparently sent the message
   has explicitly authorized the connecting Simple Mail Transfer
   Protocol (SMTP) client [SMTP] to relay messages on its behalf, but it
   does not actually validate any other property of the message itself.
   By contrast, DKIM is agnostic as to the routing of a message but uses
   cryptographic signatures to authenticate agents, assign (some)
   responsibility for the message (which implies authorization), and
   ensure that the listed portions of the message were not modified in
   transit.  Since the signatures are not tied to SMTP connections, they
   can be added by the ADMD of origin, intermediate ADMDs (such as a
   mailing list server), other handling agents, or any combination of
   these.

   Rather than create a separate header field for each class of
   solution, this specification groups them both into a single header
   field.

1.5.4.  Email Architecture

   o  A "border MTA" is an MTA that acts as a gateway between the
      general Internet and the users within an organizational boundary.
      (See also Section 1.2.)

   o  A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that
      actually enacts delivery of a message to a user's inbox or other
      final delivery.

   o  An "intermediate MTA" is any MTA that is not a delivery MTA and is
      also not the first MTA to handle the message.

   o  A Message Submission Agent (MSA) is an agent that accepts a
      message from an MUA, introducing it to the mail-handling stream.

   The following diagram illustrates the flow of mail among these
   defined components.  See "Internet Mail Architecture" [EMAIL-ARCH]
   for further discussion on general email system architecture, which
   includes detailed descriptions of these components, and Appendix C of
   this document for discussion about the common aspects of email
   authentication in current environments.

                          +-----+   +-----+   +------------+
                          | MUA |-->| MSA |-->| Border MTA |
                          +-----+   +-----+   +------------+
                                                    |
                                                    |
                                                    V
                                               +----------+
                                               | Internet |
                                               +----------+
                                                    |
                                                    |
                                                    V
   +-----+   +-----+   +------------------+   +------------+
   | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA |
   +-----+   +-----+   +------------------+   +------------+

   Generally, it is assumed that the work of applying message
   authentication schemes takes place at a border MTA or a delivery MTA.
   This specification is written with that assumption in mind.  However,
   there are some sites at which the entire mail infrastructure consists
   of a single host.  In such cases, such terms as "border MTA" and
   "delivery MTA" might well apply to the same machine or even the very
   same agent.  It is also possible that some message authentication
   tests could take place on an intermediate MTA.  Although this
   document doesn't specifically describe such cases, they are not meant
   to be excluded.

1.5.5.  Other Terms

   In this document, the term "producer" refers to any component that
   adds this header field to messages it is handling, and "consumer"
   refers to any component that identifies, extracts, and parses the
   header field to use as part of a handling decision.

1.6.  Trust Environment

   This header field permits one or more message validation mechanisms
   to communicate output to one or more separate assessment mechanisms.
   These mechanisms operate within a unified trust boundary that defines
   an ADMD.  An ADMD contains one or more entities that perform
   validation and generate the header field and one or more that consume
   it for some type of assessment.  The field often contains no
   integrity or validation mechanism of its own, so its presence must be
   trusted implicitly.  Hence, valid use of the header field requires
   removing any occurrences of it that claim to be associated with the
   ADMD when the message enters the ADMD.  This ensures that later
   occurrences have been added within the trust boundary of the ADMD.

   The authserv-id token defined in Section 2.2 can be used to reference
   an entire ADMD or a specific validation engine within an ADMD.
   Although the labeling scheme is left as an operational choice, some
   guidance for selecting a token is provided in later sections of this
   document.