7Internet Engineering Task Force (IETF) D. Margolis
8Request for Comments: 8461 M. Risher
9Category: Standards Track Google, Inc.
10ISSN: 2070-1721 B. Ramakrishnan
19 SMTP MTA Strict Transport Security (MTA-STS)
23 SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling
24 mail service providers (SPs) to declare their ability to receive
25 Transport Layer Security (TLS) secure SMTP connections and to specify
26 whether sending SMTP servers should refuse to deliver to MX hosts
27 that do not offer TLS with a trusted server certificate.
31 This is an Internet Standards Track document.
33 This document is a product of the Internet Engineering Task Force
34 (IETF). It represents the consensus of the IETF community. It has
35 received public review and has been approved for publication by the
36 Internet Engineering Steering Group (IESG). Further information on
37 Internet Standards is available in Section 2 of RFC 7841.
39 Information about the current status of this document, any errata,
40 and how to provide feedback on it may be obtained at
41 https://www.rfc-editor.org/info/rfc8461.
58Margolis, et al. Standards Track [Page 1]
60RFC 8461 MTA-STS September 2018
65 Copyright (c) 2018 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (https://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
114Margolis, et al. Standards Track [Page 2]
116RFC 8461 MTA-STS September 2018
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
122 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
123 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5
124 3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 5
125 3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 6
126 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 7
127 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 10
128 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 11
129 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 11
130 4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 12
131 4.2. Recipient MTA Certificate Validation . . . . . . . . . . 12
132 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 12
133 5.1. Policy Application Control Flow . . . . . . . . . . . . . 13
134 6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 13
135 7. Interoperability Considerations . . . . . . . . . . . . . . . 14
136 7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 14
137 7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 14
138 8. Operational Considerations . . . . . . . . . . . . . . . . . 15
139 8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 15
140 8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 15
141 8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 16
142 8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 17
143 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
144 9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 17
145 9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 17
146 9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 18
147 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
148 10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 18
149 10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 19
150 10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 19
151 10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 20
152 10.5. Compromise of the Web PKI System . . . . . . . . . . . . 20
153 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
154 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
155 11.2. Informative References . . . . . . . . . . . . . . . . . 23
156 Appendix A. MTA-STS Example Record and Policy . . . . . . . . . 25
157 Appendix B. Message Delivery Pseudocode . . . . . . . . . . . . 25
158 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
170Margolis, et al. Standards Track [Page 3]
172RFC 8461 MTA-STS September 2018
177 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
178 hosts to negotiate the use of a TLS channel for encrypted mail
181 While this opportunistic encryption protocol by itself provides a
182 high barrier against passive man-in-the-middle traffic interception,
183 any attacker who can delete parts of the SMTP session (such as the
184 "250 STARTTLS" response) or who can redirect the entire SMTP session
185 (perhaps by overwriting the resolved MX record of the delivery
186 domain) can perform downgrade or interception attacks.
188 This document defines a mechanism for recipient domains to publish
189 policies, via a combination of DNS and HTTPS, specifying:
191 o whether MTAs sending mail to this domain can expect PKIX-
192 authenticated TLS support
194 o what a conforming client should do with messages when TLS cannot
195 be successfully negotiated
199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
201 "OPTIONAL" in this document are to be interpreted as described in
202 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
203 capitals, as shown here.
205 We also define the following terms for further use in this document:
207 o MTA-STS Policy: A commitment by the Policy Domain to support TLS
208 authenticated with PKIX [RFC5280] for the specified MX hosts.
210 o Policy Domain: The domain for which an MTA-STS Policy is defined.
211 This is the next-hop domain; when sending mail to
212 "alice@example.com", this would ordinarily be "example.com", but
213 this may be overridden by explicit routing rules (as described in
214 Section 3.4, "Policy Selection for Smart Hosts and Subdomains").
216 o Policy Host: The HTTPS host that serves the MTA-STS Policy for a
217 Policy Domain. Rules for constructing the hostname are described
218 in Section 3.2, "MTA-STS Policies".
220 o Sender or Sending MTA: The SMTP MTA sending an email message.
226Margolis, et al. Standards Track [Page 4]
228RFC 8461 MTA-STS September 2018
231 o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying
232 syntax, defined in [RFC5234] and [RFC7405].
2342. Related Technologies
236 The DNS-Based Authentication of a Named Entities (DANE) TLSA record
237 [RFC7672] is similar, in that DANE is also designed to upgrade
238 unauthenticated encryption or plaintext transmission into
239 authenticated, downgrade-resistant encrypted transmission. DANE
240 requires DNSSEC [RFC4033] for authentication; the mechanism described
241 here instead relies on certification authorities (CAs) and does not
242 require DNSSEC, at a cost of risking malicious downgrades. For a
243 thorough discussion of this trade-off, see Section 10, "Security
246 In addition, MTA-STS provides an optional testing-only mode, enabling
247 soft deployments to detect policy failures; partial deployments can
248 be achieved in DANE by deploying TLSA records only for some of a
249 domain's MXes, but such a mechanism is not possible for the per-
250 domain policies used by MTA-STS.
252 The primary motivation of MTA-STS is to provide a mechanism for
253 domains to ensure transport security even when deploying DNSSEC is
254 undesirable or impractical. However, MTA-STS is designed not to
255 interfere with DANE deployments when the two overlap; in particular,
256 senders who implement MTA-STS validation MUST NOT allow MTA-STS
257 Policy validation to override a failing DANE validation.
261 MTA-STS policies are distributed via HTTPS from a "well-known"
262 [RFC5785] path served within the Policy Domain, and their presence
263 and current version are indicated by a TXT record at the Policy
264 Domain. These TXT records additionally contain a policy "id" field,
265 allowing Sending MTAs to check that a cached policy is still current
266 without performing an HTTPS request.
268 To discover if a recipient domain implements MTA-STS, a sender need
269 only resolve a single TXT record. To see if an updated policy is
270 available for a domain for which the sender has a previously cached
271 policy, the sender need only check the TXT record's version "id"
272 against the cached value.
282Margolis, et al. Standards Track [Page 5]
284RFC 8461 MTA-STS September 2018
2873.1. MTA-STS TXT Records
290 the Policy Domain. For the domain "example.com", this record would
291 be "_mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII,
292 semicolon-separated key/value pairs containing the following fields:
294 o "v" (plaintext, required): Currently, only "STSv1" is supported.
296 o "id" (plaintext, required): A short string used to track policy
297 updates. This string MUST uniquely identify a given instance of a
298 policy, such that senders can determine when the policy has been
299 updated by comparing to the "id" of a previously seen policy.
300 There is no implied ordering of "id" fields between revisions.
302 An example TXT record is as below:
304 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
307 ABNF [RFC7405], is as follows:
309 sts-text-record = sts-version 1*(sts-field-delim sts-field)
312 sts-field = sts-id / ; Note that sts-id record
313 sts-extension ; is required.
317 sts-version = %s"v=STSv1"
321 sts-extension = sts-ext-name "=" sts-ext-value ; name=value
323 sts-ext-name = (ALPHA / DIGIT)
324 *31(ALPHA / DIGIT / "_" / "-" / ".")
327 ; chars excluding "=", ";", SP, and CTLs
329 The TXT record MUST begin with the sts-version field; the order of
330 other fields is not significant. If multiple TXT records for
332 with "v=STSv1;" are discarded. If the number of resulting records is
334 MUST assume the recipient domain does not have an available MTA-STS
338Margolis, et al. Standards Track [Page 6]
340RFC 8461 MTA-STS September 2018
343 Policy and skip the remaining steps of policy discovery. (Note that
344 the absence of a usable TXT record is not by itself sufficient to
345 remove a sender's previously cached policy for the Policy Domain, as
346 discussed in Section 5.1, "Policy Application Control Flow".) If the
347 resulting TXT record contains multiple strings, then the record MUST
348 be treated as if those strings are concatenated without adding
352 other CNAMEs) to a TXT record, in which case senders MUST follow the
353 CNAME pointers. This can be used for policy delegation, as described
358 The policy itself is a set of key/value pairs (similar to header
359 fields in [RFC5322]) served via the HTTPS GET method from the fixed
360 "well-known" [RFC5785] path of ".well-known/mta-sts.txt" served by
361 the Policy Host. The Policy Host DNS name is constructed by
362 prepending "mta-sts" to the Policy Domain.
364 Thus, for a Policy Domain of "example.com", the full URL is
365 "https://mta-sts.example.com/.well-known/mta-sts.txt".
368 is "text/plain" to guard against cases where web servers allow
369 untrusted users to host non-text content (typically, HTML or images)
370 at a user-defined path. All parameters other than charset=utf-8 or
371 charset=us-ascii are ignored. Additional "Content-Type" parameters
374 This resource contains the following CRLF-separated key/value pairs:
376 o "version": Currently, only "STSv1" is supported.
378 o "mode": One of "enforce", "testing", or "none", indicating the
379 expected behavior of a Sending MTA in the case of a policy
380 validation failure. See Section 5, "Policy Application", for more
381 details about the three modes.
383 o "max_age": Max lifetime of the policy (plaintext non-negative
384 integer seconds, maximum value of 31557600). Well-behaved clients
385 SHOULD cache a policy for up to this value from the last policy
386 fetch time. To mitigate the risks of attacks at policy refresh
387 time, it is expected that this value typically be in the range of
394Margolis, et al. Standards Track [Page 7]
396RFC 8461 MTA-STS September 2018
399 o "mx": Allowed MX patterns. One or more patterns matching allowed
400 MX hosts for the Policy Domain. As an example,
402 mx: mail.example.com <CRLF>
405 indicates that mail for this domain might be handled by MX
406 "mail.example.com" or any MX at "example.net". Valid patterns can be
407 either fully specified names ("example.com") or suffixes prefixed by
408 a wildcard ("*.example.net"). If a policy specifies more than one
409 MX, each MX MUST have its own "mx:" key, and each MX key/value pair
410 MUST be on its own line in the policy file. In the case of
412 the Punycode-encoded A-label [RFC3492] to match against, and not the
413 Unicode-encoded U-label. The full semantics of certificate
414 validation (including the use of wildcard patterns) are described in
415 Section 4.1, "MX Host Validation".
417 An example policy is as below:
423 mx: backupmx.example.com
427 [RFC7405], is as follows:
429sts-policy-record = sts-policy-field *WSP
430 *(sts-policy-term sts-policy-field *WSP)
433sts-policy-field = sts-policy-version / ; required once
434 sts-policy-mode / ; required once
435 sts-policy-max-age / ; required once
439 sts-policy-extension ; other fields
441sts-policy-field-delim = ":" *WSP
443sts-policy-version = sts-policy-version-field sts-policy-field-delim
444 sts-policy-version-value
446sts-policy-version-field = %s"version"
450Margolis, et al. Standards Track [Page 8]
452RFC 8461 MTA-STS September 2018
455sts-policy-version-value = %s"STSv1"
457sts-policy-mode = sts-policy-mode-field sts-policy-field-delim
458 sts-policy-mode-value
460sts-policy-mode-field = %s"mode"
462sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none"
464sts-policy-mx = sts-policy-mx-field sts-policy-field-delim
467sts-policy-mx-field = %s"mx"
471sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim
472 sts-policy-max-age-value
474sts-policy-max-age-field = %s"max_age"
478sts-policy-extension = sts-policy-ext-name ; additional
479 sts-policy-field-delim ; extension
480 sts-policy-ext-value ; fields
483 *31(sta-policy-alphanum / "_" / "-" / ".")
488 [*(%x20 / sts-policy-vchar)
490 ; chars, including UTF-8 [RFC3629],
491 ; excluding CTLs and no
492 ; leading/trailing spaces
494sts-policy-alphanum = ALPHA / DIGIT
496sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4
498UTF8-2 = <Defined in Section 4 of [RFC3629]>
500UTF8-3 = <Defined in Section 4 of [RFC3629]>
502UTF8-4 = <Defined in Section 4 of [RFC3629]>
506Margolis, et al. Standards Track [Page 9]
508RFC 8461 MTA-STS September 2018
511Domain = <Defined in Section 4.1.2 of [RFC5321]>
513 Parsers MUST accept TXT records and policy files that are
514 syntactically valid (i.e., valid key/value pairs separated by
515 semicolons for TXT records), possibly containing additional key/value
516 pairs not specified in this document, in which case unknown fields
518 excepting "mx" -- is duplicated, all entries except for the first
5213.3. HTTPS Policy Fetching
523 Policy bodies are, as described above, retrieved by Sending MTAs via
525 or updated policy from the Policy Host, the Policy Host HTTPS server
526 MUST present an X.509 certificate that is valid for the "mta-sts"
527 DNS-ID [RFC6125] (e.g., "mta-sts.example.com") as described below,
528 chain to a root CA that is trusted by the Sending MTA, and be non-
529 expired. It is expected that Sending MTAs use a set of trusted CAs
530 similar to those in widely deployed web browsers and operating
531 systems. See [RFC5280] for more details about certificate
534 The certificate is valid for the Policy Host (i.e., "mta-sts"
535 prepended to the Policy Domain) with respect to the rules described
536 in [RFC6125], with the following application-specific considerations:
538 o Matching is performed only against the DNS-ID identifiers.
540 o DNS domain names in server certificates MAY contain the wildcard
541 character '*' as the complete left-most label within the
544 The certificate MAY be checked for revocation via the Online
545 Certificate Status Protocol (OCSP) [RFC6960], certificate revocation
546 lists (CRLs), or some other mechanism.
550 caching (as specified in [RFC7234]) MUST NOT be used.
553 HTTPS endpoint even if a valid TXT record for the recipient domain
554 exists. In the case where the HTTPS GET fails, implementers SHOULD
556 version ID, to avoid overwhelming resource-constrained recipients
557 with cascading failures.
562Margolis, et al. Standards Track [Page 10]
564RFC 8461 MTA-STS September 2018
567 Senders MAY impose a timeout on the HTTPS GET and/or a limit on the
568 maximum size of the response body to avoid long delays or resource
571 Policy Hosts SHOULD respond to requests with a complete policy body
572 within that timeout and size limit.
575 (for any reason), and there is no valid (non-expired) previously
576 cached policy, senders MUST continue with delivery as though the
577 domain has not implemented MTA-STS.
579 Conversely, if no "live" policy can be discovered via DNS or fetched
580 via HTTPS, but a valid (non-expired) policy exists in the sender's
581 cache, the sender MUST apply that cached policy.
584 refresh, as discussed in-depth in Section 10, MTAs SHOULD proactively
585 refresh cached policies before they expire; a suggested refresh
586 frequency is once per day. To enable administrators to discover
588 (through the use of logs or similar) when such attempts fail, unless
589 the cached policy mode is "none".
5913.4. Policy Selection for Smart Hosts and Subdomains
593 When sending mail via a "smart host" -- an administratively
594 configured intermediate SMTP relay, which is different from the
595 message recipient's server as determined from DNS -- compliant
596 senders MUST treat the smart host domain as the Policy Domain for the
597 purposes of policy discovery and application. This specification
598 does not provide a means of associating policies with email addresses
599 that employ Address Literals [RFC5321].
601 When sending mail to a mailbox at a subdomain, compliant senders MUST
602 NOT attempt to fetch a policy from the parent zone. Thus, for mail
603 sent to "user@mail.example.com", the policy can be fetched only from
604 "mail.example.com", not "example.com".
608 When sending to an MX at a domain for which the sender has a valid
609 and non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS MUST
612 1. At least one of the policy's "mx" patterns matches the selected
613 MX host, as described in Section 4.1, "MX Host Validation".
618Margolis, et al. Standards Track [Page 11]
620RFC 8461 MTA-STS September 2018
623 2. The recipient mail server supports STARTTLS and offers a PKIX-
624 based TLS certificate, during TLS handshake, which is valid for
625 that host, as described in Section 4.2, "Recipient MTA
626 Certificate Validation".
628 When these conditions are not met, a policy is said to fail to
629 validate. This section does not dictate the behavior of Sending MTAs
630 when the above conditions are not met; see Section 5, "Policy
631 Application", for a description of Sending MTA behavior when policy
6344.1. MX Host Validation
637 STS Policy if the MX record name matches one or more of the "mx"
638 fields in the applied policy. Matching is identical to the rules
639 given in [RFC6125], with the restriction that the wildcard character
640 '*' may only be used to match the entire left-most label in the
641 presented identifier. Thus, the mx pattern "*.example.com" matches
642 "mail.example.com" but not "example.com" or "foo.bar.example.com".
6444.2. Recipient MTA Certificate Validation
646 The certificate presented by the receiving MTA MUST not be expired
647 and MUST chain to a root CA that is trusted by the Sending MTA. The
648 certificate MUST have a subject alternative name (SAN) [RFC5280] with
649 a DNS-ID [RFC6125] matching the hostname, per the rules given in
650 [RFC6125]. The MX's certificate MAY also be checked for revocation
651 via OCSP [RFC6960], CRLs [RFC6818], or some other mechanism.
656 non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS applies
657 the result of a policy validation failure in one of two ways,
658 depending on the value of the policy "mode" field:
660 1. "enforce": In this mode, Sending MTAs MUST NOT deliver the
661 message to hosts that fail MX matching or certificate validation
662 or that do not support STARTTLS.
664 2. "testing": In this mode, Sending MTAs that also implement the
665 TLSRPT (TLS Reporting) specification [RFC8460] send a report
666 indicating policy application failures (as long as TLSRPT is also
667 implemented by the recipient domain); in any case, messages may
668 be delivered as though there were no MTA-STS validation failure.
674Margolis, et al. Standards Track [Page 12]
676RFC 8461 MTA-STS September 2018
679 3. "none": In this mode, Sending MTAs should treat the Policy Domain
680 as though it does not have any active policy; see Section 8.3,
681 "Removing MTA-STS", for use of this mode value.
683 When a message fails to deliver due to an "enforce" policy, a
684 compliant MTA MUST NOT permanently fail to deliver messages before
685 checking, via DNS, for the presence of an updated policy at the
686 Policy Domain. (In all cases, MTAs SHOULD treat such failures as
687 transient errors and retry delivery later.) This allows implementing
688 domains to update long-lived policies on the fly.
6905.1. Policy Application Control Flow
692 An example control flow for a compliant sender consists of the
695 1. Check for a cached policy whose time-since-fetch has not exceeded
696 its "max_age". If none exists, attempt to fetch a new policy
697 (perhaps asynchronously, so as not to block message delivery).
698 Optionally, Sending MTAs may unconditionally check for a new
701 2. For each candidate MX, in order of MX priority, attempt to
702 deliver the message. If a policy is present with an "enforce"
703 mode, when attempting to deliver to each candidate MX, ensure
704 STARTTLS support and host identity validity as described in
705 Section 4, "Policy Validation". If a candidate fails validation,
706 continue to the next candidate (if there is one).
708 3. A message delivery attempt MUST NOT be permanently failed until
709 the sender has first checked for the presence of a new policy (as
710 indicated by the "id" field in the "_mta-sts" TXT record). If a
711 new policy is not found, existing rules for the case of temporary
712 message delivery failures apply (as discussed in [RFC5321],
717 MTA-STS is intended to be used along with TLSRPT [RFC8460] in order
718 to ensure that implementing domains can detect cases of both benign
719 and malicious failures and to ensure that failures that indicate an
720 active attack are discoverable. As such, senders that also implement
721 TLSRPT SHOULD treat the following events as reportable failures:
723 o HTTPS policy fetch failures when a valid TXT record is present.
725 o Policy fetch failures of any kind when a valid policy exists in
726 the policy cache, except if that policy's mode is "none".
730Margolis, et al. Standards Track [Page 13]
732RFC 8461 MTA-STS September 2018
735 o Delivery attempts in which a contacted MX does not support
736 STARTTLS or does not present a certificate that validates
737 according to the applied policy, except if that policy's mode is
7407. Interoperability Considerations
744 To ensure that the server sends the right certificate chain, the SMTP
745 client MUST have support for the TLS Server Name Indication (SNI)
746 extension [RFC6066]. When connecting to an HTTP server to retrieve
747 the MTA-STS Policy, the SNI extension MUST contain the name of the
748 Policy Host (e.g., "mta-sts.example.com"). When connecting to an
749 SMTP server, the SNI extension MUST contain the MX hostname.
751 HTTP servers used to deliver MTA-STS policies MAY rely on SNI to
752 determine which certificate chain to present to the client. HTTP
753 servers MUST respond with a certificate chain that matches the policy
754 hostname or abort the TLS handshake if unable to do so. Clients that
755 do not send SNI information may not see the expected certificate
758 SMTP servers MAY rely on SNI to determine which certificate chain to
759 present to the client. However, servers that have one identity and a
760 single matching certificate do not require SNI support. Servers MUST
761 NOT enforce the use of SNI by clients, as the client may be using
762 unauthenticated opportunistic TLS and may not expect any particular
763 certificate from the server. If the client sends no SNI extension or
764 sends an SNI extension for an unsupported server name, the server
765 MUST simply send a fallback certificate chain of its choice. The
766 reason for not enforcing strict matching of the requested SNI
767 hostname is that MTA-STS TLS clients may be typically willing to
768 accept multiple server names but can only send one name in the SNI
769 extension. The server's fallback certificate may match a different
770 name that is acceptable to the client, e.g., the original next-hop
7737.2. Minimum TLS Version Support
775 MTAs supporting MTA-STS MUST have support for TLS 1.2 [RFC5246] or
776 TLS 1.3 [RFC8446] or higher. The general TLS usage guidance in
777 [RFC7525] SHOULD be followed.
786Margolis, et al. Standards Track [Page 14]
788RFC 8461 MTA-STS September 2018
7918. Operational Considerations
795 Updating the policy requires that the owner make changes in two
796 places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and
797 at the corresponding HTTPS endpoint. As a result, recipients should
798 expect that a policy will continue to be used by senders until both
799 the HTTPS and TXT endpoints are updated and the TXT record's TTL has
802 In other words, a sender who is unable to successfully deliver a
803 message while applying a cache of the recipient's now-outdated policy
804 may be unable to discover that a new policy exists until the DNS TTL
805 has passed. Recipients SHOULD therefore ensure that old policies
806 continue to work for message delivery during this period of time, or
809 Recipients SHOULD also update the HTTPS policy body before updating
810 the TXT record; this ordering avoids the risk that senders, seeing a
811 new TXT record, mistakenly cache the old policy from HTTPS.
8138.2. Policy Delegation
815 Domain owners commonly delegate SMTP hosting to a different
816 organization, such as an ISP or a web host. In such a case, they may
817 wish to also delegate the MTA-STS Policy to the same organization,
818 which can be accomplished with two changes.
820 First, the Policy Domain must point the "_mta-sts" record, via CNAME,
821 to the "_mta-sts" record maintained by the provider. This allows the
822 provider to control update signaling.
824 Second, the Policy Domain must point the "well-known" policy location
825 to the provider. This can be done either by setting the "mta-sts"
826 record to an IP address or CNAME specified by the provider and by
827 giving the provider a TLS certificate that is valid for that host or
828 by setting up a "reverse proxy" (also known as a "gateway") server
829 for the Policy Domain's Policy Host, configured to serve proxied
830 responses from the Policy Host of the provider.
832 For example, given a user domain "user.example" hosted by a mail
833 provider "provider.example", the following configuration would allow
838 _mta-sts.user.example. IN CNAME _mta-sts.provider.example.
842Margolis, et al. Standards Track [Page 15]
844RFC 8461 MTA-STS September 2018
849 > GET /.well-known/mta-sts.txt Host: mta-sts.user.example
850 < HTTP/1.1 200 OK # Response proxies content from
851 # https://mta-sts.provider.example
853 Note that in all such cases, the policy endpoint
854 ("https://mta-sts.user.example/.well-known/mta-sts.txt" in this
855 example) must still present a certificate valid for the Policy Host
856 ("mta-sts.user.example"), and not for that host at the provider's
857 domain ("mta-sts.provider.example").
859 Note that while Sending MTAs MUST NOT use HTTP caching when fetching
860 policies via HTTPS, such caching may nonetheless be useful to a
861 reverse proxy configured as described in this section. An HTTPS
862 policy endpoint expecting to be proxied for multiple hosted domains
863 -- as with a large mail hosting provider or similar -- may wish to
864 indicate an HTTP Cache-Control "max-age" response directive (as
865 specified in [RFC7234]) of 60 seconds as a reasonable value to save
866 reverse proxies an unnecessarily high-rate of proxied policy
871 In order to facilitate clean opt-out of MTA-STS by implementing
872 Policy Domains, and to distinguish clearly between failures that
873 indicate attacks and those that indicate such opt-outs, MTA-STS
874 implements the "none" mode, which allows validated policies to
875 indicate authoritatively that the Policy Domain wishes to no longer
876 implement MTA-STS and may, in the future, remove the MTA-STS TXT and
877 policy endpoints entirely.
879 A suggested workflow to implement such an opt out is as follows:
881 1. Publish a new policy with "mode" equal to "none" and a small
882 "max_age" (e.g., one day).
884 2. Publish a new TXT record to trigger fetching of the new policy.
886 3. When all previously served policies have expired -- normally this
887 is the time the previously published policy was last served plus
888 that policy's "max_age", but note that policies older than the
889 previously published policy may have been served with a greater
890 "max_age" than the previously published policy, allowing
891 overlapping policy caches -- safely remove the TXT record and
898Margolis, et al. Standards Track [Page 16]
900RFC 8461 MTA-STS September 2018
9038.4. Preserving MX Candidate Traversal
905 Implementers of send-time MTA-STS validation in mail transfer agents
906 should take note of the risks of modifying the logic of traversing MX
907 candidate lists. Because an MTA-STS Policy can be used to prefilter
908 invalid MX candidates from the MX candidate list, it is tempting to
909 implement a "two-pass" model, where MX candidates are first filtered
910 for possible validity according to the MTA-STS Policy, and then the
911 remaining candidates are attempted in order as without an MTA-STS
912 Policy. This may lead to incorrect implementations, such as message
914 candidate list as usual, and treat invalid candidates as though they
915 were unreachable (i.e., as though there were some transient error
916 when trying to deliver to that candidate).
918 One consequence of validating MX hosts in order of ordinary candidate
919 traversal is that in the event a higher-priority MX is MTA-STS valid
920 and a lower-priority MX is not, senders may never encounter the
921 lower-priority MX, leading to a risk that policy misconfigurations
922 that apply only to "backup" MXes may only be discovered in the case
923 of primary MX failure.
9259. IANA Considerations
9279.1. Well-Known URIs Registry
929 A new "well-known" URI as described in Section 3 has been registered
930 in the "Well-Known URIs" registry as described below:
932 URI Suffix: mta-sts.txt
934 Change Controller: IETF
9369.2. MTA-STS TXT Record Fields
938 IANA has created a new registry titled "MTA-STS TXT Record Fields".
939 The initial entries in the registry are:
941 +------------+--------------------+-------------------------+
942 | Field Name | Description | Reference |
943 +------------+--------------------+-------------------------+
944 | v | Record version | Section 3.1 of RFC 8461 |
945 | id | Policy instance ID | Section 3.1 of RFC 8461 |
946 +------------+--------------------+-------------------------+
948 New fields are added to this registry using IANA's "Expert Review"
954Margolis, et al. Standards Track [Page 17]
956RFC 8461 MTA-STS September 2018
9599.3. MTA-STS Policy Fields
961 IANA has created a new registry titled "MTA-STS Policy Fields". The
962 initial entries in the registry are:
964 +------------+----------------------+-------------------------+
965 | Field Name | Description | Reference |
966 +------------+----------------------+-------------------------+
967 | version | Policy version | Section 3.2 of RFC 8461 |
968 | mode | Enforcement behavior | Section 3.2 of RFC 8461 |
969 | max_age | Policy lifetime | Section 3.2 of RFC 8461 |
970 | mx | MX identities | Section 3.2 of RFC 8461 |
971 +------------+----------------------+-------------------------+
973 New fields are added to this registry using IANA's "Expert Review"
97610. Security Considerations
978 SMTP MTA-STS attempts to protect against an active attacker trying to
979 intercept or tamper with mail between hosts that support STARTTLS.
980 There are two classes of attacks considered:
982 o Foiling TLS negotiation (for example, by deleting the "250
983 STARTTLS" response from a server or altering TLS session
984 negotiation). This would result in the SMTP session occurring
985 over plaintext, despite both parties supporting TLS.
987 o Impersonating the destination mail server, whereby the sender
988 might deliver the message to an impostor, who could then monitor
989 and/or modify messages despite opportunistic TLS. This
990 impersonation could be accomplished by spoofing the DNS MX record
991 for the recipient domain or by redirecting client connections
992 intended for the legitimate recipient server (for example, by
993 altering BGP routing tables).
995 MTA-STS can thwart such attacks only if the sender is able to
996 previously obtain and cache a policy for the recipient domain, and
997 only if the attacker is unable to obtain a valid certificate that
998 complies with that policy. Below, we consider specific attacks on
100110.1. Obtaining a Signed Certificate
1003 SMTP MTA-STS relies on certificate validation via PKIX-based TLS
1004 identity checking [RFC6125]. Attackers who are able to obtain a
1005 valid certificate for the targeted recipient mail service (e.g., by
1006 compromising a CA) are thus able to circumvent STS authentication.
1010Margolis, et al. Standards Track [Page 18]
1012RFC 8461 MTA-STS September 2018
101510.2. Preventing Policy Discovery
1017 Since MTA-STS uses DNS TXT records for policy discovery, an attacker
1018 who is able to block DNS responses can suppress the discovery of an
1019 MTA-STS Policy, making the Policy Domain appear not to have an MTA-
1020 STS Policy. The sender policy cache is designed to resist this
1021 attack by decreasing the frequency of policy discovery and thus
1022 reducing the window of vulnerability; it is nonetheless a risk that
1023 attackers who can predict or induce policy discovery -- for example,
1024 by inducing a sending domain to send mail to a never-before-contacted
1025 recipient while carrying out a man-in-the-middle attack -- may be
1026 able to foil policy discovery and effectively downgrade the security
1027 of the message delivery.
1029 Since this attack depends upon intercepting initial policy discovery,
1030 implementers SHOULD prefer policy "max_age" values to be as long as
1033 Because this attack is also possible upon refresh of a cached policy,
1034 implementers SHOULD NOT wait until a cached policy has expired before
1035 checking for an update; if senders attempt to refresh the cache
1036 regularly (for example, by fetching the current live policy in a
1037 background task that runs daily or weekly, regardless of the state of
1038 the "_mta-sts" TXT record, and updating their cache's "max age"
1039 accordingly), an attacker would have to foil policy discovery
1040 consistently over the lifetime of a cached policy to prevent a
1043 Additionally, MTAs SHOULD alert administrators to repeated policy
1044 refresh failures long before cached policies expire (through warning
1045 logs or similar applicable mechanisms), allowing administrators to
1046 detect such a persistent attack on policy refresh. (However, they
1047 should not implement such alerts if the cached policy has a "none"
1048 mode, to allow clean MTA-STS removal, as described in Section 8.3.)
1050 Resistance to downgrade attacks of this nature -- due to the ability
1051 to authoritatively determine "lack of a record" even for non-
1052 participating recipients -- is a feature of DANE, due to its use of
1053 DNSSEC for policy discovery.
105510.3. Denial of Service
1057 We additionally consider the Denial-of-Service risk posed by an
1058 attacker who can modify the DNS records for a recipient domain.
1059 Absent MTA-STS, such an attacker can cause a Sending MTA to cache
1060 invalid MX records, but only for however long the sending resolver
1061 caches those records. With MTA-STS, the attacker can additionally
1062 advertise a new, long "max_age" MTA-STS Policy with "mx" constraints
1066Margolis, et al. Standards Track [Page 19]
1068RFC 8461 MTA-STS September 2018
1071 that validate the malicious MX record, causing senders to cache the
1072 policy and refuse to deliver messages once the victim has resecured
1075 This attack is mitigated in part by the ability of a victim domain to
1076 (at any time) publish a new policy updating the cached, malicious
1077 policy, though this does require the victim domain to both obtain a
1078 valid CA-signed certificate and to understand and properly configure
1081 Similarly, we consider the possibility of domains that deliberately
1082 allow untrusted users to serve untrusted content on user-specified
1083 subdomains. In some cases (e.g., the service "tumblr.com"), this
1084 takes the form of providing HTTPS hosting of user-registered
1085 subdomains; in other cases (e.g. dynamic DNS providers), this takes
1086 the form of allowing untrusted users to register custom DNS records
1087 at the provider's domain.
1089 In these cases, there is a risk that untrusted users would be able to
1090 serve custom content at the "mta-sts" host, including serving an
1091 illegitimate MTA-STS Policy. We believe this attack is rendered more
1092 difficult by the need for the attacker to also serve the "_mta-sts"
1093 TXT record on the same domain -- something not, to our knowledge,
1094 widely provided to untrusted users. This attack is additionally
1095 mitigated by the aforementioned ability for a victim domain to update
1096 an invalid policy at any future date.
109810.4. Weak Policy Constraints
1100 Even if an attacker cannot modify a served policy, the potential
1101 exists for configurations that allow attackers on the same domain to
1102 receive mail for that domain. For example, an easy configuration
1103 option when authoring an MTA-STS Policy for "example.com" is to set
1104 the "mx" equal to "*.example.com"; in this case, recipient domains
1105 must consider the risk that any user possessing a valid hostname and
1106 CA-signed certificate (for example, "dhcp-123.example.com") will,
1107 from the perspective of MTA-STS Policy validation, be a valid MX host
111010.5. Compromise of the Web PKI System
1112 A number of risks apply to the PKI system that is used for
1113 certificate authentication, both of the "mta-sts" HTTPS host's
1114 certificate and the SMTP servers' certificates. These risks are
1115 broadly applicable within the Web PKI ecosystem and are not specific
1116 to MTA-STS; nonetheless, they deserve some consideration in this
1122Margolis, et al. Standards Track [Page 20]
1124RFC 8461 MTA-STS September 2018
1127 Broadly speaking, attackers may compromise the system by obtaining
1128 certificates under fraudulent circumstances (i.e., by impersonating
1129 the legitimate owner of the victim domain), by compromising a CA or
1130 Delegate Authority's private keys, by obtaining a legitimate
1131 certificate issued to the victim domain, and similar.
1133 One approach commonly employed by web browsers to help mitigate
1134 against some of these attacks is to allow for revocation of
1135 compromised or fraudulent certificates via OCSP [RFC6960] or CRLs
1136 [RFC6818]. Such mechanisms themselves represent trade-offs and are
1137 not universally implemented; we nonetheless recommend implementers of
1138 MTA-STS to implement revocation mechanisms that are most applicable
1139 to their implementations.
114311.1. Normative References
1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1146 Requirement Levels", BCP 14, RFC 2119,
1147 DOI 10.17487/RFC2119, March 1997,
1148 <https://www.rfc-editor.org/info/rfc2119>.
1150 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1151 DOI 10.17487/RFC2818, May 2000,
1152 <https://www.rfc-editor.org/info/rfc2818>.
1154 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
1155 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
1156 February 2002, <https://www.rfc-editor.org/info/rfc3207>.
1158 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
1159 for Internationalized Domain Names in Applications
1160 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
1161 <https://www.rfc-editor.org/info/rfc3492>.
1163 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1164 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
1165 2003, <https://www.rfc-editor.org/info/rfc3629>.
1167 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1168 Specifications: ABNF", STD 68, RFC 5234,
1169 DOI 10.17487/RFC5234, January 2008,
1170 <https://www.rfc-editor.org/info/rfc5234>.
1178Margolis, et al. Standards Track [Page 21]
1180RFC 8461 MTA-STS September 2018
1183 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1184 (TLS) Protocol Version 1.2", RFC 5246,
1185 DOI 10.17487/RFC5246, August 2008,
1186 <https://www.rfc-editor.org/info/rfc5246>.
1188 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1189 Housley, R., and W. Polk, "Internet X.509 Public Key
1190 Infrastructure Certificate and Certificate Revocation List
1191 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1192 <https://www.rfc-editor.org/info/rfc5280>.
1194 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1195 DOI 10.17487/RFC5321, October 2008,
1196 <https://www.rfc-editor.org/info/rfc5321>.
1198 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
1199 Uniform Resource Identifiers (URIs)", RFC 5785,
1200 DOI 10.17487/RFC5785, April 2010,
1201 <https://www.rfc-editor.org/info/rfc5785>.
1203 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
1204 Extensions: Extension Definitions", RFC 6066,
1205 DOI 10.17487/RFC6066, January 2011,
1206 <https://www.rfc-editor.org/info/rfc6066>.
1208 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1209 Verification of Domain-Based Application Service Identity
1210 within Internet Public Key Infrastructure Using X.509
1211 (PKIX) Certificates in the Context of Transport Layer
1212 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
1213 2011, <https://www.rfc-editor.org/info/rfc6125>.
1215 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
1216 RFC 7405, DOI 10.17487/RFC7405, December 2014,
1217 <https://www.rfc-editor.org/info/rfc7405>.
1219 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
1220 "Recommendations for Secure Use of Transport Layer
1221 Security (TLS) and Datagram Transport Layer Security
1222 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
1223 2015, <https://www.rfc-editor.org/info/rfc7525>.
1225 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1226 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1227 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1234Margolis, et al. Standards Track [Page 22]
1236RFC 8461 MTA-STS September 2018
1239 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1240 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1241 <https://www.rfc-editor.org/info/rfc8446>.
1243 [RFC8460] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J.,
1244 and M. Risher, "SMTP TLS Reporting", RFC 8460,
1245 DOI 10.17487/RFC8460, September 2018,
1246 <https://www.rfc-editor.org/info/rfc8460>.
124811.2. Informative References
1250 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1251 Rose, "DNS Security Introduction and Requirements",
1252 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1253 <https://www.rfc-editor.org/info/rfc4033>.
1255 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1256 DOI 10.17487/RFC5322, October 2008,
1257 <https://www.rfc-editor.org/info/rfc5322>.
1259 [RFC5891] Klensin, J., "Internationalized Domain Names in
1260 Applications (IDNA): Protocol", RFC 5891,
1261 DOI 10.17487/RFC5891, August 2010,
1262 <https://www.rfc-editor.org/info/rfc5891>.
1264 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key
1265 Infrastructure Certificate and Certificate Revocation List
1266 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January
1267 2013, <https://www.rfc-editor.org/info/rfc6818>.
1269 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
1270 Galperin, S., and C. Adams, "X.509 Internet Public Key
1271 Infrastructure Online Certificate Status Protocol - OCSP",
1272 RFC 6960, DOI 10.17487/RFC6960, June 2013,
1273 <https://www.rfc-editor.org/info/rfc6960>.
1275 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1276 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1277 RFC 7234, DOI 10.17487/RFC7234, June 2014,
1278 <https://www.rfc-editor.org/info/rfc7234>.
1280 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
1281 Opportunistic DNS-Based Authentication of Named Entities
1282 (DANE) Transport Layer Security (TLS)", RFC 7672,
1283 DOI 10.17487/RFC7672, October 2015,
1284 <https://www.rfc-editor.org/info/rfc7672>.
1290Margolis, et al. Standards Track [Page 23]
1292RFC 8461 MTA-STS September 2018
1295 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1296 Writing an IANA Considerations Section in RFCs", BCP 26,
1297 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1298 <https://www.rfc-editor.org/info/rfc8126>.
1346Margolis, et al. Standards Track [Page 24]
1348RFC 8461 MTA-STS September 2018
1351Appendix A. MTA-STS Example Record and Policy
1353 The owner of "example.com" wishes to begin using MTA-STS with a
1354 policy that will solicit reports from senders without affecting how
1355 the messages are processed, in order to verify the identity of MXes
1356 that handle mail for "example.com", confirm that TLS is correctly
1357 used, and ensure that certificates presented by the recipient MX
1360 MTA-STS Policy indicator TXT RR:
1362 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
1364 MTA-STS Policy file served as the response body at
1365 "https://mta-sts.example.com/.well-known/mta-sts.txt":
1371 mx: mx.backup-example.com
1374Appendix B. Message Delivery Pseudocode
1376 Below is pseudocode demonstrating the logic of a compliant Sending
1379 While this pseudocode implementation suggests synchronous policy
1380 retrieval in the delivery path, that may be undesirable in a working
1381 implementation, and we expect some implementers to instead prefer a
1382 background fetch that does not block delivery when no cached policy
1386 func isEnforce(policy) {
1387 // Return true if the policy mode is "enforce".
1390 func isNonExpired(policy) {
1391 // Return true if the policy is not expired.
1394 func tryStartTls(connection) {
1395 // Attempt to open an SMTP STARTTLS connection with the MX.
1398 func certMatches(connection, host) {
1402Margolis, et al. Standards Track [Page 25]
1404RFC 8461 MTA-STS September 2018
1407 // Assume a handy function to return if the server
1408 // certificate presented in "connection" is valid for "host".
1411 func policyMatches(candidate, policy) {
1412 for mx in policy.mx {
1414 if mx == candidate {
1417 // Wildcard matches only the leftmost label.
1418 // Wildcards must always be followed by a '.'.
1420 parts = SplitN(candidate, '.', 2) // Split on the first '.'.
1421 if len(parts) > 1 && parts[1] == mx[2:] {
1429 func tryDeliverMail(connection, message) {
1430 // Attempt to deliver "message" via "connection".
1433 func tryGetNewPolicy(domain) {
1434 // Check for an MTA-STS TXT record for "domain" in DNS, and return
1435 // the indicated policy.
1438 func cachePolicy(domain, policy) {
1439 // Store "policy" as the cached policy for "domain".
1442 func tryGetCachedPolicy(domain) {
1443 // Return a cached policy for "domain".
1446 func reportError(error) {
1447 // Report an error via TLSRPT.
1450 func tryMxAccordingTo(message, mx, policy) {
1451 connection := connect(mx)
1453 return false // Can't connect to the MX, so it's not an MTA-STS
1458Margolis, et al. Standards Track [Page 26]
1460RFC 8461 MTA-STS September 2018
1465 if !policyMatches(mx, policy) {
1467 reportError(E_HOST_MISMATCH)
1468 } else if !tryStartTls(connection) {
1470 reportError(E_NO_VALID_TLS)
1471 } else if !certMatches(connection, policy) {
1473 reportError(E_CERT_MISMATCH)
1475 if secure || !isEnforce(policy) {
1476 return tryDeliverMail(connection, message)
1481 func tryWithPolicy(message, domain, policy) {
1482 mxes := getMxForDomain(domain)
1484 if tryMxAccordingTo(message, mx, policy) {
1491 func handleMessage(message) {
1492 domain := ... // domain part after '@' from recipient
1493 policy := tryGetNewPolicy(domain)
1495 cachePolicy(domain, policy)
1497 policy = tryGetCachedPolicy(domain)
1500 return tryWithPolicy(message, domain, policy)
1502 // Try to deliver the message normally (i.e., without MTA-STS).
1514Margolis, et al. Standards Track [Page 27]
1516RFC 8461 MTA-STS September 2018
1526 ietf-dane@dukhovni.de
1529 1&1 Mail & Media Development & Technology GmbH
1530 markus.laber@1und1.de
1542 fmartin@linkedin.com
1545 1&1 Mail & Media Development & Technology GmbH
1546 klaus.umbach@1und1.de
1570Margolis, et al. Standards Track [Page 28]
1572RFC 8461 MTA-STS September 2018
1580 Email: dmargolis@google.com
1586 Email: risher@google.com
1592 Email: prbinu@yahoo.com
1598 Email: alex_brotman@comcast.com
1604 Email: janet.jones@microsoft.com
1626Margolis, et al. Standards Track [Page 29]