1
2
3
4
5
6
7Internet Engineering Task Force (IETF) D. Margolis
8Request for Comments: 8461 M. Risher
9Category: Standards Track Google, Inc.
10ISSN: 2070-1721 B. Ramakrishnan
11 Oath, Inc.
12 A. Brotman
13 Comcast, Inc.
14 J. Jones
15 Microsoft, Inc.
16 September 2018
17
18
19 SMTP MTA Strict Transport Security (MTA-STS)
20
21Abstract
22
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.
28
29Status of This Memo
30
31 This is an Internet Standards Track document.
32
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.
38
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.
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58Margolis, et al. Standards Track [Page 1]
59
60RFC 8461 MTA-STS September 2018
61
62
63Copyright Notice
64
65 Copyright (c) 2018 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
67
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.
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114Margolis, et al. Standards Track [Page 2]
115
116RFC 8461 MTA-STS September 2018
117
118
119Table of Contents
120
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
160
161
162
163
164
165
166
167
168
169
170Margolis, et al. Standards Track [Page 3]
171
172RFC 8461 MTA-STS September 2018
173
174
1751. Introduction
176
177 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
178 hosts to negotiate the use of a TLS channel for encrypted mail
179 transmission.
180
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.
187
188 This document defines a mechanism for recipient domains to publish
189 policies, via a combination of DNS and HTTPS, specifying:
190
191 o whether MTAs sending mail to this domain can expect PKIX-
192 authenticated TLS support
193
194 o what a conforming client should do with messages when TLS cannot
195 be successfully negotiated
196
1971.1. Terminology
198
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.
204
205 We also define the following terms for further use in this document:
206
207 o MTA-STS Policy: A commitment by the Policy Domain to support TLS
208 authenticated with PKIX [RFC5280] for the specified MX hosts.
209
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").
215
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".
219
220 o Sender or Sending MTA: The SMTP MTA sending an email message.
221
222
223
224
225
226Margolis, et al. Standards Track [Page 4]
227
228RFC 8461 MTA-STS September 2018
229
230
231 o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying
232 syntax, defined in [RFC5234] and [RFC7405].
233
2342. Related Technologies
235
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
244 Considerations".
245
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.
251
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.
258
2593. Policy Discovery
260
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.
267
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.
273
274
275
276
277
278
279
280
281
282Margolis, et al. Standards Track [Page 5]
283
284RFC 8461 MTA-STS September 2018
285
286
2873.1. MTA-STS TXT Records
288
289 The MTA-STS TXT record is a TXT record with the name "_mta-sts" at ../mtasts/mtasts.go:190
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:
293
294 o "v" (plaintext, required): Currently, only "STSv1" is supported.
295
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.
301
302 An example TXT record is as below:
303
304 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
305
306 The formal definition of the "_mta-sts" TXT record, defined using ../mtasts/parse.go:35
307 ABNF [RFC7405], is as follows:
308
309 sts-text-record = sts-version 1*(sts-field-delim sts-field)
310 [sts-field-delim]
311
312 sts-field = sts-id / ; Note that sts-id record
313 sts-extension ; is required.
314
315 sts-field-delim = *WSP ";" *WSP ../mtasts/parse.go:224
316
317 sts-version = %s"v=STSv1"
318
319 sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=... ../mtasts/parse.go:210
320
321 sts-extension = sts-ext-name "=" sts-ext-value ; name=value
322
323 sts-ext-name = (ALPHA / DIGIT)
324 *31(ALPHA / DIGIT / "_" / "-" / ".")
325
326 sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ../mtasts/parse.go:217
327 ; chars excluding "=", ";", SP, and CTLs
328
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
331 "_mta-sts" are returned by the resolver, records that do not begin ../mtasts/mtasts.go:208
332 with "v=STSv1;" are discarded. If the number of resulting records is
333 not one, or if the resulting record is syntactically invalid, senders 8461:574 ../mtastsdb/db.go:248
334 MUST assume the recipient domain does not have an available MTA-STS
335
336
337
338Margolis, et al. Standards Track [Page 6]
339
340RFC 8461 MTA-STS September 2018
341
342
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
349 spaces.
350
351 The "_mta-sts" record MAY return a CNAME that points (directly or via ../mtasts/mtasts.go:191
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
354 in Section 8.2.
355
3563.2. MTA-STS Policies
357
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.
363
364 Thus, for a Policy Domain of "example.com", the full URL is
365 "https://mta-sts.example.com/.well-known/mta-sts.txt".
366
367 When fetching a policy, senders SHOULD validate that the media type ../mtasts/mtasts.go:299
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
372 are also ignored.
373
374 This resource contains the following CRLF-separated key/value pairs:
375
376 o "version": Currently, only "STSv1" is supported.
377
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.
382
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
388 weeks or greater.
389
390
391
392
393
394Margolis, et al. Standards Track [Page 7]
395
396RFC 8461 MTA-STS September 2018
397
398
399 o "mx": Allowed MX patterns. One or more patterns matching allowed
400 MX hosts for the Policy Domain. As an example,
401
402 mx: mail.example.com <CRLF>
403 mx: *.example.net
404
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
411 Internationalized Domain Names [RFC5891], the "mx" value MUST specify 5321:2303 ../mtasts/parse.go:306
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".
416
417 An example policy is as below:
418
419 version: STSv1
420 mode: enforce
421 mx: mail.example.com
422 mx: *.example.net
423 mx: backupmx.example.com
424 max_age: 604800
425
426 The formal definition of the policy resource, defined using ABNF ../mtasts/parse.go:93
427 [RFC7405], is as follows:
428
429sts-policy-record = sts-policy-field *WSP
430 *(sts-policy-term sts-policy-field *WSP)
431 [sts-policy-term]
432
433sts-policy-field = sts-policy-version / ; required once
434 sts-policy-mode / ; required once
435 sts-policy-max-age / ; required once
436 sts-policy-mx /
437 ; required at least once, except when ../mtasts/parse.go:140
438 ; mode is "none"
439 sts-policy-extension ; other fields
440
441sts-policy-field-delim = ":" *WSP
442
443sts-policy-version = sts-policy-version-field sts-policy-field-delim
444 sts-policy-version-value
445
446sts-policy-version-field = %s"version"
447
448
449
450Margolis, et al. Standards Track [Page 8]
451
452RFC 8461 MTA-STS September 2018
453
454
455sts-policy-version-value = %s"STSv1"
456
457sts-policy-mode = sts-policy-mode-field sts-policy-field-delim
458 sts-policy-mode-value
459
460sts-policy-mode-field = %s"mode"
461
462sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none"
463
464sts-policy-mx = sts-policy-mx-field sts-policy-field-delim
465 sts-policy-mx-value
466
467sts-policy-mx-field = %s"mx"
468
469sts-policy-mx-value = ["*."] Domain ../mtasts/parse.go:281
470
471sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim
472 sts-policy-max-age-value
473
474sts-policy-max-age-field = %s"max_age"
475
476sts-policy-max-age-value = 1*10(DIGIT) ../mtasts/parse.go:261
477
478sts-policy-extension = sts-policy-ext-name ; additional
479 sts-policy-field-delim ; extension
480 sts-policy-ext-value ; fields
481
482sts-policy-ext-name = (sts-policy-alphanum) ../mtasts/parse.go:203
483 *31(sta-policy-alphanum / "_" / "-" / ".")
484
485sts-policy-term = LF / CRLF ../mtasts/parse.go:246
486
487sts-policy-ext-value = sts-policy-vchar ../mtasts/parse.go:304 ../mtasts/parse.go:320
488 [*(%x20 / sts-policy-vchar)
489 sts-policy-vchar]
490 ; chars, including UTF-8 [RFC3629],
491 ; excluding CTLs and no
492 ; leading/trailing spaces
493
494sts-policy-alphanum = ALPHA / DIGIT
495
496sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4
497
498UTF8-2 = <Defined in Section 4 of [RFC3629]>
499
500UTF8-3 = <Defined in Section 4 of [RFC3629]>
501
502UTF8-4 = <Defined in Section 4 of [RFC3629]>
503
504
505
506Margolis, et al. Standards Track [Page 9]
507
508RFC 8461 MTA-STS September 2018
509
510
511Domain = <Defined in Section 4.1.2 of [RFC5321]>
512
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
517 SHALL be ignored. If any non-repeated field -- i.e., all fields ../mtasts/parse.go:52 ../mtasts/parse.go:101
518 excepting "mx" -- is duplicated, all entries except for the first
519 SHALL be ignored.
520
5213.3. HTTPS Policy Fetching
522
523 Policy bodies are, as described above, retrieved by Sending MTAs via
524 HTTPS [RFC2818]. During the TLS handshake initiated to fetch a new ../mtasts/mtasts.go:270
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
532 verification.
533
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:
537
538 o Matching is performed only against the DNS-ID identifiers.
539
540 o DNS domain names in server certificates MAY contain the wildcard
541 character '*' as the complete left-most label within the
542 identifier.
543
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.
547
548 Policies fetched via HTTPS are only valid if the HTTP response code ../mtasts/mtasts.go:294
549 is 200 (OK). HTTP 3xx redirects MUST NOT be followed, and HTTP ../mtasts/mtasts.go:239
550 caching (as specified in [RFC7234]) MUST NOT be used.
551
552 Senders may wish to rate-limit the frequency of attempts to fetch the ../mtastsdb/db.go:172 ../mtastsdb/db.go:289
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
555 limit further attempts to a period of five minutes or longer per ../mtastsdb/db.go:276
556 version ID, to avoid overwhelming resource-constrained recipients
557 with cascading failures.
558
559
560
561
562Margolis, et al. Standards Track [Page 10]
563
564RFC 8461 MTA-STS September 2018
565
566
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
569 exhaustion during attempted policy updates. A suggested timeout is ../mtasts/mtasts.go:265
570 one minute, and a suggested maximum policy size is 64 kilobytes; ../mtasts/mtasts.go:301
571 Policy Hosts SHOULD respond to requests with a complete policy body
572 within that timeout and size limit.
573
574 If a valid TXT record is found but no policy can be fetched via HTTPS 8461:333 ../mtastsdb/db.go:248
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.
578
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.
582
583 Finally, to mitigate the risk of persistent interference with policy ../mtastsdb/refresh.go:28
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
587 problems with policy refresh, MTAs SHOULD alert administrators ../mtastsdb/refresh.go:150
588 (through the use of logs or similar) when such attempts fail, unless
589 the cached policy mode is "none".
590
5913.4. Policy Selection for Smart Hosts and Subdomains
592
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].
600
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".
605
6064. Policy Validation
607
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
610 check whether:
611
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".
614
615
616
617
618Margolis, et al. Standards Track [Page 11]
619
620RFC 8461 MTA-STS September 2018
621
622
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".
627
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
632 validation fails.
633
6344.1. MX Host Validation
635
636 A receiving candidate MX host is valid according to an applied MTA- ../mtasts/mtasts.go:131
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".
643
6444.2. Recipient MTA Certificate Validation
645
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.
652
6535. Policy Application
654
655 When sending to an MX at a domain for which the sender has a valid, ../mtasts/mtasts.go:70
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:
659
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.
663
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.
669
670
671
672
673
674Margolis, et al. Standards Track [Page 12]
675
676RFC 8461 MTA-STS September 2018
677
678
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.
682
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.
689
6905.1. Policy Application Control Flow
691
692 An example control flow for a compliant sender consists of the
693 following steps:
694
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
699 policy at this step.
700
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).
707
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],
713 Section 4.5.4.1).
714
7156. Reporting Failures
716
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:
722
723 o HTTPS policy fetch failures when a valid TXT record is present.
724
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".
727
728
729
730Margolis, et al. Standards Track [Page 13]
731
732RFC 8461 MTA-STS September 2018
733
734
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
738 "none".
739
7407. Interoperability Considerations
741
7427.1. SNI Support
743
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.
750
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
756 chain.
757
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
771 domain.
772
7737.2. Minimum TLS Version Support
774
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.
778
779
780
781
782
783
784
785
786Margolis, et al. Standards Track [Page 14]
787
788RFC 8461 MTA-STS September 2018
789
790
7918. Operational Considerations
792
7938.1. Policy Updates
794
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
800 passed.
801
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
807 risk message delays.
808
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.
812
8138.2. Policy Delegation
814
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.
819
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.
823
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.
831
832 For example, given a user domain "user.example" hosted by a mail
833 provider "provider.example", the following configuration would allow
834 policy delegation:
835
836 DNS:
837
838 _mta-sts.user.example. IN CNAME _mta-sts.provider.example.
839
840
841
842Margolis, et al. Standards Track [Page 15]
843
844RFC 8461 MTA-STS September 2018
845
846
847 Policy:
848
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
852
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").
858
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
867 fetching.
868
8698.3. Removing MTA-STS
870
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.
878
879 A suggested workflow to implement such an opt out is as follows:
880
881 1. Publish a new policy with "mode" equal to "none" and a small
882 "max_age" (e.g., one day).
883
884 2. Publish a new TXT record to trigger fetching of the new policy.
885
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
892 HTTPS endpoint.
893
894
895
896
897
898Margolis, et al. Standards Track [Page 16]
899
900RFC 8461 MTA-STS September 2018
901
902
9038.4. Preserving MX Candidate Traversal
904
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
913 loops; instead, it is recommended that implementers traverse the MX ../queue/direct.go:200
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).
917
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.
924
9259. IANA Considerations
926
9279.1. Well-Known URIs Registry
928
929 A new "well-known" URI as described in Section 3 has been registered
930 in the "Well-Known URIs" registry as described below:
931
932 URI Suffix: mta-sts.txt
933
934 Change Controller: IETF
935
9369.2. MTA-STS TXT Record Fields
937
938 IANA has created a new registry titled "MTA-STS TXT Record Fields".
939 The initial entries in the registry are:
940
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 +------------+--------------------+-------------------------+
947
948 New fields are added to this registry using IANA's "Expert Review"
949 policy [RFC8126].
950
951
952
953
954Margolis, et al. Standards Track [Page 17]
955
956RFC 8461 MTA-STS September 2018
957
958
9599.3. MTA-STS Policy Fields
960
961 IANA has created a new registry titled "MTA-STS Policy Fields". The
962 initial entries in the registry are:
963
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 +------------+----------------------+-------------------------+
972
973 New fields are added to this registry using IANA's "Expert Review"
974 policy.
975
97610. Security Considerations
977
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:
981
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.
986
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).
994
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
999 this model.
1000
100110.1. Obtaining a Signed Certificate
1002
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.
1007
1008
1009
1010Margolis, et al. Standards Track [Page 18]
1011
1012RFC 8461 MTA-STS September 2018
1013
1014
101510.2. Preventing Policy Discovery
1016
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.
1028
1029 Since this attack depends upon intercepting initial policy discovery,
1030 implementers SHOULD prefer policy "max_age" values to be as long as
1031 is practical.
1032
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
1041 successful refresh.
1042
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.)
1049
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.
1054
105510.3. Denial of Service
1056
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
1063
1064
1065
1066Margolis, et al. Standards Track [Page 19]
1067
1068RFC 8461 MTA-STS September 2018
1069
1070
1071 that validate the malicious MX record, causing senders to cache the
1072 policy and refuse to deliver messages once the victim has resecured
1073 the MX records.
1074
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
1079 MTA-STS.
1080
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.
1088
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.
1097
109810.4. Weak Policy Constraints
1099
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
1108 for that domain.
1109
111010.5. Compromise of the Web PKI System
1111
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
1117 context.
1118
1119
1120
1121
1122Margolis, et al. Standards Track [Page 20]
1123
1124RFC 8461 MTA-STS September 2018
1125
1126
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.
1132
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.
1140
114111. References
1142
114311.1. Normative References
1144
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>.
1149
1150 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1151 DOI 10.17487/RFC2818, May 2000,
1152 <https://www.rfc-editor.org/info/rfc2818>.
1153
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>.
1157
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>.
1162
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>.
1166
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>.
1171
1172
1173
1174
1175
1176
1177
1178Margolis, et al. Standards Track [Page 21]
1179
1180RFC 8461 MTA-STS September 2018
1181
1182
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>.
1187
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>.
1193
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>.
1197
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>.
1202
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>.
1207
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>.
1214
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>.
1218
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>.
1224
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>.
1228
1229
1230
1231
1232
1233
1234Margolis, et al. Standards Track [Page 22]
1235
1236RFC 8461 MTA-STS September 2018
1237
1238
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>.
1242
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>.
1247
124811.2. Informative References
1249
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>.
1254
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>.
1258
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>.
1263
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>.
1268
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>.
1274
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>.
1279
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>.
1285
1286
1287
1288
1289
1290Margolis, et al. Standards Track [Page 23]
1291
1292RFC 8461 MTA-STS September 2018
1293
1294
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>.
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346Margolis, et al. Standards Track [Page 24]
1347
1348RFC 8461 MTA-STS September 2018
1349
1350
1351Appendix A. MTA-STS Example Record and Policy
1352
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
1358 validate.
1359
1360 MTA-STS Policy indicator TXT RR:
1361
1362 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
1363
1364 MTA-STS Policy file served as the response body at
1365 "https://mta-sts.example.com/.well-known/mta-sts.txt":
1366
1367 version: STSv1
1368 mode: testing
1369 mx: mx1.example.com
1370 mx: mx2.example.com
1371 mx: mx.backup-example.com
1372 max_age: 1296000
1373
1374Appendix B. Message Delivery Pseudocode
1375
1376 Below is pseudocode demonstrating the logic of a compliant Sending
1377 MTA.
1378
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
1383 is present.
1384
1385
1386 func isEnforce(policy) {
1387 // Return true if the policy mode is "enforce".
1388 }
1389
1390 func isNonExpired(policy) {
1391 // Return true if the policy is not expired.
1392 }
1393
1394 func tryStartTls(connection) {
1395 // Attempt to open an SMTP STARTTLS connection with the MX.
1396 }
1397
1398 func certMatches(connection, host) {
1399
1400
1401
1402Margolis, et al. Standards Track [Page 25]
1403
1404RFC 8461 MTA-STS September 2018
1405
1406
1407 // Assume a handy function to return if the server
1408 // certificate presented in "connection" is valid for "host".
1409 }
1410
1411 func policyMatches(candidate, policy) {
1412 for mx in policy.mx {
1413 // Literal match.
1414 if mx == candidate {
1415 return true
1416 }
1417 // Wildcard matches only the leftmost label.
1418 // Wildcards must always be followed by a '.'.
1419 if mx[0] == '*' {
1420 parts = SplitN(candidate, '.', 2) // Split on the first '.'.
1421 if len(parts) > 1 && parts[1] == mx[2:] {
1422 return true
1423 }
1424 }
1425 }
1426 return false
1427 }
1428
1429 func tryDeliverMail(connection, message) {
1430 // Attempt to deliver "message" via "connection".
1431 }
1432
1433 func tryGetNewPolicy(domain) {
1434 // Check for an MTA-STS TXT record for "domain" in DNS, and return
1435 // the indicated policy.
1436 }
1437
1438 func cachePolicy(domain, policy) {
1439 // Store "policy" as the cached policy for "domain".
1440 }
1441
1442 func tryGetCachedPolicy(domain) {
1443 // Return a cached policy for "domain".
1444 }
1445
1446 func reportError(error) {
1447 // Report an error via TLSRPT.
1448 }
1449
1450 func tryMxAccordingTo(message, mx, policy) {
1451 connection := connect(mx)
1452 if !connection {
1453 return false // Can't connect to the MX, so it's not an MTA-STS
1454 // error.
1455
1456
1457
1458Margolis, et al. Standards Track [Page 26]
1459
1460RFC 8461 MTA-STS September 2018
1461
1462
1463 }
1464 secure := true
1465 if !policyMatches(mx, policy) {
1466 secure = false
1467 reportError(E_HOST_MISMATCH)
1468 } else if !tryStartTls(connection) {
1469 secure = false
1470 reportError(E_NO_VALID_TLS)
1471 } else if !certMatches(connection, policy) {
1472 secure = false
1473 reportError(E_CERT_MISMATCH)
1474 }
1475 if secure || !isEnforce(policy) {
1476 return tryDeliverMail(connection, message)
1477 }
1478 return false
1479 }
1480
1481 func tryWithPolicy(message, domain, policy) {
1482 mxes := getMxForDomain(domain)
1483 for mx in mxes {
1484 if tryMxAccordingTo(message, mx, policy) {
1485 return true
1486 }
1487 }
1488 return false
1489 }
1490
1491 func handleMessage(message) {
1492 domain := ... // domain part after '@' from recipient
1493 policy := tryGetNewPolicy(domain)
1494 if policy {
1495 cachePolicy(domain, policy)
1496 } else {
1497 policy = tryGetCachedPolicy(domain)
1498 }
1499 if policy {
1500 return tryWithPolicy(message, domain, policy)
1501 }
1502 // Try to deliver the message normally (i.e., without MTA-STS).
1503 }
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514Margolis, et al. Standards Track [Page 27]
1515
1516RFC 8461 MTA-STS September 2018
1517
1518
1519Contributors
1520
1521 Wei Chuang
1522 Google, Inc.
1523 weihaw@google.com
1524
1525 Viktor Dukhovni
1526 ietf-dane@dukhovni.de
1527
1528 Markus Laber
1529 1&1 Mail & Media Development & Technology GmbH
1530 markus.laber@1und1.de
1531
1532 Nicolas Lidzborski
1533 Google, Inc.
1534 nlidz@google.com
1535
1536 Brandon Long
1537 Google, Inc.
1538 blong@google.com
1539
1540 Franck Martin
1541 LinkedIn, Inc.
1542 fmartin@linkedin.com
1543
1544 Klaus Umbach
1545 1&1 Mail & Media Development & Technology GmbH
1546 klaus.umbach@1und1.de
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570Margolis, et al. Standards Track [Page 28]
1571
1572RFC 8461 MTA-STS September 2018
1573
1574
1575Authors' Addresses
1576
1577 Daniel Margolis
1578 Google, Inc.
1579
1580 Email: dmargolis@google.com
1581
1582
1583 Mark Risher
1584 Google, Inc.
1585
1586 Email: risher@google.com
1587
1588
1589 Binu Ramakrishnan
1590 Oath, Inc.
1591
1592 Email: prbinu@yahoo.com
1593
1594
1595 Alexander Brotman
1596 Comcast, Inc.
1597
1598 Email: alex_brotman@comcast.com
1599
1600
1601 Janet Jones
1602 Microsoft, Inc.
1603
1604 Email: janet.jones@microsoft.com
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626Margolis, et al. Standards Track [Page 29]
1627
1628