Skip to main content

RFC 8314 - Cleartext Considered Obsolete: Use of TLS for Email Submission and Access

Document Information​

  • RFC Number: 8314
  • Title: Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
  • Authors: K. Moore, C. Newman
  • Date: January 2018
  • Category: Best Current Practice
  • ISSN: 2070-1721

Abstract​

This document requires that mail access protocols (POP, IMAP) and mail submission protocols (SMTP submission) be secured by TLS (Transport Layer Security) and that the use of cleartext for these protocols be deprecated.

Status of This Memo​

This memo documents an Internet Best Current Practice.

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 BCPs 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 (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.

Table of Contents​

  1. Introduction
  2. Terminology
  3. Deprecation of Cleartext
  4. Specific Protocols
  5. Security Considerations
  6. IANA Considerations
  7. References

1. Introduction​

The use of cleartext (unencrypted) communication for email protocols (POP, IMAP, SMTP Submission) exposes user credentials and email content to eavesdropping. This document specifies that TLS MUST be used for these protocols.

2. Terminology​

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.

3. Deprecation of Cleartext​

3.1. Mail User Agents (MUAs)​

MUAs MUST configure TLS for all email submission and access sessions.

3.2. Mail Service Providers (MSPs)​

MSPs MUST provide TLS for all email submission and access services. MSPs SHOULD deprecate and disable cleartext access.

3.3. Use of TLS 1.2 or Greater​

Implementations MUST support TLS 1.2 [RFC5246] or greater.

4. Specific Protocols​

4.1. IMAP​

IMAP servers MUST support implicit TLS on port 993. STARTTLS on port 143 is also permitted but implicit TLS is preferred.

4.2. POP​

POP servers MUST support implicit TLS on port 995. STARTTLS on port 110 is also permitted but implicit TLS is preferred.

4.3. SMTP Submission​

SMTP Submission servers MUST support implicit TLS on port 465. STARTTLS on port 587 is also permitted.

5. Security Considerations​

This document addresses the security risks of using cleartext for email protocols. It mandates the use of TLS to protect confidentiality and integrity.

6. IANA Considerations​

This document requires no IANA actions.

7. References​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.

Authors' Addresses

Keith Moore Network Heretics

Email: [email protected]

Chris Newman Oracle

Email: [email protected]

Last updated on