RFC 2487

SMTP Service Extension for Secure SMTP over TLS 💌

Okay bestie, this is RFC 2487 🎀, from the Network Working Group ✨. It was written by P. Hoffman of the Internet Mail Consortium 💅 and dated January 1999. It's a Standards Track document 👑, so it's a real protocol spec, not just a chat about ideas.

Status of This Memo 📝

This document specifies an Internet standards track protocol for the Internet community 🌈, and it requests discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.

Copyright Notice 🔐

Copyright (C) The Internet Society (1999). All Rights Reserved. 💜

1. Abstract ✨

This doc describes an extension to the SMTP service 📨 that lets an SMTP server and client use transport-layer security to get private, authenticated communication over the Internet 🔒. So SMTP agents can protect some or all of their communications from eavesdroppers and attackers 🕵️‍♀️. Iconic. 👑

2. Introduction 🌸

SMTP [RFC-821] servers and clients normally talk in the clear over the Internet 🫣. A lot of the time, that traffic goes through one or more routers that neither side controls or trusts 🚏. An untrusted router like that could let a third party watch or change what the server and client are saying to each other 😬.

There's also often a real need for two SMTP agents to verify each other's identities 🪪. For example, a secure SMTP server might only accept communication from other SMTP agents it already knows 🤝. Or it might handle messages from a known agent differently than messages from one it doesn't know 🧐.

TLS [TLS], which you probably know better as SSL, is a popular way to give TCP communications privacy and authentication 🔐. It's widely used with HTTP, and it's also being used to add security to lots of other common protocols that run over TCP 💖.

2.1 Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119] 🧠.

3. STARTTLS Extension 🎀

The STARTTLS extension to SMTP is set up like this 🧚:

1. the name of the SMTP service defined here is STARTTLS;
2. the EHLO keyword value associated with the extension is STARTTLS;
3. the STARTTLS keyword has no parameters;
4. a new SMTP verb, STARTTLS, is defined;
5. no additional parameters are added to any SMTP command.

4. The STARTTLS Keyword 🦋

The STARTTLS keyword is how the SMTP server tells the SMTP client that it allows TLS 🙌. It takes no parameters 🫶.

5. The STARTTLS Command 💅

The format for the STARTTLS command is:

STARTTLS

with no parameters 🌷.

After the client sends the STARTTLS command, the server replies with one of these reply codes 📬:

220 Ready to start TLS
501 Syntax error (no parameters allowed)
454 TLS not available due to temporary reason

Okay, this next part is a big deal 🚨. A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally 🙅‍♀️. This rule stops the STARTTLS extension from wrecking the interoperability of the Internet's SMTP infrastructure 🌐. A publicly-referenced SMTP server is an SMTP server that runs on port 25 of an Internet host listed in the MX record (or the A record if there's no MX record) for the domain name on the right-hand side of an Internet mail address 📍.

Any SMTP server may refuse to accept messages for relay based on authentication supplied during the TLS negotiation 🚪. An SMTP server that is not publicly referenced may refuse to accept any messages for relay or local delivery based on authentication supplied during the TLS negotiation 🛑.

An SMTP server that is not publicly referenced may choose to require that the client do a TLS negotiation before accepting any commands 🔑. In that case, the server SHOULD return this reply code:

530 Must issue a STARTTLS command first

to every command other than NOOP, EHLO, STARTTLS, or QUIT 🙈. If the client and server are using the ENHANCEDSTATUSCODES ESMTP extension [RFC-2034], the status code to be returned SHOULD be 5.7.0 🌈.

After receiving a 220 response to a STARTTLS command, the client SHOULD start the TLS negotiation before sending any other SMTP commands 🏃‍♀️.

If the SMTP client is using pipelining as defined in RFC 1854, the STARTTLS command must be the last command in a group 🍓.

5.1 Processing After the STARTTLS Command 🔍

