idnits 2.17.1 draft-ietf-uta-smtp-require-tls-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 7, 2017) is 2452 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'MailParams' ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMTPStatusCodes' == Outdated reference: A later version (-21) exists of draft-ietf-uta-mta-sts-07 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Fenton 3 Internet-Draft Altmode Networks 4 Intended status: Standards Track August 7, 2017 5 Expires: February 8, 2018 7 SMTP Require TLS Option 8 draft-ietf-uta-smtp-require-tls-00 10 Abstract 12 The SMTP STARTTLS option, used in negotiating transport-level 13 encryption of SMTP connections, is not as useful from a security 14 standpoint as it might be because of its opportunistic nature; 15 message delivery is prioritized over security. This document 16 describes a complementary SMTP service extension, REQUIRETLS. If the 17 REQUIRETLS option is used when sending a message, it asserts a 18 request on the part of the message sender to override the default 19 negotiation of TLS, either by requiring that TLS be negotiated when 20 the message is relayed, or by requesting that policy mechanisms such 21 as SMTP STS and DANE be ignored when relaying a high priority 22 message. 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 February 8, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 3 61 3. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 5 62 3.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 5 63 3.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 5 64 3.2.1. Sending with TLS Required . . . . . . . . . . . . . . 5 65 3.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 6 66 3.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 7 67 3.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 7 68 4. Non-delivery message handling . . . . . . . . . . . . . . . . 7 69 5. Mailing list considerations . . . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 9 73 7.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 9 74 7.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 9. Revision History . . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Changes since fenton-03 Draft . . . . . . . . . . . . . . 10 78 9.2. Changes Since -02 Draft . . . . . . . . . . . . . . . . . 10 79 9.3. Changes Since -01 Draft . . . . . . . . . . . . . . . . . 10 80 9.4. Changes Since -00 Draft . . . . . . . . . . . . . . . . . 11 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 10.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a 89 means by which an SMTP server and client can establish a Transport 90 Layer Security (TLS) protected session for the transmission of email 91 messages. By default, TLS is used only upon mutual agreement 92 (successful negotiation) of STARTTLS between the client and server; 93 if this is not possible, the message is sent without transport 94 encryption. Furthermore, it is common practice for the client to 95 negotiate TLS even if the SMTP server's certificate fails to 96 authenticate it. 98 Policy mechanisms such as DANE [RFC7672] and SMTP STS 99 [I-D.ietf-uta-mta-sts] may impose requirements for the use of TLS for 100 email destined for some domains. However, such policies do not allow 101 the sender to specify which messages are more sensitive and require 102 transport-level encryption, and which ones are urgent and ought to be 103 relayed even if TLS cannot be negotiated successfully. 105 The default opportunistic nature of SMTP TLS enables several "on the 106 wire" attacks on SMTP security between MTAs. These include passive 107 eavesdropping on connections for which TLS is not used, interference 108 in the SMTP protocol to prevent TLS from being negotiated (presumably 109 followed by eavesdropping), and insertion of a man-in-the-middle 110 attacker taking advantage of the lack of server authentication by the 111 client. Attacks are described in more detail in the Security 112 Considerations section of this document. 114 The REQUIRETLS SMTP service extension allows the SMTP client to 115 specify that a given message sent during a particular session MUST be 116 sent over a TLS protected session with specified security 117 characteristics, or conversely that delivery should be prioritized 118 over ability to negotiate TLS. For messages requiring TLS 119 negotiation, it also requires that the SMTP server advertise that it 120 supports REQUIRETLS, in effect promising that it will honor the 121 requirement to enforce TLS transmission and REQUIRETLS support for 122 onward transmission of those messages. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. The REQUIRETLS Service Extension 132 1. The textual name of the extension is "Require TLS". 134 2. The EHLO keyword value associated with this extension is 135 "REQUIRETLS". 137 3. One MAIL FROM option is defined by this extension. 139 4. Two new SMTP status codes are defined by this extension to convey 140 error conditions resulting from failure of the client to 141 negotiate a TLS connection with the required security and as a 142 result of an attempt to send to a server not also supporting the 143 REQUIRETLS extension. 145 In order to specify REQUIRETLS treatment for a given message, the 146 REQUIRETLS option is specified on the MAIL FROM command when that 147 message is transmitted. With the exception of REQUIRETLS=NO 148 (described below), this option MUST only be specified in the context 149 of an SMTP session meeting the security requirements that have been 150 specified: 152 o The session itself MUST employ TLS transmission, unless the NO 153 parameter is specified. 155 o Any server authentication requirements included as an option to 156 the REQUIRETLS option (see below) MUST have been satisfied in 157 establishing the current session. 159 o The SMTP server advertises that it supports REQUIRETLS. 161 An optional parameter to the REQUIRETLS MAIL FROM option specifies 162 the requirements for server authentication that MUST be used for any 163 onward transmission of the following message. The parameter takes 164 the form of either a single value or comma-separated list, separated 165 from the REQUIRETLS option by a single "=" (equals-sign) character. 166 If present, the parameter MUST take one or more of the following 167 values: 169 o CHAIN - The certificate presented by the SMTP server MUST verify 170 successfully in a trust chain leading to a certificate trusted by 171 the SMTP client. The choice of trusted (root) certificates by the 172 client is at their own discretion. The client MAY choose to use 173 the certificate set maintained by the CA/B forum [citation needed] 174 for this purpose. 176 o DANE - The certificate presented by the SMTP server MUST verify 177 succesfully using DANE as specified in RFC 7672 [RFC7672]. 179 o DNSSEC - The server MUST confirm that any MX record or CNAME 180 lookup used to locate the SMTP server must be DNSSEC [RFC4035] 181 signed and valid. 183 o NO - The SMTP client SHOULD attempt to send the message regardless 184 of its ability to negotiate STARTTLS with the SMTP server, 185 ignoring policy-based mechanisms, if any, asserted by the 186 recipient domain. Nevertheless, the client MAY negotiate STARTTLS 187 with the server if available. If the NO parameter is present, any 188 other REQUIRETLS parameter MUST NOT be used. 190 The CHAIN and DANE parameters are additive; if both are specified, 191 either method of certificate validation is acceptable. If neither 192 CHAIN nor DANE is specified, the certificate presented by the SMTP 193 server is not required to be verified. 195 3. REQUIRETLS Semantics 197 3.1. REQUIRETLS Receipt Requirements 199 Upon receipt of the REQUIRETLS option on a MAIL FROM command during 200 the receipt of a message, an SMTP server MUST tag that message as 201 needing REQUIRETLS handling with the specified option(s). The manner 202 in which this tagging takes place is implementation-dependent. If 203 the message is being locally aliased and redistributed to multiple 204 addresses, all instances of the message MUST be tagged in the same 205 manner. 207 3.2. REQUIRETLS Sender Requirements 209 3.2.1. Sending with TLS Required 211 When sending a message tagged with REQUIRETLS other than the 212 REQUIRETLS=NO option, the sending (client) MTA MUST: 214 1. Look up the SMTP server to which the message is to be sent as 215 described in [RFC5321] Section 5.1. If the DNSSEC option is 216 included in the message tag, the MX record lookups in this 217 process MUST use DNSSEC verification and the response(s) MUST be 218 DNSSEC-signed in order to ensure the integrity of the resource 219 identifier [RFC6125] used to authenticate the SMTP server. 221 2. Open an SMTP session with the peer SMTP server using the EHLO 222 verb. The server MUST advertise the REQUIRETLS capability. 224 3. Establish a TLS-protected SMTP session with its peer SMTP server 225 and authenticate the server's certificate with the specified 226 authentication method as specified in [RFC6125] or [RFC6698] as 227 applicable. 229 4. The SMTP client SHOULD also require that meaningfully secure 230 cipher algorithms and key lengths be negotiated with the server. 231 The choices of key lengths and algorithms change over time, so a 232 specific requirement is not presented here. 234 If any of the above steps fail, the client SHOULD issue a QUIT to the 235 server and repeat steps 2-4 with each host on the recipient domain's 236 list of MX hosts in an attempt to find a mail path that meets the 237 sender's requirements. If there are no more MX hosts or if the MX 238 record lookup is not DNSSEC-protected and DNSSEC verification is 239 required, the client MUST NOT transmit the message and MUST issue an 240 SMTP QUIT command to the server. The client MAY send other, 241 unprotected, messages to that server prior to issuing the QUIT if it 242 has any. 244 Following such a failure, the SMTP client MUST send a non-delivery 245 notification to the reverse-path of the failed message as described 246 in section 3.6 of [RFC5321]. The following status codes [RFC5248] 247 SHOULD be used: 249 o DNSSEC lookup failure: 5.x.x DNSSEC lookup required 251 o REQUIRETLS not supported by server: 5.7.x REQUIRETLS needed 253 o Unable to establish TLS-protected SMTP session: 5.7.10 Encryption 254 needed 256 Refer to Section 4. for further requirements regarding non-delivery 257 messages. 259 If all REQUIRETLS requirements have been met, transmit the message, 260 issuing the REQUIRETLS option on the MAIL FROM command with the 261 required option(s), if any. 263 3.2.2. Sending with TLS Optional 265 Messages tagged REQUIRETLS=NO are handled differently from other 266 REQUIRETLS messages, as follows. When sending a message tagged with 267 REQUIRETLS=NO, the sending (client) MTA MUST: 269 o Look up the SMTP server to which the message is to be sent as 270 described in [RFC5321] Section 5.1. 272 o Open an SMTP session with the peer SMTP server using the EHLO 273 verb. Attempt to negotiate STARTTLS if possible, and follow any 274 policy published by the recipient domain, but do not fail if this 275 is unsuccessful. 277 o If the server does not advertise the REQUIRETLS capability, send 278 the message in the usual manner (without the REQUIRETLS option, 279 because the server will not understand the option). 281 o If the server advertises the REQUIRETLS capability, send the 282 message with the REQUIRETLS=NO option. 284 Some SMTP servers that are configured to expect STARTTLS connections 285 as a matter of policy may not accept messages in the absence of 286 STARTTLS. This MUST be expected, and a non-delivery notification 287 returned to the sender. 289 Messages tagged with the REQUIRETLS=NO option will be sent without 290 the option to SMTP servers not supporting REQUIRETLS. REQUIRETLS=NO 291 MAY therefore not persist through multiple email relay hops. 293 3.3. REQUIRETLS Submission 295 An MUA or other agent making the initial introduction of a message to 296 SMTP has authority to decide whether to require TLS, and if so, using 297 what authentication method(s). It does so by issuing the REQUIRETLS 298 option in the MAIL FROM command during message submission. This MAY 299 be done based on a user interface selection, on a header field 300 included in the message, or based on policy. The manner in which the 301 decision to require TLS is made is implementation-dependent and is 302 beyond the scope of this specification. 304 3.4. Delivery of REQUIRETLS messages 306 Messages are usually retrieved by end users using protocols other 307 than SMTP such as IMAP [RFC3501], POP [RFC1939], or web mail systems. 308 Mail delivery agents supporting REQUIRETLS SHOULD require that 309 retrieval of messages requiring transport encryption take place over 310 authenticated, encrypted channels. 312 4. Non-delivery message handling 314 Non-delivery ("bounce") messages usually contain important metadata 315 about the message to which they refer, including the original message 316 header. They therefore MUST be protected in the same manner as the 317 original message. All non-delivery messages, whether resulting from 318 a REQUIRETLS error or some other, MUST employ REQUIRETLS using the 319 same authentication method(s) as the message that caused the error to 320 occur. 322 It should be noted that the path from the origination of an error 323 bounce message back to the MAIL FROM address may not share the same 324 REQUIRETLS support as the forward path. Therefore, users of 325 REQUIRETLS (other than REQUIRETLS=NO) are advised to make sure that 326 they are capable of receiving mail using REQUIRETLS at the same 327 authentication method(s) as messages they send. Otherwise, such non- 328 delivery messages will be lost. 330 If unable to send a bounce message due to a REQUIRETLS failure (the 331 return path not supporting the TLS requirements in the original 332 message), the MTA sending the bounce message MAY send a redacted non- 333 delivery message to the postmaster of the domain identified in the 334 envelope-From address identifying the message only by Message-ID and 335 indicating the type of failure. The original From, Return-path, To, 336 Sender, Cc, and related header fields MUST NOT be included in this 337 message. 339 Senders of messages specifying REQUIRETLS (other than REQUIRETLS=NO) 340 are advised to consider the increased likelihood that bounce messages 341 will be lost as a result of REQUIRETLS return path failure. 343 5. Mailing list considerations 345 Mailing lists, upon receipt of a message, originate new messages to 346 list addresses, as distinct from an aliasing operation that redirects 347 the original message, in some cases to multiple recipients. The 348 requirement to preserve the REQUIRETLS tag and options therefore does 349 not extend to mailing lists. REQUIRETLS users SHOULD be made aware 350 of this limitation so that they use caution when sending to mailing 351 lists and do not assume that REQUIRETLS applies to messages from the 352 list operator to list members. 354 Mailing list operators MAY apply REQUIRETLS requirements in incoming 355 messages to the resulting messages they originate. If this is done, 356 they SHOULD also apply these requirements to administrative traffic, 357 such as messages to moderators requesting approval of messages. 359 6. IANA Considerations 361 If published as an RFC, this draft requests the addition of the 362 keyword REQUIRETLS to the SMTP Service Extensions Registry 363 [MailParams]. 365 If published as an RFC, this draft also requests the creation of a 366 registry, REQUIRETLS Security Requirements, to be initially populated 367 with the CHAIN, DANE, DNSSEC, and NO keywords. 369 If published as an RFC, this draft requests the addition of an entry 370 to the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes 371 Registry [SMTPStatusCodes] in the 5.7.YYY range to indicate lack of 372 REQUIRETLS support by an SMTP server to which a message is being 373 routed. 375 This section is to be removed during conversion into an RFC by the 376 RFC Editor. 378 7. Security Considerations 380 The purpose of REQUIRETLS is to improve communications security for 381 email by giving the originator of a message an expectation that it 382 will be transmitted in an encrypted form "over the wire". When used, 383 REQUIRETLS changes the traditional behavior of email transmission, 384 which favors delivery over the ability to send email messages using 385 transport-layer security, to one in which requested security takes 386 precedence over delivery and domain-level policy. 388 The following considerations apply to STARTTLS other than the 389 STARTTLS=NO option, since messages specifying that option are 390 specifying less concern with transport security. 392 7.1. Passive attacks 394 REQUIRETLS is generally effective against passive attackers who are 395 merely trying to eavesdrop on an SMTP exchange between an SMTP client 396 and server. This assumes, of course, the cryptographic integrity of 397 the TLS connection being used. 399 7.2. Active attacks 401 Active attacks against TLS encrypted SMTP connections can take many 402 forms. One such attack is to interfere in the negotiation by 403 changing the STARTTLS command to something illegal such as XXXXXXXX. 404 This causes TLS negotiation to fail and messages to be sent in the 405 clear, where they can be intercepted. REQUIRETLS detects the failure 406 of STARTTLS and declines to send the message rather than send it 407 insecurely. 409 A second form of attack is a man-in-the-middle attack where the 410 attacker terminates the TLS connection rather than the intended SMTP 411 server. This is possible when, as is commonly the case, the SMTP 412 client either does not verify the server's certificate or establishes 413 the connection even when the verification fails. The REQUIRETLS 414 CHAIN and DANE options allow the message sender to specify that 415 successful certificate validation, using either or both of two 416 different methods, is required before sending the message. 418 Another active attack involves the spoofing of DNS MX records of the 419 recipient domain. An attacker having this capability could cause the 420 message to be redirected to a mail server under the attacker's own 421 control, which would presumably have a valid certificate. The 422 REQUIRETLS DNSSEC option allows the message sender to require that 423 valid DNSSEC [RFC4033] signatures be obtained when locating the 424 recipient's mail server, in order to address that attack. 426 In addition to support of the DNSSEC option, domains receiving email 427 SHOULD deploy DNSSEC and SMTP clients SHOULD deploy DNSSEC 428 verification. 430 7.3. Bad Actor MTAs 432 A bad-actor MTA along the message transmission path could 433 misrepresent its support of REQUIRETLS and/or actively strip 434 REQUIRETLS tags from messages it handles. However, since 435 intermediate MTAs are already trusted with the cleartext of messages 436 they handle, and are not part of the threat model for transport-layer 437 security, they are also not part of the threat model for REQUIRETLS. 439 It should be reemphasized that since SMTP TLS is a transport-layer 440 security protocol, messages sent using REQUIRETLS are not encrypted 441 end-to-end and are visible to MTAs that are part of the message 442 delivery path. Messages containing sensitive information that MTAs 443 should not have access to MUST be sent using end-to-end content 444 encryption such as OpenPGP [RFC4880] or S/MIME [RFC5751]. 446 8. Acknowledgements 448 The author would like to acknowledge many helpful suggestions on the 449 ietf-smtp and uta mailing lists, in particular those of Viktor 450 Dukhovni, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin, 451 John Levine, Rolf Sonneveld, and Per Thorsheim. 453 9. Revision History 455 To be removed by RFC Editor upon publication as an RFC. 457 9.1. Changes since fenton-03 Draft 459 o Wording improvements from Rolf Sonneveld review 22 July 2017 461 o A few copy edits 463 o Conversion from individual to UTA WG draft 465 9.2. Changes Since -02 Draft 467 o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per 468 suggestion on UTA WG mailing list. 470 o Additional guidance on bounce messages 472 9.3. Changes Since -01 Draft 474 o Specified retries when multiple MX hosts exist for a given domain. 476 o Clarified generation of non-delivery messages 477 o Specified requirements for application of REQUIRETLS to mail 478 forwarders and mailing lists. 480 o Clarified DNSSEC requirements to include MX lookup only. 482 o Corrected terminology regarding message retrieval vs. delivery. 484 o Changed category to standards track. 486 9.4. Changes Since -00 Draft 488 o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM 489 parameter to better associate REQUIRETLS requirements with 490 transmission of individual messages. 492 o Addition of an option to require DNSSEC lookup of the remote mail 493 server, since this affects the common name of the certificate that 494 is presented. 496 o Clarified the wording to more clearly state that TLS sessions must 497 be established and not simply that STARTTLS is negotiated. 499 o Introduced need for minimum encryption standards (key lengths and 500 algorithms) 502 o Substantially rewritten Security Considerations section 504 10. References 506 10.1. Normative References 508 [MailParams] 509 Internet Assigned Numbers Authority (IANA), "IANA Mail 510 Parameters", 2007, 511 . 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, 515 DOI 10.17487/RFC2119, March 1997, 516 . 518 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 519 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 520 February 2002, . 522 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 523 Rose, "Protocol Modifications for the DNS Security 524 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 525 . 527 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 528 Mail System Status Codes", BCP 138, RFC 5248, 529 DOI 10.17487/RFC5248, June 2008, 530 . 532 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 533 DOI 10.17487/RFC5321, October 2008, 534 . 536 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 537 Verification of Domain-Based Application Service Identity 538 within Internet Public Key Infrastructure Using X.509 539 (PKIX) Certificates in the Context of Transport Layer 540 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 541 2011, . 543 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 544 of Named Entities (DANE) Transport Layer Security (TLS) 545 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 546 2012, . 548 [SMTPStatusCodes] 549 Internet Assigned Numbers Authority (IANA), "Simple Mail 550 Transfer Protocol (SMTP) Enhanced Status Codes Registry", 551 2008, . 554 10.2. Informative References 556 [I-D.ietf-uta-mta-sts] 557 Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., 558 and J. Jones, "SMTP MTA Strict Transport Security (MTA- 559 STS)", draft-ietf-uta-mta-sts-07 (work in progress), June 560 2017. 562 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 563 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 564 . 566 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 567 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 568 . 570 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 571 Rose, "DNS Security Introduction and Requirements", 572 RFC 4033, DOI 10.17487/RFC4033, March 2005, 573 . 575 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 576 Thayer, "OpenPGP Message Format", RFC 4880, 577 DOI 10.17487/RFC4880, November 2007, 578 . 580 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 581 Mail Extensions (S/MIME) Version 3.2 Message 582 Specification", RFC 5751, DOI 10.17487/RFC5751, January 583 2010, . 585 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 586 Opportunistic DNS-Based Authentication of Named Entities 587 (DANE) Transport Layer Security (TLS)", RFC 7672, 588 DOI 10.17487/RFC7672, October 2015, 589 . 591 Author's Address 593 Jim Fenton 594 Altmode Networks 595 Los Altos, California 94024 596 USA 598 Email: fenton@bluepopcorn.net