SMTP Service Extension for Secure SMTP over TLS
RFC 2487
Document | Type |
RFC - Proposed Standard
(January 1999; No errata)
Obsoleted by RFC 3207
Was draft-hoffman-smtp-ssl (individual)
|
|
---|---|---|---|
Author | Paul Hoffman | ||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2487 (Proposed Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group P. Hoffman Request for Comments: 2487 Internet Mail Consortium Category: Standards Track January 1999 SMTP Service Extension for Secure SMTP over TLS Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 1. Abstract This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. 2. Introduction SMTP [RFC-821] servers and clients normally communicate in the clear over the Internet. In many cases, this communication goes through one or more router that is not controlled or trusted by either entity. Such an untrusted router might allow a third party to monitor or alter the communications between the server and client. Further, there is often a desire for two SMTP agents to be able to authenticate each others' identities. For example, a secure SMTP server might only allow communications from other SMTP agents it knows, or it might act differently for messages received from an agent it knows than from one it doesn't know. TLS [TLS], more commonly known as SSL, is a popular mechanism for enhancing TCP communications with privacy and authentication. TLS is in wide use with the HTTP protocol, and is also being used for adding security to many other common protocols that run over TCP. Hoffman Standards Track [Page 1] RFC 2487 SMTP Service Extension January 1999 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 laid out as follows: (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 used to tell the SMTP client that the SMTP server allows use of TLS. It takes no parameters. 5. The STARTTLS Command The format for the STARTTLS command is: STARTTLS with no parameters. After the client gives the STARTTLS command, the server responds with one of the following reply codes: 220 Ready to start TLS 501 Syntax error (no parameters allowed) 454 TLS not available due to temporary reason A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address. Hoffman Standards Track [Page 2] RFC 2487 SMTP Service Extension January 1999 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. A SMTP server that is not publicly referenced may choose to require that the client perform a TLS negotiation before accepting any commands. In this case, the server SHOULD return the 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 giving 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 has been completed, both parties MUSTShow full document text