I-D on esmtp

8 files changed, 3224 insertions, 0 deletions

diff --git a/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-00.txt b/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-00.txt
new file mode 100644
index 00000000..d661baa3
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-00.txt
@@ -0,0 +1,310 @@
+
+
+Network Working Group                        K. Toyoda, MGCS
+Internet Draft                       D. Crocker, Brandenburg
+  draft-ietf-fax-esmtp-conneg-00.txt               June 2001
+Expires: <12/01>
+
+
+
+                   SMTP Service Extension
+           for Content Negotiation of Internet Fax
+     
+     
+     
+     STATUS OF THIS MEMO
+     
+     This document is an Internet-Draft and is in full
+     conformance with all provisions of Section 10 of
+     RFC2026. Internet-Drafts are working documents of the
+     Internet Engineering Task Force (IETF), its areas, and
+     its working groups.  Note that other groups may also
+     distribute working documents as Internet-Drafts.
+     
+     Internet-Drafts are draft documents valid for a maximum
+     of six months and may be updated, replaced, or
+     obsoleted by other documents at any time.  It is
+     inappropriate to use Internet-Drafts as reference
+     material or to cite them other than as "work in
+     progress."
+     
+     The list of current Internet-Drafts can be accessed at
+          http://www.ietf.org/ietf/1id-abstracts.txt
+     
+     The list of Internet-Draft Shadow Directories can be
+     accessed at
+          http://www.ietf.org/shadow.html.
+     
+     COPYRIGHT NOTICE
+     
+     Copyright (C) The Internet Society (2001).  All Rights
+     Reserved.
+     
+     SUMMARY
+     
+     This document defines a content negotiation SMTP
+     service extension [ESMTP1, ESMTP2] whereby an SMTP
+     client may request information about content
+     capabilities of the target device or system that is
+     serviced by an SMTP server.  The SMTP server may report
+     the target's content capabilities back to the client.
+     This process emulates a classic facsimile start-of-
+     session capabilities negotiation.  This service
+     extension is primarily intended for "direct" SMTP
+     transfers, although relayed scenarios are permitted.
+
+
+
+1.   CONVENTIONS
+     
+     In examples, "C:" and "S:" indicate lines sent by the
+     client and server respectively.
+     
+     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD
+     NOT", and "MAY" in this document are to be interpreted
+     as defined in "Key words for use in RFCs to Indicate
+     Requirement Levels" [KEYWORDS].
+
+
+
+2.   CONTENT NEGOTIATION SERVICE EXTENSION
+     
+     (1)  The name of the SMTP service extension is
+          "Content_Negotiation"
+
+     (2)  The EHLO keyword value associated with this extension
+          is "CONNEG"
+
+     (3)  A parameter using the keyword "CONNEG" is added to the
+          RCPT-TO command
+
+     (4)  The server responds with a report of the content
+          capabilities of the device or system that embodies the
+          target RCPT-TO address.
+
+
+
+3.   CONNEG PARAMETER TO RCPT-TO
+     
+     Parameter:
+          
+          CONNEG
+     
+     Arguments:
+          
+          There are no arguments.
+     
+     Client Action:
+          
+          If the server issued a 250-CONNEG, as part of its
+     EHLO response for the current session, the client MAY
+     issue the CONNEG parameter with RCPT-TO.
+          
+          If the client issues the CONNEG parameter with
+     RCPT-TO, then it MUST honor the capabilities specified
+     in the CONNEG RCPT-TO reply, and transform data that is
+     sent, so that the target can accept the data. The
+     client SHOULD transform the data to the "highest" level
+     of capability of the server.
+     
+     Server Action:
+          
+          If the client specifies CONNEG in the RCPT-TO, but
+     the server does not support the CONNEG parameter, the
+     server MUST reject the RCPT-TO command with a 504
+     reply.
+          
+          If the server does support the CONNEG parameter,
+     then it MUST issue a 250 reply, followed by its
+     capabilities of the target that is specified by the
+     RCPT-TO address.
+          
+          The response to a CONNEG RCPT-TO request will be
+     multi-line.  For successful (250) responses, at least
+     the first line of the response is for RCPT-TO
+     information other than CONNEG.  Additional response
+     lines are for CONNEG.    In order to avoid problems due
+     to variations in line buffer sizes, the total
+     parametric listing must be provided as a series of
+     lines, each beginning with "250-CONNEG" except for the
+     last line, which is "250 CONNEG".
+          
+          An alternative approach for lengthy CONNEG data
+     would be to fit the entire parameter list into one,
+     very long virtual line, using backslash ("\") escapes
+     at the end of each physical line.  This risks the
+     buffer overflow problem, cited above.
+          
+          The contents of the capability listing MUST
+     conform to the specifications in "Content Feature
+     Schema for Internet Fax". [RFC2879]
+
+
+
+4.   SYNTAX
+     
+     Content_Negotiation =    "CONNEG"
+     
+     Capability          =    <<as per [RFC2879]>>
+
+
+
+5.   EXAMPLE
+     
+     S: 220 ifax1.jp IFAX
+     
+     C: EHLO ifax1.jp
+     
+     S: 250-ifax1.jp
+     S: 250-DSN
+     S: 250 CONNEG
+     
+     C: MAIL FROM:<May@ifax2.jp>
+     
+     S: 250 <May@ifax2.jp> sender ok
+     
+     C: RCPT TO:<June@ifax1.jp> CONNEG
+     
+     S: 250-<June@ifax1.jp> recipient ok
+     S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
+     S: 250-CONNEG   (MRC-mode=0)
+     S: 250-CONNEG   (color=Binary)
+     S: 250-CONNEG   (|(&(dpi=204)
+     S: 250-CONNEG       (dpi-xyratio=[204/98,204/196]) )
+     S: 250-CONNEG     (&(dpi=200)
+     S: 250-CONNEG       (dpi-xyratio=[200/100,1]) )
+     S: 250-CONNEG     (&(dpi=400)
+     S: 250-CONNEG       (dpi-xyratio=1) ) )
+     S: 250-CONNEG   (|(image-coding=[MH,MR,MMR])
+     S: 250-CONNEG      (&(image-coding=JBIG)
+     S: 250-CONNEG        (image-coding-constraint=JBIG-T85)
+     S: 250-CONNEG        (JBIG-stripe-size=128) ) )
+     S: 250-CONNEG   (paper-size=[letter,A4,B4])
+     S: 250 CONNEG   (ua-media=stationery) )
+     
+     C: DATA
+     
+     S: 354 okay, send data
+     
+     C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
+          Per:
+          (  image-file-structure=TIFF-minimal
+             dpi=400
+             image-coding=JBIG
+             size-x=2150
+           )
+        >>
+     
+     S: 250 message accepted
+     
+     C: QUIT
+     
+     S: 221 goodbye
+
+
+
+6.   IANA CONSIDERATIONS
+     
+     This memo is not intended to create any new issues for
+     IANA.
+
+
+
+7.   SECURITY CONSIDERATIONS
+     
+     This ESMTP option calls for a respondent to disclose
+     its capabilities.  Mechanisms for determining the
+     requestor's authenticated identity are outside the
+     scope of this specification.  It is intended that this
+     mechanism permit disclosure of public information;
+     hence there is no particular need for security
+     measures.
+     
+     However there is nothing to prevent disclosure of
+     sensitive information that should receive restricted
+     distribution.  It is, therefore, the responsibility of
+     the disclosing ESMTP server to determine whether
+     additional security measures should be applied to the
+     use of this ESMTP option.
+
+
+
+8.   ACKNOWLEDGEMENTS
+     
+     Graham Klyne provided useful suggestions to an earlier
+     draft.
+
+
+
+9.   REFERENCES
+     
+     [ESMTP1]  Klensin, J., Freed, N., Rose, M., Stefferud,
+               E. and D. Crocker, "SMTP Service Extensions",
+               RFC 1869, November 1995
+     
+     [ESMTP2]  Klensin, J., "Simple Mail Transfer Protocol",
+               RFC 2821, April 2001.
+     
+     [RFC2879] McIntyre, L. and G. Klyne, "Content Feature
+               Schema for Internet Fax", RFC 2531, August
+               2000
+
+
+
+10.       AUTHORS' ADDRESSES
+     
+     Kiyoshi Toyoda
+     Matsushita Graphic Communication Systems,Inc
+     2-3-8 Shimomeguro, Meguro-Ku
+     Tokyo 153  JAPAN
+     
+     +81.3.5434.7161
+     ktoyoda@rdmg.mgcs.mei.co.jp
+     
+     
+     Dave Crocker
+     Brandenburg InternetWorking
+     675 Spruce Drive
+     Sunnyvale, CA  94086  USA
+     
+     +1.408.246.8253
+     dcrocker@brandenburg.com
+
+
+
+11.       FULL COPYRIGHT STATEMENT
+     
+     Copyright (C) The Internet Society (2001).  All Rights
+     Reserved.
+     
+     This document and translations of it may be copied and
+     furnished to others, and derivative works that comment
+     on or otherwise explain it or assist in its
+     implementation may be prepared, copied, published and
+     distributed, in whole or in part, without restriction
+     of any kind, provided that the above copyright notice
+     and this paragraph are included on all such copies and
+     derivative works.  However, this document itself may
+     not be modified in any way, such as by removing the
+     copyright notice or references to the Internet Society
+     or other Internet organizations, except as needed for
+     the purpose of developing Internet standards in which
+     case the procedures for copyrights defined in the
+     Internet Standards process must be followed, or as
+     required to translate it into languages other than
+     English.
+     
+     The limited permissions granted above are perpetual and
+     will not be revoked by the Internet Society or its
+     successors or assigns.
+     
+     This document and the information contained herein is
+     provided on an "AS IS" basis and THE INTERNET SOCIETY
+     AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
+     WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
+     LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+     HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+     PARTICULAR PURPOSE.
+
+
diff --git a/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-01.txt b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-01.txt
new file mode 100644
index 00000000..ca00420a
--- /dev/null
+++ b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-01.txt
@@ -0,0 +1,736 @@
+
+
+     Internet Draft                                       Greg Vaudreuil
+     Expires in six months                           Lucent Technologies
+                                                           July 13, 2000
+
+
+                            SMTP Service Extensions
+                           for Transmission of Large
+                            and Binary MIME Messages
+
+                     <draft-vaudreuil-esmtp-binary2-01.txt
+
+
+
+  Status of this Memo
+
+     This document is an Internet-Draft and is in full conformance with all
+     provisions of Section 10 of RFC 2026.
+
+     This document is an Internet Draft.  Internet Drafts are working
+     documents of the Internet Engineering Task Force (IETF), its Areas,
+     and its Working Groups.  Note that other groups may also distribute
+     working documents as Internet Drafts.
+
+     Internet Drafts are valid for a maximum of six months and may be
+     updated, replaced, or obsoleted by other documents at any time.  It is
+     inappropriate to use Internet Drafts as reference material or to cite
+     them other than as a "work in progress".
+
+     To learn the current status of any Internet-Draft, please check the
+     "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+     Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+     munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+     ftp.isi.edu (US West Coast).
+
+
+
+  Copyright Notice
+
+     Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+     This Internet-Draft is in conformance with Section 10 of RFC 2026.
+
+  Abstract
+
+     This memo defines two extensions to the SMTP service.  The first
+     service enables a SMTP client and server to negotiate the use of an
+     alternative to the DATA command, called "BDAT" for efficiently sending
+     large MIME messages.  The second extension takes advantage of the BDAT
+     command to permit the negotiated sending of binary contents wrapped in
+     MIME but without a transport encoding.  This document is intended to
+     update and obsolete RFC1830.
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+  Working Group Summary
+
+     This protocol is not the product of an IETF working group, however the
+     specification resulted from discussions within the ESMTP working
+     group.  The resulting protocol documented in RFC1830 was classified as
+     experimental at that time due to questions about the robustness of the
+     Binary Content-Transport-Encoding deployed in then existent MIME
+     implementations.  As MIME has matured and other uses of the Binary
+     Content-Transport-Encoding have been deployed, these concerns have
+     been allayed.  With this document, Binary ESMTP is expected to become
+     standards-track.
+
+  Table of Contents
+
+  1.   OVERVIEW ..........................................................2
+  2.   FRAMEWORK FOR THE LARGE MESSAGE EXTENSIONS ........................3
+  3.   FRAMEWORK FOR THE BINARY SERVICE EXTENSION ........................6
+  4.   EXAMPLES ..........................................................8
+    4.1  Simple Chunking .................................................8
+    4.2  Pipelining Binarymime ...........................................9
+  5.   SECURITY CONSIDERATIONS ..........................................10
+  6.   ACKNOWLEDGMENTS ..................................................10
+  7.   REFERENCES .......................................................10
+  8.   COPYRIGHT NOTICE .................................................10
+  9.   AUTHOR'S ADDRESS .................................................11
+  10.  APPENDIX A - CHANGES FROM RFC1830 ................................12
+
+
+  1. Overview
+
+     The MIME extensions to the Internet message protocol provides for the
+     transmission of many kinds of data that was previously unsupported in
+     Internet mail.  Anticipating the need to more efficiently transport
+     the new media made possible with MIME, the SMTP protocol has been
+     extended to provide transport for new message types.  RFC 1426 defines
+     one such extension for the transmission of unencoded 8-bit MIME
+     messages [8BIT].  This service extension permits the receiver SMTP to
+     declare support for 8-bit body parts and the sender to request 8-bit
+     transmission of a particular message.
+
+     One expected result of the use of MIME is that the Internet mail
+     system will be expected to carry very large mail messages.  In such
+     transactions, there is a performance-based desire to eliminate the
+     requirement that the message be scanned for "CR LF . CR LF" sequences
+     upon sending and receiving to detect the end of message.
+
+     Independent of the need to send large messages, Internet mail is
+     increasingly multi-media.  There is a need to avoid the overhead of
+     base64 and quoted-printable encoding of binary objects sent using the
+     MIME message format over SMTP between hosts that support binary
+     message processing.
+
+     This memo uses the mechanism defined in [ESMTP] to define two
+     extensions to the SMTP service whereby a client ("sender-SMTP") may
+
+     Vaudreuil                Expires 5/1/00                    [Page 2]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+     declare support for the message chunking transmission mode and support
+     for the receiption of Binary messages.
+
+  2. Framework for the Large Message Extensions
+
+     The following service extension is hereby defined:
+
+     1) The name of the data chunking service extension is "CHUNKING".
+
+     2) The EHLO keyword value associated with this extension is
+     "CHUNKING".
+
+     3) A new SMTP verb is defined "BDAT" as an alternative to the "DATA"
+     command of [RFC821]. The BDAT verb takes two arguments.  The first
+     argument indicates the length, in octets, of the binary data chunk.
+     The second optional argument indicates that the data packet is the
+     last.
+
+        bdat-cmd   ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
+        chunk-size ::= 1*DIGIT
+        end-marker ::= "LAST"
+
+     4) This extension may be used for SMTP message submission. [Submit]
+
+     The CHUNKING service extension enables the use of the BDAT alternative
+     to the DATA command.  This extension can be used for any message,
+     whether 7 bit, 8BITMIME or BINARYMIME.
+
+     When a client SMTP wishes to submit (using the MAIL command) a large
+     message using the CHUNKING extension, 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
+     CHUNKING, then the server SMTP is indicating that it supports the BDAT
+     command and will accept the sending of messages in chunks.
+
+     After all MAIL FROM and RCPT TO responses are collected and processed,
+     the message is sent using a series of BDAT commands.  The BDAT command
+     takes one required argument, the exact length of the data segment in
+     octets.  The message data is sent immediately after the trailing <CR>
+     <LF> of the BDAT command line.  Once the receiver-SMTP receives the
+     specified number of octets, it will return a 250 reply code.
+
+     The optional LAST parameter on the BDAT command indicates that this is
+     the last chunk of message data to be sent.  Any BDAT command sent
+     after the BDAT LAST is illegal and must be replied to with a 503 "Bad
+     sequence of commands" reply code. The state resulting from this error
+     is indeterminate.  A RSET command must be sent to clear the
+     transaction before continuing.
+
+     A 250 response should be sent to each BDAT data block.  If a failure
+     occurs after a BDAT command is received, the receiver-SMTP must accept
+     and discard the associated message data before sending the 5XX code.
+     If a 5XX code is received by the sender-SMTP in response to a BDAT
+     chunk, the message should be considered failed and the sender SMTP
+
+     Vaudreuil                Expires 5/1/00                    [Page 3]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+     must not send any additional BDAT segments. If the receiver-SMTP has
+     declared support for streaming, the receiver SMTP must be prepared to
+     accept and discard additional BDAT chunks already in the pipeline
+     after the failed BDAT.
+
+          Note: An error on the receiver-SMTP such as disk full or imminent
+          shutdown can only be reported after the BDAT segment has been
+          received.  It is therefore important to choose a reasonable chunk
+          size given the expected end-to-end bandwidth.
+
+          Note:  Because the receiver-SMTP does not acknowledge the BDAT
+          command before the message data is sent, it is important to send
+          the BDAT only to systems that have declared their capability to
+          accept BDAT commands. Illegally sending a BDAT command and
+          associated message data to a non-chunking capable system will
+          result in the receiver-SMTP parsing the associated message data
+          as if it were a potentially very long, binary-data containing
+          ESMTP command line.
+
+     The resulting state from a failed BDAT command is indeterminate.  A
+     RSET command must be issued to clear the transaction before additional
+     commands may be sent. The RSET command, when issued after the first
+     BDAT and before the BDAT LAST, clears all segments sent during that
+     transaction and resets the session.
+
+     DATA and BDAT commands cannot be used in the same transaction.  If a
+     DATA statement is issued after a BDAT for the current transaction, a
+     503 "Bad sequence of commands" must be issued.  The state resulting
+     from this error is indeterminate.  A RSET command must be sent to
+     clear the transaction before continuing.  There is no prohibition on
+     using DATA and BDAT in the same session, so long as they are not mixed
+     in the same transaction.
+
+     The local storage size of a message may not accurately reflect the
+     actual size of the message sent due to local storage conventions.  In
+     particular, text messages sent with the BDAT command MUST be sent in
+     the canonical MIME format with lines delimited with a <CR><LF>.  It
+     may not be possible to convert the entire message to the canonical
+     format at once. Chunking provides a mechanism to convert the message
+     to canonical form, accurately count the bytes, and send the message a
+     single chunk at a time.
+
+          Note that correct byte counting is essential.  If the sender
+          SMTP indicates a chunk-size larger than the actual chunk-size,
+          the receiver SMTP will continue to wait for the remainder of the
+          data or when using streaming, will read the subsequent command
+          as additional message data.  In the case where a portion of the
+          previous command was read as data, the parser will return a
+          syntax error when the incomplete command is read.
+
+          If the sender SMTP indicates a chunk-size smaller than the
+          actual chunk-size, the receiver SMTP will interpret the
+          remainder of the message data as invalid commands.  Note that
+          the remainder of the message data may be binary and as such
+
+     Vaudreuil                Expires 5/1/00                    [Page 4]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+          lexicographical parsers must be prepared to receive, process,
+          and reject lines of arbitrary octets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                    [Page 5]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+  3. Framework for the Binary Service Extension
+
+     The following service extension is hereby defined:
+
+     1) The name of the binary service extension is "BINARYMIME".
+
+     2) The EHLO keyword value associated with this extension is
+     "BINARYMIME".
+
+     3) The BINARYMIME service extension can only be used with the
+     "CHUNKING" service extension.
+
+     4) No parameter is used with the BINARYMIME keyword.
+
+     5) [8BIT] defines the BODY parameter for the MAIL command.  This
+     extension defines an additional value for the BODY parameter,
+     "BINARYMIME". The value "BINARYMIME" associated with this parameter
+     indicates that this message is a Binary MIME message (in strict
+     compliance with [MIME]) with arbitrary octet content being sent. The
+     revised syntax of the value is as follows, using the ABNF notation of
+     [RFC822]:
+
+                 body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
+
+     6) No new verbs are defined for the BINARYMIME extension.
+
+     7) This extension may be used for SMTP message submission. [Submit]
+
+     A sender SMTP may request that a binary MIME message be sent without
+     transport encoding by sending a BINARYMIME parameter with the MAIL
+     command.  When the receiver SMTP accepts a MAIL FROM command with the
+     BINARYMIME body type requested, it agrees to preserve all bits in each
+     octet passed using the BDAT command. A receiver-SMTP MUST NOT
+     advertise the BINARYMIME service extension unless it relays the MIME
+     encoded message bodies octet-for-octet intact.
+
+     BINARYMIME cannot be used with the DATA command.  If a DATA command is
+     issued after a MAIL command containing the body-value of "BINARYMIME",
+     a 501 response should be sent.  The resulting state from this error
+     condition is indeterminate and the transaction should be reset with
+     the RSET command.
+
+     It is important to note that when using BINARYMIME, it is especially
+     important to ensure that the MIME message itself is properly formed.
+     In particular, it is essential that text be canonically encoded with
+     each line properly terminated with <CR> <LF>.  Any transformation of
+     text into non-canonical MIME to observe local storage conventions must
+     be reversed before sending as BINARYMIME.  Some line-oriented
+     shortcuts will break if used with BINARYMIME. A sender-SMTP MUST use
+     the canonical encoding for a given MIME content-type.  In particular,
+     text/* MUST be sent with <CR><LF> terminated lines.
+
+            Note: Although CR and LF do not represent SMTP command line
+            endings in BDAT chunks, and the 7-bit and 8-bit encodings are
+
+     Vaudreuil                Expires 5/1/00                    [Page 6]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+            not required with BINARYMIME, the RFC 2781 prohibition against
+            using a UTF-16 charset within the text top-level media type or
+            remains.
+
+     The syntax of the extended MAIL command is identical to the MAIL
+     command in [RFC821], except that a BODY parameter must appear after
+     the address.  The complete syntax of this extended command is defined
+     in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-value
+     is given by the syntax for body-value in [ESMTP].
+
+     If a receiver-SMTP does not indicate support the BINARYMIME message
+     format then the client SMTP must not, under any circumstances, send
+     binary data using the BDAT command.
+
+     If the receiver-SMTP does not support BINARYMIME and the message
+     content is a MIME object with a binary encoding, a client SMTP has two
+     options with which to forward the message.  First, it may implement a
+     gateway transformation to convert the message into valid 7bit-encoded
+     MIME.  Second, it may treat this as a permanent error and handle it in
+     the usual manner for delivery failures.  The specifics of MIME
+     content-transfer-encodings, including transformations from Binary MIME
+     to 7bit MIME are not described by this RFC; the conversion is
+     nevertheless constrained in the following ways:
+
+     1.        The conversion must cause no loss of information; MIME transport
+       encodings must be employed as needed to insure this is the case.
+
+     2.        The resulting message must be valid 7bit MIME.  In particular, the
+       transformation may not result in nested Base-64 or Quoted-Printable
+       content-transfer-encodings.
+
+     As of present there are no mechanisms for converting a binary MIME
+     object into an 8-bit MIME object.  Such a transformation will require
+     the specification of a new MIME content-transfer-encoding, the
+     standardization of which is discouraged by [MIME].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                    [Page 7]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+  4. Examples
+
+  4.1 Simple Chunking
+
+     The following simple dialogue illustrates the use of the large message
+     extension to send a short psudo-RFC822 message to one recipient using
+     the CHUNKING extension:
+
+     R: <wait for connection on TCP port 25>
+     S: <open connection to server>
+     R: 220 cnri.reston.va.us SMTP service ready
+     S: EHLO ymir.claremont.edu
+     R: 250-cnri.reston.va.us says hello
+     R: 250 CHUNKING
+     S: MAIL FROM:<Sam@Random.com>
+     R: 250 <Sam@Random.com> Sender ok
+     S: RCPT TO:<Susan@Random.com>
+     R: 250 <Susan@random.com> Recipient ok
+     S: BDAT 86 LAST
+     S: To: Susan@random.com<CR><LF>
+     S: From: Sam@random.com<CR><LF>
+     S: Subject: This is a bodyless test message<CR><LF>
+     R: 250 Message OK, 86 octets received
+     S: QUIT
+     R: 221 Goodbye
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                    [Page 8]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+  4.2 Pipelining BINARYMIME
+
+     The following dialogue illustrates the use of the large message
+     extension to send a BINARYMIME object to two recipients using the
+     CHUNKING and PIPELINING extensions:
+
+     R: <wait for connection on TCP port
+     S: <open connection to server>
+     R: 220 cnri.reston.va.us SMTP service ready
+     S: EHLO ymir.claremont.edu
+     R: 250-cnri.reston.va.us says hello
+     R: 250-PIPELINING
+     R: 250-BINARYMIME
+     R: 250 CHUNKING
+     S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME
+     S: RCPT TO:<gvaudre@cnri.reston.va.us>
+     S: RCPT TO:<jstewart@cnri.reston.va.us>
+     R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
+     R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
+     R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
+     S: BDAT 100000
+     S: (First 10000 octets of canonical MIME message data)
+     S: BDAT 324 LAST
+     S: (Remaining 324 octets of canonical MIME message data)
+     R: 250 100000 bytes received
+     R: 250 Message OK, 100324 octets received
+     S: QUIT
+     R: 221 Goodbye
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                    [Page 9]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+  5. Security Considerations
+
+     This extension is not known to present any additional security issues
+     not already endemic to electronic mail and present in fully conforming
+     implementations of [RFC821], or otherwise made possible by [MIME].
+
+  6. Acknowledgments
+
+     This protocol is the result of numerous discussions in the IETF SMTP
+     Extensions Working Group and in particular due to the continued
+     advocacy of "chunking" by Neil Katin.
+
+  7. References
+
+     [BINARY] Vaudreuil, G, " SMTP Service Extensions for Transmission of
+     Large and Binary MIME Messages", RFC 1830, August 1995.
+
+     [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+     USC/Information Sciences Institute, August 1982.
+
+     [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
+     Messages", STD 11, RFC 822, UDEL, August 1982.
+
+     [MIME] N. Borenstein, and N. Freed, "Multipurpose Internet Mail
+     Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
+     2045, Bellcore, Innosoft, November 1996.
+
+     [SUBMIT] R. Gellens, and J. Klensin, "Message Submission", RFC 2476,
+     Qualcomm, MCI, December 1998.
+
+     [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+     E., and D. Crocker, "SMTP Service Extensions" RFC 1869, United Nations
+     University, Innosoft International, Inc., Dover Beach Consulting,
+     Inc., Network Management Associates, Inc., The Branch Office, November
+     1995.
+
+     [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+     E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport"
+     RFC 1652, United Nations University, Innosoft International, Inc.,
+     Dover Beach Consulting, Inc., Network Management Associates, Inc., The
+     Branch Office, July 1994.
+
+     [PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining",
+     RFC 1854, Innosoft International, October 1995.
+
+  8. Copyright Notice
+
+     "Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+     This document and translations of it may be copied and furnished to
+     others, and derivative works that comment on or otherwise explain it
+     or assist in its implementation may be prepared, copied, published and
+     distributed, in whole or in part, without restriction of any kind,
+     provided that the above copyright notice and this paragraph are
+
+     Vaudreuil                Expires 5/1/00                   [Page 10]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+     included on all such copies and derivative works.  However, this
+     document itself may not be modified in any way, such as by removing
+     the copyright notice or references to the Internet Society or other
+     Internet organizations, except as needed for the  purpose of
+     developing Internet standards in which case the procedures for
+     copyrights defined in the Internet Standards process must be followed,
+     or as required to translate it into languages other than English.
+
+     The limited permissions granted above are perpetual and will not be
+     revoked by the Internet Society or its successors or assigns.
+
+     This document and the information contained herein is provided on an
+     "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+     TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
+     NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
+     WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+     MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+  9. Author's Address
+
+     Gregory M. Vaudreuil
+     Lucent Technologies
+     17080 Dallas Parkway
+     Dallas, TX 75248-1905
+     Voice/Fax: +1-972-733-2722
+     GregV@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                   [Page 11]
+
+
+
+     Internet Draft            Binary ESMTP                July 13, 2000
+
+
+  10. Appendix A - Changes from RFC1830
+
+     Numerous editorial changes including required intellectual property
+     boilerplate and revised authors contact information
+
+     Corrected the simple chunking example to use the correct number of
+     bytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                   [Page 12]
+
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-02.txt b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-02.txt
new file mode 100644
index 00000000..f36e3300
--- /dev/null
+++ b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-02.txt
@@ -0,0 +1,744 @@
+
+     Internet Draft                                       Greg Vaudreuil
+     Expires in six months                           Lucent Technologies
+                                                         August 10, 2000
+
+
+                            SMTP Service Extensions
+                           for Transmission of Large
+                            and Binary MIME Messages
+
+                     <draft-vaudreuil-esmtp-binary2-02.txt
+
+
+
+  Status of this Memo
+
+     This document is an Internet-Draft and is in full conformance with all
+     provisions of Section 10 of RFC 2026.
+
+     This document is an Internet Draft.  Internet Drafts are working
+     documents of the Internet Engineering Task Force (IETF), its Areas,
+     and its Working Groups.  Note that other groups may also distribute
+     working documents as Internet Drafts.
+
+     Internet Drafts are valid for a maximum of six months and may be
+     updated, replaced, or obsoleted by other documents at any time.  It is
+     inappropriate to use Internet Drafts as reference material or to cite
+     them other than as a "work in progress".
+
+
+     The list of current Internet-Drafts can be accessed at
+     http://www.ietf.org/ietf/1id-abstracts.txt
+
+     The list of Internet-Draft Shadow Directories can be accessed at
+     http://www.ietf.org/shadow.html.
+
+
+
+     To learn the current status of any Internet-Draft, please check the
+     "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+     Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+     munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+     ftp.isi.edu (US West Coast).
+
+
+
+  Copyright Notice
+
+     Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+     This Internet-Draft is in conformance with Section 10 of RFC 2026.
+
+  Abstract
+
+     This memo defines two extensions to the SMTP service.  The first
+     service enables a SMTP client and server to negotiate the use of an
+     alternative to the DATA command, called "BDAT" for efficiently sending
+     large MIME messages.  The second extension takes advantage of the BDAT
+     command to permit the negotiated sending of binary contents wrapped in
+     MIME but without a transport encoding.  This document is intended to
+     update and obsolete RFC1830.
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+  Working Group Summary
+
+     This protocol is not the product of an IETF working group, however the
+     specification resulted from discussions within the ESMTP working
+     group.  The resulting protocol documented in RFC1830 was classified as
+     experimental at that time due to questions about the robustness of the
+     Binary Content-Transport-Encoding deployed in then existent MIME
+     implementations.  As MIME has matured and other uses of the Binary
+     Content-Transport-Encoding have been deployed, these concerns have
+     been allayed.  With this document, Binary ESMTP is expected to become
+     standards-track.
+
+  Table of Contents
+
+  1.   OVERVIEW ..........................................................2
+  2.   FRAMEWORK FOR THE LARGE MESSAGE EXTENSIONS ........................3
+  3.   FRAMEWORK FOR THE BINARY SERVICE EXTENSION ........................6
+  4.   EXAMPLES ..........................................................8
+    4.1  Simple Chunking .................................................8
+    4.2  Pipelining BINARYMIME ...........................................9
+  5.   SECURITY CONSIDERATIONS ..........................................10
+  6.   REFERENCES .......................................................10
+  7.   COPYRIGHT NOTICE .................................................10
+  8.   AUTHOR'S ADDRESS .................................................11
+  9.   APPENDIX A - CHANGES FROM RFC1830 ................................12
+
+
+  1. Overview
+
+     The MIME extensions to the Internet message protocol provides for the
+     transmission of many kinds of data that were previously unsupported in
+     Internet mail.  Anticipating the need to more efficiently transport
+     the new media made possible with MIME, the SMTP protocol has been
+     extended to provide transport for new message types.  RFC 1652 defines
+     one such extension for the transmission of unencoded 8-bit MIME
+     messages [8BIT].  This service extension permits the receiver SMTP to
+     declare support for 8-bit body parts and the sender to request 8-bit
+     transmission of a particular message.
+
+     One expected result of the use of MIME is that the Internet mail
+     system will be expected to carry very large mail messages.  In such
+     transactions, there is a performance-based desire to eliminate the
+     requirement that the message be scanned for "CR LF . CR LF" sequences
+     upon sending and receiving to detect the end of message.
+
+     Independent of the need to send large messages, Internet mail is
+     increasingly multimedia.  There is a need to avoid the overhead of
+     base64 and quoted-printable encoding of binary objects sent using the
+     MIME message format over SMTP between hosts that support binary
+     message processing.
+
+     This memo uses the mechanism defined in [ESMTP] to define two
+     extensions to the SMTP service whereby a client ("sender-SMTP") may
+
+
+     Vaudreuil                Expires 2/10/01                   [Page 2]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+     declare support for the message chunking transmission mode and support
+     for the receiption of Binary messages.
+
+  2. Framework for the Large Message Extensions
+
+     The following service extension is hereby defined:
+
+     1) The name of the data chunking service extension is "CHUNKING".
+
+     2) The EHLO keyword value associated with this extension is
+     "CHUNKING".
+
+     3) A new SMTP verb is defined "BDAT" as an alternative to the "DATA"
+     command of [RFC821]. The BDAT verb takes two arguments.  The first
+     argument indicates the length, in octets, of the binary data chunk.
+     The second optional argument indicates that the data chunk is the
+     last.
+
+        bdat-cmd   ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
+        chunk-size ::= 1*DIGIT
+        end-marker ::= "LAST"
+
+     4) This extension may be used for SMTP message submission. [Submit]
+
+     The CHUNKING service extension enables the use of the BDAT alternative
+     to the DATA command.  This extension can be used for any message,
+     whether 7-bit, 8BITMIME or BINARYMIME.
+
+     When a sender-SMTP wishes to send (using the MAIL command) a large
+     message using the CHUNKING extension, it first issues the EHLO command
+     to the receiver-SMTP.  If the receiver-SMTP responds with code 250 to
+     the EHLO command and the response includes the EHLO keyword value
+     CHUNKING, then the receiver-SMTP is indicating that it supports the
+     BDAT command and will accept the sending of messages in chunks.
+
+     After all MAIL and RCPT responses are collected and processed, the
+     message is sent using a series of BDAT commands.  The BDAT command
+     takes one required argument, the exact length of the data segment in
+     octets.  The message data is sent immediately after the trailing <CR>
+     <LF> of the BDAT command line.  Once the receiver-SMTP receives the
+     specified number of octets, it will return a 250 reply code.
+
+     The optional LAST parameter on the BDAT command indicates that this is
+     the last chunk of message data to be sent.  The last BDAT command MAY
+     have a byte-count of zero indicating there is no additional data to be
+     sent. Any BDAT command sent after the BDAT LAST is illegal and MUST be
+     replied to with a 503 "Bad sequence of commands" reply code. The state
+     resulting from this error is indeterminate.  A RSET command MUST be
+     sent to clear the transaction before continuing.
+
+  A 250 response MUST be sent to each successful BDAT data block within a
+  mail transaction.  If a failure occurs after a BDAT command is received,
+  the receiver-SMTP MUST accept and discard the associated message data
+  before sending the appropriate 5XX or 4XX code.  If a 5XX or 4XX code is
+
+     Vaudreuil                Expires 2/10/01                   [Page 3]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+  received by the sender-SMTP in response to a BDAT chunk, the transaction
+  should be considered failed and the sender-SMTP MUST NOT send any
+  additional BDAT segments. If the receiver-SMTP has declared support for
+  command pipelining [PIPE], the receiver SMTP MUST be prepared to accept
+  and discard additional BDAT chunks already in the pipeline after the
+  failed BDAT.
+
+          Note: An error on the receiver-SMTP such as disk full or imminent
+          shutdown can only be reported after the BDAT segment has been
+          received.  It is therefore important to choose a reasonable chunk
+          size given the expected end-to-end bandwidth.
+
+          Note:  Because the receiver-SMTP does not acknowledge the BDAT
+          command before the message data is sent, it is important to send
+          the BDAT only to systems that have declared their capability to
+          accept BDAT commands. Illegally sending a BDAT command and
+          associated message data to a non-CHUNKING capable system will
+          result in the receiver-SMTP parsing the associated message data
+          as if it were a potentially very long, ESMTP command line
+          containing binary data.
+
+     The resulting state from a failed BDAT command is indeterminate.  A
+     RSET command MUST be issued to clear the transaction before additional
+     commands may be sent. The RSET command, when issued after the first
+     BDAT and before the BDAT LAST, clears all segments sent during that
+     transaction and resets the session.
+
+     DATA and BDAT commands cannot be used in the same transaction.  If a
+     DATA statement is issued after a BDAT for the current transaction, a
+     503 "Bad sequence of commands" MUST be issued.  The state resulting
+     from this error is indeterminate.  A RSET command MUST be sent to
+     clear the transaction before continuing.  There is no prohibition on
+     using DATA and BDAT in the same session, so long as they are not mixed
+     in the same transaction.
+
+     The local storage size of a message may not accurately reflect the
+     actual size of the message sent due to local storage conventions.  In
+     particular, text messages sent with the BDAT command MUST be sent in
+     the canonical MIME format with lines delimited with a <CR><LF>.  It
+     may not be possible to convert the entire message to the canonical
+     format at once. CHUNKING provides a mechanism to convert the message
+     to canonical form, accurately count the bytes, and send the message a
+     single chunk at a time.
+
+          Note that correct byte counting is essential.  If the sender-
+          SMTP indicates a chunk-size larger than the actual chunk-size,
+          the receiver-SMTP will continue to wait for the remainder of the
+          data or when using streaming, will read the subsequent command
+          as additional message data.  In the case where a portion of the
+          previous command was read as data, the parser will return a
+          syntax error when the incomplete command is read.
+
+          If the sender-SMTP indicates a chunk-size smaller than the
+          actual chunk-size, the receiver-SMTP will interpret the
+
+     Vaudreuil                Expires 2/10/01                   [Page 4]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+          remainder of the message data as invalid commands.  Note that
+          the remainder of the message data may be binary and as such
+          lexicographical parsers MUST be prepared to receive, process,
+          and reject lines of arbitrary octets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 2/10/01                   [Page 5]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+  3. Framework for the Binary Service Extension
+
+     The following service extension is hereby defined:
+
+     1) The name of the binary service extension is "BINARYMIME".
+
+     2) The EHLO keyword value associated with this extension is
+     "BINARYMIME".
+
+     3) The BINARYMIME service extension can only be used with the
+     "CHUNKING" service extension.
+
+     4) No parameter is used with the BINARYMIME keyword.
+
+     5) [8BIT] defines the BODY parameter for the MAIL command.  This
+     extension defines an additional value for the BODY parameter,
+     "BINARYMIME". The value "BINARYMIME" associated with this parameter
+     indicates that this message is a Binary MIME message (in strict
+     compliance with [MIME]) with arbitrary octet content being sent. The
+     revised syntax of the value is as follows, using the ABNF notation of
+     [RFC822]:
+
+                 body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
+
+     6) No new verbs are defined for the BINARYMIME extension.
+
+     7) This extension may be used for SMTP message submission. [Submit]
+
+     A sender-SMTP may request that a binary MIME message be sent without
+     transport encoding by sending a BODY parameter with a value of
+     "BINARYMIME" with the MAIL command.  When the receiver-SMTP accepts a
+     MAIL command with the BINARYMIME body-value, it agrees to preserve all
+     bits in each octet passed using the BDAT command. A receiver-SMTP MUST
+     NOT advertise the BINARYMIME service extension unless it relays the
+     MIME encoded message bodies octet-for-octet intact.
+
+     BINARYMIME cannot be used with the DATA command.  If a DATA command is
+     issued after a MAIL command containing the body-value of "BINARYMIME",
+     a 503 "Bad sequence of commands" response MUST be sent.  The resulting
+     state from this error condition is indeterminate and the transaction
+     MUST be reset with the RSET command.
+
+     It is important to note that when using BINARYMIME, it is especially
+     important to ensure that the MIME message itself is properly formed.
+     In particular, it is essential that text be canonically encoded with
+     each line properly terminated with <CR><LF>.  Any transformation of
+     text into non-canonical MIME to observe local storage conventions MUST
+     be reversed before sending as BINARYMIME.  Some line-oriented
+     shortcuts will break if used with BINARYMIME. A sender-SMTP MUST use
+     the canonical encoding for a given MIME content-type.  In particular,
+     text/* MUST be sent with <CR><LF> terminated lines.
+
+            Note: Although CR and LF do not represent SMTP command line
+            endings in BDAT chunks, and the 7-bit and 8-bit encodings are
+
+     Vaudreuil                Expires 2/10/01                   [Page 6]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+            not required with BINARYMIME, the RFC 2781 prohibition against
+            using a UTF-16 charset within the text top-level media type or
+            remains.
+
+     The syntax of the extended MAIL command is identical to the MAIL
+     command in [RFC821], except that a BODY parameter MUST appear after
+     the address.  The complete syntax of this extended command is defined
+     in [ESMTP].
+
+     If a receiver-SMTP does not indicate support the BINARYMIME message
+     format then the sender-SMTP MUST NOT, under any circumstances, send
+     binary data.
+
+     If the receiver-SMTP does not support BINARYMIME and the message to be
+     sent is a MIME object with a binary encoding, a sender-SMTP has two
+     options with which to forward the message.  First, it may implement a
+     gateway transformation to convert the message into valid 7bit-encoded
+     MIME.  Second, it may treat this as a permanent error and handle it in
+     the usual manner for delivery failures.  The specifics of MIME
+     content-transfer-encodings, including transformations from Binary MIME
+     to 7bit MIME are not described by this RFC;  the conversion is
+     nevertheless constrained in the following ways:
+
+     1. The conversion MUST cause no loss of information;  MIME transport
+     encodings MUST be employed as needed to insure this is the case.
+
+     2. The resulting message MUST be valid 7bit MIME.  In particular, the
+     transformation may not result in nested Base-64 or Quoted-Printable
+     content-transfer-encodings.
+
+     As of present there are no mechanisms for converting a binary MIME
+     object into an 8-bit MIME object.  Such a transformation will require
+     the specification of a new MIME content-transfer-encoding, the
+     standardization of which is discouraged by [MIME].
+
+     If the MIME message contains a "Binary" content-transfer-encoding and
+     the BODY parameter does not indicate BINARYMIME, the message MUST be
+     accepted.  The message SHOULD be returned to the sender with an
+     appropriate DSN.  The message contents MAY be returned to the sender
+     if the offending content can be mangled into a legal DSN structure.
+     "Fixing" and forwarding the offending content is beyond the scope of
+     this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 2/10/01                   [Page 7]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+  4. Examples
+
+  4.1 Simple Chunking
+
+     The following simple dialogue illustrates the use of the large message
+     extension to send a short psudo-RFC822 message to one recipient using
+     the CHUNKING extension:
+
+     R: <wait for connection on TCP port 25>
+     S: <open connection to server>
+     R: 220 cnri.reston.va.us SMTP service ready
+     S: EHLO ymir.claremont.edu
+     R: 250-cnri.reston.va.us says hello
+     R: 250 CHUNKING
+     S: MAIL FROM:<Sam@Random.com>
+     R: 250 <Sam@Random.com> Sender ok
+     S: RCPT TO:<Susan@Random.com>
+     R: 250 <Susan@random.com> Recipient ok
+     S: BDAT 86 LAST
+     S: To: Susan@random.com<CR><LF>
+     S: From: Sam@random.com<CR><LF>
+     S: Subject: This is a bodyless test message<CR><LF>
+     R: 250 Message OK, 86 octets received
+     S: QUIT
+     R: 221 Goodbye
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 2/10/01                   [Page 8]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+  4.2 Pipelining BINARYMIME
+
+     The following dialogue illustrates the use of the large message
+     extension to send a BINARYMIME object to two recipients using the
+     CHUNKING and PIPELINING extensions:
+
+     R: <wait for connection on TCP port
+     S: <open connection to server>
+     R: 220 cnri.reston.va.us SMTP service ready
+     S: EHLO ymir.claremont.edu
+     R: 250-cnri.reston.va.us says hello
+     R: 250-PIPELINING
+     R: 250-BINARYMIME
+     R: 250 CHUNKING
+     S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME
+     S: RCPT TO:<gvaudre@cnri.reston.va.us>
+     S: RCPT TO:<jstewart@cnri.reston.va.us>
+     R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
+     R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
+     R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
+     S: BDAT 100000
+     S: (First 10000 octets of canonical MIME message data)
+     S: BDAT 324
+     S: (Remaining 324 octets of canonical MIME message data)
+     S: BDAT 0 LAST
+     R: 250 100000 octets received
+     R: 250 324 octets received
+     R: 250 Message OK, 100324 octets received
+     S: QUIT
+     R: 221 Goodbye
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 2/10/01                   [Page 9]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+  5. Security Considerations
+
+     This extension is not known to present any additional security issues
+     not already endemic to electronic mail and present in fully conforming
+     implementations of [RFC821], or otherwise made possible by [MIME].
+
+  6. References
+
+     [BINARY] Vaudreuil, G, " SMTP Service Extensions for Transmission of
+     Large and Binary MIME Messages", RFC 1830, August 1995.
+
+     [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+     USC/Information Sciences Institute, August 1982.
+
+     [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
+     Messages", STD 11, RFC 822, UDEL, August 1982.
+
+     [MIME] N. Borenstein, and N. Freed, "Multipurpose Internet Mail
+     Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
+     2045, Bellcore, Innosoft, November 1996.
+
+     [SUBMIT] R. Gellens, and J. Klensin, "Message Submission", RFC 2476,
+     Qualcomm, MCI, December 1998.
+
+     [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+     E., and D. Crocker, "SMTP Service Extensions" RFC 1869, United Nations
+     University, Innosoft International, Inc., Dover Beach Consulting,
+     Inc., Network Management Associates, Inc., The Branch Office, November
+     1995.
+
+     [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+     E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport"
+     RFC 1652, United Nations University, Innosoft International, Inc.,
+     Dover Beach Consulting, Inc., Network Management Associates, Inc., The
+     Branch Office, July 1994.
+
+     [PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining",
+     RFC 2197, Innosoft International, September 1997.
+
+
+
+  7. Copyright Notice
+
+     "Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+     This document and translations of it may be copied and furnished to
+     others, and derivative works that comment on or otherwise explain it
+     or assist in its implementation may be prepared, copied, published and
+     distributed, in whole or in part, without restriction of any kind,
+     provided that the above copyright notice and this paragraph are
+     included on all such copies and derivative works.  However, this
+     document itself may not be modified in any way, such as by removing
+     the copyright notice or references to the Internet Society or other
+     Internet organizations, except as needed for the  purpose of
+
+     Vaudreuil                Expires 2/10/01                  [Page 10]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+     developing Internet standards in which case the procedures for
+     copyrights defined in the Internet Standards process MUST be followed,
+     or as required to translate it into languages other than English.
+
+     The limited permissions granted above are perpetual and will not be
+     revoked by the Internet Society or its successors or assigns.
+
+     This document and the information contained herein is provided on an
+     "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+     TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
+     NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
+     WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+     MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+  8. Author's Address
+
+     Gregory M. Vaudreuil
+     Lucent Technologies
+     17080 Dallas Parkway
+     Dallas, TX 75248-1905
+     Voice/Fax: +1-972-733-2722
+     GregV@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 2/10/01                  [Page 11]
+
+
+
+     Internet Draft            Binary ESMTP              August 10, 2000
+
+
+  9. Appendix A - Changes from RFC1830
+
+     Numerous editorial changes including required intellectual property
+     boilerplate and revised authors contact information
+
+     Corrected the simple chunking example to use the correct number of
+     bytes.  Updated the pipelining example to illustrate use of the BDAT 0
+     LAST construct.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 2/10/01                  [Page 12]
+
diff --git a/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-03.txt b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-03.txt
new file mode 100644
index 00000000..624a8aac
--- /dev/null
+++ b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-03.txt
@@ -0,0 +1,62 @@
+A new Request for Comments is now available in online RFC libraries.

+

+

+        RFC 3030

+

+        Title:      SMTP Service Extensions for Transmission of Large

+                    and Binary MIME Messages

+        Author(s):  G. Vaudreuil

+        Status:     Standards Track

+        Date:       December 2000

+        Mailbox:    GregV@ieee.org

+        Pages:      12

+        Characters: 23405

+        Obsoletes:  1830

+

+        I-D Tag:    draft-vaudreuil-esmtp-binary2-03.txt

+

+        URL:        ftp://ftp.isi.edu/in-notes/rfc3030.txt

+

+

+This memo defines two extensions to the SMTP (Simple Mail Transfer

+Protocol) service.  The first extension enables a SMTP client and

+server to negotiate the use of an alternative to the DATA command,

+called "BDAT", for efficiently sending large MIME (Multipurpose

+Internet Mail Extensions) messages.  The second extension takes

+advantage of the BDAT command to permit the negotiated sending of MIME

+messages that employ the binary transfer encoding.  This document is

+intended to update and obsolete RFC 1830.

+

+This is now a Proposed Standard Protocol.

+

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

+

+This announcement is sent to the IETF list and the RFC-DIST list.

+Requests to be added to or deleted from the IETF distribution list

+should be sent to IETF-REQUEST@IETF.ORG.  Requests to be

+added to or deleted from the RFC-DIST distribution list should

+be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

+

+Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

+an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

+help: ways_to_get_rfcs.  For example:

+

+        To: rfc-info@RFC-EDITOR.ORG

+        Subject: getting rfcs

+

+        help: ways_to_get_rfcs

+

+Requests for special distribution should be addressed to either the

+author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless

+specifically noted otherwise on the RFC itself, all RFCs are for

+unlimited distribution.echo 

+Submissions for Requests for Comments should be sent to

+RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC

+Authors, for further information.

+

+

diff --git a/Documentation/en/I-D/draft-ward-esmtp-slide-00.txt b/Documentation/en/I-D/draft-ward-esmtp-slide-00.txt
new file mode 100644
index 00000000..230d5b31
--- /dev/null
+++ b/Documentation/en/I-D/draft-ward-esmtp-slide-00.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+                                                             A. Ward
+INTERNET-DRAFT
+Category:  Experimental                                 9 March 2000
+draft-ward-esmtp-slide-00.txt            Exprires:  9 September 2000
+
+
+             SMTP Service Extension for Slightly Differing
+                       Multicast Messages (SLIDE)
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Abstract
+
+   This memo defines an extension to the SMTP service [Klensin, et al
+   1995] to realize efficiency improvements in the relaying and delivery
+   of slightly differing messages bound for more than one recipient, as
+   specified by multiple RCPT TO commands.
+
+0. Revision History
+
+   The first version (-00) of this document was unleashed on 9 March
+   2000.
+
+1. Introduction
+
+   SMTP is an Internet message protocol that is used to send messages to
+   one or more recipients.  To realize any efficiency when sending a
+   message to multiple recipients, the message body and all headers must
+
+
+
+Ward                                                            [Page 1]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          9 March 2000
+
+
+   be identical.  It is desirable, under some circumstances, to send
+   messages to multiple recipients that differ only slightly in their
+   body and/or headers.
+
+   Under SMTP [Postel 1982] such a scenario would result in a different
+   message being sent from the initial SMTP-client through each relay
+   server until the final SMTP server is reached.  In situations where
+   more that one of the multiple recipients have mail handled by the
+   same SMTP-server, a significant bandwidth reduction can be realized
+   with the SLIDE service extension.
+
+2. Framework for the Slightly Differing Multicast Message Extension
+
+   The slightly differing multicast message extension is as follows:
+
+   (1) the name of the SMTP service extension defined here is slightly-
+   differing-multicast-message; (2) the EHLO keyword value associated
+   with the extension is SLIDE; (3) no parameter is used with the SLIDE
+   EHLO keyword; (4) no additional SMTP verbs are defined by this
+   extension (5) one optional parameter using the keyword SLIDERANGE is
+   added to the RCPT TO command.  The value associated with this
+   parameter is a comma-delimited list of octet ranges indicating which
+   pieces of the overall message SHOULD be delivered to the specified
+   recipient.  The syntax for the value follows, using the ABNF notation
+   of [Crocker 1982]:
+
+   sliderange-value ::= octet-range *( "," octet-range )
+
+   octet-range ::= octet-address [ "-" octet-address ]
+
+   octet-address ::= DIGIT *(DIGIT)
+
+   DIGIT ::= <any one of the 10 numeric characters (0 through 9)>
+
+   (6) the next section specifies how support for the extension affects
+   the behaviour of a server and client SMTP; and, (7) the maximum
+   length of a RCPT TO command line is increased by 256 characters by
+   the possible addition of the SLIDERANGE keyword and value.  Of
+   course, since the value could conceivably be longer than 256
+   characters, implementations are welcome to allot more space for this
+   purpose.
+
+3. The slightly-differing-multicast-message Service Extension
+
+3.1 Effects on the Client SMTP
+
+   When a client SMTP wishes to submit (using the MAIL command) messages
+   with slightly different content to recipients at the same server
+
+
+
+Ward                                                            [Page 2]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          9 March 2000
+
+
+   SMTP, 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 SLIDE, then the server SMTP
+   is indicating that is supports the extended RCPT command.  Such a
+   server SMTP will accept a message containing the combined contents of
+   the slightly differing messages addressed to all of the recipients
+   for delivery.  The method for combining the various message bodies
+   (and interpreting combined message bodies) is described in the next
+   section.
+
+   The extended RCPT command is issued by a client SMTP when it wishes
+   to transmit part of a combined message body to the specified
+   recipient.  The syntax for this command is identical to the RCPT
+   command in [Postel 1982], except that a SLIDERANGE parameter must
+   appear after the address.  Multiple SLIDERANGE parameters may be used
+   in a single RCPT command; however, in such a case, the values of the
+   several parameters SHOULD be combined into a single, continuous,
+   comma-delimited list of octet ranges.
+
+   The value associated with the SLIDERANGE parameter lists which octets
+   in the impending DATA command are to be sent to the specified
+   recipient.
+
+3.2 Effects on the Server SMTP
+
+   A server SMTP which supports the slightly differing multicast message
+   service extension SHOULD relay only those octets bound for recipients
+   at a particular domain to the mail exchange for that domain.  If this
+   suggested message trimming occurs, the octets specified in the
+   SLIDERANGE parameter for each recipient MUST be adjusted to
+   correspond with the changes to the message DATA.
+
+   The final 5 octets of the message DATA (<CR><LF>.<CR><LF>) MUST
+   always be relayed, even if not explicitly specified in the SLIDERANGE
+   parameter value.
+
+   Once a server SMTP supporting the slightly differing multicast
+   message service extension accepts a message for which any recipient
+   has a non-trivial SLIDERANGE parameter value, the server SMTP MUST
+   deliver or relay the message in such a way as to ensure that only the
+   octets specified for a particular recipient will be received by that
+   recipient.  As well, when the server SMTP is relaying the message, it
+   SHOULD attempt to minimize the number of octets that are relayed to
+   each downstream server SMTP.
+
+4. Usage Examples
+
+   The following dialogue illustrates the use of the slightly differing
+
+
+
+Ward                                                            [Page 3]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          9 March 2000
+
+
+   multicast message service extension:
+
+   S: <wait for connection>
+   C: <open connection to server>
+   S: 220 anstruther.elsewhere.com SMTP ready
+   C: EHLO burleigh.uwaterloo.ca
+   S: 250-hello burleigh.uwaterloo.ca
+   S: 250 SLIDE
+   C: MAIL FROM:<andrew@burleigh.uwaterloo.ca>
+   S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay
+   C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-125,200-1234
+   S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay
+   C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=126-1234
+   S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay
+   C: DATA
+   S: 354 any octets beyond 1235 will not be relayed, end with CRLF.CRLF
+   C: ...<message data>...
+   C: .
+   S: 250 okay
+   C: QUIT
+   S: 250 bye bye
+
+   The following dialogue illustrates the efficiencies that can be
+   realized in a relaying scenario:
+
+   S1: 220 one.there.com SMTP ready
+   C0: EHLO zero.here.com
+   S1: 250-hello zero.here.com
+   S1: 250 SLIDE
+   C0: MAIL FROM:<me@here.com>
+   S1: 250 <me@here.com>... sender okay
+   C0: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250
+   S1: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199
+   S1: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<laurene@everywhere.com> SLIDERANGE=0-250
+   S1: 250 <laurene@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<rachael@elsewhere.com>
+   S1: 250 <rachael@elsewhere.com>... recipient okay
+   C0: DATA
+   S1: 354 okay, send message body, end with CRLF.CRLF
+   C0: ...<1000 octets of message>...
+   C0: .
+   S1: 250 okay
+   C0: QUIT
+   S1: 250 bye bye
+    ...
+   S2: 220 two.everywhere.com SMTP ready
+
+
+
+Ward                                                            [Page 4]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          9 March 2000
+
+
+   C1: EHLO one.there.com
+   S2: 250-hello one.there.com
+   S2: 250 SLIDE
+   C1: MAIL FROM:<me@here.com>
+   S2: 250 <me@here.com>... sender okay
+   C1: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250
+   S2: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay
+   C1: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199
+   S2: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay
+   C1: RCPT TO:<laurene@everywhere.com>
+   S2: 250 <laurene@everywhere.com>... recipient okay
+   C1: DATA
+   S2: 354 okay, send message body, end with CRLF.CRLF
+   C1: ...<octets 0 to 250 of message>...
+   C1: .
+   S2: 250 okay
+   C1: QUIT
+   S2: 250 bye bye
+    ...
+   S3: 220 three.elsewhere.com SMTP ready
+   C1: EHLO one.there.com
+   S3: 250-hello one.there.com
+   S3: 250 SLIDE
+   C1: MAIL FROM:<me@here.com>
+   S3: 250 <me@here.com>... sender okay
+   C1: RCPT TO:<rachael@elsewhere.com>
+   S3: 250 <rachael@elsewhere.com>... recipient okay
+   C1: DATA
+   S3: 354 okay, send message body, end with CRLF.CRLF
+   C1: ...<all octets of message>...
+   C1: .
+   S3: 250 okay
+   C1: QUIT
+   S3: 250 bye bye
+
+5. Security Considerations
+
+   This extension takes some of the "final control" out of the hands of
+   the client, and places it on the server SMTPs that are charged with
+   relaying and delivering the message.  While any server SMTP has
+   access to change the content of a message that it relays or delivers,
+   a server SMTP that supports the slightly differing multicast message
+   service extension is obliged to be able to alter a message that takes
+   advantage of this extension.  As a result of the increased handling
+   by the server SMTP, there is more room for error in the message
+   transmission.
+
+6. Acknowledgements
+
+
+
+Ward                                                            [Page 5]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          9 March 2000
+
+
+   Thanks to Ed, Doug, Laurene and Rachael for their (unwilling)
+   participation in the usage examples.
+
+7. References
+
+   [Crocker 1982]  Crocker, D.  "Standard for the Format of ARPA
+   Internet Text Messages", STD 11, RFC 822.  UDEL, August 1982.
+
+   [Klensin, et al 1995]  Klensin, J., N. Freed, M. Rose, E. Stefferud,
+   and D. Crocker.  "SMTP Service Extensions", STD 10, RFC 1869.
+   November 1995.
+
+   [Postel 1982]  Postel, J.  "Simple Mail Transfer Protocol", STD 10,
+   RFC 821.  USC/Information Sciences Institute, August 1982.
+
+8. Author's Address
+
+   Andrew Ward
+   70 Gruhn Street
+   Kitchener, ON  N2G 1S6
+   CANADA
+
+   Phone:  +1 519 581 1201
+   EMail:  amward@uwaterloo.ca
+
+
+
+                        EXPIRES:  9 September 2000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ward                                                            [Page 6]
+
diff --git a/Documentation/en/I-D/draft-ward-esmtp-slide-01.txt b/Documentation/en/I-D/draft-ward-esmtp-slide-01.txt
new file mode 100644
index 00000000..90cccd3d
--- /dev/null
+++ b/Documentation/en/I-D/draft-ward-esmtp-slide-01.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+                                                             A. Ward
+INTERNET-DRAFT
+Category:  Experimental                                 7 April 2000
+draft-ward-esmtp-slide-01.txt              Exprires:  7 October 2000
+
+
+             SMTP Service Extension for Slightly Differing
+                       Multicast Messages (SLIDE)
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Abstract
+
+   This memo defines an extension to the SMTP service [Klensin, et al
+   1995] to realize efficiency improvements in the relaying and delivery
+   of slightly differing messages bound for more than one recipient, as
+   specified by multiple RCPT TO commands [Postel 1982].
+
+0. Revision History
+
+   The first version (-00) of this document was unleashed on 9 March
+   2000.
+
+   (-01)  Added section (5.1), regarding the impact of the SLIDE
+   extension to signed or encrypted messages.  Modified the first
+   example in section (4.) to make the impact of SLIDE more explicit.
+
+0.0 Conventions Used in this Document
+
+
+
+Ward                                                            [Page 1]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          7 April 2000
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [Bradner
+   1997].
+
+1. Introduction
+
+   SMTP is an Internet message protocol that is used to send messages to
+   one or more recipients.  To realize any efficiency when sending a
+   message to multiple recipients, the message body and all headers must
+   be identical.  It is desirable, under some circumstances, to send
+   messages to multiple recipients that differ only slightly in their
+   body and/or headers.
+
+   Under SMTP [Postel 1982] such a scenario would result in a different
+   message being sent from the initial client SMTP through each relay
+   server until the final server SMTP is reached.  In situations where
+   more that one of the multiple recipients have mail handled by the
+   same server SMTP, a significant bandwidth reduction can be realized
+   with the SLIDE service extension.
+
+2. Framework for the Slightly Differing Multicast Message Extension
+
+   The slightly differing multicast message extension is as follows:
+
+   (1) the name of the SMTP service extension defined here is slightly-
+   differing-multicast-message;
+
+   (2) the EHLO keyword value associated with the extension is SLIDE;
+
+   (3) no parameter is used with the SLIDE EHLO keyword;
+
+   (4) no additional SMTP verbs are defined by this extension
+
+   (5) one optional parameter using the keyword SLIDERANGE is added to
+   the RCPT TO command.  The value associated with this parameter is a
+   comma-delimited list of octet ranges indicating which pieces of the
+   overall message SHOULD be delivered to the specified recipient.  The
+   syntax for the value follows, using the ABNF notation of [Crocker
+   1982]:
+
+   sliderange-value ::= octet-range *( "," octet-range )
+
+   octet-range ::= octet-address [ "-" octet-address ]
+
+   octet-address ::= DIGIT *(DIGIT)
+
+   DIGIT ::= <any one of the 10 numeric characters (0 through 9)>
+
+
+
+Ward                                                            [Page 2]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          7 April 2000
+
+
+   (6) the next section specifies how support for the extension affects
+   the behaviour of a server and client SMTP; and,
+
+   (7) the maximum length of a RCPT TO command line is increased by 256
+   characters by the possible addition of the SLIDERANGE keyword and
+   value.  Of course, since the value could conceivably be longer than
+   256 characters, implementations are welcome to allot more space for
+   this purpose.
+
+3. The slightly-differing-multicast-message Service Extension
+
+3.1 Effects on the Client SMTP
+
+   When a client SMTP wishes to submit (using the MAIL command) messages
+   with slightly different content to recipients at the same server
+   SMTP, 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 SLIDE, then the server SMTP
+   is indicating that it supports the extended RCPT command.  Such a
+   server SMTP will accept a message containing the combined contents of
+   the slightly differing messages addressed to all of the recipients
+   for delivery.  The method for combining the various message bodies
+   (and interpreting combined message bodies) is described in the next
+   section.
+
+   The extended RCPT command is issued by a client SMTP when it wishes
+   to transmit part of a combined message body to the specified
+   recipient.  The syntax for this command is identical to the RCPT
+   command in [Postel 1982], except that a SLIDERANGE parameter must
+   appear after the address.  Multiple SLIDERANGE parameters may be used
+   in a single RCPT command; however, in such a case, the values of the
+   several parameters SHOULD be combined into a single, continuous,
+   comma-delimited list of octet ranges.
+
+   The value associated with the SLIDERANGE parameter lists which octets
+   in the impending DATA command are to be sent to the specified
+   recipient.
+
+3.2 Effects on the Server SMTP
+
+   A server SMTP which supports the slightly differing multicast message
+   service extension SHOULD relay only those octets bound for recipients
+   at a particular domain to the mail exchange for that domain.  If this
+   suggested message trimming occurs, the octets specified in the
+   SLIDERANGE parameter for each recipient MUST be adjusted to
+   correspond with the changes to the message DATA.
+
+   The final 5 octets of the message DATA (<CR><LF>.<CR><LF>) MUST
+
+
+
+Ward                                                            [Page 3]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          7 April 2000
+
+
+   always be relayed, even if not explicitly specified in the SLIDERANGE
+   parameter value.
+
+   Once a server SMTP supporting the slightly differing multicast
+   message service extension accepts a message for which any recipient
+   has a non-trivial SLIDERANGE parameter value, the server SMTP MUST
+   deliver or relay the message in such a way as to ensure that only the
+   octets specified for a particular recipient will be received by that
+   recipient.  As well, when the server SMTP is relaying the message, it
+   SHOULD attempt to minimize the number of octets that are relayed to
+   each downstream server SMTP.
+
+4. Usage Examples
+
+   The following dialogue illustrates the use of the slightly differing
+   multicast message service extension:
+
+   S: <wait for connection>
+   C: <open connection to server>
+   S: 220 anstruther.elsewhere.com SMTP ready
+   C: EHLO burleigh.uwaterloo.ca
+   S: 250-hello burleigh.uwaterloo.ca
+   S: 250 SLIDE
+   C: MAIL FROM:<andrew@burleigh.uwaterloo.ca>
+   S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay
+   C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-322
+   S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay
+   C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-272,320-322
+   S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay
+   C: DATA
+   S: 354 any octets beyond 1235 will not be relayed, end with CRLF.CRLF
+   C: Message-ID: <1234.abcd@uwaterloo.ca>
+   C: Date: Mon, 03 Apr 2000 12:05:10 -0400
+   C: From: Andrew <andrew@burleigh.uwaterloo.ca>
+   C: To: Ed <ed@elsewhere.com>
+   C: To: Doug <doug@elsewhere.com>
+   C: Subject: special message
+   C:
+   C: this is the message body for a special message
+   C:
+   C: enjoy, andrew
+   C:
+   C: ps. this is a secret that Doug doesn't know
+   C: .
+   S: 250 okay
+   C: QUIT
+   S: 250 bye bye
+
+
+
+
+Ward                                                            [Page 4]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          7 April 2000
+
+
+   This transaction would result in ed@elsewhere.com receiving the
+   message:
+
+   Message-ID: <1234.abcd@uwaterloo.ca>
+   Date: Mon, 03 Apr 2000 12:05:10 -0400
+   From: Andrew <andrew@burleigh.uwaterloo.ca>
+   To: Ed <ed@elsewhere.com>
+   Subject: special message
+
+   this is the message body for a special message
+
+   enjoy, andrew
+
+   ps. this is a secret that Doug doesn't know
+
+   while doug@elsewhere.com whould receive:
+
+   Message-ID: <1234.abcd@uwaterloo.ca>
+   Date: Mon, 03 Apr 2000 12:05:10 -0400
+   From: Andrew <andrew@burleigh.uwaterloo.ca>
+   To: Doug <doug@elsewhere.com>
+   Subject: special message
+
+   this is the message body for a special message
+
+   enjoy, andrew
+
+   The following dialogue illustrates the efficiencies that can be
+   realized in a relaying scenario:
+
+   S1: 220 one.there.com SMTP ready
+   C0: EHLO zero.here.com
+   S1: 250-hello zero.here.com
+   S1: 250 SLIDE
+   C0: MAIL FROM:<me@here.com>
+   S1: 250 <me@here.com>... sender okay
+   C0: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250
+   S1: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199
+   S1: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<laurene@everywhere.com> SLIDERANGE=0-250
+   S1: 250 <laurene@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<rachael@elsewhere.com>
+   S1: 250 <rachael@elsewhere.com>... recipient okay
+   C0: DATA
+   S1: 354 okay, send message body, end with CRLF.CRLF
+   C0: ...<1000 octets of message>...
+   C0: .
+
+
+
+Ward                                                            [Page 5]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          7 April 2000
+
+
+   S1: 250 okay
+   C0: QUIT
+   S1: 250 bye bye
+    ...
+   S2: 220 two.everywhere.com SMTP ready
+   C1: EHLO one.there.com
+   S2: 250-hello one.there.com
+   S2: 250 SLIDE
+   C1: MAIL FROM:<me@here.com>
+   S2: 250 <me@here.com>... sender okay
+   C1: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250
+   S2: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay
+   C1: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199
+   S2: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay
+   C1: RCPT TO:<laurene@everywhere.com>
+   S2: 250 <laurene@everywhere.com>... recipient okay
+   C1: DATA
+   S2: 354 okay, send message body, end with CRLF.CRLF
+   C1: ...<octets 0 to 250 of message>...
+   C1: .
+   S2: 250 okay
+   C1: QUIT
+   S2: 250 bye bye
+    ...
+   S3: 220 three.elsewhere.com SMTP ready
+   C1: EHLO one.there.com
+   S3: 250-hello one.there.com
+   S3: 250 SLIDE
+   C1: MAIL FROM:<me@here.com>
+   S3: 250 <me@here.com>... sender okay
+   C1: RCPT TO:<rachael@elsewhere.com>
+   S3: 250 <rachael@elsewhere.com>... recipient okay
+   C1: DATA
+   S3: 354 okay, send message body, end with CRLF.CRLF
+   C1: ...<all octets of message>...
+   C1: .
+   S3: 250 okay
+   C1: QUIT
+   S3: 250 bye bye
+
+5. Security Considerations
+
+   This extension takes some of the "final control" over the message
+   body out of the hands of the client, and places it on the server
+   SMTPs that are charged with relaying and delivering the message.
+   While any server SMTP has access to change the content of a message
+   that it relays or delivers, a server SMTP that supports the slightly
+   differing multicast message service extension is obliged to be able
+
+
+
+Ward                                                            [Page 6]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          7 April 2000
+
+
+   to alter a message that takes advantage of this extension.  As a
+   result of the increased handling by the server SMTP, there is more
+   room for error in the message transmission.
+
+5.1 Impact on Signed and Encrypted Messages
+
+   Messages that are transferred between a client SMTP and a server SMTP
+   over a secure channel such as SSL or TLS should not be adversely
+   affected by the SLIDE extension.
+
+   Things get messy when it comes to signing or encrypting the message
+   data (all or part of the information sent to the server SMTP
+   following a 354 response to the DATA command).  Two alternatives are
+   suggested in section (5.1.1) and section (5.1.2).  A client SMTP may
+   implement either method, as both methods can be used transparently to
+   all other nodes in the chain of relays (including the final server
+   SMTP node).
+
+5.1.1 Piecewise Signing and Encryption
+
+   With this method, the initial client SMTP may sign or encrypt each
+   separate range of bytes (or part thereof), as defined by the various
+   SLIDERANGE values.
+
+   (example to follow)
+
+5.1.2 Component Message Signing
+
+   This method creates a single signature for each distinct message
+   contained in a set of messages encoded using the SLIDE extension.
+   During encoding of the SLIDE message, each component message that
+   needs to be signed can have a signature generated for it before the
+   component messages are SLIDE encoded.
+
+   (example to follow)
+
+6. Acknowledgements
+
+   Thanks to Ed, Doug, Laurene and Rachael for their (unwilling)
+   participation in the usage examples.  Thanks to Dan Wing for his
+   suggested improvements in usage examples and security considerations.
+
+7. References
+
+   [Bradner 1997]  Bradner, S.  "Key words for use in RFCs to Indicate
+   Requirement Levels", BCP 14, RFC 2119.  March 1997.
+
+   [Crocker 1982]  Crocker, D.  "Standard for the Format of ARPA
+
+
+
+Ward                                                            [Page 7]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          7 April 2000
+
+
+   Internet Text Messages", STD 11, RFC 822.  UDEL, August 1982.
+
+   [Klensin, et al 1995]  Klensin, J., N. Freed, M. Rose, E. Stefferud,
+   and D. Crocker.  "SMTP Service Extensions", STD 10, RFC 1869.
+   November 1995.
+
+   [Postel 1982]  Postel, J.  "Simple Mail Transfer Protocol", STD 10,
+   RFC 821.  USC/Information Sciences Institute, August 1982.
+
+8. Author's Address
+
+   Andrew Ward
+   70 Gruhn Street
+   Kitchener, ON  N2G 1S6
+   CANADA
+
+   Phone:  +1 519 581 1201
+   EMail:  amward@uwaterloo.ca
+
+
+
+                         EXPIRES:  7 October 2000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ward                                                            [Page 8]
+
diff --git a/Documentation/en/I-D/draft-ward-esmtp-slide-02.txt b/Documentation/en/I-D/draft-ward-esmtp-slide-02.txt
new file mode 100644
index 00000000..cbf7866c
--- /dev/null
+++ b/Documentation/en/I-D/draft-ward-esmtp-slide-02.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+                                                             A. Ward
+INTERNET-DRAFT
+Category:  Experimental                                   4 May 2000
+draft-ward-esmtp-slide-02.txt             Exprires:  4 November 2000
+
+
+             SMTP Service Extension for Slightly Differing
+                       Multicast Messages (SLIDE)
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+i. Revision History
+
+   The first version (-00) of this document was unleashed on 9 March
+   2000.
+
+   (-01)  Added section (5.1), regarding the impact of the SLIDE
+   extension to signed or encrypted messages.  Modified the first
+   example in section (4.) to make the impact of SLIDE more explicit. (7
+   April 2000)
+
+   (-02)  Added examples to section (5.1.1) and section (5.1.2). (4 May
+   2000)
+
+Abstract
+
+   This memo defines an extension to the SMTP service [Klensin, et al
+   1995] to realize efficiency improvements in the relaying and delivery
+
+
+
+Ward                                                            [Page 1]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE            4 May 2000
+
+
+   of slightly differing messages bound for more than one recipient, as
+   specified by multiple RCPT TO commands [Postel 1982].
+
+0. Conventions Used in this Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [Bradner
+   1997].
+
+1. Introduction
+
+   SMTP is an Internet message protocol that is used to send messages to
+   one or more recipients.  To realize any efficiency when sending a
+   message to multiple recipients, the message body and all headers must
+   be identical.  It is desirable, under some circumstances, to send
+   messages to multiple recipients that differ only slightly in their
+   body and/or headers.
+
+   Under SMTP [Postel 1982] such a scenario would result in a different
+   message being sent from the initial client SMTP through each relay
+   server until the final server SMTP is reached.  In situations where
+   more that one of the multiple recipients have mail handled by the
+   same server SMTP, a significant bandwidth reduction can be realized
+   with the SLIDE service extension.
+
+2. Framework for the Slightly Differing Multicast Message Extension
+
+   The slightly differing multicast message extension is as follows:
+
+   (1) the name of the SMTP service extension defined here is slightly-
+   differing-multicast-message;
+
+   (2) the EHLO keyword value associated with the extension is SLIDE;
+
+   (3) no parameter is used with the SLIDE EHLO keyword;
+
+   (4) no additional SMTP verbs are defined by this extension
+
+   (5) one optional parameter using the keyword SLIDERANGE is added to
+   the RCPT TO command.  The value associated with this parameter is a
+   comma-delimited list of octet ranges indicating which pieces of the
+   overall message SHOULD be delivered to the specified recipient.  The
+   syntax for the value follows, using the ABNF notation of [Crocker
+   1982]:
+
+   sliderange-value ::= octet-range *( "," octet-range )
+
+
+
+
+Ward                                                            [Page 2]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE            4 May 2000
+
+
+   octet-range ::= octet-address [ "-" octet-address ]
+
+   octet-address ::= DIGIT *(DIGIT)
+
+   DIGIT ::= <any one of the 10 numeric characters (0 through 9)>
+
+   (6) the next section specifies how support for the extension affects
+   the behaviour of a server and client SMTP; and,
+
+   (7) the maximum length of a RCPT TO command line is increased by 256
+   characters by the possible addition of the SLIDERANGE keyword and
+   value.  Of course, since the value could conceivably be longer than
+   256 characters, implementations are welcome to allot more space for
+   this purpose.
+
+3. The slightly-differing-multicast-message Service Extension
+
+3.1 Effects on the Client SMTP
+
+   When a client SMTP wishes to submit (using the MAIL command) messages
+   with slightly different content to recipients at the same server
+   SMTP, 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 SLIDE, then the server SMTP
+   is indicating that it supports the extended RCPT command.  Such a
+   server SMTP will accept a message containing the combined contents of
+   the slightly differing messages addressed to all of the recipients
+   for delivery.  The method for combining the various message bodies
+   (and interpreting combined message bodies) is described in the next
+   section.
+
+   The extended RCPT command is issued by a client SMTP when it wishes
+   to transmit part of a combined message body to the specified
+   recipient.  The syntax for this command is identical to the RCPT
+   command in [Postel 1982], except that a SLIDERANGE parameter must
+   appear after the address.  Multiple SLIDERANGE parameters may be used
+   in a single RCPT command; however, in such a case, the values of the
+   several parameters SHOULD be combined into a single, continuous,
+   comma-delimited list of octet ranges.
+
+   The value associated with the SLIDERANGE parameter lists which octets
+   in the impending DATA command are to be sent to the specified
+   recipient.
+
+3.2 Effects on the Server SMTP
+
+   A server SMTP which supports the slightly differing multicast message
+   service extension SHOULD relay only those octets bound for recipients
+
+
+
+Ward                                                            [Page 3]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE            4 May 2000
+
+
+   at a particular domain to the mail exchange for that domain.  If this
+   suggested message trimming occurs, the octets specified in the
+   SLIDERANGE parameter for each recipient MUST be adjusted to
+   correspond with the changes to the message DATA.
+
+   The final 5 octets of the message DATA (<CR><LF>.<CR><LF>) MUST
+   always be relayed, even if not explicitly specified in the SLIDERANGE
+   parameter value.
+
+   Once a server SMTP supporting the slightly differing multicast
+   message service extension accepts a message for which any recipient
+   has a non-trivial SLIDERANGE parameter value, the server SMTP MUST
+   deliver or relay the message in such a way as to ensure that only the
+   octets specified for a particular recipient will be received by that
+   recipient.  As well, when the server SMTP is relaying the message, it
+   SHOULD attempt to minimize the number of octets that are relayed to
+   each downstream server SMTP.
+
+4. Usage Examples
+
+   The following dialogue illustrates the use of the slightly differing
+   multicast message service extension:
+
+   S: <wait for connection>
+   C: <open connection to server>
+   S: 220 anstruther.elsewhere.com SMTP ready
+   C: EHLO burleigh.uwaterloo.ca
+   S: 250-hello burleigh.uwaterloo.ca
+   S: 250 SLIDE
+   C: MAIL FROM:<andrew@burleigh.uwaterloo.ca>
+   S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay
+   C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-322
+   S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay
+   C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-272,320-322
+   S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay
+   C: DATA
+   S: 354 any octets beyond 1235 will not be relayed, end with CRLF.CRLF
+   C: Message-ID: <1234.abcd@uwaterloo.ca>
+   C: Date: Mon, 03 Apr 2000 12:05:10 -0400
+   C: From: Andrew <andrew@burleigh.uwaterloo.ca>
+   C: To: Ed <ed@elsewhere.com>
+   C: To: Doug <doug@elsewhere.com>
+   C: Subject: special message
+   C:
+   C: this is the message body for a special message
+   C:
+   C: enjoy, andrew
+   C:
+
+
+
+Ward                                                            [Page 4]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE            4 May 2000
+
+
+   C: ps. this is a secret that Doug doesn't know
+   C: .
+   S: 250 okay
+   C: QUIT
+   S: 250 bye bye
+
+   This transaction would result in ed@elsewhere.com receiving the
+   message:
+
+   Message-ID: <1234.abcd@uwaterloo.ca>
+   Date: Mon, 03 Apr 2000 12:05:10 -0400
+   From: Andrew <andrew@burleigh.uwaterloo.ca>
+   To: Ed <ed@elsewhere.com>
+   Subject: special message
+
+   this is the message body for a special message
+
+   enjoy, andrew
+
+   ps. this is a secret that Doug doesn't know
+   .
+
+   while doug@elsewhere.com would receive:
+
+   Message-ID: <1234.abcd@uwaterloo.ca>
+   Date: Mon, 03 Apr 2000 12:05:10 -0400
+   From: Andrew <andrew@burleigh.uwaterloo.ca>
+   To: Doug <doug@elsewhere.com>
+   Subject: special message
+
+   this is the message body for a special message
+
+   enjoy, andrew
+   .
+
+   The following dialogue illustrates the efficiencies that can be
+   realized in a relaying scenario:
+
+   S1: 220 one.there.com SMTP ready
+   C0: EHLO zero.here.com
+   S1: 250-hello zero.here.com
+   S1: 250 SLIDE
+   C0: MAIL FROM:<me@here.com>
+   S1: 250 <me@here.com>... sender okay
+   C0: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250
+   S1: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199
+   S1: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay
+
+
+
+Ward                                                            [Page 5]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE            4 May 2000
+
+
+   C0: RCPT TO:<laurene@everywhere.com> SLIDERANGE=0-250
+   S1: 250 <laurene@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<rachael@elsewhere.com>
+   S1: 250 <rachael@elsewhere.com>... recipient okay
+   C0: DATA
+   S1: 354 okay, send message body, end with CRLF.CRLF
+   C0: ...<1000 octets of message>...
+   C0: .
+   S1: 250 okay
+   C0: QUIT
+   S1: 250 bye bye
+    ...
+   S2: 220 two.everywhere.com SMTP ready
+   C1: EHLO one.there.com
+   S2: 250-hello one.there.com
+   S2: 250 SLIDE
+   C1: MAIL FROM:<me@here.com>
+   S2: 250 <me@here.com>... sender okay
+   C1: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250
+   S2: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay
+   C1: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199
+   S2: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay
+   C1: RCPT TO:<laurene@everywhere.com>
+   S2: 250 <laurene@everywhere.com>... recipient okay
+   C1: DATA
+   S2: 354 okay, send message body, end with CRLF.CRLF
+   C1: ...<octets 0 to 250 of message>...
+   C1: .
+   S2: 250 okay
+   C1: QUIT
+   S2: 250 bye bye
+    ...
+   S3: 220 three.elsewhere.com SMTP ready
+   C1: EHLO one.there.com
+   S3: 250-hello one.there.com
+   S3: 250 SLIDE
+   C1: MAIL FROM:<me@here.com>
+   S3: 250 <me@here.com>... sender okay
+   C1: RCPT TO:<rachael@elsewhere.com>
+   S3: 250 <rachael@elsewhere.com>... recipient okay
+   C1: DATA
+   S3: 354 okay, send message body, end with CRLF.CRLF
+   C1: ...<all octets of message>...
+   C1: .
+   S3: 250 okay
+   C1: QUIT
+   S3: 250 bye bye
+
+
+
+
+Ward                                                            [Page 6]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE            4 May 2000
+
+
+5. Security Considerations
+
+   This extension takes some of the "final control" over the message
+   body out of the hands of the client, and places it on the server
+   SMTPs that are charged with relaying and delivering the message.
+   While any server SMTP has access to change the content of a message
+   that it relays or delivers, a server SMTP that supports the slightly
+   differing multicast message service extension is obliged to be able
+   to alter a message that takes advantage of this extension.  As a
+   result of the increased handling by the server SMTP, there is more
+   room for error in the message transmission.
+
+5.1 Impact on Signed and Encrypted Messages
+
+   Messages that are transferred between a client SMTP and a server SMTP
+   over a secure channel such as SSL or TLS should not be adversely
+   affected by the SLIDE extension.
+
+   Things get messy when it comes to signing or encrypting the message
+   data (all or part of the information sent to the server SMTP
+   following a 354 response to the DATA command).  Two alternatives are
+   suggested in section (5.1.1) and section (5.1.2).  A client SMTP may
+   implement either method, as both methods can be used transparently to
+   all other nodes in the chain of relays (including the final server
+   SMTP node).
+
+5.1.1 Piecewise Signing and Encryption
+
+   With this method, the initial client SMTP may sign or encrypt each
+   separate range of bytes (or part thereof), as defined by the various
+   SLIDERANGE values.
+
+   As an example, consider the piecewise approach as applied to the
+   first usage example presented in section 4.
+
+   S: <wait for connection>
+   C: <open connection to server>
+   S: 220 anstruther.elsewhere.com SMTP ready
+   C: EHLO burleigh.uwaterloo.ca
+   S: 250-hello burleigh.uwaterloo.ca
+   S: 250 SLIDE
+   C: MAIL FROM:<andrew@burleigh.uwaterloo.ca>
+   S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay
+   C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-727
+   S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay
+   C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-483,725-727
+   S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay
+   C: DATA
+
+
+
+Ward                                                            [Page 7]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE            4 May 2000
+
+
+   S: 354 any octets beyond 1235 will not be relayed, end with CRLF.CRLF
+   C: Message-ID: <1234.abcd@uwaterloo.ca>
+   C: Date: Mon, 03 Apr 2000 12:05:10 -0400
+   C: From: Andrew <andrew@burleigh.uwaterloo.ca>
+   C: To: Ed <ed@elsewhere.com>
+   C: To: Doug <doug@elsewhere.com>
+   C: Subject: special message
+   C:
+   C: -----BEGIN PGP SIGNED MESSAGE-----
+   C: Hash: SHA1
+   C:
+   C: this is the message body for a special message
+   C:
+   C: enjoy, andrew
+   C: -----BEGIN PGP SIGNATURE-----
+   C: Version: fakePGP v0.0
+   C:
+   C: aefiuh98ar7ehfpo34h9q83h4fp9q34h9a8efha9348hao
+   C: 98h5nbq3rub9a08ahfoi4no34=
+   C: -----END PGP SIGNATURE-----
+   C:
+   C: -----BEGIN PGP SIGNED MESSAGE-----
+   C: Hash: SHA1
+   C:
+   C: ps. this is a secret that Doug doesn't know
+   C: -----BEGIN PGP SIGNATURE-----
+   C: Version: fakePGP v0.0
+   C:
+   C: 98sdu9bd9fu4eiob3iovb9eb93buiou908fhv9sf
+   C: jlknsdfi0h93un=
+   C: -----END PGP SIGNATURE-----
+   C: .
+   S: 250 okay
+   C: QUIT
+   S: 250 bye bye
+
+
+5.1.2 Component Message Signing
+
+   This method creates a single signature for each distinct message
+   contained in a set of messages encoded using the SLIDE extension.
+   During encoding of the SLIDE message, each component message that
+   needs to be signed can have a signature generated for it before the
+   component messages are SLIDE encoded.
+
+   It is important to note that in most (if not all) cases this will not
+   work for encryption, as the same text in the unencrypted component
+   messages will not generate the same encrypted group of octets.
+
+
+
+Ward                                                            [Page 8]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE            4 May 2000
+
+
+   As an example, consider the component message approach as applied to
+   the first usage example presented in section 4.
+
+   S: <wait for connection>
+   C: <open connection to server>
+   S: 220 anstruther.elsewhere.com SMTP ready
+   C: EHLO burleigh.uwaterloo.ca
+   S: 250-hello burleigh.uwaterloo.ca
+   S: 250 SLIDE
+   C: MAIL FROM:<andrew@burleigh.uwaterloo.ca>
+   S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay
+   C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-322,484-677
+   S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay
+   C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-483,675-677
+   S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay
+   C: DATA
+   S: 354 any octets beyond 1235 will not be relayed, end with CRLF.CRLF
+   C: Message-ID: <1234.abcd@uwaterloo.ca>
+   C: Date: Mon, 03 Apr 2000 12:05:10 -0400
+   C: From: Andrew <andrew@burleigh.uwaterloo.ca>
+   C: To: Ed <ed@elsewhere.com>
+   C: To: Doug <doug@elsewhere.com>
+   C: Subject: special message
+   C:
+   C: -----BEGIN PGP SIGNED MESSAGE-----
+   C: Hash: SHA1
+   C:
+   C: this is the message body for a special message
+   C:
+   C: enjoy, andrew
+   C: -----BEGIN PGP SIGNATURE-----
+   C: Version: fakePGP v0.0
+   C:
+   C: nsdf9n934nioq3j4un9ua9fvuerh98h43n9ae8u85
+   C: 34kjfbna9ea9e8rb8d9sd0ge3=
+   C: -----END PGP SIGNATURE-----
+   C:
+   C: ps. this is a secret that Doug doesn't know
+   C: -----BEGIN PGP SIGNATURE-----
+   C: Version: fakePGP v0.0
+   C:
+   C: ikbdfv98u4bka8rhi34ubkq3828756bkjai7rf7
+   C: 1kj3k4jnkj3kjk3=
+   C: -----END PGP SIGNATURE-----
+   C: .
+   S: 250 okay
+   C: QUIT
+   S: 250 bye bye
+
+
+
+Ward                                                            [Page 9]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE            4 May 2000
+
+
+6. Acknowledgements
+
+   Thanks to Ed, Doug, Laurene and Rachael for their (unwilling)
+   participation in the usage examples.  Thanks to Dan Wing for his
+   suggested improvements in usage examples and security considerations.
+
+7. References
+
+   [Bradner 1997]  Bradner, S.  "Key words for use in RFCs to Indicate
+   Requirement Levels", BCP 14, RFC 2119.  March 1997.
+
+   [Crocker 1982]  Crocker, D.  "Standard for the Format of ARPA
+   Internet Text Messages", STD 11, RFC 822.  UDEL, August 1982.
+
+   [Klensin, et al 1995]  Klensin, J., N. Freed, M. Rose, E. Stefferud,
+   and D. Crocker.  "SMTP Service Extensions", STD 10, RFC 1869.
+   November 1995.
+
+   [Postel 1982]  Postel, J.  "Simple Mail Transfer Protocol", STD 10,
+   RFC 821.  USC/Information Sciences Institute, August 1982.
+
+8. Author's Address
+
+   Andrew Ward
+   70 Gruhn Street
+   Kitchener, ON  N2G 1S6
+   CANADA
+
+   Phone:  +1 519 581 1201
+   EMail:  amward@uwaterloo.ca
+
+
+
+                         EXPIRES:  4 November 2000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ward                                                           [Page 10]
+
diff --git a/Documentation/en/I-D/draft-ward-esmtp-slide-04.txt b/Documentation/en/I-D/draft-ward-esmtp-slide-04.txt
new file mode 100644
index 00000000..4bdea7e5
--- /dev/null
+++ b/Documentation/en/I-D/draft-ward-esmtp-slide-04.txt
@@ -0,0 +1,19 @@
+

+This Internet-Draft has been deleted. Unrevised documents placed in the

+Internet-Drafts directories have a maximum life of six months. After

+that time, they are deleted. This Internet-Draft was not published as

+an RFC.

+

+Internet-Drafts are not an archival document series, and expired

+drafts, such as this one, are not available; please do not ask for

+copies... they are not available. The Secretariat does not have

+information as to future plans of the authors or working groups WRT the

+deleted Internet-Draft.

+

+For more information or a copy of the document, contact the author directly.

+

+Draft Author(s):

+

+A. Ward: neoplasm@aol.com                                                        

+

+