idnits 2.17.1 draft-ietf-uta-mta-sts-02.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 3 instances of too long lines in the document, the longest one being 6 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 15, 2016) is 2681 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 657 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: June 18, 2017 B. Ramakrishnan 6 Yahoo!, Inc 7 A. Brotman 8 Comcast, Inc 9 J. Jones 10 Microsoft, Inc 11 December 15, 2016 13 SMTP MTA Strict Transport Security (MTA-STS) 14 draft-ietf-uta-mta-sts-02 16 Abstract 18 SMTP Mail Transfer Agent Strict Transport Security (SMTP STS) is a 19 mechanism enabling mail service providers to declare their ability to 20 receive TLS-secured connections and an expected validity of 21 certificates presented by their MX hosts, and to specify whether 22 sending SMTP servers should refuse to deliver to MX hosts that do not 23 offer TLS with a trusted server certificate. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 18, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3 62 3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4 64 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5 65 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 6 66 3.4. Policy Selection for Smart Hosts . . . . . . . . . . . . 6 67 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. MX Matching . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.2. MX Certificate Validation . . . . . . . . . . . . . . . . 7 70 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. MX Preference . . . . . . . . . . . . . . . . . . . . . . 8 72 5.2. Policy Application Control Flow . . . . . . . . . . . . . 8 73 6. Operational Considerations . . . . . . . . . . . . . . . . . 8 74 6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. Appendix 1: Domain Owner STS example record . . . . . . . . . 11 79 10.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 11 80 11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 11 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and 89 hosts to negotiate the use of a TLS channel for secure mail 90 transmission. 92 While such _opportunistic_ encryption protocols provide a high 93 barrier against passive man-in-the-middle traffic interception, any 94 attacker who can delete parts of the SMTP session (such as the "250 95 STARTTLS" response) or who can redirect the entire SMTP session 96 (perhaps by overwriting the resolved MX record of the delivery 97 domain) can perform downgrade or interception attacks. 99 This document defines a mechanism for recipient domains to publish 100 policies specifying: 102 o whether MTAs sending mail to this domain can expect TLS support 104 o expected validity of server certificates presented by the domain's 105 MX hosts 107 o what a conforming client should do with messages when TLS cannot 108 be successfully negotiated 110 1.1. Terminology 112 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 113 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 114 document, are to be interpreted as described in [RFC2119]. 116 We also define the following terms for further use in this document: 118 o STS Policy: A committment by the Policy Domain to support PKIX 119 authenticated TLS for the specified MX hosts. 121 o Policy Domain: The domain for which an STS Policy is defined. 122 (For example, when sending mail to "alice@example.com", the policy 123 domain is "example.com".) 125 o Policy Authentication: Authentication of the STS policy retrieved 126 for a recipient domain by the sender. 128 2. Related Technologies 130 The DANE TLSA record [RFC7672] is similar, in that DANE is also 131 designed to upgrade opportunistic, unauthenticated encryption into 132 required, authenticated encryption. DANE requires DNSSEC [RFC4033] 133 for authentication; the mechanism described here instead relies on 134 certificate authorities (CAs) and does not require DNSSEC. For a 135 thorough discussion of this trade-off, see the section _Security_ 136 _Considerations_. 138 In addition, SMTP STS provides an optional report-only mode, enabling 139 soft deployments to detect policy failures. 141 3. Policy Discovery 143 SMTP STS policies are distributed via HTTPS from a "well-known" 144 [RFC5785] path served within the Policy Domain, and their presence 145 and current version are indicated by a TXT record at the Policy 146 Domain. These TXT records additionally contain a policy "id" field, 147 allowing sending MTAs to check the currency of a cached policy 148 without performing an HTTPS request. 150 To discover if a recipient domain implements MTA-STS, a sender need 151 only resolve a single TXT record. To see if an updated policy is 152 available for a domain for which the sender has a previously cached 153 policy, the sender need only check the TXT record's version "id" 154 against the cached value. 156 3.1. MTA-STS TXT Records 158 The MTA-STS TXT record is a TXT record with the name "_mta-sts" at 159 the Policy Domain. For the domain "example.com", this record would 160 be "_mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII, 161 semicolon-separated key/value pairs containing the following fields: 163 o "v": (plain-text, required). Currently only "STSv1" is supported. 165 o "id": (plain-text, required). A short string used to track policy 166 updates. This string MUST uniquely identify a given instance of a 167 policy, such that senders can determine when the policy has been 168 updated by comparing to the "id" of a previously seen policy. 169 There is no implied ordering of "id" fields between revisions. 171 An example TXT record is as below: 173 "_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"" 175 The formal definition of the "_mta-sts" TXT record, defined using 176 [RFC5234], is as follows: 178 sts-text-record = sts-version *WSP %x3B *WSP sts-id [%x3B] 180 sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" 181 %x53 %x76 %x31 183 sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) 185 If multiple TXT records for "_mta-sts" are returned by the resolver, 186 records which do not begin with "v=STSv1;" are discarded. If the 187 number of resulting records is not one, senders MUST assume the 188 recipient domain does not implement MTA STS and skip the remaining 189 steps of policy discovery. 191 3.2. MTA-STS Policies 193 The policy itself is a JSON [RFC4627] object served via the HTTPS GET 194 method from the fixed [RFC5785] "well-known" path of ".well-known/ 195 mta-sts.json" served by the "mta-sts" host at the Policy Domain. 196 Thus for "example.com" the path is "https://mta-sts.example.com 197 /.well-known/mta-sts.json". 199 This JSON object contains the following key/value pairs: 201 o "version": (plain-text, required). Currently only "STSv1" is 202 supported. 204 o "mode": (plain-text, required). Either "enforce" or "report", 205 indicating the expected behavior of a sending MTA in the case of a 206 policy validation failure. 208 o "max_age": Max lifetime of the policy (plain-text non-negative 209 integer seconds, required). Well-behaved clients SHOULD cache a 210 policy for up to this value from last policy fetch time. To 211 mitigate the risks of attacks at policy refresh time, it is 212 expected that this value typically be in the range of weeks or 213 greater. 215 o "mx": MX patterns (list of plain-text MX match strings, required). 216 One or more patterns matching the expected MX for this domain. 217 For example, "["*.example.com", "*.example.net"]" indicates that 218 mail for this domain might be handled by any MX with a hostname at 219 "example.com" or "example.net". Valid patterns can be either 220 hostname literals (e.g. "mx1.example.com") or wildcard matches, so 221 long as the wildcard occupies the full left-most label in the 222 pattern. (Thus "*.example.com" is valid but "mx*.example.com" is 223 not.) 225 An example JSON policy is as below: 227 { 228 "version": "STSv1", 229 "mode": "enforce", 230 "mx": ["*.mail.example.com"], 231 "max_age": 123456 232 } 234 A lenient parser SHOULD accept TXT records and policy files which are 235 syntactically valid (i.e. valid key-value pairs separated by semi- 236 colons for TXT records and valid JSON for policy files) and 237 implementing a superset of this specification, in which case unknown 238 fields SHALL be ignored. 240 3.3. HTTPS Policy Fetching 242 When fetching a new policy or updating a policy, the HTTPS endpoint 243 MUST present a TLS certificate which is valid for the "mta-sts" host 244 (as described in [RFC6125]), chain to a root CA that is trusted by 245 the sending MTA, and be non-expired. It is expected that sending 246 MTAs use a set of trusted CAs similar to those in widely deployed Web 247 browsers and operating systems. 249 HTTP 3xx redirects MUST NOT be followed. 251 Senders may wish to rate-limit the frequency of attempts to fetch the 252 HTTPS endpoint even if a valid TXT record for the recipient domain 253 exists. In the case that the HTTPS GET fails, we suggest 254 implementions may limit further attempts to a period of five minutes 255 or longer per version ID, to avoid overwhelming resource-constrained 256 recipients with cascading failures. 258 Senders MAY impose a timeout on the HTTPS GET to avoid long delays 259 imposed by attempted policy updates. A suggested timeout is one 260 minute; policy hosts SHOULD respond to requests with a complete 261 policy body within that timeout. 263 3.4. Policy Selection for Smart Hosts 265 When sending mail via a "smart host"--an intermediate SMTP relay 266 rather than the message recipient's server--compliant senders MUST 267 treat the smart host domain as the policy domain for the purposes of 268 policy discovery and application. 270 4. Policy Validation 272 When sending to an MX at a domain for which the sender has a valid 273 and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP STS 274 MUST validate: 276 1. That the recipient MX matches the "mx" pattern from the recipient 277 domain's policy. 279 2. That the recipient MX supports STARTTLS and offers a valid PKIX 280 based TLS certificate. 282 This section does not dictate the behavior of sending MTAs when 283 policies fail to validate; in particular, validation failures of 284 policies which specify "report" mode MUST NOT be interpreted as 285 delivery failures, as described in the section _Policy_ 286 _Application_. 288 4.1. MX Matching 290 When delivering mail for the Policy Domain to a recipient MX host, 291 the sender validates the MX match against the "mx" pattern from the 292 applied policy. The semantics for these patterns are those found in 293 section 6.4 of [RFC6125]. 295 Patterns may contain a wildcard character "*" which matches any 296 single domain name component or component fragment, though only as 297 the leftmost component in a pattern. For example, "*.example.com" is 298 a valid pattern, but "foo.*.example.com" is not. Given the pattern 299 "*.example.com", "mx1.example.com" is a valid MX host, but 300 "1234.dhcp.example.com" is not. 302 4.2. MX Certificate Validation 304 The certificate presented by the receiving MX MUST be valid for the 305 MX hostname and chain to a root CA that is trusted by the sending 306 MTA. The certificate MUST have a CN or SAN matching the MX hostname 307 (as described in [RFC6125]) and be non-expired. 309 In the case of an "implicit" MX record (as specified in [RFC2821]) 310 where no MX RR exists for the recipient domain but there is an A RR, 311 the MX hostname is assumed to be that of the A RR and should be 312 validated as such. 314 5. Policy Application 316 When sending to an MX at a domain for which the sender has a valid, 317 non-expired STS policy, a sending MTA honoring SMTP STS applies the 318 result of a policy validation one of two ways, depending on the value 319 of the policy "mode" field: 321 1. "report": In this mode, sending MTAs merely send a report (as 322 described in the TLSRPT specification (TODO: add ref)) indicating 323 policy application failures. 325 2. "enforce": In this mode, sending MTAs treat STS policy failures 326 as a mail delivery error, and MUST NOT deliver the message to 327 this host. 329 When a message fails to deliver due to an "enforce" policy, a 330 compliant MTA MUST check for the presence of an updated policy at the 331 Policy Domain before permanently failing to deliver the message. 333 This allows implementing domains to update long-lived policies on the 334 fly. 336 Finally, in both "enforce" and "report" modes, failures to deliver in 337 compliance with the applied policy result in failure reports to the 338 policy domain, as described in the TLSRPT specification (TODO: add 339 ref). 341 5.1. MX Preference 343 When applying a policy, sending MTAs SHOULD select recipient MXs by 344 first eliminating any MXs at lower priority than the current host (if 345 in the MX candidate set), then eliminating any non-matching (as 346 specified by the STS Policy) MX hosts from the candidate MX set, and 347 then attempting delivery to matching hosts as indicated by their MX 348 priority, until delivery succeeds or the MX candidate set is empty. 350 5.2. Policy Application Control Flow 352 An example control flow for a compliant sender consists of the 353 following steps: 355 1. Check for a cached policy whose time-since-fetch has not exceeded 356 its "max_age". If none exists, attempt to fetch a new policy. 357 (Optionally, sending MTAs may unconditionally check for a new 358 policy at this step.) 360 2. Filter candidate MXs against the current policy. 362 3. If no candidate MXs are valid and the policy mode is "enforce", 363 temporarily fail the message. (Otherwise, generate a failure 364 report but deliver as though MTA STS were not implemented.) 366 4. For each candidate MX, in order of MX priority, attempt to 367 deliver the message, enforcing STARTTLS and the MX host's PKIX 368 certificate validation. 370 5. Upon message retries, a message MAY be permanently failed 371 following first checking for the presence of a new policy (as 372 indicated by the "id" field in the "_mta-sts" TXT record). 374 6. Operational Considerations 376 6.1. Policy Updates 378 Updating the policy requires that the owner make changes in two 379 places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and 380 at the corresponding HTTPS endpoint. In the case where the HTTPS 381 endpoint has been updated but the TXT record has not yet been, 382 senders will not know there is a new policy released and may thus 383 continue to use old, previously cached versions. Recipients should 384 thus expect a policy will continue to be used by senders until both 385 the HTTPS and TXT endpoints are updated and the TXT record's TTL has 386 passed. 388 7. IANA Considerations 390 A new .well-known URI will be registered in the Well-Known URIs 391 registry as described below: 393 URI Suffix: mta-sts.json Change Controller: IETF 395 8. Security Considerations 397 SMTP Strict Transport Security attempts to protect against an active 398 attacker who wishes to intercept or tamper with mail between hosts 399 who support STARTTLS. There are two classes of attacks considered: 401 1. Foiling TLS negotiation, for example by deleting the "250 402 STARTTLS" response from a server or altering TLS session 403 negotiation. This would result in the SMTP session occurring 404 over plaintext, despite both parties supporting TLS. 406 2. Impersonating the destination mail server, whereby the sender 407 might deliver the message to an impostor, who could then monitor 408 and/or modify messages despite opportunistic TLS. This 409 impersonation could be accomplished by spoofing the DNS MX record 410 for the recipient domain, or by redirecting client connections 411 intended for the legitimate recipient server (for example, by 412 altering BGP routing tables). 414 SMTP Strict Transport Security relies on certificate validation via 415 PKIX based TLS identity checking [RFC6125]. Attackers who are able 416 to obtain a valid certificate for the targeted recipient mail service 417 (e.g. by compromising a certificate authority) are thus able to 418 circumvent STS authentication. 420 Since we use DNS TXT records for policy discovery, an attacker who is 421 able to block DNS responses can suppress the discovery of an STS 422 Policy, making the Policy Domain appear not to have an STS Policy. 423 The sender policy cache is designed to resist this attack. 425 We additionally consider the Denial of Service risk posed by an 426 attacker who can modify the DNS records for a victim domain. Absent 427 SMTP STS, such an attacker can cause a sending MTA to cache invalid 428 MX records for a long TTL. With SMTP STS, the attacker can 429 additionally advertise a new, long-"max_age" SMTP STS policy with 430 "mx" constraints that validate the malicious MX record, causing 431 senders to cache the policy and refuse to deliver messages once the 432 victim has resecured the MX records. 434 This attack is mitigated in part by the ability of a victim domain to 435 (at any time) publish a new policy updating the cached, malicious 436 policy, though this does require the victim domain to both obtain a 437 valid CA-signed certificate and to understand and properly configure 438 SMTP STS. 440 Similarly, we consider the possibilty of domains that deliberately 441 allow untrusted users to serve untrusted content on user-specified 442 subdomains. In some cases (e.g. the service Tumblr.com) this takes 443 the form of providing HTTPS hosting of user-registered subdomains; in 444 other cases (e.g. dynamic DNS providers) this takes the form of 445 allowing untrusted users to register custom DNS records at the 446 provider's domain. 448 In these cases, there is a risk that untrusted users would be able to 449 serve custom content at the "mta-sts" host, including serving an 450 illegitimate SMTP STS policy. We believe this attack is rendered 451 more difficult by the need for the attacker to both inject malicious 452 (but temporarily working) MX records and also serve the "_mta-sts" 453 TXT record on the same domain--something not, to our knowledge, 454 widely provided to untrusted users. This attack is additionally 455 mitigated by the aforementioned ability for a victim domain to update 456 an invalid policy at any future date. 458 Even if an attacker cannot modify a served policy, the potential 459 exists for configurations that allow attackers on the same domain to 460 receive mail for that domain. For example, an easy configuration 461 option when authoring an STS Policy for "example.com" is to set the 462 "mx" equal to "*.example.com"; recipient domains must consider in 463 this case the risk that any user possessing a valid hostname and CA- 464 signed certificate (for example, "dhcp-123.example.com") will, from 465 the perspective of STS Policy validation, be a valid MX host for that 466 domain. 468 9. Contributors 470 Nicolas Lidzborski Google, Inc nlidz (at) google (dot com) 472 Wei Chuang Google, Inc weihaw (at) google (dot com) 474 Brandon Long Google, Inc blong (at) google (dot com) 476 Franck Martin LinkedIn, Inc fmartin (at) linkedin (dot com) 477 Klaus Umbach 1&1 Mail & Media Development & Technology GmbH 478 klaus.umbach (at) 1und1 (dot de) 480 Markus Laber 1&1 Mail & Media Development & Technology GmbH 481 markus.laber (at) 1und1 (dot de) 483 10. Appendix 1: Domain Owner STS example record 485 10.1. Example 1 487 The owner of "example.com" wishes to begin using STS with a policy 488 that will solicit reports from receivers without affecting how the 489 messages are processed, in order to verify the identity of MXs that 490 handle mail for "example.com", confirm that TLS is correctly used, 491 and ensure that certificates presented by the recipient MX validate. 493 STS policy indicator TXT RR: 495 _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" 497 STS Policy JSON served as the response body at [1] 499 { 500 "version": "STSv1", 501 "mode": "report", 502 "mx": ["mx1.example.com", "mx2.example.com"], 503 "max_age": 123456 504 } 506 11. Appendix 2: Message delivery pseudocode 508 Below is pseudocode demonstrating the logic of a complaint sending 509 MTA. This implements the "two-pass" approach, first attempting 510 delivery with a newly fetched policy (if present) before falling back 511 to a cached policy (if present). 513 func isEnforce(policy) { 514 // Return true if the policy mode is "enforce". 515 } 517 func isNonExpired(policy) { 518 // Return true if the policy is not expired. 519 } 521 func tryStartTls(mx) { 522 // Attempt to open an SMTP connection with STARTTLS with the MX. 524 } 526 func certMatches(connection, mx) { 527 // Return if the server certificate from "connection" matches the "mx" host. 528 } 530 func tryDeliverMail(connection, message) { 531 // Attempt to deliver "message" via "connection". 532 } 534 func getMxsForPolicy(domain, policy) { 535 // Sort the MXs by priority, filtering out those which are invalid according 536 // to "policy". 537 } 539 func tryGetNewPolicy(domain) { 540 // Check for an MTA STS TXT record for "domain" in DNS, and return the 541 // indicated policy (or a local cache of the unvalidated policy). 542 } 544 func cachePolicy(domain, policy) { 545 // Store "policy" as the cached policy for "domain". 546 } 548 func tryGetCachedPolicy(domain, policy) { 549 // Return a cached policy for "domain". 550 } 552 func reportError(error) { 553 // Report an error via TLSRPT. 554 } 556 func tryMxAccordingTo(message, mx, policy) { 557 connection := connect(mx) 558 if !connection { 559 return false // Can't connect to the MX so it's not an STS error. 560 } 561 status := !(tryStartTls(mx, &connection) && certMatches(connection, mx)) 562 status = true 563 if !tryStartTls(mx, &connection) { 564 status = false 565 reportError(E_NO_VALID_TLS) 566 } else if certMatches(connection, mx) { 567 status = false 568 reportError(E_CERT_MISMATCH) 569 } 570 if status || !isEnforce(policy) { 571 return tryDeliverMail(connection, message) 573 } 574 return false 575 } 577 func tryWithPolicy(message, domain, policy) { 578 mxes := getMxesForPolicy(domain, policy) 579 if mxs is empty { 580 reportError(E_NO_VALID_MXES) 581 } 582 for mx in mxes { 583 if tryMxAccordingTo(message, mx, policy) { 584 return true 585 } 586 } 587 return false 588 } 590 func handleMessage(message) { 591 domain := ... // domain part after '@' from recipient 592 oldPolicy := tryGetCachedPolicy(domain) 593 newPolicy := tryGetNewPolicy(domain) 594 if newPolicy { 595 cachePolicy(domain, newPolicy) 596 oldPolicy = newPolicy 597 } 598 if oldPolicy { 599 return tryWithPolicy(message, oldPolicy) 600 } 601 // There is no policy or there's a new policy that did not work. 602 // Try to deliver the message normally (i.e. without STS). 603 } 605 12. References 607 12.1. Normative References 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 611 RFC2119, March 1997, 612 . 614 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 615 2821, DOI 10.17487/RFC2821, April 2001, 616 . 618 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 619 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 620 February 2002, . 622 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 623 Rose, "DNS Security Introduction and Requirements", RFC 624 4033, DOI 10.17487/RFC4033, March 2005, 625 . 627 [RFC4627] Crockford, D., "The application/json Media Type for 628 JavaScript Object Notation (JSON)", RFC 4627, DOI 10 629 .17487/RFC4627, July 2006, 630 . 632 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 633 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 634 RFC5234, January 2008, 635 . 637 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 638 Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10 639 .17487/RFC5785, April 2010, 640 . 642 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 643 Verification of Domain-Based Application Service Identity 644 within Internet Public Key Infrastructure Using X.509 645 (PKIX) Certificates in the Context of Transport Layer 646 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 647 2011, . 649 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 650 Opportunistic DNS-Based Authentication of Named Entities 651 (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10 652 .17487/RFC7672, October 2015, 653 . 655 12.2. URIs 657 [1] https://mta-sts.example.com/.well-known/mta-sts.json: 659 Authors' Addresses 661 Daniel Margolis 662 Google, Inc 664 Email: dmargolis (at) google.com 665 Mark Risher 666 Google, Inc 668 Email: risher (at) google (dot com) 670 Binu Ramakrishnan 671 Yahoo!, Inc 673 Email: rbinu (at) yahoo-inc (dot com) 675 Alexander Brotman 676 Comcast, Inc 678 Email: alexander_brotman (at) cable.comcast (dot com) 680 Janet Jones 681 Microsoft, Inc 683 Email: janet.jones (at) microsoft (dot com)