Implicit TLS (TLS negotiated immediately on a dedicated port) is preferred over STARTTLS because it is simpler to implement, debug, and deploy. The STARTTLS command injection vulnerability (CERT VU#555316) demonstrated that STARTTLS complexity is an enemy of security; independent implementers made the same mistake. Implicit TLS also enables generic TLS load-balancers.

tls, email, security

Port 465 is registered as 'submissions' (SMTP Submission over Implicit TLS) to align with widespread existing practice rather than assigning a new port. Registering a new port would create interoperability problems since a large number of clients and providers already use port 465 for this purpose.

email, tls, registry

An AVAS (Antivirus/Antispam) product or service is considered compatible with this specification only if all IMAP, POP, and SMTP-related software (including proxies) it includes are compliant. SMTP relay proxies that intercept mail at the application layer can directly interfere with TLS confidentiality.

email, tls, security

This document updates RFC 6186 by changing preference rules and adding the new SRV service label _submissions._tcp for Message Submission with Implicit TLS. MUAs using RFC 6186 for account setup SHOULD ignore advertised services not satisfying minimum confidentiality requirements unless the user has explicitly requested reduced confidentiality.

email, tls, dns

A client supporting client certificate authentication with Implicit TLS MUST implement the SASL EXTERNAL mechanism, using AUTH for POP3, AUTH for SMTP Submission, or AUTHENTICATE for IMAP.

tls, email, security

After a user's cleartext authentication access is revoked, the server MUST NOT provide any indication over a cleartext channel of whether the user's credentials were valid. Both invalid and valid credentials MUST result in the same access-denied indication.

email, security

All Mail Access Servers and Mail Submission Servers MUST support TLS 1.2 or later.

tls, email, security

An MUA MUST NOT attempt to test a Mail Account configuration by submitting authentication credentials to a server unless a TLS session meeting minimum confidentiality levels has been established. If requirements are not satisfied, the MUA must explicitly warn that the user's password may be exposed.

tls, email, security

An MUA MUST NOT consult SRV records on every connection attempt to determine which servers to use unless those SRV records are signed by DNSSEC with a valid signature.

tls, email, dns, security

An MUA MUST NOT provide a client certificate during the TLS handshake unless the server requests one and the MUA has been explicitly authorized to use that certificate with that account. Installing a certificate for one account MUST NOT automatically authorize its use with other accounts.

tls, email, security, pkix

Certificate pinning MUST NOT be offered as an option in response to a failed certificate validation for an existing Mail Account — only during initial account setup. An MUA MUST NOT allow a certificate pinned for one account to validate connections for other accounts, and MUST allow users to revoke a pinned certificate.

tls, email, pkix, security

Mail Submission Servers MUST NOT request a client certificate during the TLS handshake unless the server is configured to accept some certificates as sufficient for authentication and can determine a matching authorization identity. If a certificate is accepted, the server MUST enable SASL EXTERNAL.

tls, email, security, pkix

MSPs MUST maintain valid server certificates for all servers, per the recommendations and requirements in RFC 7817.

tls, email, pkix, security

MSPs that support POP, IMAP, and/or Message Submission MUST support TLS access for those protocol servers. Servers supporting authentication via username and password MUST support TLS access.

tls, email, security

MUAs MUST implement TLS 1.2 or later. Earlier TLS and SSL versions MAY also be supported, so long as the MUA requires at least TLS 1.1 when accessing accounts configured to impose minimum confidentiality requirements.

tls, email, security

MUAs MUST NOT indicate confidentiality to the user for a connection relying on certificate pinning, as such connections do not meet the minimum confidentiality level due to susceptibility to man-in-the-middle at account setup time.

tls, email, security, privacy

MUAs MUST validate TLS server certificates according to RFC 7817 and PKIX (RFC 5280). MUAs MUST NOT treat a session as meeting minimum confidentiality if the server's TLS certificate cannot be validated.

tls, email, pkix, security

The default minimum confidentiality for all new MUA accounts MUST require successful validation of the server's certificate and SHOULD require negotiation of TLS version 1.1 or greater. An MUA configured to require minimum confidentiality MUST NOT perform any operation other than capability discovery or STARTTLS unless that minimum is met.

tls, email, security

TLSA records MUST NOT be advertised unless they are signed using DNSSEC. MSPs SHOULD advertise TLSA records to provide an additional trust anchor for public keys used in TLS server certificates.

tls, email, dns, pkix, security

When a client or server wishes to close a POP, IMAP, or SMTP Submission connection, it SHOULD initiate the exchange of TLS close alerts before TCP connection termination. The client MAY send a TLS close alert and then close the TCP connection without waiting for a TLS response.

tls, email

A new SMTP 'tls' Received header additional-registered-clause records the TLS ciphersuite negotiated for a connection. Optionally, a 'group' sub-clause records the Diffie-Hellman group name. ABNF: tls-cipher-clause = CFWS 'tls' FWS tls-cipher [ CFWS tls-dh-group-clause ]; tls-cipher is either a registered ciphersuite name or a 4-digit hex identifier.

tls, email

Implicit TLS for IMAP: when a TCP connection is established for 'imaps' (default port 993), a TLS handshake begins immediately. If the server accepts the client certificate, it MAY issue PREAUTH (entering AUTHENTICATED state); otherwise an OK greeting places both parties in NOT AUTHENTICATED state.

tls, email

Implicit TLS for POP: when a TCP connection is established for 'pop3s' (default port 995), a TLS handshake begins immediately. After the server sends an +OK greeting, both parties MUST enter the AUTHORIZATION state, even if a client certificate was supplied.

tls, email

Implicit TLS for SMTP Submission: when a TCP connection is established for 'submissions' (default port 465), a TLS handshake begins immediately. During the transition period, clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465.

tls, email

IANA added two additional-registered-clauses for SMTP Received header fields: 'tls' (indicates the TLS cipher used, if applicable) and 'group' (indicates the Diffie-Hellman group used with the TLS cipher, if applicable), as defined in Section 4.3.

email, tls, registry

IANA updated the registration of TCP port 995 (pop3s) and TCP port 993 (imaps) to reference RFC 8314. IANA also assigned TCP port 465 an alternate usage as 'submissions' (Message Submission over TLS protocol) as a one-time procedural exception, without a corresponding UDP assignment.

email, tls, registry

This document targets confidentiality against external network-level snooping and interception; it is not intended to mitigate active attackers who have compromised service provider systems. End-to-end encryption of email is a separate and unreplaced requirement.

email, tls, security, privacy

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, compromising user privacy. TLS 1.3 reduces this risk somewhat; the only mitigation in TLS 1.2 is to avoid presenting client certificates except with explicit authorization.

tls, email, security, privacy