summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1651.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1651.txt')
-rw-r--r--doc/rfc/rfc1651.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc1651.txt b/doc/rfc/rfc1651.txt
new file mode 100644
index 0000000..6398eab
--- /dev/null
+++ b/doc/rfc/rfc1651.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group J. Klensin, WG Chair
+Request for Comments: 1651 MCI
+Obsoletes: 1425 N. Freed, Editor
+Category: Standards Track Innosoft
+ M. Rose
+ Dover Beach Consulting, Inc.
+ E. Stefferud
+ Network Management Associates, Inc.
+ D. Crocker
+ Silicon Graphics, Inc.
+ July 1994
+
+
+ SMTP Service Extensions
+
+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.
+
+1. Abstract
+
+ This memo defines a framework for extending the SMTP service by
+ defining a means whereby a server SMTP can inform a client SMTP as to
+ the service extensions it supports. Standard extensions to the SMTP
+ service are registered with the IANA. This framework does not
+ require modification of existing SMTP clients or servers unless the
+ features of the service extensions are to be requested or provided.
+
+2. Introduction
+
+ The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable,
+ effective basis for the relay function of message transfer agents.
+ Although a decade old, SMTP has proven remarkably resilient.
+ Nevertheless, the need for a number of protocol extensions has become
+ evident. Rather than describing these extensions as separate and
+ haphazard entities, this document enhances SMTP in a straightforward
+ fashion that provides a framework in which all future extensions can
+ be built in a single consistent way.
+
+3. Framework for SMTP Extensions
+
+ For the purpose of service extensions to SMTP, SMTP relays a mail
+ object containing an envelope and a content.
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 1]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ (1) The SMTP envelope is straightforward, and is sent as a
+ series of SMTP protocol units: it consists of an
+ originator address (to which error reports should be
+ directed); a delivery mode (e.g., deliver to recipient
+ mailboxes); and, one or more recipient addresses.
+
+ (2) The SMTP content is sent in the SMTP DATA protocol unit
+ and has two parts: the headers and the body. The headers
+ form a collection of field/value pairs structured
+ according to STD 11, RFC 822 [2], whilst the body, if
+ structured, is defined according to MIME [3]. The content is
+ textual in nature, expressed using the US-ASCII repertoire (ANSI
+ X3.4-1986). Although extensions (such as MIME) may relax
+ this restriction for the content body, the content
+ headers are always encoded using the US-ASCII repertoire.
+ The algorithm defined in [4] is used to represent header
+ values outside the US-ASCII repertoire, whilst still
+ encoding them using the US-ASCII repertoire.
+
+ Although SMTP is widely and robustly deployed, some parts of the
+ Internet community might wish to extend the SMTP service. This memo
+ defines a means whereby both an extended SMTP client and server may
+ recognize each other as such and the server can inform the client as
+ to the service extensions that it supports.
+
+ It must be emphasized that any extension to the SMTP service should
+ not be considered lightly. SMTP's strength comes primarily from its
+ simplicity. Experience with many protocols has shown that:
+
+ protocols with few options tend towards ubiquity, whilst
+ protocols with many options tend towards obscurity.
+
+ This means that each and every extension, regardless of its benefits,
+ must be carefully scrutinized with respect to its implementation,
+ deployment, and interoperability costs. In many cases, the cost of
+ extending the SMTP service will likely outweigh the benefit.
+
+ Given this environment, the framework for the extensions described in
+ this memo consists of:
+
+ (1) a new SMTP command (section 4)
+
+ (2) a registry of SMTP service extensions (section 5)
+
+ (3) additional parameters to the SMTP MAIL FROM and RCPT TO
+ commands (section 6).
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 2]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+4. The EHLO command
+
+ A client SMTP supporting SMTP service extensions should start an SMTP
+ session by issuing the EHLO command instead of the HELO command. If
+ the SMTP server supports the SMTP service extensions it will give a
+ successful response (see section 4.3), a failure response (see 4.4),
+ or an error response (4.5). If the SMTP server does not support any
+ SMTP service extensions it will generate an error response (see
+ section 4.5).
+
+4.1. Changes to STD 10, RFC 821
+
+ STD 10, RFC 821 states that the first command in an SMTP session must
+ be the HELO command. This requirement is hereby amended to allow a
+ session to start with either EHLO or HELO.
+
+4.2. Command syntax
+
+ The syntax for this command, using the ABNF notation of [2], is:
+
+ ehlo-cmd ::= "EHLO" SP domain CR LF
+
+ If successful, the server SMTP responds with code 250. On failure,
+ the server SMTP responds with code 550. On error, the server SMTP
+ responds with one of codes 500, 501, 502, 504, or 421.
+
+ This command is issued instead of the HELO command, and may be issued
+ at any time that a HELO command would be appropriate. That is, if
+ the EHLO command is issued, and a successful response is returned,
+ then a subsequent HELO or EHLO command will result in the server SMTP
+ replying with code 503. A client SMTP must not cache any information
+ returned if the EHLO command succeeds. That is, a client SMTP must
+ issue the EHLO command at the start of each SMTP session if
+ information about extended facilities is needed.
+
+4.3. Successful response
+
+ If the server SMTP implements and is able to perform the EHLO
+ command, it will return code 250. This indicates that both the
+ server and client SMTP are in the initial state, that is, there is no
+ transaction in progress and all state tables and buffers are cleared.
+
+ Normally, this response will be a multiline reply. Each line of the
+ response contains a keyword and, optionally, one or more parameters.
+ The syntax for a positive response, using the ABNF notation of [2],
+ is:
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 3]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF
+ / ( "250-" domain [ SP greeting ] CR LF
+ *( "250-" ehlo-line CR LF )
+ "250" SP ehlo-line CR LF )
+
+ ; the usual HELO chit-chat
+ greeting ::= 1*<any character other than CR or LF>
+
+ ehlo-line ::= ehlo-keyword *( SP ehlo-param )
+
+ ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+ ; syntax and values depend on ehlo-keyword
+ ehlo-param ::= 1*<any CHAR excluding SP and all
+ control characters (US-ASCII 0-31
+ inclusive)>
+
+ ALPHA ::= <any one of the 52 alphabetic characters
+ (A through Z in upper case, and,
+ a through z in lower case)>
+ DIGIT ::= <any one of the 10 numeric characters
+ (0 through 9)>
+
+ CR ::= <the carriage-return character
+ (ASCII decimal code 13)>
+ LF ::= <the line-feed character
+ (ASCII decimal code 10)>
+ SP ::= <the space character
+ (ASCII decimal code 32)>
+
+ Although EHLO keywords may be specified in upper, lower, or mixed
+ case, they must always be recognized and processed in a case-
+ insensitive manner. This is simply an extension of practices begun in
+ RFC 821.
+
+ The IANA maintains a registry of standard SMTP service extensions.
+ Associated with each such extension is a corresponding EHLO keyword
+ value. Each service extension registered with the IANA is defined by
+ a standards-track RFC, and such a definition includes:
+
+ (1) the textual name of the SMTP service extension;
+
+ (2) the EHLO keyword value associated with the extension;
+
+ (3) the syntax and possible values of parameters associated
+ with the EHLO keyword value;
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 4]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ (4) any additional SMTP verbs associated with the extension
+ (additional verbs will usually be, but are not required
+ to be, the same as the EHLO keyword value);
+
+ (5) any new parameters the extension associates with the MAIL
+ FROM or RCPT TO verbs; and,
+
+ (6) how support for the extension affects the behavior of a
+ server and client SMTP.
+
+ In addition, any EHLO keyword value that starts with an upper or
+ lower case "X" refers to a local SMTP service extension, which is
+ used through bilateral, rather than standardized, agreement. Keywords
+ beginning with "X" may not be used in a registered service extension.
+
+ Any keyword values presented in the EHLO response that do not begin
+ with "X" must correspond to a standard or standards-track SMTP
+ service extension registered with IANA. A conforming server must not
+ offer non "X" prefixed keyword values that are not described in a
+ registered and standardized extension.
+
+ Additional verbs are bound by the same rules as EHLO keywords;
+ specifically, verbs begining with "X" are local extensions that may
+ not be standardized and verbs not beginning with "X" must always be
+ registered.
+
+4.4. Failure response
+
+ If for some reason the server SMTP is unable to list the service
+ extensions it supports, it will return code 554.
+
+ In the case of a failure response, the client SMTP should issue
+ either the HELO or QUIT command.
+
+4.5. Error responses from extended servers
+
+ If the server SMTP recognizes the EHLO command, but the command
+ argument is unacceptable, it will return code 501.
+
+ If the server SMTP recognizes, but does not implement, the EHLO
+ command, it will return code 502.
+
+ If the server SMTP determines that the SMTP service is no longer
+ available (e.g., due to imminent system shutdown), it will return
+ code 421.
+
+ In the case of any error response, the client SMTP should issue
+ either the HELO or QUIT command.
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 5]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+4.6. Responses from servers without extensions
+
+ A server SMTP that conforms to RFC 821 but does not support the
+ extensions specified here will not recognize the EHLO command and
+ will consequently return code 500, as specified in RFC 821. The
+ server SMTP should stay in the same state after returning this code
+ (see section 4.1.1 of RFC 821). The client SMTP may then issue
+ either a HELO or a QUIT command.
+
+4.7. Responses from improperly implemented servers
+
+ Some SMTP servers are known to disconnect the SMTP transmission
+ channel upon receipt of the EHLO command. The disconnect can occur
+ immediately or after sending a response. Such behavior violates
+ section 4.1.1 of RFC 821, which explicitly states that disconnection
+ should only occur after a QUIT command is issued.
+
+ Nevertheless, in order to achieve maxmimum interoperablity it is
+ suggested that extended SMTP clients using EHLO be coded to check for
+ server connection closure after EHLO is sent, either before or after
+ returning a reply. If this happens the client must decide if the
+ operation can be successfully completed without using any SMTP
+ extensions. If it can a new connection can be opened and the HELO
+ command can be used.
+
+ Other improperly-implemented servers will not accept a HELO command
+ after EHLO has been sent and rejected. In some cases, this problem
+ can be worked around by sending a RSET after the failure response to
+ EHLO, then sending the HELO. Clients that do this should be aware
+ that many implementations will return a failure code (e.g., 503 Bad
+ sequence of commands) in response to the RSET. This code can be
+ safely ignored.
+
+5. Initial IANA Registry
+
+ The IANA's initial registry of SMTP service extensions consists of
+ these entries:
+
+ Service Ext EHLO Keyword Parameters Verb Added Behavior
+ ------------- ------------ ---------- ---------- ------------------
+ Send SEND none SEND defined in RFC 821
+ Send or Mail SOML none SOML defined in RFC 821
+ Send and Mail SAML none SAML defined in RFC 821
+ Expand EXPN none EXPN defined in RFC 821
+ Help HELP none HELP defined in RFC 821
+ Turn TURN none TURN defined in RFC 821
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 6]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ which correspond to those SMTP commands which are defined as optional
+ in [5]. (The mandatory SMTP commands, according to [5], are HELO,
+ MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.)
+
+6. MAIL FROM and RCPT TO Parameters
+
+ It is recognized that several of the extensions planned for SMTP will
+ make use of additional parameters associated with the MAIL FROM and
+ RCPT TO command. The syntax for these commands, again using the ABNF
+ notation of [2] as well as underlying definitions from [1], is:
+
+ esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF
+ esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter)
+ esmtp-parameter ::= esmtp-keyword ["=" esmtp-value]
+ esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+ ; syntax and values depend on esmtp-keyword
+ esmtp-value ::= 1*<any CHAR excluding "=", SP, and all
+ control characters (US-ASCII 0-31
+ inclusive)>
+
+ ; The following commands are extended to
+ ; accept extended parameters.
+ inner-esmtp-cmd ::= ("MAIL FROM:<" reverse-path ">") /
+ ("RCPT TO:<" forward-path ">")
+
+ All esmtp-keyword values must be registered as part of the IANA
+ registration process described above. This definition only provides
+ the framework for future extension; no extended MAIL FROM or RCPT TO
+ parameters are defined by this RFC.
+
+6.1. Error responses
+
+ If the server SMTP does not recognize or cannot implement one or more
+ of the parameters associated with a particular MAIL FROM or RCPT TO
+ command, it will return code 555.
+
+ If for some reason the server is temporarily unable to accomodate one
+ or more of the parameters associated with a MAIL FROM or RCPT TO
+ command, and if the definition of the specific parameter does not
+ mandate the use of another code, it should return code 455.
+
+ Errors specific to particular parameters and their values will be
+ specified in the parameter's defining RFC.
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 7]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+7. Received: Header Field Annotation
+
+ SMTP servers are required to add an appropriate Received: field to
+ the headers of all messages they receive. A "with ESMTP" clause
+ should be added to this field when any SMTP service extensions are
+ used. "ESMTP" is hereby added to the list of standard protocol names
+ registered with IANA.
+
+8. Usage Examples
+
+ (1) An interaction of the form:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250 dbc.mtview.ca.us says hello
+ ...
+
+ indicates that the server SMTP implements only those SMTP
+ commands which are defined as mandatory in [5].
+
+
+ (2) In contrast, an interaction of the form:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250-dbc.mtview.ca.us says hello
+ S: 250-EXPN
+ S: 250-HELP
+ S: 250-8BITMIME
+ S: 250-XONE
+ S: 250 XVRB
+ ...
+
+ indicates that the server SMTP also implements the SMTP
+ EXPN and HELP commands, one standard service extension
+ (8BITMIME), and two non-standard service extensions (XONE
+ and XVRB).
+
+
+ (3) Finally, a server that does not support SMTP service
+ extensions would act as follows:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 8]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 500 Command not recognized: EHLO
+ ...
+
+ The 500 response indicates that the server SMTP does not
+ implement the extensions specified here. The client
+ would normally send a HELO command and proceed as
+ specified in RFC 821. See section 4.7 for additional
+ discussion.
+
+9. Security Considerations
+
+ This RFC does not discuss security issues and is not believed to
+ raise any security issues not already endemic in electronic mail and
+ present in fully conforming implementations of RFC-821. It does
+ provide an announcement of server mail capabilities via the response
+ to the EHLO verb. However, all information provided by announcement
+ of any of the initial set of service extensions defined by this RFC
+ can be readily deduced by selective probing of the verbs required to
+ transport and deliver mail. The security implications of service
+ extensions described in other RFCs should be dealt with in those
+ RFCs.
+
+10. Acknowledgements
+
+ This document represents a synthesis of the ideas of many people and
+ reactions to the ideas and proposals of others. Randall Atkinson,
+ Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
+ and text sufficient to be considered co-authors. Other important
+ suggestions, text, or encouragement came from Harald Alvestrand, Jim
+ Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per
+ Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A.
+ Miller, Dan Oscarsson, Julian Onions, Rayan Zachariassen, and the
+ contributions of the entire IETF SMTP Working Group. Of course, none
+ of the individuals are necessarily responsible for the combination of
+ ideas represented here. Indeed, in some cases, the response to a
+ particular criticism was to accept the problem identification but to
+ include an entirely different solution from the one originally
+ proposed.
+
+11. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 9]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+ Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
+
+ [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
+ Headers", RFC 1522, University of Tennessee, September 1993.
+
+ [5] Braden, R., "Requirements for Internet Hosts - Application and
+ Support", STD 3, RFC 1123, USC/Information Sciences Institute,
+ October 1989.
+
+12. Chair, Editor, and Authors' Addresses
+
+ John Klensin, WG Chair
+ MCI Data Services Division
+ 2100 Reston Parkway, 6th floor
+ Reston, VA 22091
+ USA
+
+ Phone:: 1 703 715 7361
+ Fax: +1 703 715 7435
+ EMail: klensin@mci.net
+
+
+ Ned Freed, Editor
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+
+ Phone:: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Moutain View, CA 94043-2186
+ USA
+
+ Phone: +1 415 968 1052
+ Fax: +1 415 968 2510
+ EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 10]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ Einar A. Stefferud
+ Network Management Associates, Inc.
+ 17301 Drey Lane
+ Huntington Beach, CA, 92647-5615
+ USA
+
+ Phone: +1 714 842 3711
+ Fax: +1 714 848 2091
+ EMail: stef@nma.com
+
+
+ Dave Crocker
+ Silicon Graphics, Inc.
+ 2011 N. Shoreline Blvd.
+ P.O. Box 7311
+ Mountain View, CA 94039
+ USA
+
+ Phone: +1 415 390 1804
+ Fax: +1 415 962 8404
+ EMail: dcrocker@sgi.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 11]
+