doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc1425.txt b/doc/rfc/rfc1425.txt
new file mode 100644
index 0000000..a118265
--- /dev/null
+++ b/doc/rfc/rfc1425.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                               J. Klensin, WG Chair
+Request for Comments: 1425                     United Nations University
+                                                        N. Freed, Editor
+                                            Innosoft International, Inc.
+                                                                 M. Rose
+                                            Dover Beach Consulting, Inc.
+                                                            E. Stefferud
+                                     Network Management Associates, Inc.
+                                                              D. Crocker
+                                                       The Branch Office
+                                                           February 1993
+
+
+                        SMTP Service Extensions
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" 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 Internet Assigned Numbers Authority
+   (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 1425                SMTP Service Extensions            February 1993
+
+
+          (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 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 1425                SMTP Service Extensions            February 1993
+
+
+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.1), a failure response (see 4.2),
+   or an error response (4.3). If the SMTP server does not support any
+   SMTP service extensions it will generate an error response (see
+   section 4.4).
+
+   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.1.  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 1425                SMTP Service Extensions            February 1993
+
+
+         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 1425                SMTP Service Extensions            February 1993
+
+
+          (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 an SMTP service extension registered with
+   IANA.  A conforming server must not offer non "X" prefixed keyword
+   values that are not described in a registered 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.2.  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.3.  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 1425                SMTP Service Extensions            February 1993
+
+
+4.4.  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.
+
+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
+
+   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
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 6]
+
+RFC 1425                SMTP Service Extensions            February 1993
+
+
+   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.
+
+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
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 7]
+
+RFC 1425                SMTP Service Extensions            February 1993
+
+
+               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>
+               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 RSET to reset the connection, and,
+               after getting a successful reply, send a HELO command and
+               proceed as specified in RFC 821.
+
+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.
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 8]
+
+RFC 1425                SMTP Service Extensions            February 1993
+
+
+   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.
+
+   [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+       Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
+
+   [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
+       Headers", RFC 1342, University of Tennessee, June 1992.
+
+   [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
+       United Nations University
+       PO Box 500, Charles Street Station
+       Boston, MA 02114-0500  USA
+
+       Phone: +1 617 227 8747
+       Fax: +1 617 491 6266
+       Email: klensin@infoods.unu.edu
+
+
+       Ned Freed, Editor
+       Innosoft International, Inc.
+       250 West First Street, Suite 240
+       Claremont, CA 91711  USA
+
+       Phone: +1 909 624 7907
+       Fax: +1 909 621 5319
+       Email: ned@innosoft.com
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 9]
+
+RFC 1425                SMTP Service Extensions            February 1993
+
+
+       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
+
+
+       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
+
+
+       David H. Crocker
+       The Branch Office
+       USA
+
+       Email: dcrocker@mordor.stanford.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                      [Page 10]
+
\ No newline at end of file