idnits 2.17.00 (12 Aug 2021) /tmp/idnits35309/draft-ietf-uta-mta-sts-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [BCP 14], but that reference does not seem to mention RFC 2119 either. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The certificate presented by the receiving MTA MUST not be expired, and MUST chain to a root CA that is trusted by the sending MTA. The certificate MUST have a subject alternative name (SAN, [RFC5280]) with a DNS-ID ([RFC6125]) matching the host name, per the rules given in [RFC6125]. The MX's certificate MAY also be checked for revocation via OCSP [RFC6960], CRLs [RFC6818], or some other mechanism. -- The document date (June 16, 2018) is 1428 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BCP 14' is mentioned on line 127, but not defined -- Looks like a reference, but probably isn't: '0' on line 1114 == Outdated reference: draft-ietf-uta-smtp-tlsrpt has been published as RFC 8460 ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Using TLS in Applications D. Margolis 3 Internet-Draft M. Risher 4 Intended status: Standards Track Google, Inc 5 Expires: December 18, 2018 B. Ramakrishnan 6 Yahoo!, Inc 7 A. Brotman 8 Comcast, Inc 9 J. Jones 10 Microsoft, Inc 11 June 16, 2018 13 SMTP MTA Strict Transport Security (MTA-STS) 14 draft-ietf-uta-mta-sts-21 16 Abstract 18 SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a 19 mechanism enabling mail service providers to declare their ability to 20 receive Transport Layer Security (TLS) secure SMTP connections, and 21 to specify whether sending SMTP servers should refuse to deliver to 22 MX hosts that do not offer TLS with a trusted server certificate. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 18, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 61 3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4 63 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 6 64 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 9 65 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 10 66 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 10 67 4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 11 68 4.2. Recipient MTA Certificate Validation . . . . . . . . . . 11 69 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 11 70 5.1. Policy Application Control Flow . . . . . . . . . . . . . 12 71 6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 12 72 7. Interoperability Considerations . . . . . . . . . . . . . . . 13 73 7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 13 74 7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 13 75 8. Operational Considerations . . . . . . . . . . . . . . . . . 14 76 8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 14 77 8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 14 78 8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 15 79 8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 16 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 16 82 9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 16 83 9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 17 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 17 86 10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 18 87 10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 18 88 10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 19 89 10.5. Compromise of the Web PKI System . . . . . . . . . . . . 19 90 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 12.2. Informative References . . . . . . . . . . . . . . . . . 22 94 Appendix A. MTA-STS example record & policy . . . . . . . . . . 23 95 Appendix B. Message delivery pseudocode . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 98 1. Introduction 100 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and 101 hosts to negotiate the use of a TLS channel for encrypted mail 102 transmission. 104 While this opportunistic encryption protocol by itself provides a 105 high barrier against passive man-in-the-middle traffic interception, 106 any attacker who can delete parts of the SMTP session (such as the 107 "250 STARTTLS" response) or who can redirect the entire SMTP session 108 (perhaps by overwriting the resolved MX record of the delivery 109 domain) can perform downgrade or interception attacks. 111 This document defines a mechanism for recipient domains to publish 112 policies, via a combination of DNS and HTTPS, specifying: 114 o whether MTAs sending mail to this domain can expect PKIX- 115 authenticated TLS support 117 o what a conforming client should do with messages when TLS cannot 118 be successfully negotiated 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 [BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 We also define the following terms for further use in this document: 130 o MTA-STS Policy: A commitment by the Policy Domain to support PKIX 131 [RFC5280] authenticated TLS for the specified MX hosts. 133 o Policy Domain: The domain for which an MTA-STS Policy is defined. 134 This is the next-hop domain; when sending mail to 135 "alice@example.com" this would ordinarily be "example.com", but 136 this may be overridden by explicit routing rules (as described in 137 Section 3.4, "Policy Selection for Smart Hosts and Subdomains"). 139 o Policy Host: The HTTPS host which serves the MTA-STS Policy for a 140 Policy Domain. Rules for constructing the hostname are described 141 in Section 3.2, "MTA-STS Policies". 143 o Sender: The SMTP Mail Transfer Agent sending an email message. 145 o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying 146 syntax, defined in [RFC5234] and [RFC7405]. 148 2. Related Technologies 150 The DANE TLSA record [RFC7672] is similar, in that DANE is also 151 designed to upgrade unauthenticated encryption or plaintext 152 transmission into authenticated, downgrade-resistant encrypted 153 transmission. DANE requires DNSSEC [RFC4033] for authentication; the 154 mechanism described here instead relies on certificate authorities 155 (CAs) and does not require DNSSEC, at a cost of risking malicious 156 downgrades. For a thorough discussion of this trade-off, see 157 Section 10, "Security Considerations". 159 In addition, MTA-STS provides an optional testing-only mode, enabling 160 soft deployments to detect policy failures; partial deployments can 161 be achieved in DANE by deploying TLSA records only for some of a 162 domain's MXs, but such a mechanism is not possible for the per-domain 163 policies used by MTA-STS. 165 The primary motivation of MTA-STS is to provide a mechanism for 166 domains to ensure transport security even when deploying DNSSEC is 167 undesirable or impractical. However, MTA-STS is designed not to 168 interfere with DANE deployments when the two overlap; in particular, 169 senders who implement MTA-STS validation MUST NOT allow a "valid" or 170 "testing"-only MTA-STS validation to override a failing DANE 171 validation. 173 3. Policy Discovery 175 MTA-STS policies are distributed via HTTPS from a "well-known" 176 [RFC5785] path served within the Policy Domain, and their presence 177 and current version are indicated by a TXT record at the Policy 178 Domain. These TXT records additionally contain a policy "id" field, 179 allowing sending MTAs to check the currency of a cached policy 180 without performing an HTTPS request. 182 To discover if a recipient domain implements MTA-STS, a sender need 183 only resolve a single TXT record. To see if an updated policy is 184 available for a domain for which the sender has a previously cached 185 policy, the sender need only check the TXT record's version "id" 186 against the cached value. 188 3.1. MTA-STS TXT Records 190 The MTA-STS TXT record is a TXT record with the name "_mta-sts" at 191 the Policy Domain. For the domain "example.com", this record would 192 be "_mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII, 193 semicolon-separated key/value pairs containing the following fields: 195 o "v": (plain-text, required). Currently only "STSv1" is supported. 197 o "id": (plain-text, required). A short string used to track policy 198 updates. This string MUST uniquely identify a given instance of a 199 policy, such that senders can determine when the policy has been 200 updated by comparing to the "id" of a previously seen policy. 201 There is no implied ordering of "id" fields between revisions. 203 An example TXT record is as below: 205 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" 207 The formal definition of the "_mta-sts" TXT record, defined using 208 ABNF ([RFC7405]), is as follows: 210 sts-text-record = sts-version 1*(sts-field-delim sts-field) 211 [sts-field-delim] 213 sts-field = sts-id / ; Note that sts-id record 214 sts-extension ; is required. 216 sts-field-delim = *WSP ";" *WSP 218 sts-version = %s"v=STSv1" 220 sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=... 222 sts-extension = sts-ext-name "=" sts-ext-value ; name=value 224 sts-ext-name = (ALPHA / DIGIT) 225 *31(ALPHA / DIGIT / "_" / "-" / ".") 227 sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) 228 ; chars excluding "=", ";", SP, and CTLs 230 The TXT record MUST begin with sts-version field, and the order of 231 other fields is not significant. If multiple TXT records for "_mta- 232 sts" are returned by the resolver, records which do not begin with 233 "v=STSv1;" are discarded. If the number of resulting records is not 234 one, or if the resulting record is syntactically invalid, senders 235 MUST assume the recipient domain does not have an available MTA-STS 236 policy and skip the remaining steps of policy discovery. (Note that 237 absence of a usable TXT record is not by itself sufficient to remove 238 a sender's previously cached policy for the Policy Domain, as 239 discussed in Section 5.1, "Policy Application Control Flow".) If the 240 resulting TXT record contains multiple strings, then the record MUST 241 be treated as if those strings are concatenated together without 242 adding spaces. 244 3.2. MTA-STS Policies 246 The policy itself is a set of key/value pairs (similar to [RFC5322] 247 header fields) served via the HTTPS GET method from the fixed 248 [RFC5785] "well-known" path of ".well-known/mta-sts.txt" served by 249 the Policy Host. The Policy Host DNS name is constructed by 250 prepending "mta-sts" to the Policy Domain. 252 Thus for a Policy Domain of "example.com" the full URL is 253 "https://mta-sts.example.com/.well-known/mta-sts.txt". 255 When fetching a policy, senders SHOULD validate that the media type 256 is "text/plain" to guard against cases where webservers allow 257 untrusted users to host non-text content (typically, HTML or images) 258 at a user-defined path. All parameters other than charset=utf-8 or 259 charset=us-ascii are ignored. Additional "Content-Type" parameters 260 are also ignored. 262 This resource contains the following CRLF-separated key/value pairs: 264 o "version": Currently only "STSv1" is supported. 266 o "mode": One of "enforce", "testing", or "none", indicating the 267 expected behavior of a sending MTA in the case of a policy 268 validation failure. See Section 5, "Policy Application." for more 269 details about the three modes. 271 o "max_age": Max lifetime of the policy (plain-text non-negative 272 integer seconds, maximum value of 31557600). Well-behaved clients 273 SHOULD cache a policy for up to this value from last policy fetch 274 time. To mitigate the risks of attacks at policy refresh time, it 275 is expected that this value typically be in the range of weeks or 276 greater. 278 o "mx": Allowed MX patterns. One or more patterns matching allowed 279 MX hosts for the Policy Domain. As an example, 281 mx: mail.example.com 282 mx: *.example.net 284 indicates that mail for this domain might be handled by MX 285 "mail.example.com" or any MX at "example.net". Valid patterns can be 286 either fully specified names ("example.com") or suffixes prefixed by 287 a wildcard ("*.example.net"). If a policy specifies more than one 288 MX, each MX MUST have its own "mx:" key, and each MX key/value pair 289 MUST be on its own line in the policy file. In the case of 290 Internationalized Domain Names ([RFC5891]), the "mx" value MUST 291 specify the Punycode-encoded A-label [RFC3492] to match against, and 292 not the Unicode-encoded U-label. The full semantics of certificate 293 validation (including the use of wildcard patterns) are described in 294 Section 4.1, "MX Host Validation." 296 An example policy is as below: 298 version: STSv1 299 mode: enforce 300 mx: mail.example.com 301 mx: *.example.net 302 mx: backupmx.example.com 303 max_age: 604800 305 The formal definition of the policy resource, defined using 306 [RFC7405], is as follows: 308 sts-policy-record = sts-policy-field *WSP 309 *(sts-policy-term sts-policy-field *WSP) 310 [sts-policy-term] 312 sts-policy-field = sts-policy-version / ; required once 313 sts-policy-mode / ; required once 314 sts-policy-max-age / ; required once 316 sts-policy-term / 317 ; required at least once, except when 318 ; mode is "none" 320 sts-policy-extension ; other fields 322 sts-policy-field-delim = ":" *WSP 324 sts-policy-version = sts-policy-version-field sts-policy-field-delim 325 sts-policy-version-value 327 sts-policy-version-field = %s"version" 329 sts-policy-version-value = %s"STSv1" 331 sts-policy-mode = sts-policy-mode-field sts-policy-field-delim 332 sts-policy-mode-value 334 sts-policy-mode-field = %s"mode" 335 sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none" 337 sts-policy-mx = sts-policy-mx-field sts-policy-field-delim 338 sts-policy-mx-value 340 sts-policy-mx-field = %s"mx" 342 sts-policy-mx-value = ["."] Domain 344 sts-policy-mx-label = sts-policy-alphanum / 345 sts-policy-alphanum *(sts-policy-alphanum / "-") 346 sts-policy-alphanum 348 sts-policy-mx-toplabel = ALPHA / ALPHA *(sts-policy-alphanum / "-") 349 sts-policy-alphanum 351 sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim 352 sts-policy-max-age-value 354 sts-policy-max-age-field = %s"max_age" 356 sts-policy-max-age-value = 1*10(DIGIT) 358 sts-policy-extension = sts-policy-ext-name ; additional 359 sts-policy-field-delim ; extension 360 sts-policy-ext-value ; fields 362 sts-policy-ext-name = (sts-policy-alphanum) 363 *31(sta-policy-alphanum / "_" / "-" / ".") 365 sts-policy-term = LF / CRLF 367 sts-policy-ext-value = sts-policy-vchar 368 [*(%x20 / sts-policy-vchar) 369 sts-policy-vchar] 370 ; chars, including UTF-8 [@!RFC3629], 371 ; excluding CTLs and no 372 ; leading/trailing spaces 374 sts-policy-alphanum = ALPHA / DIGIT 376 sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4 378 UTF8-2 = 380 UTF8-3 = 382 UTF8-4 = 383 Domain = 385 Parsers MUST accept TXT records and policy files which are 386 syntactically valid (i.e., valid key/value pairs separated by semi- 387 colons for TXT records), possibly containing additional key/value 388 pairs not specified in this document, in which case unknown fields 389 SHALL be ignored. If any non-repeated field--i.e., all fields 390 excepting "mx"--is duplicated, all entries except for the first SHALL 391 be ignored. 393 3.3. HTTPS Policy Fetching 395 Policy bodies are, as described above, retrieved by sending MTAs via 396 HTTPS [RFC2818]. During the TLS handshake initiated to fetch a new 397 or updated policy from the Policy Host, the Policy Host HTTPS server 398 MUST present a X.509 certificate which is valid for the "mta-sts" 399 DNS-ID ([RFC6125]) (e.g., "mta-sts.example.com") as described below, 400 chain to a root CA that is trusted by the sending MTA, and be non- 401 expired. It is expected that sending MTAs use a set of trusted CAs 402 similar to those in widely deployed Web browsers and operating 403 systems. See [RFC5280] for more details about certificate 404 verification. 406 The certificate is valid for the Policy Host (i.e., "mta-sts" 407 prepended to the Policy Domain) with respect to the rules described 408 in [RFC6125], with the following application-specific considerations: 410 o Matching is performed only against the DNS-ID identifiers. 412 o DNS domain names in server certificates MAY contain the wildcard 413 character '*' as the complete left-most label within the 414 identifier. 416 The certificate MAY be checked for revocation via the Online 417 Certificate Status Protocol (OCSP) [RFC6960], certificate revocation 418 lists (CRLs), or some other mechanism. 420 Policies fetched via HTTPS are only valid if the HTTP response code 421 is 200 (OK). HTTP 3xx redirects MUST NOT be followed, and HTTP 422 caching (as specified in [RFC7234]) MUST NOT be used. 424 Senders may wish to rate-limit the frequency of attempts to fetch the 425 HTTPS endpoint even if a valid TXT record for the recipient domain 426 exists. In the case that the HTTPS GET fails, implementers SHOULD 427 limit further attempts to a period of five minutes or longer per 428 version ID, to avoid overwhelming resource-constrained recipients 429 with cascading failures. 431 Senders MAY impose a timeout on the HTTPS GET and/or a limit on the 432 maximum size of the response body to avoid long delays or resource 433 exhaustion during attempted policy updates. A suggested timeout is 434 one minute, and a suggested maximum policy size 64 kilobytes; policy 435 hosts SHOULD respond to requests with a complete policy body within 436 that timeout and size limit. 438 If a valid TXT record is found but no policy can be fetched via HTTPS 439 (for any reason), and there is no valid (non-expired) previously- 440 cached policy, senders MUST continue with delivery as though the 441 domain has not implemented MTA-STS. 443 Conversely, if no "live" policy can be discovered via DNS or fetched 444 via HTTPS, but a valid (non-expired) policy exists in the sender's 445 cache, the sender MUST apply that cached policy. 447 Finally, to mitigate the risk of persistent interference with policy 448 refresh, as discussed in-depth in Section 10, MTAs SHOULD proactively 449 refresh cached policies before they expire; a suggested refresh 450 frequency is once per day. To enable administrators to discover 451 problems with policy refresh, MTAs SHOULD alert administrators 452 (through the use of logs or similar) when such attempts fail, unless 453 the cached policy mode is "none". 455 3.4. Policy Selection for Smart Hosts and Subdomains 457 When sending mail via a "smart host"--an administratively configured 458 intermediate SMTP relay, which is different from the message 459 recipient's server as determined from DNS --compliant senders MUST 460 treat the smart host domain as the policy domain for the purposes of 461 policy discovery and application. This specification does not 462 provide a means of associating policies with addresses that employ 463 Address Literals [RFC5321]. 465 When sending mail to a mailbox at a subdomain, compliant senders MUST 466 NOT attempt to fetch a policy from the parent zone. Thus for mail 467 sent to "user@mail.example.com", the policy can be fetched only from 468 "mail.example.com", not "example.com". 470 4. Policy Validation 472 When sending to an MX at a domain for which the sender has a valid 473 and non-expired MTA-STS policy, a sending MTA honoring MTA-STS MUST 474 check whether: 476 1. At least one of the policy's "mx" patterns matches the selected 477 MX host, as described in Section 4.1, "MX Host Validation". 479 2. The recipient mail server supports STARTTLS and offers a PKIX- 480 based TLS certificate, during TLS handshake, which is valid for 481 that host, as described in Section 4.2, "Recipient MTA 482 Certificate Validation". 484 When these conditions are not met, a policy is said to fail to 485 validate. This section does not dictate the behavior of sending MTAs 486 when the above conditions are not met; see Section 5, "Policy 487 Application" for a description of sending MTA behavior when policy 488 validation fails. 490 4.1. MX Host Validation 492 A receiving candidate MX host is valid according to an applied MTA- 493 STS policy if the MX record name matches one or more of the "mx" 494 fields in the applied policy. Matching is identical to the rules 495 given in [RFC6125], with restriction that the wildcard character "*" 496 may only be used to match the entire left-most label in the presented 497 identifier. Thus the mx pattern "*.example.com" matches 498 "mail.example.com" but not "example.com" or "foo.bar.example.com". 500 4.2. Recipient MTA Certificate Validation 502 The certificate presented by the receiving MTA MUST not be expired, 503 and MUST chain to a root CA that is trusted by the sending MTA. The 504 certificate MUST have a subject alternative name (SAN, [RFC5280]) 505 with a DNS-ID ([RFC6125]) matching the host name, per the rules given 506 in [RFC6125]. The MX's certificate MAY also be checked for 507 revocation via OCSP [RFC6960], CRLs [RFC6818], or some other 508 mechanism. 510 5. Policy Application 512 When sending to an MX at a domain for which the sender has a valid, 513 non-expired MTA-STS policy, a sending MTA honoring MTA-STS applies 514 the result of a policy validation failure one of two ways, depending 515 on the value of the policy "mode" field: 517 1. "enforce": In this mode, sending MTAs MUST NOT deliver the 518 message to hosts which fail MX matching or certificate 519 validation, or do not support STARTTLS. 521 2. "testing": In this mode, sending MTAs which also implement the 522 TLSRPT specification [I-D.ietf-uta-smtp-tlsrpt] merely send a 523 report indicating policy application failures (so long as TLSRPT 524 is also implemented by the recipient domain). 526 3. "none": In this mode, sending MTAs should treat the policy domain 527 as though it does not have any active policy; see Section 8.3, 528 "Removing MTA-STS", for use of this mode value. 530 When a message fails to deliver due to an "enforce" policy, a 531 compliant MTA MUST NOT permanently fail to deliver messages before 532 checking, via DNS, for the presence of an updated policy at the 533 Policy Domain. (In all cases, MTAs SHOULD treat such failures as 534 transient errors and retry delivery later.) This allows implementing 535 domains to update long-lived policies on the fly. 537 5.1. Policy Application Control Flow 539 An example control flow for a compliant sender consists of the 540 following steps: 542 1. Check for a cached policy whose time-since-fetch has not exceeded 543 its "max_age". If none exists, attempt to fetch a new policy 544 (perhaps asynchronously, so as not to block message delivery). 545 Optionally, sending MTAs may unconditionally check for a new 546 policy at this step. 548 2. For each candidate MX, in order of MX priority, attempt to 549 deliver the message. If a policy is present with an "enforce" 550 mode, when attempting to deliver to each candidate MX, ensure 551 STARTTLS support and host identity validity as described in 552 Section 4, "Policy Validation". If a candidate fails validation, 553 continue to the next candidate (if there is one). 555 3. A message delivery MUST NOT be permanently failed until the 556 sender has first checked for the presence of a new policy (as 557 indicated by the "id" field in the "_mta-sts" TXT record). If a 558 new policy is not found, existing rules for the case of temporary 559 message delivery failures apply (as discussed in [RFC5321] 560 section 4.5.4.1). 562 6. Reporting Failures 564 MTA-STS is intended to be used along with TLSRPT 565 [I-D.ietf-uta-smtp-tlsrpt] in order to ensure implementing domains 566 can detect cases of both benign and malicious failures, and to ensure 567 that failures that indicate an active attack are discoverable. As 568 such, senders who also implement TLSRPT SHOULD treat the following 569 events as reportable failures: 571 o HTTPS policy fetch failures when a valid TXT record is present. 573 o Policy fetch failures of any kind when a valid policy exists in 574 the policy cache, except if that policy's mode is "none". 576 o Delivery attempts in which a contacted MX does not support 577 STARTTLS or does not present a certificate which validates 578 according to the applied policy, except if that policy's mode is 579 "none". 581 7. Interoperability Considerations 583 7.1. SNI Support 585 To ensure that the server sends the right certificate chain, the SMTP 586 client MUST have support for the TLS SNI extension [RFC6066]. When 587 connecting to a HTTP server to retrieve the MTA-STS policy, the SNI 588 extension MUST contain the name of the policy host (e.g., "mta- 589 sts.example.com"). When connecting to an SMTP server, the SNI 590 extension MUST contain the MX hostname. 592 HTTP servers used to deliver MTA-STS policies MAY rely on SNI to 593 determine which certificate chain to present to the client. HTTP 594 servers MUST respond with a certificate chain that matches the policy 595 hostname or abort the TLS handshake if unable to do so. Clients that 596 do not send SNI information may not see the expected certificate 597 chain. 599 SMTP servers MAY rely on SNI to determine which certificate chain to 600 present to the client. However servers that have one identity and a 601 single matching certificate do not require SNI support. Servers MUST 602 NOT enforce the use of SNI by clients, as the client may be using 603 unauthenticated opportunistic TLS and may not expect any particular 604 certificate from the server. If the client sends no SNI extension or 605 sends an SNI extension for an unsupported server name, the server 606 MUST simply send a fallback certificate chain of its choice. The 607 reason for not enforcing strict matching of the requested SNI 608 hostname is that MTA-STS TLS clients may be typically willing to 609 accept multiple server names but can only send one name in the SNI 610 extension. The server's fallback certificate may match a different 611 name that is acceptable to the client, e.g., the original next-hop 612 domain. 614 7.2. Minimum TLS Version Support 616 MTAs supporting MTA-STS MUST have support for TLS version 1.2 617 [RFC5246] or higher. The general TLS usage guidance in [RFC7525] 618 SHOULD be followed. 620 8. Operational Considerations 622 8.1. Policy Updates 624 Updating the policy requires that the owner make changes in two 625 places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and 626 at the corresponding HTTPS endpoint. As a result, recipients should 627 expect a policy will continue to be used by senders until both the 628 HTTPS and TXT endpoints are updated and the TXT record's TTL has 629 passed. 631 In other words, a sender who is unable to successfully deliver a 632 message while applying a cache of the recipient's now-outdated policy 633 may be unable to discover that a new policy exists until the DNS TTL 634 has passed. Recipients SHOULD therefore ensure that old policies 635 continue to work for message delivery during this period of time, or 636 risk message delays. 638 Recipients SHOULD also update the HTTPS policy body before updating 639 the TXT record; this ordering avoids the risk that senders, seeing a 640 new TXT record, mistakenly cache the old policy from HTTPS. 642 8.2. Policy Delegation 644 Domain owners commonly delegate SMTP hosting to a different 645 organization, such as an ISP or a Web host. In such a case, they may 646 wish to also delegate the MTA-STS policy to the same organization 647 which can be accomplished with two changes. 649 First, the Policy Domain must point the "_mta-sts" record, via CNAME, 650 to the "_mta-sts" record maintained by the hosting organization. 651 This allows the hosting organization to control update signaling. 653 Second, the Policy Domain must point the "well-known" policy location 654 to the hosting organization. This can be done either by setting the 655 "mta-sts" record to an IP address or CNAME specified by the hosting 656 organization and by giving the hosting organization a TLS certificate 657 which is valid for that host, or by setting up a "reverse proxy" 658 (also known as a "gateway") server that serves as the Policy Domain's 659 policy the policy currently served by the hosting organization. 661 For example, given a user domain "user.example" hosted by a mail 662 provider "provider.example", the following configuration would allow 663 policy delegation: 665 DNS: 667 _mta-sts.user.example. IN CNAME _mta-sts.provider.example. 669 Policy: 671 > GET /.well-known/mta-sts.txt Host: mta-sts.user.example 672 < HTTP/1.1 200 OK # Response proxies content from 673 # https://mta-sts.provider.example 675 Note that in all such cases, the policy endpoint ("https://mta- 676 sts.user.example/.well-known/mta-sts.txt" in this example) must still 677 present a certificate valid for the Policy Host ("mta- 678 sts.user.example"), and not for that host at the provider's domain 679 ("mta-sts.provider.example"). 681 Note that while sending MTAs MUST NOT use HTTP caching when fetching 682 policies via HTTPS, such caching may nonetheless be useful to a 683 reverse proxy configured as described in this section. An HTTPS 684 policy endpoint expecting to be proxied for multiple hosted domains-- 685 as with a large mail hosting provider or similar--may wish to 686 indicate an HTTP Cache-Control "max-age" response directive (as 687 specified in [RFC7234]) of 60 seconds as a reasonable value to save 688 reverse proxies an unnecessarily high-rate of proxied policy 689 fetching. 691 8.3. Removing MTA-STS 693 In order to facilitate clean opt-out of MTA-STS by implementing 694 policy domains, and to distinguish clearly between failures which 695 indicate attacks and those which indicate such opt-outs, MTA-STS 696 implements the "none" mode, which allows validated policies to 697 indicate authoritatively that the policy domain wishes to no longer 698 implement MTA-STS and may, in the future, remove the MTA-STS TXT and 699 policy endpoints entirely. 701 A suggested workflow to implement such an opt out is as follows: 703 1. Publish a new policy with "mode" equal to "none" and a small 704 "max_age" (e.g., one day). 706 2. Publish a new TXT record to trigger fetching of the new policy. 708 3. When all previously served policies have expired--normally this 709 is the time the previously published policy was last served plus 710 that policy's "max_age", but note that older policies may have 711 been served with a greater "max_age", allowing overlapping policy 712 caches--safely remove the TXT record and HTTPS endpoint. 714 8.4. Preserving MX Candidate Traversal 716 Implementors of send-time MTA-STS validation in mail transfer agents 717 should take note of the risks of modifying the logic of traversing MX 718 candidate lists. Because an MTA-STS policy can be used to prefilter 719 invalid MX candidates from the MX candidate list, it is tempting to 720 implement a "two-pass" model, where MX candidates are first filtered 721 for possible validity according to the MTA-STS policy, and then the 722 remaining candidates attempted in order as without an MTA-STS policy. 723 This may lead to incorrect implementations, such a message loops; 724 implementors are instead recommended to traverse the MX candidate 725 list as usual, and treat invalid candidates as though they were 726 unreachable (i.e., as though there were some transient error when 727 trying to deliver to that candidate). 729 One consequence of validating MX hosts in order of ordinary candidate 730 traversal is that, in the event that a higher-priority MX is MTA-STS 731 valid and a lower-priority MX is not, senders may never encounter the 732 lower-priority MX, leading to a risk that policy misconfigurations 733 that apply only to "backup" MXes may only be discovered in the case 734 of primary MX failure. 736 9. IANA Considerations 738 9.1. Well-Known URIs Registry 740 A new "well-known" URI as described in Section 3 will be registered 741 in the Well-Known URIs registry as described below: 743 URI Suffix: mta-sts.txt Change Controller: IETF 745 9.2. MTA-STS TXT Record Fields 747 IANA is requested to create a new registry titled "MTA-STS TXT Record 748 Fields". The initial entries in the registry are: 750 +------------+--------------------+------------------------+ 751 | Field Name | Description | Reference | 752 +------------+--------------------+------------------------+ 753 | v | Record version | Section 3.1 of RFC XXX | 754 | id | Policy instance ID | Section 3.1 of RFC XXX | 755 +------------+--------------------+------------------------+ 757 New fields are added to this registry using IANA's "Expert Review" 758 policy. 760 9.3. MTA-STS Policy Fields 762 IANA is requested to create a new registry titled "MTA-STS Policy 763 Fields". The initial entries in the registry are: 765 +------------+----------------------+------------------------+ 766 | Field Name | Description | Reference | 767 +------------+----------------------+------------------------+ 768 | version | Policy version | Section 3.2 of RFC XXX | 769 | mode | Enforcement behavior | Section 3.2 of RFC XXX | 770 | max_age | Policy lifetime | Section 3.2 of RFC XXX | 771 | mx | MX identities | Section 3.2 of RFC XXX | 772 +------------+----------------------+------------------------+ 774 New fields are added to this registry using IANA's "Expert Review" 775 policy. 777 10. Security Considerations 779 SMTP MTA Strict Transport Security attempts to protect against an 780 active attacker trying to intercept or tamper with mail between hosts 781 that support STARTTLS. There are two classes of attacks considered: 783 o Foiling TLS negotiation, for example by deleting the "250 784 STARTTLS" response from a server or altering TLS session 785 negotiation. This would result in the SMTP session occurring over 786 plaintext, despite both parties supporting TLS. 788 o Impersonating the destination mail server, whereby the sender 789 might deliver the message to an impostor, who could then monitor 790 and/or modify messages despite opportunistic TLS. This 791 impersonation could be accomplished by spoofing the DNS MX record 792 for the recipient domain, or by redirecting client connections 793 intended for the legitimate recipient server (for example, by 794 altering BGP routing tables). 796 MTA-STS can thwart such attacks only if the sender is able to 797 previously obtain and cache a policy for the recipient domain, and 798 only if the attacker is unable to obtain a valid certificate that 799 complies with that policy. Below, we consider specific attacks on 800 this model. 802 10.1. Obtaining a Signed Certificate 804 SMTP MTA-STS relies on certificate validation via PKIX based TLS 805 identity checking [RFC6125]. Attackers who are able to obtain a 806 valid certificate for the targeted recipient mail service (e.g., by 807 compromising a certificate authority) are thus able to circumvent STS 808 authentication. 810 10.2. Preventing Policy Discovery 812 Since MTA-STS uses DNS TXT records for policy discovery, an attacker 813 who is able to block DNS responses can suppress the discovery of an 814 MTA-STS Policy, making the Policy Domain appear not to have an MTA- 815 STS Policy. The sender policy cache is designed to resist this 816 attack by decreasing the frequency of policy discovery and thus 817 reducing the window of vulnerability; it is nonetheless a risk that 818 attackers who can predict or induce policy discovery--for example, by 819 inducing a sending domain to send mail to a never-before-contacted 820 recipient while carrying out a man-in-the-middle attack--may be able 821 to foil policy discovery and effectively downgrade the security of 822 the message delivery. 824 Since this attack depends upon intercepting initial policy discovery, 825 implementers SHOULD prefer policy "max_age" values to be as long as 826 is practical. 828 Because this attack is also possible upon refresh of a cached policy, 829 implementors SHOULD NOT wait until a cached policy has expired before 830 checking for an update; if senders attempt to refresh the cache 831 regularly (for example, by fetching currently live policy in a 832 background task that runs daily or weekly, regardless of the state of 833 the "_mta_sts" TXT record, and updating their cache's "max age" 834 accordingly), an attacker would have to foil policy discovery 835 consistently over the lifetime of a cached policy to prevent a 836 successful refresh. 838 Additionally, MTAs SHOULD alert administrators to repeated policy 839 refresh failures long before cached policies expire (through warning 840 logs or similar applicable mechanisms), allowing administrators to 841 detect such a persistent attack on policy refresh. (However, they 842 should not implement such alerts if the cached policy has a "none" 843 mode, to allow clean MTA-STS removal, as described in Section 8.3.) 845 Resistance to downgrade attacks of this nature--due to the ability to 846 authoritatively determine "lack of a record" even for non- 847 participating recipients--is a feature of DANE, due to its use of 848 DNSSEC for policy discovery. 850 10.3. Denial of Service 852 We additionally consider the Denial of Service risk posed by an 853 attacker who can modify the DNS records for a recipient domain. 854 Absent MTA-STS, such an attacker can cause a sending MTA to cache 855 invalid MX records, but only for however long the sending resolver 856 caches those records. With MTA-STS, the attacker can additionally 857 advertise a new, long-"max_age" MTA-STS policy with "mx" constraints 858 that validate the malicious MX record, causing senders to cache the 859 policy and refuse to deliver messages once the victim has resecured 860 the MX records. 862 This attack is mitigated in part by the ability of a victim domain to 863 (at any time) publish a new policy updating the cached, malicious 864 policy, though this does require the victim domain to both obtain a 865 valid CA-signed certificate and to understand and properly configure 866 MTA-STS. 868 Similarly, we consider the possibility of domains that deliberately 869 allow untrusted users to serve untrusted content on user-specified 870 subdomains. In some cases (e.g., the service Tumblr.com) this takes 871 the form of providing HTTPS hosting of user-registered subdomains; in 872 other cases (e.g. dynamic DNS providers) this takes the form of 873 allowing untrusted users to register custom DNS records at the 874 provider's domain. 876 In these cases, there is a risk that untrusted users would be able to 877 serve custom content at the "mta-sts" host, including serving an 878 illegitimate MTA-STS policy. We believe this attack is rendered more 879 difficult by the need for the attacker to also serve the "_mta-sts" 880 TXT record on the same domain--something not, to our knowledge, 881 widely provided to untrusted users. This attack is additionally 882 mitigated by the aforementioned ability for a victim domain to update 883 an invalid policy at any future date. 885 10.4. Weak Policy Constraints 887 Even if an attacker cannot modify a served policy, the potential 888 exists for configurations that allow attackers on the same domain to 889 receive mail for that domain. For example, an easy configuration 890 option when authoring an MTA-STS Policy for "example.com" is to set 891 the "mx" equal to "*.example.com"; recipient domains must consider in 892 this case the risk that any user possessing a valid hostname and CA- 893 signed certificate (for example, "dhcp-123.example.com") will, from 894 the perspective of MTA-STS Policy validation, be a valid MX host for 895 that domain. 897 10.5. Compromise of the Web PKI System 899 A host of risks apply to the PKI system used for certificate 900 authentication, both of the "mta-sts" HTTPS host's certificate and 901 the SMTP servers' certificates. These risks are broadly applicable 902 within the Web PKI ecosystem and are not specific to MTA-STS; 903 nonetheless, they deserve some consideration in this context. 905 Broadly speaking, attackers may compromise the system by obtaining 906 certificates under fraudulent circumstances (i.e., by impersonating 907 the legitimate owner of the victim domain), by compromising a 908 Certificate Authority or Delegate Authority's private keys, by 909 obtaining a legitimate certificate issued to the victim domain, and 910 similar. 912 One approach commonly employed by Web browsers to help mitigate 913 against some of these attacks is to allow for revocation of 914 compromised or fraudulent certificates via OCSP [RFC6960] or CRLs 915 [RFC6818]. Such mechanisms themselves represent tradeoffs and are 916 not universally implemented; we nonetheless recommend implementors of 917 MTA-STS to implement revocation mechanisms which are most applicable 918 to their implementations. 920 11. Contributors 922 Wei Chuang Google, Inc weihaw@google.com 924 Viktor Dukhovni ietf-dane@dukhovni.de 926 Markus Laber 1&1 Mail & Media Development & Technology GmbH 927 markus.laber@1und1.de 929 Nicolas Lidzborski Google, Inc nlidz@google.com 931 Brandon Long Google, Inc blong@google.com 933 Franck Martin LinkedIn, Inc fmartin@linkedin.com 935 Klaus Umbach 1&1 Mail & Media Development & Technology GmbH 936 klaus.umbach@1und1.de 938 12. References 940 12.1. Normative References 942 [I-D.ietf-uta-smtp-tlsrpt] 943 Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., 944 and M. Risher, "SMTP TLS Reporting", draft-ietf-uta-smtp- 945 tlsrpt-22 (work in progress), May 2018. 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", BCP 14, RFC 2119, 949 DOI 10.17487/RFC2119, March 1997, . 952 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 953 DOI 10.17487/RFC2818, May 2000, . 956 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 957 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 958 February 2002, . 960 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 961 for Internationalized Domain Names in Applications 962 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 963 . 965 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 966 Specifications: ABNF", STD 68, RFC 5234, 967 DOI 10.17487/RFC5234, January 2008, . 970 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 971 (TLS) Protocol Version 1.2", RFC 5246, 972 DOI 10.17487/RFC5246, August 2008, . 975 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 976 Housley, R., and W. Polk, "Internet X.509 Public Key 977 Infrastructure Certificate and Certificate Revocation List 978 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 979 . 981 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 982 DOI 10.17487/RFC5321, October 2008, . 985 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 986 Uniform Resource Identifiers (URIs)", RFC 5785, 987 DOI 10.17487/RFC5785, April 2010, . 990 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 991 Extensions: Extension Definitions", RFC 6066, 992 DOI 10.17487/RFC6066, January 2011, . 995 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 996 Verification of Domain-Based Application Service Identity 997 within Internet Public Key Infrastructure Using X.509 998 (PKIX) Certificates in the Context of Transport Layer 999 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1000 2011, . 1002 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1003 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1004 . 1006 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1007 "Recommendations for Secure Use of Transport Layer 1008 Security (TLS) and Datagram Transport Layer Security 1009 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1010 2015, . 1012 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1013 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1014 May 2017, . 1016 12.2. Informative References 1018 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1019 Rose, "DNS Security Introduction and Requirements", 1020 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1021 . 1023 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1024 DOI 10.17487/RFC5322, October 2008, . 1027 [RFC5891] Klensin, J., "Internationalized Domain Names in 1028 Applications (IDNA): Protocol", RFC 5891, 1029 DOI 10.17487/RFC5891, August 2010, . 1032 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 1033 Infrastructure Certificate and Certificate Revocation List 1034 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 1035 2013, . 1037 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1038 Galperin, S., and C. Adams, "X.509 Internet Public Key 1039 Infrastructure Online Certificate Status Protocol - OCSP", 1040 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1041 . 1043 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1044 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1045 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1046 . 1048 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 1049 Opportunistic DNS-Based Authentication of Named Entities 1050 (DANE) Transport Layer Security (TLS)", RFC 7672, 1051 DOI 10.17487/RFC7672, October 2015, . 1054 Appendix A. MTA-STS example record & policy 1056 The owner of "example.com" wishes to begin using MTA-STS with a 1057 policy that will solicit reports from senders without affecting how 1058 the messages are processed, in order to verify the identity of MXs 1059 that handle mail for "example.com", confirm that TLS is correctly 1060 used, and ensure that certificates presented by the recipient MX 1061 validate. 1063 MTA-STS policy indicator TXT RR: 1065 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" 1067 MTA-STS Policy file served as the response body at "https://mta- 1068 sts.example.com/.well-known/mta-sts.txt": 1070 version: STSv1 1071 mode: testing 1072 mx: mx1.example.com 1073 mx: mx2.example.com 1074 mx: mx.backup-example.com 1075 max_age: 1296000 1077 Appendix B. Message delivery pseudocode 1079 Below is pseudocode demonstrating the logic of a compliant sending 1080 MTA. 1082 While this pseudocode implementation suggests synchronous policy 1083 retrieval in the delivery path, in a working implementation that may 1084 be undesirable, and we expect some implementers to instead prefer a 1085 background fetch that does not block delivery if no cached policy is 1086 present. 1088 func isEnforce(policy) { 1089 // Return true if the policy mode is "enforce". 1091 } 1093 func isNonExpired(policy) { 1094 // Return true if the policy is not expired. 1095 } 1097 func tryStartTls(connection) { 1098 // Attempt to open an SMTP connection with STARTTLS with the MX. 1099 } 1101 func certMatches(connection, host) { 1102 // Assume a handy function to return check if the server certificate presented 1103 // in "connection" is valid for "host". 1104 } 1106 func policyMatches(candidate, policy) { 1107 for mx in policy.mx { 1108 // Literal match. 1109 if mx == candidate { 1110 return true 1111 } 1112 // Wildcard matches only the leftmost label. 1113 // Wildcards must always be followed by a '.'. 1114 if mx[0] == '*' { 1115 parts = SplitN(candidate, '.', 2) // Split on the first '.'. 1116 if len(parts) > 1 && parts[1] == mx[2:] { 1117 return true 1118 } 1119 } 1120 } 1121 return false 1122 } 1124 func tryDeliverMail(connection, message) { 1125 // Attempt to deliver "message" via "connection". 1126 } 1128 func tryGetNewPolicy(domain) { 1129 // Check for an MTA-STS TXT record for "domain" in DNS, and return the 1130 // indicated policy. 1131 } 1133 func cachePolicy(domain, policy) { 1134 // Store "policy" as the cached policy for "domain". 1135 } 1137 func tryGetCachedPolicy(domain) { 1138 // Return a cached policy for "domain". 1140 } 1142 func reportError(error) { 1143 // Report an error via TLSRPT. 1144 } 1146 func tryMxAccordingTo(message, mx, policy) { 1147 connection := connect(mx) 1148 if !connection { 1149 return false // Can't connect to the MX so it's not an MTA-STS 1150 // error. 1151 } 1152 secure := true 1153 if !policyMatches(mx, policy) { 1154 secure = false 1155 reportError(E_HOST_MISMATCH) 1156 } else if !tryStartTls(connection) { 1157 secure = false 1158 reportError(E_NO_VALID_TLS) 1159 } else if !certMatches(connection, policy) { 1160 secure = false 1161 reportError(E_CERT_MISMATCH) 1162 } 1163 if secure || !isEnforce(policy) { 1164 return tryDeliverMail(connection, message) 1165 } 1166 return false 1167 } 1169 func tryWithPolicy(message, domain, policy) { 1170 mxes := getMxForDomain(domain) 1171 for mx in mxes { 1172 if tryMxAccordingTo(message, mx, policy) { 1173 return true 1174 } 1175 } 1176 return false 1177 } 1179 func handleMessage(message) { 1180 domain := ... // domain part after '@' from recipient 1181 policy := tryGetNewPolicy(domain) 1182 if policy { 1183 cachePolicy(domain, policy) 1184 } else { 1185 policy = tryGetCachedPolicy(domain) 1186 } 1187 if policy { 1188 return tryWithPolicy(message, domain, policy) 1189 } 1190 // Try to deliver the message normally (i.e., without MTA-STS). 1191 } 1193 Authors' Addresses 1195 Daniel Margolis 1196 Google, Inc 1198 Email: dmargolis@google.com 1200 Mark Risher 1201 Google, Inc 1203 Email: risher@google.com 1205 Binu Ramakrishnan 1206 Yahoo!, Inc 1208 Email: rbinu@yahoo-inc.com 1210 Alexander Brotman 1211 Comcast, Inc 1213 Email: alex_brotman@comcast.com 1215 Janet Jones 1216 Microsoft, Inc 1218 Email: janet.jones@microsoft.com