1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc1426.txt b/doc/rfc/rfc1426.txt
new file mode 100644
index 0000000..6569f4c
--- /dev/null
+++ b/doc/rfc/rfc1426.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                               J. Klensin, WG Chair
+Request for Comments: 1426                     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 Extension
+                         for 8bit-MIMEtransport
+
+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 an extension to the SMTP service whereby an SMTP
+   content body containing octets outside of the US ASCII octet range
+   (hex 00-7F) may be relayed using SMTP.
+
+2.  Introduction
+
+   Although SMTP is widely and robustly deployed, various extensions
+   have been requested by parts of the Internet community. In
+   particular, a significant portion of the Internet community wishes to
+   exchange messages in which the content body consists of a MIME
+   message [3] containing arbitrary octet-aligned material. This memo
+   uses the mechanism described in [5] to define an extension to the
+   SMTP service whereby such contents may be exchanged. Note that this
+   extension does NOT eliminate the possibility of an SMTP server
+   limiting line length; servers are free to implement this extension
+   but nevertheless set a line length limit no lower than 1000 octets.
+
+3.  Framework for the 8bit MIME Transport Extension
+
+   The 8bit MIME transport extension is laid out as follows:
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 1]
+
+RFC 1426                SMTP 8bit-MIMEtransport            February 1993
+
+
+          (1)  the name of the SMTP service extension defined here is
+               8bit-MIMEtransport;
+
+          (2)  the EHLO keyword value associated with the extension is
+               8BITMIME;
+
+          (3)  no parameter is used with the 8BITMIME EHLO keyword;
+
+          (4)  one optional parameter using the keyword BODY is added to
+               the MAIL FROM command.  The value associated with this
+               parameter is a keyword indicating whether a 7bit message
+               (in strict compliance with [1]) or a MIME message (in
+               strict compliance with [3]) with arbitrary octet content
+               is being sent. The syntax of the value is as follows,
+               using the ABNF notation of [2]:
+
+                    body-value ::= "7BIT" / "8BITMIME"
+
+          (5)  no additional SMTP verbs are defined by this extension;
+               and,
+
+          (6)  the next section specifies how support for the extension
+               affects the behavior of a server and client SMTP.
+
+4.  The 8bit-MIMEtransport service extension
+
+   When a client SMTP wishes to submit (using the MAIL command) a
+   content body consisting of a MIME message containing arbitrary
+   octet-aligned material, it first issues the EHLO command to the
+   server SMTP. If the server SMTP responds with code 250 to the EHLO
+   command, and the response includes the EHLO keyword value 8BITMIME,
+   then the server SMTP is indicating that it supports the extended MAIL
+   command and will accept MIME messages containing arbitrary octet-
+   aligned material.
+
+   The extended MAIL command is issued by a client SMTP when it wishes
+   to transmit a content body consisting of a MIME message containing
+   arbitrary octet-aligned material. The syntax for this command is
+   identical to the MAIL command in [1], except that a BODY parameter
+   must appear after the address.
+
+   The complete syntax of this extended command is defined in [5]. The
+   esmtp-keyword is BODY and the syntax for esmtp-value is given by the
+   syntax for body-value shown above.
+
+   The value associated with the BODY parameter indicates whether the
+   content body which will be passed using the DATA command consists of
+   a MIME message containing some arbitrary octet-aligned material
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 2]
+
+RFC 1426                SMTP 8bit-MIMEtransport            February 1993
+
+
+   ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT").
+
+   A server which supports the 8-bit MIME transport service extension
+   shall preserve all bits in each octet passed using the DATA command.
+
+   Naturally, the usual SMTP data-stuffing algorithm applies so that a
+   content which contains the five-character sequence of
+
+               <CR> <LF> <DOT> <CR> <LF>
+
+   or a content that begins with the three-character sequence of
+
+               <DOT> <CR> <LF>
+
+   does not prematurely terminate the transfer of the content.  Further,
+   it should be noted that the CR-LF pair immediately preceeding the
+   final dot is considered part of the content.  Finally, although the
+   content body contains arbitrary octet-aligned material, the length of
+   each line (number of octets between two CR-LF pairs), is still
+   subject to SMTP server line length restrictions (which may allow as
+   few as 1000 octets on a single line).
+
+   Once a server SMTP supporting the 8bit-MIMEtransport service
+   extension accepts a content body containing octets with the high-
+   order (8th) bit set, the server SMTP must deliver or relay the
+   content in such a way as to preserve all bits in each octet.
+
+   If a server SMTP does not support the 8-bit MIME transport extension
+   (either by not responding with code 250 to the EHLO command, or by
+   not including the EHLO keyword value 8BITMIME in its response), then
+   the client SMTP must not, under any circumstances, attempt to
+   transfer a content which contains characters outside the US ASCII
+   octet range (hex 00-7F).
+
+   A client SMTP has two options in this case: first,  it may implement
+   a gateway transformation to convert the message into valid 7bit MIME,
+   or second, or may treat this as a permanent error and handle it in
+   the usual manner for delivery failures.  The specifics of the
+   transformation from 8bit MIME to 7bit MIME are not described by this
+   RFC; the conversion is nevertheless constrained in the following
+   ways:
+
+          (1)  it must cause no loss of information; MIME transport
+               encodings must be employed as needed to insure this is
+               the case, and
+
+          (2)  the resulting message must be valid 7bit MIME.
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 3]
+
+RFC 1426                SMTP 8bit-MIMEtransport            February 1993
+
+
+5.  Usage Example
+
+   The following dialogue illustrates the use of the 8bit-MIMEtransport
+   service extension:
+
+          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 8BITMIME
+          C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
+          S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
+          C: RCPT TO:<mrose@dbc.mtview.ca.us>
+          S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
+          C: DATA
+          S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
+           ...
+          C: .
+          S: 250 OK
+          C: QUIT
+          S: 250 Goodbye
+
+6.  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 [1].
+
+7.  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, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John
+   Wagner, 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.
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 4]
+
+RFC 1426                SMTP 8bit-MIMEtransport            February 1993
+
+
+8.  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] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+       E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
+       Nations University, Innosoft International, Inc., Dover Beach
+       Consulting, Inc., Network Management Associates, Inc., The Branch
+       Office, February 1993.
+
+   [6] Partridge, C., "Mail Routing and the Domain System", RFC 974,
+       BBN, January 1986.
+
+9.  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 5]
+
+RFC 1426                SMTP 8bit-MIMEtransport            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 6]
+
+\ No newline at end of file