rack-mail_exception 0.0.1

data/vendor/mail/reference/rfc1652 SMTP Service Extension for 8bit-MIMEtransport.txt

@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                               J. Klensin, WG Chair
+Request for Comments: 1652                                           MCI
+Obsoletes: 1426                                         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 Extension for 8bit-MIMEtransport
+
+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.
+
+Abstract
+
+   This memo defines an extension to the SMTP service whereby an SMTP
+   content body consisting of text containing octets outside of the US-
+   ASCII octet range (hex 00-7F) may be relayed using SMTP.
+
+1.  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.
+   Given that this restriction still applies, this extension does NOT
+   provide a means for transferring unencoded binary via SMTP.
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 1]
+
+RFC 1652                SMTP 8bit-MIMEtransport                July 1994
+
+
+2.  Framework for the 8bit MIME Transport Extension
+
+   The 8bit MIME transport extension is laid out as follows:
+
+      (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.
+
+3.  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 lines
+   of 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 lines of 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.  Only one BODY parameter may
+   be used in a single MAIL command.
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 2]
+
+RFC 1652                SMTP 8bit-MIMEtransport                July 1994
+
+
+   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
+   ("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 lines of 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). This restriction means
+   that this extension MAY provide the necessary facilities for
+   transferring a MIME object with the 8BIT content-transfer-encoding,
+   it DOES NOT provide a means of transferring an object with the BINARY
+   content-transfer-encoding.
+
+   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
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 3]
+
+RFC 1652                SMTP 8bit-MIMEtransport                July 1994
+
+
+   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.
+
+4.  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
+
+5.  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].
+
+6.  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
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 4]
+
+RFC 1652                SMTP 8bit-MIMEtransport                July 1994
+
+
+   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.
+
+7.  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 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] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
+       "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
+       Consulting, Inc., Network Management Associates, Inc., Silicon
+       Graphics, Inc., July 1994.
+
+   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, BBN, January 1986.
+
+8.  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
+
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker                       [Page 5]
+
+RFC 1652                SMTP 8bit-MIMEtransport                July 1994
+
+
+   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
+
+
+   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 6]
+

data/vendor/mail/reference/rfc1892 Multipart Report .txt

