Secure SMTP
draft-hoflev-secure-smtp-01

Network Working Group                                         P. Hoffman
Internet-Draft                                                     ICANN
Intended status: Standards Track                               J. Levine
Expires: 22 January 2027                                   Standcore LLC
                                                            21 July 2026

                              Secure SMTP
                      draft-hoflev-secure-smtp-01

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 22 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 22 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 verify that it has connected to the intended server, by checking
   that the server's certificate is signed by a trusted authority, or
   using DANE for SMTP [RFC7672].  Servers MAY use MTA-STS [RFC8461] to
   describe their preference that clients use TLS secured connections.

   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 22 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 certificate with a trusted signer,
   and/or a certificate that can be verified with DANE for SMTP.

   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 22 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.  A domain can publish only _ssmtp MX records and no
   conventional MX records if it only receives TLS secured mail.

   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
   configuration 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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

Hoffman & Levine         Expires 22 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,
              <https://www.rfc-editor.org/info/rfc7672>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc8461>.

9.  Informative References

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
              February 2002, <https://www.rfc-editor.org/info/rfc3207>.

Authors' Addresses

   Paul Hoffman
   ICANN
   Email: paul.hoffman@icann.org

   John Levine
   Standcore LLC
   Email: standards@standcore.com

Hoffman & Levine         Expires 22 January 2027                [Page 5]