From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8314.txt | 1459 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1459 insertions(+) create mode 100644 doc/rfc/rfc8314.txt (limited to 'doc/rfc/rfc8314.txt') diff --git a/doc/rfc/rfc8314.txt b/doc/rfc/rfc8314.txt new file mode 100644 index 0000000..2abaa77 --- /dev/null +++ b/doc/rfc/rfc8314.txt @@ -0,0 +1,1459 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Moore +Request for Comments: 8314 Windrock, Inc. +Updates: 1939, 2595, 3501, 5068, 6186, 6409 C. Newman +Category: Standards Track Oracle +ISSN: 2070-1721 January 2018 + + + Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) + for Email Submission and Access + +Abstract + + This specification outlines current recommendations for the use of + Transport Layer Security (TLS) to provide confidentiality of email + traffic between a Mail User Agent (MUA) and a Mail Submission Server + or Mail Access Server. This document updates RFCs 1939, 2595, 3501, + 5068, 6186, and 6409. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8314. + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Moore & Newman Standards Track [Page 1] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. How This Document Updates Previous RFCs ....................3 + 2. Conventions and Terminology Used in This Document ...............4 + 3. Implicit TLS ....................................................5 + 3.1. Implicit TLS for POP .......................................5 + 3.2. Implicit TLS for IMAP ......................................5 + 3.3. Implicit TLS for SMTP Submission ...........................6 + 3.4. Implicit TLS Connection Closure for POP, IMAP, and + SMTP Submission ............................................7 + 4. Use of TLS by Mail Access Servers and Message Submission + Servers .........................................................7 + 4.1. Deprecation of Services Using Cleartext and TLS Versions + Less Than 1.1 ..............................................8 + 4.2. Mail Server Use of Client Certificate Authentication .......9 + 4.3. Recording TLS Ciphersuite in "Received" Header Field .......9 + 4.4. TLS Server Certificate Requirements .......................10 + 4.5. Recommended DNS Records for Mail Protocol Servers .........11 + 4.5.1. MX Records .........................................11 + 4.5.2. SRV Records ........................................11 + 4.5.3. DNSSEC .............................................11 + 4.5.4. TLSA Records .......................................11 + 4.6. Changes to Internet-Facing Servers ........................11 + 5. Use of TLS by Mail User Agents .................................12 + 5.1. Use of SRV Records in Establishing Configuration ..........13 + 5.2. Minimum Confidentiality Level .............................14 + 5.3. Certificate Validation ....................................15 + 5.4. Certificate Pinning .......................................15 + 5.5. Client Certificate Authentication .........................16 + 6. Considerations Related to Antivirus/Antispam Software + and Services ...................................................17 + 7. IANA Considerations ............................................17 + 7.1. POP3S Port Registration Update ............................17 + 7.2. IMAPS Port Registration Update ............................18 + 7.3. Submissions Port Registration .............................18 + 7.4. Additional Registered Clauses for "Received" Fields .......19 + 8. Security Considerations ........................................19 + 9. References .....................................................20 + 9.1. Normative References ......................................20 + 9.2. Informative References ....................................22 + Appendix A. Design Considerations .................................24 + Acknowledgements ..................................................26 + Authors' Addresses ................................................26 + + + + + + + +Moore & Newman Standards Track [Page 2] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +1. Introduction + + Software that provides email service via the Internet Message Access + Protocol (IMAP) [RFC3501], the Post Office Protocol (POP) [RFC1939], + and/or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] + usually has Transport Layer Security (TLS) [RFC5246] support but + often does not use it in a way that maximizes end-user + confidentiality. This specification describes current + recommendations for the use of TLS in interactions between Mail User + Agents (MUAs) and Mail Access Servers, and also between MUAs and Mail + Submission Servers. + + In brief, this memo now recommends that: + + o TLS version 1.2 or greater be used for all traffic between MUAs + and Mail Submission Servers, and also between MUAs and Mail Access + Servers. + + o MUAs and Mail Service Providers (MSPs) (a) discourage the use of + cleartext protocols for mail access and mail submission and + (b) deprecate the use of cleartext protocols for these purposes as + soon as practicable. + + o Connections to Mail Submission Servers and Mail Access Servers be + made using "Implicit TLS" (as defined below), in preference to + connecting to the "cleartext" port and negotiating TLS using the + STARTTLS command or a similar command. + + This memo does not address the use of TLS with SMTP for message relay + (where Message Submission [RFC6409] does not apply). Improving the + use of TLS with SMTP for message relay requires a different approach. + One approach to address that topic is described in [RFC7672]; another + is provided in [MTA-STS]. + + The recommendations in this memo do not replace the functionality of, + and are not intended as a substitute for, end-to-end encryption of + electronic mail. + +1.1. How This Document Updates Previous RFCs + + This document updates POP (RFC 1939), IMAP (RFC 3501), and Submission + (RFC 6409, RFC 5068) in two ways: + + 1. By adding Implicit TLS ports as Standards Track ports for these + protocols as described in Section 3. + + 2. By updating TLS best practices that apply to these protocols as + described in Sections 4 and 5. + + + +Moore & Newman Standards Track [Page 3] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + This document updates RFC 2595 by replacing Section 7 of RFC 2595 + with the preference for Implicit TLS as described in Sections 1 and 3 + of this document, as well as by updating TLS best practices that + apply to the protocols in RFC 2595 as described in Sections 4 and 5 + of this document. + + This document updates RFC 6186 as described herein, in Section 5.1. + +2. Conventions and Terminology Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The term "Implicit TLS" refers to the automatic negotiation of TLS + whenever a TCP connection is made on a particular TCP port that is + used exclusively by that server for TLS connections. The term + "Implicit TLS" is intended to contrast with the use of STARTTLS and + similar commands in POP, IMAP, SMTP Message Submission, and other + protocols, that are used by the client and the server to explicitly + negotiate TLS on an established cleartext TCP connection. + + The term "Mail Access Server" refers to a server for POP, IMAP, and + any other protocol used to access or modify received messages, or to + access or modify a mail user's account configuration. + + The term "Mail Submission Server" refers to a server for the protocol + specified in [RFC6409] (or one of its predecessors or successors) for + submission of outgoing messages for delivery to recipients. + + The term "Mail Service Provider" (or "MSP") refers to an operator of + Mail Access Servers and/or Mail Submission Servers. + + The term "Mail Account" refers to a user's identity with an MSP, that + user's authentication credentials, any user email that is stored by + the MSP, and any other per-user configuration information maintained + by the MSP (for example, instructions for filtering spam). Most MUAs + support the ability to access multiple Mail Accounts. + + For each account that an MUA accesses on its user's behalf, it must + have the server names, ports, authentication credentials, and other + configuration information specified by the user. This information, + which is used by the MUA, is referred to as "Mail Account + Configuration". + + + + + +Moore & Newman Standards Track [Page 4] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + This specification expresses syntax using the Augmented Backus-Naur + Form (ABNF) as described in [RFC5234], including the core rules + provided in Appendix B of [RFC5234] and the rules provided in + [RFC5322]. + +3. Implicit TLS + + Previous standards for the use of email protocols with TLS used the + STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With + STARTTLS, the client establishes a cleartext application session and + determines whether to issue a STARTTLS command based on server + capabilities and client configuration. If the client issues a + STARTTLS command, a TLS handshake follows that can upgrade the + connection. Although this mechanism has been deployed, an alternate + mechanism where TLS is negotiated immediately at connection start on + a separate port (referred to in this document as "Implicit TLS") has + been deployed more successfully. To encourage more widespread use of + TLS and to also encourage greater consistency regarding how TLS is + used, this specification now recommends the use of Implicit TLS for + POP, IMAP, SMTP Submission, and all other protocols used between an + MUA and an MSP. + +3.1. Implicit TLS for POP + + When a TCP connection is established for the "pop3s" service (default + port 995), a TLS handshake begins immediately. Clients MUST + implement the certificate validation mechanism described in + [RFC7817]. Once the TLS session is established, POP3 [RFC1939] + protocol messages are exchanged as TLS application data for the + remainder of the TCP connection. After the server sends an +OK + greeting, the server and client MUST enter the AUTHORIZATION state, + even if a client certificate was supplied during the TLS handshake. + + See Sections 5.5 and 4.2 for additional information on client + certificate authentication. See Section 7.1 for port registration + information. + +3.2. Implicit TLS for IMAP + + When a TCP connection is established for the "imaps" service (default + port 993), a TLS handshake begins immediately. Clients MUST + implement the certificate validation mechanism described in + [RFC7817]. Once the TLS session is established, IMAP [RFC3501] + protocol messages are exchanged as TLS application data for the + remainder of the TCP connection. If a client certificate was + provided during the TLS handshake that the server finds acceptable, + the server MAY issue a PREAUTH greeting, in which case both the + + + + +Moore & Newman Standards Track [Page 5] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + server and the client enter the AUTHENTICATED state. If the server + issues an OK greeting, then both the server and the client enter the + NOT AUTHENTICATED state. + + See Sections 5.5 and 4.2 for additional information on client + certificate authentication. See Section 7.2 for port registration + information. + +3.3. Implicit TLS for SMTP Submission + + When a TCP connection is established for the "submissions" service + (default port 465), a TLS handshake begins immediately. Clients MUST + implement the certificate validation mechanism described in + [RFC7817]. Once the TLS session is established, Message Submission + protocol data [RFC6409] is exchanged as TLS application data for the + remainder of the TCP connection. (Note: The "submissions" service + name is defined in Section 7.3 of this document and follows the usual + convention that the name of a service layered on top of Implicit TLS + consists of the name of the service as used without TLS, with an "s" + appended.) + + The STARTTLS mechanism on port 587 is relatively widely deployed due + to the situation with port 465 (discussed in Section 7.3). This + differs from IMAP and POP services where Implicit TLS is more widely + deployed on servers than STARTTLS. It is desirable to migrate core + protocols used by MUA software to Implicit TLS over time, for + consistency as well as for the additional reasons discussed in + Appendix A. However, to maximize the use of encryption for + submission, it is desirable to support both mechanisms for Message + Submission over TLS for a transition period of several years. As a + result, clients and servers SHOULD implement both STARTTLS on + port 587 and Implicit TLS on port 465 for this transition period. + Note that there is no significant difference between the security + properties of STARTTLS on port 587 and Implicit TLS on port 465 if + the implementations are correct and if both the client and the server + are configured to require successful negotiation of TLS prior to + Message Submission. + + Note that the "submissions" port provides access to a Message + Submission Agent (MSA) as defined in [RFC6409], so requirements and + recommendations for MSAs in that document, including the requirement + to implement SMTP AUTH [RFC4954] and the requirements of Email + Submission Operations [RFC5068], also apply to the submissions port. + + See Sections 5.5 and 4.2 for additional information on client + certificate authentication. See Section 7.3 for port registration + information. + + + + +Moore & Newman Standards Track [Page 6] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +3.4. Implicit TLS Connection Closure for POP, IMAP, and SMTP Submission + + When a client or server wishes to close the connection, it SHOULD + initiate the exchange of TLS close alerts before TCP connection + termination. The client MAY, after sending a TLS close alert, + gracefully close the TCP connection (e.g., call the close() function + on the TCP socket or otherwise issue a TCP CLOSE ([RFC793], + Section 3.5)) without waiting for a TLS response from the server. + +4. Use of TLS by Mail Access Servers and Message Submission Servers + + The following requirements and recommendations apply to Mail Access + Servers and Mail Submission Servers, or, if indicated, to MSPs: + + o MSPs that support POP, IMAP, and/or Message Submission MUST + support TLS access for those protocol servers. + + o Servers provided by MSPs other than POP, IMAP, and/or Message + Submission SHOULD support TLS access and MUST support TLS access + for those servers that support authentication via username and + password. + + o MSPs that support POP, IMAP, and/or Message Submission SHOULD + provide and support instances of those services that use Implicit + TLS. (See Section 3.) + + o For compatibility with existing MUAs and existing MUA + configurations, MSPs SHOULD also, in the near term, provide + instances of these services that support STARTTLS. This will + permit legacy MUAs to discover new availability of TLS capability + on servers and may increase the use of TLS by such MUAs. However, + servers SHOULD NOT advertise STARTTLS if the use of the STARTTLS + command by a client is likely to fail (for example, if the server + has no server certificate configured). + + o MSPs SHOULD advertise their Mail Access Servers and Mail + Submission Servers, using DNS SRV records according to [RFC6186]. + (In addition to making correct configuration easier for MUAs, this + provides a way by which MUAs can discover when an MSP begins to + offer TLS-based services.) Servers supporting TLS SHOULD be + advertised in preference to cleartext servers (if offered). In + addition, servers using Implicit TLS SHOULD be advertised in + preference to servers supporting STARTTLS (if offered). (See also + Section 4.5.) + + o MSPs SHOULD deprecate the use of cleartext Mail Access Servers and + Mail Submission Servers as soon as practicable. (See + Section 4.1.) + + + +Moore & Newman Standards Track [Page 7] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + o MSPs currently supporting such use of cleartext SMTP (on port 25) + as a means of Message Submission by their users (whether or not + requiring authentication) SHOULD transition their users to using + TLS (either Implicit TLS or STARTTLS) as soon as practicable. + + o Mail Access Servers and Mail Submission Servers MUST support + TLS 1.2 or later. + + o All Mail Access Servers and Mail Submission Servers SHOULD + implement the recommended TLS ciphersuites described in [RFC7525] + or a future BCP or Standards Track revision of that document. + + o As soon as practicable, MSPs currently supporting Secure Sockets + Layer (SSL) 2.x, SSL 3.0, or TLS 1.0 SHOULD transition their users + to TLS 1.1 or later and discontinue support for those earlier + versions of SSL and TLS. + + o Mail Submission Servers accepting mail using TLS SHOULD include in + the Received field of the outgoing message the TLS ciphersuite of + the session in which the mail was received. (See Section 4.3.) + + o All Mail Access Servers and Mail Submission Servers implementing + TLS SHOULD log TLS cipher information along with any connection or + authentication logs that they maintain. + + Additional considerations and details appear below. + +4.1. Deprecation of Services Using Cleartext and TLS Versions + Less Than 1.1 + + The specific means employed for deprecation of cleartext Mail Access + Servers and Mail Submission Servers MAY vary from one MSP to the next + in light of their user communities' needs and constraints. For + example, an MSP MAY implement a gradual transition in which, over + time, more and more users are forbidden to authenticate to cleartext + instances of these servers, thus encouraging those users to migrate + to Implicit TLS. Access to cleartext servers should eventually be + either (a) disabled or (b) limited strictly for use by legacy systems + that cannot be upgraded. + + After a user's ability to authenticate to a server using cleartext is + revoked, the server denying such access MUST NOT provide any + indication over a cleartext channel of whether the user's + authentication credentials were valid. An attempt to authenticate as + such a user using either invalid credentials or valid credentials + MUST both result in the same indication of access being denied. + + + + + +Moore & Newman Standards Track [Page 8] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + Also, users previously authenticating with passwords sent as + cleartext SHOULD be required to change those passwords when migrating + to TLS, if the old passwords were likely to have been compromised. + (For any large community of users using the public Internet to access + mail without encryption, the compromise of at least some of those + passwords should be assumed.) + + Transition of users from SSL or TLS 1.0 to later versions of TLS MAY + be accomplished by a means similar to that described above. There + are multiple ways to accomplish this. One way is for the server to + refuse a ClientHello message from any client sending a + ClientHello.version field corresponding to any version of SSL or + TLS 1.0. Another way is for the server to accept ClientHello + messages from some client versions that it does not wish to support + but later refuse to allow the user to authenticate. The latter + method may provide a better indication to the user of the reason for + the failure but (depending on the protocol and method of + authentication used) may also risk exposure of the user's password + over a channel that is known to not provide adequate confidentiality. + + It is RECOMMENDED that new users be required to use TLS version 1.1 + or greater from the start. However, an MSP may find it necessary to + make exceptions to accommodate some legacy systems that support only + earlier versions of TLS or only cleartext. + +4.2. Mail Server Use of Client Certificate Authentication + + Mail Submission Servers and Mail Access Servers MAY implement client + certificate authentication on the Implicit TLS port. Such servers + MUST NOT request a client certificate during the TLS handshake unless + the server is configured to accept some client certificates as + sufficient for authentication and the server has the ability to + determine a mail server authorization identity matching such + certificates. How to make this determination is presently + implementation specific. + + If the server accepts the client's certificate as sufficient for + authorization, it MUST enable the Simple Authentication and Security + Layer (SASL) EXTERNAL mechanism [RFC4422]. An IMAPS server MAY issue + a PREAUTH greeting instead of enabling SASL EXTERNAL. + +4.3. Recording TLS Ciphersuite in "Received" Header Field + + The ESMTPS transmission type [RFC3848] provides trace information + that can indicate that TLS was used when transferring mail. However, + TLS usage by itself is not a guarantee of confidentiality or + security. The TLS ciphersuite provides additional information about + the level of security made available for a connection. This section + + + +Moore & Newman Standards Track [Page 9] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + defines a new SMTP "tls" Received header additional-registered-clause + that is used to record the TLS ciphersuite that was negotiated for + the connection. This clause SHOULD be included whenever a Submission + server generates a Received header field for a message received via + TLS. The value included in this additional clause SHOULD be the + registered ciphersuite name (e.g., + TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) included in the "TLS Cipher + Suite Registry". In the event that the implementation does not know + the name of the ciphersuite (a situation that should be remedied + promptly), a four-digit hexadecimal ciphersuite identifier MAY be + used. In addition, the Diffie-Hellman group name associated with the + ciphersuite MAY be included (when applicable and known) following the + ciphersuite name. The ABNF for the field follows: + + tls-cipher-clause = CFWS "tls" FWS tls-cipher + [ CFWS tls-dh-group-clause ] + + tls-cipher = tls-cipher-name / tls-cipher-hex + + tls-cipher-name = ALPHA *(ALPHA / DIGIT / "_") + ; as registered in the IANA "TLS Cipher Suite Registry" + ; + + tls-cipher-hex = "0x" 4HEXDIG + + tls-dh-group-clause = "group" FWS dh-group + ; not to be used except immediately after tls-cipher + + dh-group = ALPHA *(ALPHA / DIGIT / "_" / "-") + ; as registered in the IANA "TLS Supported Groups Registry" + ; + +4.4. TLS Server Certificate Requirements + + MSPs MUST maintain valid server certificates for all servers. See + [RFC7817] for the recommendations and requirements necessary to + achieve this. + + If a protocol server provides service for more than one mail domain, + it MAY use a separate IP address for each domain and/or a server + certificate that advertises multiple domains. This will generally be + necessary unless and until it is acceptable to impose the constraint + that the server and all clients support the Server Name Indication + (SNI) extension to TLS [RFC6066]. Mail servers supporting the SNI + need to support the post-SRV hostname to interoperate with MUAs that + have not implemented [RFC6186]. For more discussion of this problem, + see Section 5.1 of [RFC7817]. + + + + +Moore & Newman Standards Track [Page 10] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +4.5. Recommended DNS Records for Mail Protocol Servers + + This section discusses not only the DNS records that are recommended + but also implications of DNS records for server configuration and TLS + server certificates. + +4.5.1. MX Records + + It is recommended that MSPs advertise MX records for the handling of + inbound mail (instead of relying entirely on A or AAAA records) and + that those MX records be signed using DNSSEC [RFC4033]. This is + mentioned here only for completeness, as the handling of inbound mail + is out of scope for this document. + +4.5.2. SRV Records + + MSPs SHOULD advertise SRV records to aid MUAs in determining the + proper configuration of servers, per the instructions in [RFC6186]. + + MSPs SHOULD advertise servers that support Implicit TLS in preference + to servers that support cleartext and/or STARTTLS operation. + +4.5.3. DNSSEC + + All DNS records advertised by an MSP as a means of aiding clients in + communicating with the MSP's servers SHOULD be signed using DNSSEC if + and when the parent DNS zone supports doing so. + +4.5.4. TLSA Records + + MSPs SHOULD advertise TLSA records to provide an additional trust + anchor for public keys used in TLS server certificates. However, + TLSA records MUST NOT be advertised unless they are signed using + DNSSEC. + +4.6. Changes to Internet-Facing Servers + + When an MSP changes the Internet-facing Mail Access Servers and Mail + Submission Servers, including SMTP-based spam/virus filters, it is + generally necessary to support the same and/or a newer version of TLS + than the one previously used. + + + + + + + + + + +Moore & Newman Standards Track [Page 11] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +5. Use of TLS by Mail User Agents + + The following requirements and recommendations apply to MUAs: + + o MUAs SHOULD be capable of using DNS SRV records to discover Mail + Access Servers and Mail Submission Servers that are advertised by + an MSP for an account being configured. Other means of + discovering server configuration information (e.g., a database + maintained by the MUA vendor) MAY also be supported. (See + Section 5.1 for more information.) + + o MUAs SHOULD be configurable to require a minimum level of + confidentiality for any particular Mail Account and refuse to + exchange information via any service associated with that Mail + Account if the session does not provide that minimum level of + confidentiality. (See Section 5.2.) + + o MUAs MUST NOT treat a session as meeting a minimum level of + confidentiality if the server's TLS certificate cannot be + validated. (See Section 5.3.) + + o MUAs MAY impose other minimum confidentiality requirements in the + future, e.g., in order to discourage the use of TLS versions or + cryptographic algorithms in which weaknesses have been discovered. + + o MUAs SHOULD provide a prominent indication of the level of + confidentiality associated with an account configuration that is + appropriate for the user interface (for example, a "lock" icon or + changed background color for a visual interface, or some sort of + audible indication for an audio user interface), at appropriate + times and/or locations, in order to inform the user of the + confidentiality of the communications associated with that + account. For example, this might be done whenever (a) the user is + prompted for authentication credentials, (b) the user is composing + mail that will be sent to a particular submission server, (c) a + list of accounts is displayed (particularly if the user can select + from that list to read mail), or (d) the user is asking to view or + update any configuration data that will be stored on a remote + server. If, however, an MUA provides such an indication, it + MUST NOT indicate confidentiality for any connection that does not + at least use TLS 1.1 with certificate verification and also meet + the minimum confidentiality requirements associated with that + account. + + o MUAs MUST implement TLS 1.2 [RFC5246] or later. Earlier TLS and + SSL versions MAY also be supported, so long as the MUA requires at + least TLS 1.1 [RFC4346] when accessing accounts that are + configured to impose minimum confidentiality requirements. + + + +Moore & Newman Standards Track [Page 12] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + o All MUAs SHOULD implement the recommended TLS ciphersuites + described in [RFC7525] or a future BCP or Standards Track revision + of that document. + + o MUAs that are configured to not require minimum confidentiality + for one or more accounts SHOULD detect when TLS becomes available + on those accounts (using [RFC6186] or other means) and offer to + upgrade the account to require TLS. + + Additional considerations and details appear below. + +5.1. Use of SRV Records in Establishing Configuration + + This document updates [RFC6186] by changing the preference rules and + adding a new SRV service label _submissions._tcp to refer to Message + Submission with Implicit TLS. + + User-configurable MUAs SHOULD support the use of [RFC6186] for + account setup. However, when using configuration information + obtained via this method, MUAs SHOULD ignore advertised services that + do not satisfy minimum confidentiality requirements, unless the user + has explicitly requested reduced confidentiality. This will have the + effect of causing the MUA to default to ignoring advertised + configurations that do not support TLS, even when those advertised + configurations have a higher priority than other advertised + configurations. + + When using configuration information per [RFC6186], MUAs SHOULD NOT + automatically establish new configurations that do not require TLS + for all servers, unless there are no advertised configurations using + TLS. If such a configuration is chosen, prior to attempting to + authenticate to the server or use the server for Message Submission, + the MUA SHOULD warn the user that traffic to that server will not be + encrypted and that it will therefore likely be intercepted by + unauthorized parties. The specific wording is to be determined by + the implementation, but it should adequately capture the sense of + risk, given the widespread incidence of mass surveillance of email + traffic. + + Similarly, an MUA MUST NOT attempt to "test" a particular Mail + Account configuration by submitting the user's authentication + credentials to a server, unless a TLS session meeting minimum + confidentiality levels has been established with that server. If + minimum confidentiality requirements have not been satisfied, the MUA + must explicitly warn that the user's password may be exposed to + attackers before testing the new configuration. + + + + + +Moore & Newman Standards Track [Page 13] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + When establishing a new configuration for connecting to an IMAP, POP, + or SMTP submission server, based on SRV records, an MUA SHOULD verify + that either (a) the SRV records are signed using DNSSEC or (b) the + target Fully Qualified Domain Name (FQDN) of the SRV record matches + the original server FQDN for which the SRV queries were made. If the + target FQDN is not in the queried domain, the MUA SHOULD verify with + the user that the SRV target FQDN is suitable for use, before + executing any connections to the host. (See Section 6 of [RFC6186].) + + An MUA MUST NOT consult SRV records to determine which servers to use + on every connection attempt, unless those SRV records are signed by + DNSSEC and have a valid signature. However, an MUA MAY consult SRV + records from time to time to determine if an MSP's server + configuration has changed and alert the user if it appears that this + has happened. This can also serve as a means to encourage users to + upgrade their configurations to require TLS if and when their MSPs + support it. + +5.2. Minimum Confidentiality Level + + MUAs SHOULD, by default, require a minimum level of confidentiality + for services accessed by each account. For MUAs supporting the + ability to access multiple Mail Accounts, this requirement SHOULD be + configurable on a per-account basis. + + The default minimum expected level of confidentiality for all new + accounts MUST require successful validation of the server's + certificate and SHOULD require negotiation of TLS version 1.1 or + greater. (Future revisions to this specification may raise these + requirements or impose additional requirements to address newly + discovered weaknesses in protocols or cryptographic algorithms.) + + MUAs MAY permit the user to disable this minimum confidentiality + requirement during initial account configuration or when subsequently + editing an account configuration but MUST warn users that such a + configuration will not assure privacy for either passwords or + messages. + + An MUA that is configured to require a minimum level of + confidentiality for a Mail Account MUST NOT attempt to perform any + operation other than capability discovery, or STARTTLS for servers + not using Implicit TLS, unless the minimum level of confidentiality + is provided by that connection. + + MUAs SHOULD NOT allow users to easily access or send mail via a + connection, or authenticate to any service using a password, if that + account is configured to impose minimum confidentiality requirements + and that connection does not meet all of those requirements. An + + + +Moore & Newman Standards Track [Page 14] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + example of "easy access" would be to display a dialog informing the + user that the security requirements of the account were not met by + the connection but allowing the user to "click through" to send mail + or access the service anyway. Experience indicates that users + presented with such an option often "click through" without + understanding the risks that they're accepting by doing so. + Furthermore, users who frequently find the need to "click through" to + use an insecure connection may become conditioned to do so as a + matter of habit, before considering whether the risks are reasonable + in each specific instance. + + An MUA that is not configured to require a minimum level of + confidentiality for a Mail Account SHOULD still attempt to connect to + the services associated with that account using the most secure means + available, e.g., by using Implicit TLS or STARTTLS. + +5.3. Certificate Validation + + MUAs MUST validate TLS server certificates according to [RFC7817] and + PKIX [RFC5280]. + + MUAs MAY also support DNS-Based Authentication of Named Entities + (DANE) [RFC6698] as a means of validating server certificates in + order to meet minimum confidentiality requirements. + + MUAs MAY support the use of certificate pinning but MUST NOT consider + a connection in which the server's authenticity relies on certificate + pinning as providing the minimum level of confidentiality. (See + Section 5.4.) + +5.4. Certificate Pinning + + During account setup, the MUA will identify servers that provide + account services such as mail access and mail submission (Section 5.1 + describes one way to do this). The certificates for these servers + are verified using the rules described in [RFC7817] and PKIX + [RFC5280]. In the event that the certificate does not validate due + to an expired certificate, a lack of an appropriate chain of trust, + or a lack of an identifier match, the MUA MAY offer to create a + persistent binding between that certificate and the saved hostname + for the server, for use when accessing that account's servers. This + is called "certificate pinning". + + (Note: This use of the term "certificate pinning" means something + subtly different than HTTP Public Key Pinning as described in + [RFC7469]. The dual use of the same term is confusing, but + unfortunately both uses are well established.) + + + + +Moore & Newman Standards Track [Page 15] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + Certificate pinning is only appropriate during Mail Account setup and + MUST NOT be offered as an option in response to a failed certificate + validation for an existing Mail Account. An MUA that allows + certificate pinning MUST NOT allow a certificate pinned for one + account to validate connections for other accounts. An MUA that + allows certificate pinning MUST also allow a user to undo the + pinning, i.e., to revoke trust in a certificate that has previously + been pinned. + + A pinned certificate is subject to a man-in-the-middle attack at + account setup time and typically lacks a mechanism to automatically + revoke or securely refresh the certificate. Note also that a man-in- + the-middle attack at account setup time will expose the user's + password to the attacker (if a password is used). Therefore, the use + of a pinned certificate does not meet the requirement for a minimum + confidentiality level, and an MUA MUST NOT indicate to the user that + such confidentiality is provided. Additional advice on certificate + pinning is presented in [RFC6125]. + +5.5. Client Certificate Authentication + + MUAs MAY implement client certificate authentication on the Implicit + TLS port. An MUA MUST NOT provide a client certificate during the + TLS handshake unless the server requests one and the MUA has been + authorized to use that client certificate with that account. Having + the end user explicitly configure a client certificate for use with a + given account is sufficient to meet this requirement. However, + installing a client certificate for use with one account MUST NOT + automatically authorize the use of that certificate with other + accounts. This is not intended to prohibit site-specific + authorization mechanisms, such as (a) a site-administrator-controlled + mechanism to authorize the use of a client certificate with a given + account or (b) a domain-name-matching mechanism. + + Note: The requirement that the server request a certificate is just a + restatement of the TLS protocol rules, e.g., Section 7.4.6 of + [RFC5246]. The requirement that the client not send a certificate + not known to be acceptable to the server is pragmatic in multiple + ways: the current TLS protocol provides no way for the client to know + which of the potentially multiple certificates it should use; also, + when the client sends a certificate, it is potentially disclosing its + identity (or its user's identity) to both the server and any party + with access to the transmission medium, perhaps unnecessarily and for + no useful purpose. + + + + + + + +Moore & Newman Standards Track [Page 16] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + A client supporting client certificate authentication with Implicit + TLS MUST implement the SASL EXTERNAL mechanism [RFC4422], using the + appropriate authentication command (AUTH for POP3 [RFC5034], AUTH for + SMTP Submission [RFC4954], or AUTHENTICATE for IMAP [RFC3501]). + +6. Considerations Related to Antivirus/Antispam Software and Services + + There are multiple ways to connect an AVAS service (e.g., "Antivirus + & Antispam") to a mail server. Some mechanisms, such as the de facto + "milter" protocol, are out of scope for this specification. However, + some services use an SMTP relay proxy that intercepts mail at the + application layer to perform a scan and proxy or forward to another + Mail Transfer Agent (MTA). Deploying AVAS services in this way can + cause many problems [RFC2979], including direct interference with + this specification, and other forms of confidentiality or security + reduction. An AVAS product or service is considered compatible with + this specification if all IMAP, POP, and SMTP-related software + (including proxies) it includes are compliant with this + specification. + + Note that end-to-end email encryption prevents AVAS software and + services from using email content as part of a spam or virus + assessment. Furthermore, although a minimum confidentiality level + can prevent a man-in-the-middle from introducing spam or virus + content between the MUA and Submission server, it does not prevent + other forms of client or account compromise. The use of AVAS + services for submitted email therefore remains necessary. + +7. IANA Considerations + +7.1. POP3S Port Registration Update + + IANA has updated the registration of the TCP well-known port 995 + using the following template [RFC6335]: + + Service Name: pop3s + Transport Protocol: TCP + Assignee: IESG + Contact: IETF Chair + Description: POP3 over TLS protocol + Reference: RFC 8314 + Port Number: 995 + + + + + + + + + +Moore & Newman Standards Track [Page 17] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +7.2. IMAPS Port Registration Update + + IANA has updated the registration of the TCP well-known port 993 + using the following template [RFC6335]: + + Service Name: imaps + Transport Protocol: TCP + Assignee: IESG + Contact: IETF Chair + Description: IMAP over TLS protocol + Reference: RFC 8314 + Port Number: 993 + + No changes to existing UDP port assignments for pop3s or imaps are + being requested. + +7.3. Submissions Port Registration + + IANA has assigned an alternate usage of TCP port 465 in addition to + the current assignment using the following template [RFC6335]: + + Service Name: submissions + Transport Protocol: TCP + Assignee: IESG + Contact: IETF Chair + Description: Message Submission over TLS protocol + Reference: RFC 8314 + Port Number: 465 + + This is a one-time procedural exception to the rules in [RFC6335]. + This requires explicit IESG approval and does not set a precedent. + Note: Since the purpose of this alternate usage assignment is to + align with widespread existing practice and there is no known usage + of UDP port 465 for Message Submission over TLS, IANA has not + assigned an alternate usage of UDP port 465. + + Historically, port 465 was briefly registered as the "smtps" port. + This registration made no sense, as the SMTP transport MX + infrastructure has no way to specify a port, so port 25 is always + used. As a result, the registration was revoked and was subsequently + reassigned to a different service. In hindsight, the "smtps" + registration should have been renamed or reserved rather than + revoked. Unfortunately, some widely deployed mail software + interpreted "smtps" as "submissions" [RFC6409] and used that port for + email submission by default when an end user requested security + during account setup. If a new port is assigned for the submissions + service, either (a) email software will continue with unregistered + use of port 465 (leaving the port registry inaccurate relative to + + + +Moore & Newman Standards Track [Page 18] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + de facto practice and wasting a well-known port) or (b) confusion + between the de facto and registered ports will cause harmful + interoperability problems that will deter the use of TLS for Message + Submission. The authors of this document believe that both of these + outcomes are less desirable than a "wart" in the registry documenting + real-world usage of a port for two purposes. Although STARTTLS on + port 587 has been deployed, it has not replaced the deployed use of + Implicit TLS submission on port 465. + +7.4. Additional Registered Clauses for "Received" Fields + + Per the provisions in [RFC5321], IANA has added two additional- + registered-clauses for Received fields as defined in Section 4.3 of + this document: + + o "tls": Indicates the TLS cipher used (if applicable) + + o "group": Indicates the Diffie-Hellman group used with the TLS + cipher (if applicable) + + The descriptions and syntax of these additional clauses are provided + in Section 4.3 of this document. + +8. Security Considerations + + This entire document is about security considerations. In general, + this is targeted to improve mail confidentiality and to mitigate + threats external to the email system such as network-level snooping + or interception; this is not intended to mitigate active attackers + who have compromised service provider systems. + + Implementers should be aware that the use of client certificates with + TLS 1.2 reveals the user's identity to any party with the ability to + read packets from the transmission medium and therefore may + compromise the user's privacy. There seems to be no easy fix with + TLS 1.2 or earlier versions, other than to avoid presenting client + certificates except when there is explicit authorization to do so. + TLS 1.3 [TLS-1.3] appears to reduce this privacy risk somewhat. + + + + + + + + + + + + + +Moore & Newman Standards Track [Page 19] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +9. References + +9.1. Normative References + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, DOI 10.17487/RFC0793, September 1981, + . + + [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over + Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, + February 2002, . + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - + VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, + March 2003, . + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + . + + [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol + (POP3) Simple Authentication and Security Layer (SASL) + Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034, + July 2007, . + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + + + + + + +Moore & Newman Standards Track [Page 20] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + . + + [RFC6186] Daboo, C., "Use of SRV Records for Locating Email + Submission/Access Services", RFC 6186, + DOI 10.17487/RFC6186, March 2011, + . + + [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", + STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, + . + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, + August 2012, . + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, + May 2015, . + + [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via + Opportunistic DNS-Based Authentication of Named Entities + (DANE) Transport Layer Security (TLS)", RFC 7672, + DOI 10.17487/RFC7672, October 2015, + . + + [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS) + Server Identity Check Procedure for Email-Related + Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + . + + + + + + +Moore & Newman Standards Track [Page 21] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +9.2. Informative References + + [CERT-555316] + CERT, "Vulnerability Note VU#555316: STARTTLS plaintext + command injection vulnerability", Carnegie Mellon + University Software Engineering Institute, September 2011, + . + + [Email-TLS] + Moore, K., "Recommendations for use of TLS by Electronic + Mail Access Protocols", Work in Progress, draft-moore- + email-tls-00, October 2013. + + [MTA-STS] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., + and J. Jones, "SMTP MTA Strict Transport Security + (MTA-STS)", Work in Progress, draft-ietf-uta-mta-sts-14, + January 2018. + + [POP3-over-TLS] + Melnikov, A., Newman, C., and M. Yevstifeyev, Ed., "POP3 + over TLS", Work in Progress, draft-melnikov-pop3- + over-tls-02, August 2011. + + [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", + RFC 2595, DOI 10.17487/RFC2595, June 1999, + . + + [RFC2979] Freed, N., "Behavior of and Requirements for Internet + Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, + . + + [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types + Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004, + . + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, + DOI 10.17487/RFC4346, April 2006, + . + + [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, + DOI 10.17487/RFC4422, June 2006, + . + + + + + + + +Moore & Newman Standards Track [Page 22] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + [RFC4954] Siemborski, R., Ed., and A. Melnikov, Ed., "SMTP Service + Extension for Authentication", RFC 4954, + DOI 10.17487/RFC4954, July 2007, + . + + [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. + Finch, "Email Submission Operations: Access and + Accountability Requirements", BCP 134, RFC 5068, + DOI 10.17487/RFC5068, November 2007, + . + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + . + + [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) + Extensions: Extension Definitions", RFC 6066, + DOI 10.17487/RFC6066, January 2011, + . + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, + March 2011, . + + [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. + Cheshire, "Internet Assigned Numbers Authority (IANA) + Procedures for the Management of the Service Name and + Transport Protocol Port Number Registry", BCP 165, + RFC 6335, DOI 10.17487/RFC6335, August 2011, + . + + [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning + Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, + April 2015, . + + [TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", Work in Progress, draft-ietf-tls-tls13-23, + January 2018. + + + + + + + + + + +Moore & Newman Standards Track [Page 23] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +Appendix A. Design Considerations + + This section is not normative. + + The first version of this document was written independently from the + October 2013 version of [Email-TLS] ("Recommendations for use of TLS + by Electronic Mail Access Protocols"). Subsequent versions merge + ideas from both documents. + + One author of this document was also the author of RFC 2595, which + became the standard for TLS usage with POP and IMAP, and the other + author was perhaps the first to propose that idea. In hindsight, + both authors now believe that that approach was a mistake. At this + point, the authors believe that while anything that makes it easier + to deploy TLS is good, the desirable end state is that these + protocols always use TLS, leaving no need for a separate port for + cleartext operation except to support legacy clients while they + continue to be used. The separate-port model for TLS is inherently + simpler to implement, debug, and deploy. It also enables a "generic + TLS load-balancer" that accepts secure client connections for + arbitrary foo-over-TLS protocols and forwards them to a server that + may or may not support TLS. Such load-balancers cause many problems + because they violate the end-to-end principle and the server loses + the ability to log security-relevant information about the client + unless the protocol is designed to forward that information (as this + specification does for the ciphersuite). However, they can result in + TLS deployment where it would not otherwise happen, which is a + sufficiently important goal that it overrides any problems. + + Although STARTTLS appears only slightly more complex than + separate-port TLS, we again learned the lesson that complexity is the + enemy of security in the form of the STARTTLS command injection + vulnerability (Computer Emergency Readiness Team (CERT) vulnerability + ID #555316 [CERT-555316]). Although there's nothing inherently wrong + with STARTTLS, the fact that it resulted in a common implementation + error (made independently by multiple implementers) suggests that it + is a less secure architecture than Implicit TLS. + + Section 7 of RFC 2595 critiques the separate-port approach to TLS. + The first bullet was a correct critique. There are proposals in the + HTTP community to address that, and the use of SRV records as + described in RFC 6186 resolves that critique for email. The second + bullet is correct as well but is not very important because useful + deployment of security layers other than TLS in email is small enough + to be effectively irrelevant. (Also, it's less correct than it used + to be because "export" ciphersuites are no longer supported in modern + versions of TLS.) The third bullet is incorrect because it misses + the desirable option of "use TLS for all subsequent connections to + + + +Moore & Newman Standards Track [Page 24] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + + this server once TLS is successfully negotiated". The fourth bullet + may be correct, but it is not a problem yet with current port + consumption rates. The fundamental error was prioritizing a + perceived better design based on a mostly valid critique over + real-world deployability. But getting security and confidentiality + facilities actually deployed is so important that it should trump + design purity considerations. + + Port 465 is presently used for two purposes: for submissions by a + large number of clients and service providers and for the "urd" + protocol by one vendor. Actually documenting this current state is + controversial, as discussed in the IANA Considerations section. + However, there is no good alternative. Registering a new port for + submissions when port 465 is already widely used for that purpose + will just create interoperability problems. Registering a port + that's only used if advertised by an SRV record (RFC 6186) would not + create interoperability problems but would require all client + deployments, server deployments, and software to change + significantly, which is contrary to the goal of promoting the + increased use of TLS. Encouraging the use of STARTTLS on port 587 + would not create interoperability problems, but it is unlikely to + have any impact on the current undocumented use of port 465 and makes + the guidance in this document less consistent. The remaining option + is to document the current state of the world and support future use + of port 465 for submission, as this increases consistency and ease of + deployment for TLS email submission. + + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Newman Standards Track [Page 25] + +RFC 8314 Use of TLS for Email Submission/Access January 2018 + + +Acknowledgements + + Thanks to Ned Freed for discussion of the initial concepts in this + document. Thanks to Alexey Melnikov for [POP3-over-TLS], which was + the basis of the POP3 Implicit TLS text. Thanks to Russ Housley, + Alexey Melnikov, and Dan Newman for review feedback. Thanks to + Paul Hoffman for interesting feedback in initial conversations about + this idea. + +Authors' Addresses + + Keith Moore + Windrock, Inc. + PO Box 1934 + Knoxville, TN 37901 + United States of America + + Email: moore@network-heretics.com + + + Chris Newman + Oracle + 440 E. Huntington Dr., Suite 400 + Arcadia, CA 91006 + United States of America + + Email: chris.newman@oracle.com + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Newman Standards Track [Page 26] + -- cgit v1.2.3