After the TLS handshake is done, both parties MUST immediately decide whether or not to keep going, based on the authentication and privacy they got 🧁. The SMTP client and server may decide to move ahead even if the TLS negotiation ended with no authentication and/or no privacy 🤷‍♀️. That's because most SMTP services run with no authentication and no privacy 💭. But some SMTP clients or servers might only want to continue if a certain level of authentication and/or privacy was achieved 🛡️.

If the SMTP client decides the level of authentication or privacy isn't high enough to continue, it SHOULD issue an SMTP QUIT command right after the TLS negotiation is complete 👋. If the SMTP server decides the level of authentication or privacy isn't high enough, it SHOULD reply to every SMTP command from the client (other than a QUIT command) with the 554 reply code 🚫. It can include a text string like "Command refused due to lack of security" 🥀.

Whether to believe the other party's authenticity in a TLS negotiation is a local decision 🏠. Still, here are some general rules for making that call 💡:

• An SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name matching the domain name the client thought it was connecting to 🎯.
• A publicly-referenced SMTP server would probably want to accept any certificate from an SMTP client 🪄, and it might want to put distinguishing information about the certificate in the Received header of messages that were relayed or submitted from the client 📝.

5.2 Result of the STARTTLS Command 🌟

When the TLS handshake finishes, the SMTP protocol resets to its initial state (the state SMTP is in after a server sends a 220 service ready greeting) 🔄. The server MUST discard any knowledge it got from the client that didn't come from the TLS negotiation itself, like the argument to the EHLO command 🗑️. The client MUST discard any knowledge it got from the server that didn't come from the TLS negotiation itself, like the list of SMTP service extensions 🧹. The client SHOULD send an EHLO command as its first command after a successful TLS negotiation 💌.

The list of SMTP service extensions returned in response to an EHLO command received after the TLS handshake MAY be different from the list returned before it 🎭. For example, an SMTP server might not want to advertise support for a particular SASL mechanism [SASL] unless the client sent an appropriate client certificate during the TLS handshake 🪪.

Both the client and the server MUST know whether a TLS session is active 👀. A client MUST NOT try to start a TLS session if one is already active 🙅‍♀️. A server MUST NOT return the TLS extension in response to an EHLO command received after a TLS handshake has completed 🚫.

---

To be continued in part 2! 🌈✨

A. References 📚

okay so this is the bibliography bit, and it's giving "receipts for everything" 💅 every doc this one leans on is listed here so you can go read them yourself 🤓

• [RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982. 📮
• [RFC-1869] Klensin, J., Freed, N, Rose, M, Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995. ✨
• [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. 🎀
• [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔥
• [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. 🦋
• [SMTP-AUTH] "SMTP Service Extension for Authentication", Work in Progress. 🚧
• [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 🔐

---

B. Author's Address 🏡

this is where you can find the author, Paul Hoffman, at the Internet Mail Consortium 💖

Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA  95060

Phone: (831) 426-9827
EMail: phoffman@imc.org

---

C. Full Copyright Statement 🌈

okay, legal bit, but make it cute 🎀 the Internet Society owns the copyright (C) for 1999, and all rights are reserved, but it's honestly super generous lowkey 🫶

so basically you're allowed to copy this doc and hand it out to people 📄 you can also make derivative works that comment on it, explain it, or help people actually implement it, and you can prepare, copy, publish, and distribute those too, in whole or in part, with no restriction at all ✨ the one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 🙏

the doc itself cannot be modified in any way, though 🙈 that means no removing the copyright notice and no removing references to the Internet Society or other Internet organizations. the exceptions are when you need it for developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process, or when you need to translate it into a language that isn't English 🌸

these permissions are perpetual, which is the forever kind of vibe 💜 they will not be revoked by the Internet Society or its successors or assigns ✨

last but not least, the doc and everything in it is provided on an "AS IS" basis 💀 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. so yeah, no guarantees, just vibes 🌟