Network Working Group P. Hoffman Internet-Draft ICANN Intended status: Standards Track J. Levine Expires: 21 January 2027 Standcore LLC 20 July 2026 Secure SMTP draft-hoflev-secure-smtp-00 Abstract SMTP [RFC5321] uses opportunistic TLS to optionally protect transport sessions. Secure SMTP uses mandatory TLS on all connections. It also provides a method for SMTP clients to locate Secure SMTP servers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 January 2027. Copyright Notice Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Hoffman & Levine Expires 21 January 2027 [Page 1] Internet-Draft SSMTP July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Session protocol . . . . . . . . . . . . . . . . . . . . . . 2 3. Server discovery . . . . . . . . . . . . . . . . . . . . . . 2 4. Differences from SMTP . . . . . . . . . . . . . . . . . . . . 3 5. Security considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 9. Informative References . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction SMTP [RFC5321] has always been defined as an unencrypted protocol. The STARTTLS extension [RFC3207] allows an optional upgrade to TLS within an existing session. Secure SMTP performs the TLS negotiation at the start of each session, so all traffic is encrypted. 1.1. Requirements Language 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. 2. Session protocol Secure SMTP uses port TBD. To start a session, a Secure SMTP client connects to that port and negotiates a TLS connection. The client MUST use MTA-STS [RFC8461] or DANE for SMTP [RFC7672] to verify that it has connected to the intended server. After the connection, the protocol is identical to SMTP. 3. Server discovery Once a Secure SMTP client identifies a domain to which mail is to be delivered, it MUST do a DNS lookup to locate an MX record for the domain. Hoffman & Levine Expires 21 January 2027 [Page 2] Internet-Draft SSMTP July 2026 Secure SMTP servers are identified in an MX record by adding a _ssmtp prefix to the hostname of the server. The _ssmtp prefix is removed from the hostname before finding addresses associated with the secure SMTP server's address. bigcorp.example. IN MX 10 _ssmtp.mail1.bigcorp.example. IN MX 20 mail2.bigcorp.example. In the example above, mail1.bigcorp.example is a Secure SMTP server, and mail2.bigcorp.example is a conventional SMTP server. If a server provides both conventional and Secure SMTP, two records identify the two services: bigcorp.example. IN MX 10 _ssmtp.mail1.bigcorp.example. IN MX 10 mail1.bigcorp.example. The numerical priority is used to select a server in the same manner as conventional SMTP. If there is both a conventional and Secure SMTP server at the same priority, a client MAY prefer the Secure one, or it may do load levelling as it would for multiple conventional servers at the same priority. Unlike conventional SMTP, there is no fallback to A or AAAA address records. A domain MUST publish an MX record with a _ssmtp prefix on the host name, to indicate that it supports Secure SMTP. The prefix appears in the MX to identify the server but is not part of the server's hostname. Note that since hostnames cannot contain underscores, there is no conflict with conventional SMTP MX records. 4. Differences from SMTP Secure SMTP servers MUST present a signed certificate that can be verified with MTA-STS, or a certificate that can be verified with DANE for SMTP, or preferably either way. Secure SMTP allows all SMTP extensions except STARTTLS which is irrelevant. When a mail server adds a Received: header field to an incoming message, it identifies the protocol as "with SSMTP" or "with SUTF8SMTP" depending on whether the session used SMTPUTF8. Hoffman & Levine Expires 21 January 2027 [Page 3] Internet-Draft SSMTP July 2026 5. Security considerations Secure SMTP is functionally the same as conventional SMTP except that all sessions are encrypted with TLS and the servers' certificates are validated, which should deter interception and entity-in-the-middle attacks. Messages are still stored in the clear on servers, so the same considerations about message encryption apply as for conventional SMTP. 6. IANA Considerations IANA is requested to allocate a port number for Secure SMTP. IANA is requested to add the following entries to the Mail Transmission Types for the "Received:" Header Field Reference, in the WITH Protocol Types table: SSMTP Secure SMTP SUTF8SMTP Secure SMTP with SMTPUTF8 IANA is requested to add the following entry to the Underscored and Globally Scoped DNS Node Names registry. MX _ssmtp [this document] 7. Implementation Status | Delete this section before publication Many MTAs provide secure submission on port 465. Often a configuation tweak will be enough to accept secure SMTP on a different port. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . Hoffman & Levine Expires 21 January 2027 [Page 4] Internet-Draft SSMTP July 2026 [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA- STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, . 9. Informative References [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . Authors' Addresses Paul Hoffman ICANN Email: paul.hoffman@icann.org John Levine Standcore LLC Email: standards@standcore.com Hoffman & Levine Expires 21 January 2027 [Page 5]