doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc8461.txt b/doc/rfc/rfc8461.txt
new file mode 100644
index 0000000..32333a5
--- /dev/null
+++ b/doc/rfc/rfc8461.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       D. Margolis
+Request for Comments: 8461                                     M. Risher
+Category: Standards Track                                   Google, Inc.
+ISSN: 2070-1721                                          B. Ramakrishnan
+                                                              Oath, Inc.
+                                                              A. Brotman
+                                                           Comcast, Inc.
+                                                                J. Jones
+                                                         Microsoft, Inc.
+                                                          September 2018
+
+
+              SMTP MTA Strict Transport Security (MTA-STS)
+
+Abstract
+
+   SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling
+   mail service providers (SPs) to declare their ability to receive
+   Transport Layer Security (TLS) secure SMTP connections and to specify
+   whether sending SMTP servers should refuse to deliver to MX hosts
+   that do not offer TLS with a trusted server certificate.
+
+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/rfc8461.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 1]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 2]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Related Technologies  . . . . . . . . . . . . . . . . . . . .   5
+   3.  Policy Discovery  . . . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  MTA-STS TXT Records . . . . . . . . . . . . . . . . . . .   6
+     3.2.  MTA-STS Policies  . . . . . . . . . . . . . . . . . . . .   7
+     3.3.  HTTPS Policy Fetching . . . . . . . . . . . . . . . . . .  10
+     3.4.  Policy Selection for Smart Hosts and Subdomains . . . . .  11
+   4.  Policy Validation . . . . . . . . . . . . . . . . . . . . . .  11
+     4.1.  MX Host Validation  . . . . . . . . . . . . . . . . . . .  12
+     4.2.  Recipient MTA Certificate Validation  . . . . . . . . . .  12
+   5.  Policy Application  . . . . . . . . . . . . . . . . . . . . .  12
+     5.1.  Policy Application Control Flow . . . . . . . . . . . . .  13
+   6.  Reporting Failures  . . . . . . . . . . . . . . . . . . . . .  13
+   7.  Interoperability Considerations . . . . . . . . . . . . . . .  14
+     7.1.  SNI Support . . . . . . . . . . . . . . . . . . . . . . .  14
+     7.2.  Minimum TLS Version Support . . . . . . . . . . . . . . .  14
+   8.  Operational Considerations  . . . . . . . . . . . . . . . . .  15
+     8.1.  Policy Updates  . . . . . . . . . . . . . . . . . . . . .  15
+     8.2.  Policy Delegation . . . . . . . . . . . . . . . . . . . .  15
+     8.3.  Removing MTA-STS  . . . . . . . . . . . . . . . . . . . .  16
+     8.4.  Preserving MX Candidate Traversal . . . . . . . . . . . .  17
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
+     9.1.  Well-Known URIs Registry  . . . . . . . . . . . . . . . .  17
+     9.2.  MTA-STS TXT Record Fields . . . . . . . . . . . . . . . .  17
+     9.3.  MTA-STS Policy Fields . . . . . . . . . . . . . . . . . .  18
+   10. Security Considerations . . . . . . . . . . . . . . . . . . .  18
+     10.1.  Obtaining a Signed Certificate . . . . . . . . . . . . .  18
+     10.2.  Preventing Policy Discovery  . . . . . . . . . . . . . .  19
+     10.3.  Denial of Service  . . . . . . . . . . . . . . . . . . .  19
+     10.4.  Weak Policy Constraints  . . . . . . . . . . . . . . . .  20
+     10.5.  Compromise of the Web PKI System . . . . . . . . . . . .  20
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .  21
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  23
+   Appendix A.  MTA-STS Example Record and Policy  . . . . . . . . .  25
+   Appendix B.  Message Delivery Pseudocode  . . . . . . . . . . . .  25
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  28
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 3]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+1.  Introduction
+
+   The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
+   hosts to negotiate the use of a TLS channel for encrypted mail
+   transmission.
+
+   While this opportunistic encryption protocol by itself provides a
+   high barrier against passive man-in-the-middle traffic interception,
+   any attacker who can delete parts of the SMTP session (such as the
+   "250 STARTTLS" response) or who can redirect the entire SMTP session
+   (perhaps by overwriting the resolved MX record of the delivery
+   domain) can perform downgrade or interception attacks.
+
+   This document defines a mechanism for recipient domains to publish
+   policies, via a combination of DNS and HTTPS, specifying:
+
+   o  whether MTAs sending mail to this domain can expect PKIX-
+      authenticated TLS support
+
+   o  what a conforming client should do with messages when TLS cannot
+      be successfully negotiated
+
+1.1.  Terminology
+
+   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.
+
+   We also define the following terms for further use in this document:
+
+   o  MTA-STS Policy: A commitment by the Policy Domain to support TLS
+      authenticated with PKIX [RFC5280] for the specified MX hosts.
+
+   o  Policy Domain: The domain for which an MTA-STS Policy is defined.
+      This is the next-hop domain; when sending mail to
+      "alice@example.com", this would ordinarily be "example.com", but
+      this may be overridden by explicit routing rules (as described in
+      Section 3.4, "Policy Selection for Smart Hosts and Subdomains").
+
+   o  Policy Host: The HTTPS host that serves the MTA-STS Policy for a
+      Policy Domain.  Rules for constructing the hostname are described
+      in Section 3.2, "MTA-STS Policies".
+
+   o  Sender or Sending MTA: The SMTP MTA sending an email message.
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 4]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   o  ABNF: Augmented Backus-Naur Form, a syntax for formally specifying
+      syntax, defined in [RFC5234] and [RFC7405].
+
+2.  Related Technologies
+
+   The DNS-Based Authentication of a Named Entities (DANE) TLSA record
+   [RFC7672] is similar, in that DANE is also designed to upgrade
+   unauthenticated encryption or plaintext transmission into
+   authenticated, downgrade-resistant encrypted transmission.  DANE
+   requires DNSSEC [RFC4033] for authentication; the mechanism described
+   here instead relies on certification authorities (CAs) and does not
+   require DNSSEC, at a cost of risking malicious downgrades.  For a
+   thorough discussion of this trade-off, see Section 10, "Security
+   Considerations".
+
+   In addition, MTA-STS provides an optional testing-only mode, enabling
+   soft deployments to detect policy failures; partial deployments can
+   be achieved in DANE by deploying TLSA records only for some of a
+   domain's MXes, but such a mechanism is not possible for the per-
+   domain policies used by MTA-STS.
+
+   The primary motivation of MTA-STS is to provide a mechanism for
+   domains to ensure transport security even when deploying DNSSEC is
+   undesirable or impractical.  However, MTA-STS is designed not to
+   interfere with DANE deployments when the two overlap; in particular,
+   senders who implement MTA-STS validation MUST NOT allow MTA-STS
+   Policy validation to override a failing DANE validation.
+
+3.  Policy Discovery
+
+   MTA-STS policies are distributed via HTTPS from a "well-known"
+   [RFC5785] path served within the Policy Domain, and their presence
+   and current version are indicated by a TXT record at the Policy
+   Domain.  These TXT records additionally contain a policy "id" field,
+   allowing Sending MTAs to check that a cached policy is still current
+   without performing an HTTPS request.
+
+   To discover if a recipient domain implements MTA-STS, a sender need
+   only resolve a single TXT record.  To see if an updated policy is
+   available for a domain for which the sender has a previously cached
+   policy, the sender need only check the TXT record's version "id"
+   against the cached value.
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 5]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+3.1.  MTA-STS TXT Records
+
+   The MTA-STS TXT record is a TXT record with the name "_mta-sts" at
+   the Policy Domain.  For the domain "example.com", this record would
+   be "_mta-sts.example.com".  MTA-STS TXT records MUST be US-ASCII,
+   semicolon-separated key/value pairs containing the following fields:
+
+   o  "v" (plaintext, required): Currently, only "STSv1" is supported.
+
+   o  "id" (plaintext, required): A short string used to track policy
+      updates.  This string MUST uniquely identify a given instance of a
+      policy, such that senders can determine when the policy has been
+      updated by comparing to the "id" of a previously seen policy.
+      There is no implied ordering of "id" fields between revisions.
+
+   An example TXT record is as below:
+
+   _mta-sts.example.com.  IN TXT "v=STSv1; id=20160831085700Z;"
+
+   The formal definition of the "_mta-sts" TXT record, defined using
+   ABNF [RFC7405], is as follows:
+
+   sts-text-record = sts-version 1*(sts-field-delim sts-field)
+                     [sts-field-delim]
+
+   sts-field       = sts-id /                 ; Note that sts-id record
+                     sts-extension            ; is required.
+
+   sts-field-delim = *WSP ";" *WSP
+
+   sts-version     = %s"v=STSv1"
+
+   sts-id          = %s"id=" 1*32(ALPHA / DIGIT)     ; id=...
+
+   sts-extension   = sts-ext-name "=" sts-ext-value  ; name=value
+
+   sts-ext-name    = (ALPHA / DIGIT)
+                     *31(ALPHA / DIGIT / "_" / "-" / ".")
+
+   sts-ext-value   = 1*(%x21-3A / %x3C / %x3E-7E)
+                     ; chars excluding "=", ";", SP, and CTLs
+
+   The TXT record MUST begin with the sts-version field; the order of
+   other fields is not significant.  If multiple TXT records for
+   "_mta-sts" are returned by the resolver, records that do not begin
+   with "v=STSv1;" are discarded.  If the number of resulting records is
+   not one, or if the resulting record is syntactically invalid, senders
+   MUST assume the recipient domain does not have an available MTA-STS
+
+
+
+Margolis, et al.             Standards Track                    [Page 6]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   Policy and skip the remaining steps of policy discovery.  (Note that
+   the absence of a usable TXT record is not by itself sufficient to
+   remove a sender's previously cached policy for the Policy Domain, as
+   discussed in Section 5.1, "Policy Application Control Flow".)  If the
+   resulting TXT record contains multiple strings, then the record MUST
+   be treated as if those strings are concatenated without adding
+   spaces.
+
+   The "_mta-sts" record MAY return a CNAME that points (directly or via
+   other CNAMEs) to a TXT record, in which case senders MUST follow the
+   CNAME pointers.  This can be used for policy delegation, as described
+   in Section 8.2.
+
+3.2.  MTA-STS Policies
+
+   The policy itself is a set of key/value pairs (similar to header
+   fields in [RFC5322]) served via the HTTPS GET method from the fixed
+   "well-known" [RFC5785] path of ".well-known/mta-sts.txt" served by
+   the Policy Host.  The Policy Host DNS name is constructed by
+   prepending "mta-sts" to the Policy Domain.
+
+   Thus, for a Policy Domain of "example.com", the full URL is
+   "https://mta-sts.example.com/.well-known/mta-sts.txt".
+
+   When fetching a policy, senders SHOULD validate that the media type
+   is "text/plain" to guard against cases where web servers allow
+   untrusted users to host non-text content (typically, HTML or images)
+   at a user-defined path.  All parameters other than charset=utf-8 or
+   charset=us-ascii are ignored.  Additional "Content-Type" parameters
+   are also ignored.
+
+   This resource contains the following CRLF-separated key/value pairs:
+
+   o  "version": Currently, only "STSv1" is supported.
+
+   o  "mode": One of "enforce", "testing", or "none", indicating the
+      expected behavior of a Sending MTA in the case of a policy
+      validation failure.  See Section 5, "Policy Application", for more
+      details about the three modes.
+
+   o  "max_age": Max lifetime of the policy (plaintext non-negative
+      integer seconds, maximum value of 31557600).  Well-behaved clients
+      SHOULD cache a policy for up to this value from the last policy
+      fetch time.  To mitigate the risks of attacks at policy refresh
+      time, it is expected that this value typically be in the range of
+      weeks or greater.
+
+
+
+
+
+Margolis, et al.             Standards Track                    [Page 7]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   o  "mx": Allowed MX patterns.  One or more patterns matching allowed
+      MX hosts for the Policy Domain.  As an example,
+
+                        mx: mail.example.com <CRLF>
+                        mx: *.example.net
+
+   indicates that mail for this domain might be handled by MX
+   "mail.example.com" or any MX at "example.net".  Valid patterns can be
+   either fully specified names ("example.com") or suffixes prefixed by
+   a wildcard ("*.example.net").  If a policy specifies more than one
+   MX, each MX MUST have its own "mx:" key, and each MX key/value pair
+   MUST be on its own line in the policy file.  In the case of
+   Internationalized Domain Names [RFC5891], the "mx" value MUST specify
+   the Punycode-encoded A-label [RFC3492] to match against, and not the
+   Unicode-encoded U-label.  The full semantics of certificate
+   validation (including the use of wildcard patterns) are described in
+   Section 4.1, "MX Host Validation".
+
+   An example policy is as below:
+
+                         version: STSv1
+                         mode: enforce
+                         mx: mail.example.com
+                         mx: *.example.net
+                         mx: backupmx.example.com
+                         max_age: 604800
+
+   The formal definition of the policy resource, defined using ABNF
+   [RFC7405], is as follows:
+
+sts-policy-record        = sts-policy-field *WSP
+                           *(sts-policy-term sts-policy-field *WSP)
+                           [sts-policy-term]
+
+sts-policy-field         = sts-policy-version /      ; required once
+                           sts-policy-mode    /      ; required once
+                           sts-policy-max-age /      ; required once
+                           sts-policy-mx /
+                           ; required at least once, except when
+                           ; mode is "none"
+                           sts-policy-extension      ; other fields
+
+sts-policy-field-delim   = ":" *WSP
+
+sts-policy-version     = sts-policy-version-field sts-policy-field-delim
+                         sts-policy-version-value
+
+sts-policy-version-field = %s"version"
+
+
+
+Margolis, et al.             Standards Track                    [Page 8]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+sts-policy-version-value = %s"STSv1"
+
+sts-policy-mode          = sts-policy-mode-field sts-policy-field-delim
+                           sts-policy-mode-value
+
+sts-policy-mode-field    = %s"mode"
+
+sts-policy-mode-value    =  %s"testing" / %s"enforce" / %s"none"
+
+sts-policy-mx            = sts-policy-mx-field sts-policy-field-delim
+                           sts-policy-mx-value
+
+sts-policy-mx-field      = %s"mx"
+
+sts-policy-mx-value      = ["*."] Domain
+
+sts-policy-max-age     = sts-policy-max-age-field sts-policy-field-delim
+                         sts-policy-max-age-value
+
+sts-policy-max-age-field = %s"max_age"
+
+sts-policy-max-age-value = 1*10(DIGIT)
+
+sts-policy-extension     = sts-policy-ext-name    ; additional
+                           sts-policy-field-delim ; extension
+                           sts-policy-ext-value   ; fields
+
+sts-policy-ext-name      = (sts-policy-alphanum)
+                           *31(sta-policy-alphanum / "_" / "-" / ".")
+
+sts-policy-term          = LF / CRLF
+
+sts-policy-ext-value     = sts-policy-vchar
+                           [*(%x20 / sts-policy-vchar)
+                           sts-policy-vchar]
+                           ; chars, including UTF-8 [RFC3629],
+                           ; excluding CTLs and no
+                           ; leading/trailing spaces
+
+sts-policy-alphanum     = ALPHA / DIGIT
+
+sts-policy-vchar        = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4
+
+UTF8-2          =   <Defined in Section 4 of [RFC3629]>
+
+UTF8-3          =   <Defined in Section 4 of [RFC3629]>
+
+UTF8-4          =   <Defined in Section 4 of [RFC3629]>
+
+
+
+Margolis, et al.             Standards Track                    [Page 9]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+Domain          =   <Defined in Section 4.1.2 of [RFC5321]>
+
+   Parsers MUST accept TXT records and policy files that are
+   syntactically valid (i.e., valid key/value pairs separated by
+   semicolons for TXT records), possibly containing additional key/value
+   pairs not specified in this document, in which case unknown fields
+   SHALL be ignored.  If any non-repeated field -- i.e., all fields
+   excepting "mx" -- is duplicated, all entries except for the first
+   SHALL be ignored.
+
+3.3.  HTTPS Policy Fetching
+
+   Policy bodies are, as described above, retrieved by Sending MTAs via
+   HTTPS [RFC2818].  During the TLS handshake initiated to fetch a new
+   or updated policy from the Policy Host, the Policy Host HTTPS server
+   MUST present an X.509 certificate that is valid for the "mta-sts"
+   DNS-ID [RFC6125] (e.g., "mta-sts.example.com") as described below,
+   chain to a root CA that is trusted by the Sending MTA, and be non-
+   expired.  It is expected that Sending MTAs use a set of trusted CAs
+   similar to those in widely deployed web browsers and operating
+   systems.  See [RFC5280] for more details about certificate
+   verification.
+
+   The certificate is valid for the Policy Host (i.e., "mta-sts"
+   prepended to the Policy Domain) with respect to the rules described
+   in [RFC6125], with the following application-specific considerations:
+
+   o  Matching is performed only against the DNS-ID identifiers.
+
+   o  DNS domain names in server certificates MAY contain the wildcard
+      character '*' as the complete left-most label within the
+      identifier.
+
+   The certificate MAY be checked for revocation via the Online
+   Certificate Status Protocol (OCSP) [RFC6960], certificate revocation
+   lists (CRLs), or some other mechanism.
+
+   Policies fetched via HTTPS are only valid if the HTTP response code
+   is 200 (OK).  HTTP 3xx redirects MUST NOT be followed, and HTTP
+   caching (as specified in [RFC7234]) MUST NOT be used.
+
+   Senders may wish to rate-limit the frequency of attempts to fetch the
+   HTTPS endpoint even if a valid TXT record for the recipient domain
+   exists.  In the case where the HTTPS GET fails, implementers SHOULD
+   limit further attempts to a period of five minutes or longer per
+   version ID, to avoid overwhelming resource-constrained recipients
+   with cascading failures.
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 10]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   Senders MAY impose a timeout on the HTTPS GET and/or a limit on the
+   maximum size of the response body to avoid long delays or resource
+   exhaustion during attempted policy updates.  A suggested timeout is
+   one minute, and a suggested maximum policy size is 64 kilobytes;
+   Policy Hosts SHOULD respond to requests with a complete policy body
+   within that timeout and size limit.
+
+   If a valid TXT record is found but no policy can be fetched via HTTPS
+   (for any reason), and there is no valid (non-expired) previously
+   cached policy, senders MUST continue with delivery as though the
+   domain has not implemented MTA-STS.
+
+   Conversely, if no "live" policy can be discovered via DNS or fetched
+   via HTTPS, but a valid (non-expired) policy exists in the sender's
+   cache, the sender MUST apply that cached policy.
+
+   Finally, to mitigate the risk of persistent interference with policy
+   refresh, as discussed in-depth in Section 10, MTAs SHOULD proactively
+   refresh cached policies before they expire; a suggested refresh
+   frequency is once per day.  To enable administrators to discover
+   problems with policy refresh, MTAs SHOULD alert administrators
+   (through the use of logs or similar) when such attempts fail, unless
+   the cached policy mode is "none".
+
+3.4.  Policy Selection for Smart Hosts and Subdomains
+
+   When sending mail via a "smart host" -- an administratively
+   configured intermediate SMTP relay, which is different from the
+   message recipient's server as determined from DNS -- compliant
+   senders MUST treat the smart host domain as the Policy Domain for the
+   purposes of policy discovery and application.  This specification
+   does not provide a means of associating policies with email addresses
+   that employ Address Literals [RFC5321].
+
+   When sending mail to a mailbox at a subdomain, compliant senders MUST
+   NOT attempt to fetch a policy from the parent zone.  Thus, for mail
+   sent to "user@mail.example.com", the policy can be fetched only from
+   "mail.example.com", not "example.com".
+
+4.  Policy Validation
+
+   When sending to an MX at a domain for which the sender has a valid
+   and non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS MUST
+   check whether:
+
+   1.  At least one of the policy's "mx" patterns matches the selected
+       MX host, as described in Section 4.1, "MX Host Validation".
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 11]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   2.  The recipient mail server supports STARTTLS and offers a PKIX-
+       based TLS certificate, during TLS handshake, which is valid for
+       that host, as described in Section 4.2, "Recipient MTA
+       Certificate Validation".
+
+   When these conditions are not met, a policy is said to fail to
+   validate.  This section does not dictate the behavior of Sending MTAs
+   when the above conditions are not met; see Section 5, "Policy
+   Application", for a description of Sending MTA behavior when policy
+   validation fails.
+
+4.1.  MX Host Validation
+
+   A receiving candidate MX host is valid according to an applied MTA-
+   STS Policy if the MX record name matches one or more of the "mx"
+   fields in the applied policy.  Matching is identical to the rules
+   given in [RFC6125], with the restriction that the wildcard character
+   '*' may only be used to match the entire left-most label in the
+   presented identifier.  Thus, the mx pattern "*.example.com" matches
+   "mail.example.com" but not "example.com" or "foo.bar.example.com".
+
+4.2.  Recipient MTA Certificate Validation
+
+   The certificate presented by the receiving MTA MUST not be expired
+   and MUST chain to a root CA that is trusted by the Sending MTA.  The
+   certificate MUST have a subject alternative name (SAN) [RFC5280] with
+   a DNS-ID [RFC6125] matching the hostname, per the rules given in
+   [RFC6125].  The MX's certificate MAY also be checked for revocation
+   via OCSP [RFC6960], CRLs [RFC6818], or some other mechanism.
+
+5.  Policy Application
+
+   When sending to an MX at a domain for which the sender has a valid,
+   non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS applies
+   the result of a policy validation failure in one of two ways,
+   depending on the value of the policy "mode" field:
+
+   1.  "enforce": In this mode, Sending MTAs MUST NOT deliver the
+       message to hosts that fail MX matching or certificate validation
+       or that do not support STARTTLS.
+
+   2.  "testing": In this mode, Sending MTAs that also implement the
+       TLSRPT (TLS Reporting) specification [RFC8460] send a report
+       indicating policy application failures (as long as TLSRPT is also
+       implemented by the recipient domain); in any case, messages may
+       be delivered as though there were no MTA-STS validation failure.
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 12]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   3.  "none": In this mode, Sending MTAs should treat the Policy Domain
+       as though it does not have any active policy; see Section 8.3,
+       "Removing MTA-STS", for use of this mode value.
+
+   When a message fails to deliver due to an "enforce" policy, a
+   compliant MTA MUST NOT permanently fail to deliver messages before
+   checking, via DNS, for the presence of an updated policy at the
+   Policy Domain.  (In all cases, MTAs SHOULD treat such failures as
+   transient errors and retry delivery later.)  This allows implementing
+   domains to update long-lived policies on the fly.
+
+5.1.  Policy Application Control Flow
+
+   An example control flow for a compliant sender consists of the
+   following steps:
+
+   1.  Check for a cached policy whose time-since-fetch has not exceeded
+       its "max_age".  If none exists, attempt to fetch a new policy
+       (perhaps asynchronously, so as not to block message delivery).
+       Optionally, Sending MTAs may unconditionally check for a new
+       policy at this step.
+
+   2.  For each candidate MX, in order of MX priority, attempt to
+       deliver the message.  If a policy is present with an "enforce"
+       mode, when attempting to deliver to each candidate MX, ensure
+       STARTTLS support and host identity validity as described in
+       Section 4, "Policy Validation".  If a candidate fails validation,
+       continue to the next candidate (if there is one).
+
+   3.  A message delivery attempt MUST NOT be permanently failed until
+       the sender has first checked for the presence of a new policy (as
+       indicated by the "id" field in the "_mta-sts" TXT record).  If a
+       new policy is not found, existing rules for the case of temporary
+       message delivery failures apply (as discussed in [RFC5321],
+       Section 4.5.4.1).
+
+6.  Reporting Failures
+
+   MTA-STS is intended to be used along with TLSRPT [RFC8460] in order
+   to ensure that implementing domains can detect cases of both benign
+   and malicious failures and to ensure that failures that indicate an
+   active attack are discoverable.  As such, senders that also implement
+   TLSRPT SHOULD treat the following events as reportable failures:
+
+   o  HTTPS policy fetch failures when a valid TXT record is present.
+
+   o  Policy fetch failures of any kind when a valid policy exists in
+      the policy cache, except if that policy's mode is "none".
+
+
+
+Margolis, et al.             Standards Track                   [Page 13]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   o  Delivery attempts in which a contacted MX does not support
+      STARTTLS or does not present a certificate that validates
+      according to the applied policy, except if that policy's mode is
+      "none".
+
+7.  Interoperability Considerations
+
+7.1.  SNI Support
+
+   To ensure that the server sends the right certificate chain, the SMTP
+   client MUST have support for the TLS Server Name Indication (SNI)
+   extension [RFC6066].  When connecting to an HTTP server to retrieve
+   the MTA-STS Policy, the SNI extension MUST contain the name of the
+   Policy Host (e.g., "mta-sts.example.com").  When connecting to an
+   SMTP server, the SNI extension MUST contain the MX hostname.
+
+   HTTP servers used to deliver MTA-STS policies MAY rely on SNI to
+   determine which certificate chain to present to the client.  HTTP
+   servers MUST respond with a certificate chain that matches the policy
+   hostname or abort the TLS handshake if unable to do so.  Clients that
+   do not send SNI information may not see the expected certificate
+   chain.
+
+   SMTP servers MAY rely on SNI to determine which certificate chain to
+   present to the client.  However, servers that have one identity and a
+   single matching certificate do not require SNI support.  Servers MUST
+   NOT enforce the use of SNI by clients, as the client may be using
+   unauthenticated opportunistic TLS and may not expect any particular
+   certificate from the server.  If the client sends no SNI extension or
+   sends an SNI extension for an unsupported server name, the server
+   MUST simply send a fallback certificate chain of its choice.  The
+   reason for not enforcing strict matching of the requested SNI
+   hostname is that MTA-STS TLS clients may be typically willing to
+   accept multiple server names but can only send one name in the SNI
+   extension.  The server's fallback certificate may match a different
+   name that is acceptable to the client, e.g., the original next-hop
+   domain.
+
+7.2.  Minimum TLS Version Support
+
+   MTAs supporting MTA-STS MUST have support for TLS 1.2 [RFC5246] or
+   TLS 1.3 [RFC8446] or higher.  The general TLS usage guidance in
+   [RFC7525] SHOULD be followed.
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 14]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+8.  Operational Considerations
+
+8.1.  Policy Updates
+
+   Updating the policy requires that the owner make changes in two
+   places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and
+   at the corresponding HTTPS endpoint.  As a result, recipients should
+   expect that a policy will continue to be used by senders until both
+   the HTTPS and TXT endpoints are updated and the TXT record's TTL has
+   passed.
+
+   In other words, a sender who is unable to successfully deliver a
+   message while applying a cache of the recipient's now-outdated policy
+   may be unable to discover that a new policy exists until the DNS TTL
+   has passed.  Recipients SHOULD therefore ensure that old policies
+   continue to work for message delivery during this period of time, or
+   risk message delays.
+
+   Recipients SHOULD also update the HTTPS policy body before updating
+   the TXT record; this ordering avoids the risk that senders, seeing a
+   new TXT record, mistakenly cache the old policy from HTTPS.
+
+8.2.  Policy Delegation
+
+   Domain owners commonly delegate SMTP hosting to a different
+   organization, such as an ISP or a web host.  In such a case, they may
+   wish to also delegate the MTA-STS Policy to the same organization,
+   which can be accomplished with two changes.
+
+   First, the Policy Domain must point the "_mta-sts" record, via CNAME,
+   to the "_mta-sts" record maintained by the provider.  This allows the
+   provider to control update signaling.
+
+   Second, the Policy Domain must point the "well-known" policy location
+   to the provider.  This can be done either by setting the "mta-sts"
+   record to an IP address or CNAME specified by the provider and by
+   giving the provider a TLS certificate that is valid for that host or
+   by setting up a "reverse proxy" (also known as a "gateway") server
+   for the Policy Domain's Policy Host, configured to serve proxied
+   responses from the Policy Host of the provider.
+
+   For example, given a user domain "user.example" hosted by a mail
+   provider "provider.example", the following configuration would allow
+   policy delegation:
+
+   DNS:
+
+        _mta-sts.user.example.  IN CNAME _mta-sts.provider.example.
+
+
+
+Margolis, et al.             Standards Track                   [Page 15]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   Policy:
+
+         > GET /.well-known/mta-sts.txt Host: mta-sts.user.example
+         < HTTP/1.1 200 OK  # Response proxies content from
+                            # https://mta-sts.provider.example
+
+   Note that in all such cases, the policy endpoint
+   ("https://mta-sts.user.example/.well-known/mta-sts.txt" in this
+   example) must still present a certificate valid for the Policy Host
+   ("mta-sts.user.example"), and not for that host at the provider's
+   domain ("mta-sts.provider.example").
+
+   Note that while Sending MTAs MUST NOT use HTTP caching when fetching
+   policies via HTTPS, such caching may nonetheless be useful to a
+   reverse proxy configured as described in this section.  An HTTPS
+   policy endpoint expecting to be proxied for multiple hosted domains
+   -- as with a large mail hosting provider or similar -- may wish to
+   indicate an HTTP Cache-Control "max-age" response directive (as
+   specified in [RFC7234]) of 60 seconds as a reasonable value to save
+   reverse proxies an unnecessarily high-rate of proxied policy
+   fetching.
+
+8.3.  Removing MTA-STS
+
+   In order to facilitate clean opt-out of MTA-STS by implementing
+   Policy Domains, and to distinguish clearly between failures that
+   indicate attacks and those that indicate such opt-outs, MTA-STS
+   implements the "none" mode, which allows validated policies to
+   indicate authoritatively that the Policy Domain wishes to no longer
+   implement MTA-STS and may, in the future, remove the MTA-STS TXT and
+   policy endpoints entirely.
+
+   A suggested workflow to implement such an opt out is as follows:
+
+   1.  Publish a new policy with "mode" equal to "none" and a small
+       "max_age" (e.g., one day).
+
+   2.  Publish a new TXT record to trigger fetching of the new policy.
+
+   3.  When all previously served policies have expired -- normally this
+       is the time the previously published policy was last served plus
+       that policy's "max_age", but note that policies older than the
+       previously published policy may have been served with a greater
+       "max_age" than the previously published policy, allowing
+       overlapping policy caches -- safely remove the TXT record and
+       HTTPS endpoint.
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 16]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+8.4.  Preserving MX Candidate Traversal
+
+   Implementers of send-time MTA-STS validation in mail transfer agents
+   should take note of the risks of modifying the logic of traversing MX
+   candidate lists.  Because an MTA-STS Policy can be used to prefilter
+   invalid MX candidates from the MX candidate list, it is tempting to
+   implement a "two-pass" model, where MX candidates are first filtered
+   for possible validity according to the MTA-STS Policy, and then the
+   remaining candidates are attempted in order as without an MTA-STS
+   Policy.  This may lead to incorrect implementations, such as message
+   loops; instead, it is recommended that implementers traverse the MX
+   candidate list as usual, and treat invalid candidates as though they
+   were unreachable (i.e., as though there were some transient error
+   when trying to deliver to that candidate).
+
+   One consequence of validating MX hosts in order of ordinary candidate
+   traversal is that in the event a higher-priority MX is MTA-STS valid
+   and a lower-priority MX is not, senders may never encounter the
+   lower-priority MX, leading to a risk that policy misconfigurations
+   that apply only to "backup" MXes may only be discovered in the case
+   of primary MX failure.
+
+9.  IANA Considerations
+
+9.1.  Well-Known URIs Registry
+
+   A new "well-known" URI as described in Section 3 has been registered
+   in the "Well-Known URIs" registry as described below:
+
+   URI Suffix: mta-sts.txt
+
+   Change Controller: IETF
+
+9.2.  MTA-STS TXT Record Fields
+
+   IANA has created a new registry titled "MTA-STS TXT Record Fields".
+   The initial entries in the registry are:
+
+       +------------+--------------------+-------------------------+
+       | Field Name | Description        | Reference               |
+       +------------+--------------------+-------------------------+
+       | v          | Record version     | Section 3.1 of RFC 8461 |
+       | id         | Policy instance ID | Section 3.1 of RFC 8461 |
+       +------------+--------------------+-------------------------+
+
+   New fields are added to this registry using IANA's "Expert Review"
+   policy [RFC8126].
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 17]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+9.3.  MTA-STS Policy Fields
+
+   IANA has created a new registry titled "MTA-STS Policy Fields".  The
+   initial entries in the registry are:
+
+      +------------+----------------------+-------------------------+
+      | Field Name | Description          | Reference               |
+      +------------+----------------------+-------------------------+
+      | version    | Policy version       | Section 3.2 of RFC 8461 |
+      | mode       | Enforcement behavior | Section 3.2 of RFC 8461 |
+      | max_age    | Policy lifetime      | Section 3.2 of RFC 8461 |
+      | mx         | MX identities        | Section 3.2 of RFC 8461 |
+      +------------+----------------------+-------------------------+
+
+   New fields are added to this registry using IANA's "Expert Review"
+   policy.
+
+10.  Security Considerations
+
+   SMTP MTA-STS attempts to protect against an active attacker trying to
+   intercept or tamper with mail between hosts that support STARTTLS.
+   There are two classes of attacks considered:
+
+   o  Foiling TLS negotiation (for example, by deleting the "250
+      STARTTLS" response from a server or altering TLS session
+      negotiation).  This would result in the SMTP session occurring
+      over plaintext, despite both parties supporting TLS.
+
+   o  Impersonating the destination mail server, whereby the sender
+      might deliver the message to an impostor, who could then monitor
+      and/or modify messages despite opportunistic TLS.  This
+      impersonation could be accomplished by spoofing the DNS MX record
+      for the recipient domain or by redirecting client connections
+      intended for the legitimate recipient server (for example, by
+      altering BGP routing tables).
+
+   MTA-STS can thwart such attacks only if the sender is able to
+   previously obtain and cache a policy for the recipient domain, and
+   only if the attacker is unable to obtain a valid certificate that
+   complies with that policy.  Below, we consider specific attacks on
+   this model.
+
+10.1.  Obtaining a Signed Certificate
+
+   SMTP MTA-STS relies on certificate validation via PKIX-based TLS
+   identity checking [RFC6125].  Attackers who are able to obtain a
+   valid certificate for the targeted recipient mail service (e.g., by
+   compromising a CA) are thus able to circumvent STS authentication.
+
+
+
+Margolis, et al.             Standards Track                   [Page 18]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+10.2.  Preventing Policy Discovery
+
+   Since MTA-STS uses DNS TXT records for policy discovery, an attacker
+   who is able to block DNS responses can suppress the discovery of an
+   MTA-STS Policy, making the Policy Domain appear not to have an MTA-
+   STS Policy.  The sender policy cache is designed to resist this
+   attack by decreasing the frequency of policy discovery and thus
+   reducing the window of vulnerability; it is nonetheless a risk that
+   attackers who can predict or induce policy discovery -- for example,
+   by inducing a sending domain to send mail to a never-before-contacted
+   recipient while carrying out a man-in-the-middle attack -- may be
+   able to foil policy discovery and effectively downgrade the security
+   of the message delivery.
+
+   Since this attack depends upon intercepting initial policy discovery,
+   implementers SHOULD prefer policy "max_age" values to be as long as
+   is practical.
+
+   Because this attack is also possible upon refresh of a cached policy,
+   implementers SHOULD NOT wait until a cached policy has expired before
+   checking for an update; if senders attempt to refresh the cache
+   regularly (for example, by fetching the current live policy in a
+   background task that runs daily or weekly, regardless of the state of
+   the "_mta-sts" TXT record, and updating their cache's "max age"
+   accordingly), an attacker would have to foil policy discovery
+   consistently over the lifetime of a cached policy to prevent a
+   successful refresh.
+
+   Additionally, MTAs SHOULD alert administrators to repeated policy
+   refresh failures long before cached policies expire (through warning
+   logs or similar applicable mechanisms), allowing administrators to
+   detect such a persistent attack on policy refresh.  (However, they
+   should not implement such alerts if the cached policy has a "none"
+   mode, to allow clean MTA-STS removal, as described in Section 8.3.)
+
+   Resistance to downgrade attacks of this nature -- due to the ability
+   to authoritatively determine "lack of a record" even for non-
+   participating recipients -- is a feature of DANE, due to its use of
+   DNSSEC for policy discovery.
+
+10.3.  Denial of Service
+
+   We additionally consider the Denial-of-Service risk posed by an
+   attacker who can modify the DNS records for a recipient domain.
+   Absent MTA-STS, such an attacker can cause a Sending MTA to cache
+   invalid MX records, but only for however long the sending resolver
+   caches those records.  With MTA-STS, the attacker can additionally
+   advertise a new, long "max_age" MTA-STS Policy with "mx" constraints
+
+
+
+Margolis, et al.             Standards Track                   [Page 19]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   that validate the malicious MX record, causing senders to cache the
+   policy and refuse to deliver messages once the victim has resecured
+   the MX records.
+
+   This attack is mitigated in part by the ability of a victim domain to
+   (at any time) publish a new policy updating the cached, malicious
+   policy, though this does require the victim domain to both obtain a
+   valid CA-signed certificate and to understand and properly configure
+   MTA-STS.
+
+   Similarly, we consider the possibility of domains that deliberately
+   allow untrusted users to serve untrusted content on user-specified
+   subdomains.  In some cases (e.g., the service "tumblr.com"), this
+   takes the form of providing HTTPS hosting of user-registered
+   subdomains; in other cases (e.g. dynamic DNS providers), this takes
+   the form of allowing untrusted users to register custom DNS records
+   at the provider's domain.
+
+   In these cases, there is a risk that untrusted users would be able to
+   serve custom content at the "mta-sts" host, including serving an
+   illegitimate MTA-STS Policy.  We believe this attack is rendered more
+   difficult by the need for the attacker to also serve the "_mta-sts"
+   TXT record on the same domain -- something not, to our knowledge,
+   widely provided to untrusted users.  This attack is additionally
+   mitigated by the aforementioned ability for a victim domain to update
+   an invalid policy at any future date.
+
+10.4.  Weak Policy Constraints
+
+   Even if an attacker cannot modify a served policy, the potential
+   exists for configurations that allow attackers on the same domain to
+   receive mail for that domain.  For example, an easy configuration
+   option when authoring an MTA-STS Policy for "example.com" is to set
+   the "mx" equal to "*.example.com"; in this case, recipient domains
+   must consider the risk that any user possessing a valid hostname and
+   CA-signed certificate (for example, "dhcp-123.example.com") will,
+   from the perspective of MTA-STS Policy validation, be a valid MX host
+   for that domain.
+
+10.5.  Compromise of the Web PKI System
+
+   A number of risks apply to the PKI system that is used for
+   certificate authentication, both of the "mta-sts" HTTPS host's
+   certificate and the SMTP servers' certificates.  These risks are
+   broadly applicable within the Web PKI ecosystem and are not specific
+   to MTA-STS; nonetheless, they deserve some consideration in this
+   context.
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 20]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   Broadly speaking, attackers may compromise the system by obtaining
+   certificates under fraudulent circumstances (i.e., by impersonating
+   the legitimate owner of the victim domain), by compromising a CA or
+   Delegate Authority's private keys, by obtaining a legitimate
+   certificate issued to the victim domain, and similar.
+
+   One approach commonly employed by web browsers to help mitigate
+   against some of these attacks is to allow for revocation of
+   compromised or fraudulent certificates via OCSP [RFC6960] or CRLs
+   [RFC6818].  Such mechanisms themselves represent trade-offs and are
+   not universally implemented; we nonetheless recommend implementers of
+   MTA-STS to implement revocation mechanisms that are most applicable
+   to their implementations.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
+              DOI 10.17487/RFC2818, May 2000,
+              <https://www.rfc-editor.org/info/rfc2818>.
+
+   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
+              Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
+              February 2002, <https://www.rfc-editor.org/info/rfc3207>.
+
+   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
+              for Internationalized Domain Names in Applications
+              (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
+              <https://www.rfc-editor.org/info/rfc3492>.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+              2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 21]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+              DOI 10.17487/RFC5321, October 2008,
+              <https://www.rfc-editor.org/info/rfc5321>.
+
+   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+              Uniform Resource Identifiers (URIs)", RFC 5785,
+              DOI 10.17487/RFC5785, April 2010,
+              <https://www.rfc-editor.org/info/rfc5785>.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              DOI 10.17487/RFC6066, January 2011,
+              <https://www.rfc-editor.org/info/rfc6066>.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
+              2011, <https://www.rfc-editor.org/info/rfc6125>.
+
+   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF",
+              RFC 7405, DOI 10.17487/RFC7405, December 2014,
+              <https://www.rfc-editor.org/info/rfc7405>.
+
+   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
+              "Recommendations for Secure Use of Transport Layer
+              Security (TLS) and Datagram Transport Layer Security
+              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
+              2015, <https://www.rfc-editor.org/info/rfc7525>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 22]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8460]  Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J.,
+              and M. Risher, "SMTP TLS Reporting", RFC 8460,
+              DOI 10.17487/RFC8460, September 2018,
+              <https://www.rfc-editor.org/info/rfc8460>.
+
+11.2.  Informative References
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <https://www.rfc-editor.org/info/rfc4033>.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              DOI 10.17487/RFC5322, October 2008,
+              <https://www.rfc-editor.org/info/rfc5322>.
+
+   [RFC5891]  Klensin, J., "Internationalized Domain Names in
+              Applications (IDNA): Protocol", RFC 5891,
+              DOI 10.17487/RFC5891, August 2010,
+              <https://www.rfc-editor.org/info/rfc5891>.
+
+   [RFC6818]  Yee, P., "Updates to the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January
+              2013, <https://www.rfc-editor.org/info/rfc6818>.
+
+   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
+              Galperin, S., and C. Adams, "X.509 Internet Public Key
+              Infrastructure Online Certificate Status Protocol - OCSP",
+              RFC 6960, DOI 10.17487/RFC6960, June 2013,
+              <https://www.rfc-editor.org/info/rfc6960>.
+
+   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
+              RFC 7234, DOI 10.17487/RFC7234, June 2014,
+              <https://www.rfc-editor.org/info/rfc7234>.
+
+   [RFC7672]  Dukhovni, V. and W. Hardaker, "SMTP Security via
+              Opportunistic DNS-Based Authentication of Named Entities
+              (DANE) Transport Layer Security (TLS)", RFC 7672,
+              DOI 10.17487/RFC7672, October 2015,
+              <https://www.rfc-editor.org/info/rfc7672>.
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 23]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 24]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+Appendix A.  MTA-STS Example Record and Policy
+
+   The owner of "example.com" wishes to begin using MTA-STS with a
+   policy that will solicit reports from senders without affecting how
+   the messages are processed, in order to verify the identity of MXes
+   that handle mail for "example.com", confirm that TLS is correctly
+   used, and ensure that certificates presented by the recipient MX
+   validate.
+
+   MTA-STS Policy indicator TXT RR:
+
+       _mta-sts.example.com.  IN TXT "v=STSv1; id=20160831085700Z;"
+
+   MTA-STS Policy file served as the response body at
+   "https://mta-sts.example.com/.well-known/mta-sts.txt":
+
+                         version: STSv1
+                         mode: testing
+                         mx: mx1.example.com
+                         mx: mx2.example.com
+                         mx: mx.backup-example.com
+                         max_age: 1296000
+
+Appendix B.  Message Delivery Pseudocode
+
+   Below is pseudocode demonstrating the logic of a compliant Sending
+   MTA.
+
+   While this pseudocode implementation suggests synchronous policy
+   retrieval in the delivery path, that may be undesirable in a working
+   implementation, and we expect some implementers to instead prefer a
+   background fetch that does not block delivery when no cached policy
+   is present.
+
+
+   func isEnforce(policy) {
+     // Return true if the policy mode is "enforce".
+   }
+
+   func isNonExpired(policy) {
+     // Return true if the policy is not expired.
+   }
+
+   func tryStartTls(connection) {
+     // Attempt to open an SMTP STARTTLS connection with the MX.
+   }
+
+   func certMatches(connection, host) {
+
+
+
+Margolis, et al.             Standards Track                   [Page 25]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+     // Assume a handy function to return if the server
+     // certificate presented in "connection" is valid for "host".
+   }
+
+   func policyMatches(candidate, policy) {
+     for mx in policy.mx {
+       // Literal match.
+       if mx == candidate {
+         return true
+       }
+       // Wildcard matches only the leftmost label.
+       // Wildcards must always be followed by a '.'.
+       if mx[0] == '*' {
+         parts = SplitN(candidate, '.', 2)  // Split on the first '.'.
+         if len(parts) > 1 && parts[1] == mx[2:] {
+           return true
+         }
+       }
+     }
+     return false
+   }
+
+   func tryDeliverMail(connection, message) {
+     // Attempt to deliver "message" via "connection".
+   }
+
+   func tryGetNewPolicy(domain) {
+     // Check for an MTA-STS TXT record for "domain" in DNS, and return
+     // the indicated policy.
+   }
+
+   func cachePolicy(domain, policy) {
+     // Store "policy" as the cached policy for "domain".
+   }
+
+   func tryGetCachedPolicy(domain) {
+     // Return a cached policy for "domain".
+   }
+
+   func reportError(error) {
+     // Report an error via TLSRPT.
+   }
+
+   func tryMxAccordingTo(message, mx, policy) {
+     connection := connect(mx)
+     if !connection {
+       return false  // Can't connect to the MX, so it's not an MTA-STS
+                     // error.
+
+
+
+Margolis, et al.             Standards Track                   [Page 26]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+     }
+     secure := true
+     if !policyMatches(mx, policy) {
+       secure = false
+       reportError(E_HOST_MISMATCH)
+     } else if !tryStartTls(connection) {
+       secure = false
+       reportError(E_NO_VALID_TLS)
+     } else if !certMatches(connection, policy) {
+       secure = false
+       reportError(E_CERT_MISMATCH)
+     }
+     if secure || !isEnforce(policy) {
+       return tryDeliverMail(connection, message)
+     }
+     return false
+   }
+
+   func tryWithPolicy(message, domain, policy) {
+     mxes := getMxForDomain(domain)
+     for mx in mxes {
+       if tryMxAccordingTo(message, mx, policy) {
+         return true
+       }
+     }
+     return false
+   }
+
+   func handleMessage(message) {
+     domain := ... // domain part after '@' from recipient
+     policy := tryGetNewPolicy(domain)
+     if policy {
+       cachePolicy(domain, policy)
+     } else {
+       policy = tryGetCachedPolicy(domain)
+     }
+     if policy {
+       return tryWithPolicy(message, domain, policy)
+     }
+     // Try to deliver the message normally (i.e., without MTA-STS).
+   }
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 27]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+Contributors
+
+   Wei Chuang
+   Google, Inc.
+   weihaw@google.com
+
+   Viktor Dukhovni
+   ietf-dane@dukhovni.de
+
+   Markus Laber
+   1&1 Mail & Media Development & Technology GmbH
+   markus.laber@1und1.de
+
+   Nicolas Lidzborski
+   Google, Inc.
+   nlidz@google.com
+
+   Brandon Long
+   Google, Inc.
+   blong@google.com
+
+   Franck Martin
+   LinkedIn, Inc.
+   fmartin@linkedin.com
+
+   Klaus Umbach
+   1&1 Mail & Media Development & Technology GmbH
+   klaus.umbach@1und1.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 28]
+
+RFC 8461                         MTA-STS                  September 2018
+
+
+Authors' Addresses
+
+   Daniel Margolis
+   Google, Inc.
+
+   Email: dmargolis@google.com
+
+
+   Mark Risher
+   Google, Inc.
+
+   Email: risher@google.com
+
+
+   Binu Ramakrishnan
+   Oath, Inc.
+
+   Email: prbinu@yahoo.com
+
+
+   Alexander Brotman
+   Comcast, Inc.
+
+   Email: alex_brotman@comcast.com
+
+
+   Janet Jones
+   Microsoft, Inc.
+
+   Email: janet.jones@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Margolis, et al.             Standards Track                   [Page 29]
+