From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1651.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc1651.txt (limited to 'doc/rfc/rfc1651.txt') 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* + + ehlo-line ::= ehlo-keyword *( SP ehlo-param ) + + ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on ehlo-keyword + ehlo-param ::= 1* + + ALPHA ::= + DIGIT ::= + + CR ::= + LF ::= + SP ::= + + 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*") / + ("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: + C: + 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: + C: + 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: + C: + + + +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] + -- cgit v1.2.3