doc: Add RFC documents

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]
+