@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                       G. Vaudreuil
+Request for Comments: 1892                        Octel Network Services
+Category: Standards Track                                   January 1996
+
+
+                   The Multipart/Report Content Type
+                          for the Reporting of
+                  Mail System Administrative Messages
+
+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. The Multipart/Report MIME content-type
+
+   The Multipart/Report MIME content-type is a general "family" or
+   "container" type for electronic mail reports of any kind. Although
+   this memo defines only the use of the Multipart/Report content-type
+   with respect to delivery status reports, mail processing programs
+   will benefit if a single content-type is used to for all kinds of
+   reports.
+
+   The Multipart/Report content-type is defined as follows:
+
+             MIME type name: multipart
+             MIME subtype name: report
+             Required parameters: boundary, report-type
+             Optional parameters: none
+             Encoding considerations: 7bit should always be adequate
+             Security considerations: see section 4 of this memo.
+
+   The syntax of Multipart/Report is identical to the Multipart/Mixed
+   content type defined in [MIME].  When used to send a report, the
+   Multipart/Report content-type must be the top-level MIME content type
+   for any report message.  The report-type parameter identifies the
+   type of report.  The parameter is the MIME content sub-type of the
+   second body part of the Multipart/Report.
+
+      User agents and gateways must be able to automatically determine
+      that a message is a mail system report and should be processed as
+      such.  Placing the Multipart/Report as the outermost content
+      provides a mechanism whereby an auto-processor may detect through
+      parsing the RFC 822 headers that the message is a report.
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 1]
+
+RFC 1892                    Multipart/Report                January 1996
+
+
+   The Multipart/Report content-type contains either two or three sub-
+   parts, in the following order:
+
+   (1) [required]  The first body part contains human readable message.
+       The purpose of this message is to provide an easily-understood
+       description of the condition(s) that caused the report to be
+       generated, for a human reader who may not have an user agent
+       capable of interpreting the second section of the
+       Multipart/Report.
+
+       The text in the first section may be in any MIME standards-track
+       content-type, charset, or language.  Where a description of the
+       error is desired in several languages or several media, a
+       Multipart/Alternative construct may be used.
+
+       This body part may also be used to send detailed information
+       that cannot be easily formatted into a Message/Report body part.
+
+   (2) [required]  A machine parsable body part containing an account
+       of the reported message handling event. The purpose of this body
+       part is to provide a machine-readable description of the
+       condition(s) which caused the report to be generated, along with
+       details not present in the first body part that may be useful to
+       human experts.  An initial body part, Message/delivery-status is
+       defined in [DSN]
+
+   (3) [optional]  A body part containing the returned message or a
+       portion thereof.  This information may be useful to aid human
+       experts in diagnosing problems.  (Although it may also be useful
+       to allow the sender to identify the message which the report was
+       issued, it is hoped that the envelope-id and original-recipient-
+       address returned in the Message/Report body part will replace
+       the traditional use of the returned content for this purpose.)
+
+   Return of content may be wasteful of network bandwidth and a variety
+   of implementation strategies can be used.  Generally the sender
+   should choose the appropriate strategy and inform the recipient of
+   the required level of returned content required.  In the absence of
+   an explicit request for level of return of content such as that
+   provided in [DRPT], the agent which generated the delivery service
+   report should return the full message content.
+
+   When data not encoded in 7 bits is to be returned, and the return
+   path is not guaranteed to be 8-bit capable, two options are
+   available.  The origional message MAY be reencoded into a legal 7 bit
+   MIME message or the Text/RFC822-Headers content-type MAY be used to
+   return only the origional message headers.
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 2]
+
+RFC 1892                    Multipart/Report                January 1996
+
+
+2. The Text/RFC822-Headers MIME content-type
+
+   The Text/RFC822-Headers MIME content-type provides a mechanism to
+   label and return only the RFC 822 headers of a failed message.  These
+   headers are not the complete message and should not be returned as a
+   Message/RFC822.  The returned headers are useful for identifying the
+   failed message and for diagnostics based on the received: lines.
+
+   The Text/RFC822-Headers content-type is defined as follows:
+
+          MIME type name: Text
+          MIME subtype name: RFC822-Headers
+          Required parameters: None
+          Optional parameters: none
+          Encoding considerations: 7 bit is sufficient for normal RFC822
+                 headers, however, if the headers are broken and require
+                 encoding, they may be encoded in quoted-printable.
+          Security considerations: see section 4 of this memo.
+
+   The Text/RFC822-headers body part should contain all the RFC822
+   header lines from the message which caused the report.  The RFC822
+   headers include all lines prior to the blank line in the message.
+   They include the MIME-Version and MIME Content- headers.
+
+3. References
+
+   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+       Delivery Status Notifications", RFC 1894, University of
+       Tennessee, Octel Network Services, January 1996.
+
+   [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
+       Messages", STD 11, RFC 822, UDEL, August 1982.
+
+   [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+       Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
+
+   [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
+       Notifications", RFC 1891, University of Tennessee, January 1996.
+
+4. Security Considerations
+
+   Automated use of report types without authentication presents several
+   security issues.  Forging negative reports presents the opportunity
+   for denial-of-service attacks when the reports are used for automated
+   maintenance of directories or mailing lists.  Forging positive
+   reports may cause the sender to incorrectly believe a message was
+   delivered when it was not.
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 3]
+
+RFC 1892                    Multipart/Report                January 1996
+
+
+5. Author's Address
+
+   Gregory M. Vaudreuil
+   Octel Network Services
+   17060 Dallas Parkway
+   Dallas, TX 75248-1905
+
+   Phone: +1-214-733-2722
+   EMail: Greg.Vaudreuil@Octel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 4]
+