

     Internet Draft                                       Greg Vaudreuil 
     Expires in six months                           Lucent Technologies 
                                                           June 17, 2003 
                                         

                            SMTP Service Extensions 
                           for Transmission of Large 
                            and Binary MIME Messages 

                     <draft-vaudreuil-esmtp-binary3-00.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 (2003).  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 
     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 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 3030. 

      



     Internet Draft            Binary ESMTP                June 17, 2003 


  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 RFC 1830 was classified 
     as experimental at that time due to questions about the robustness of 
     the Binary Content-Transfer-Encoding deployed in then existent MIME 
     implementations.  The protocol was re-issued as a proposed standard in 
     RFC 3030.  This document provides minor clarifications to that 
     document in anticipation of elevation to Draft Standard status. 

  Document Conventions 

     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 [RFC2119]. 

  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.   NORMATIVE REFERENCES .............................................10 
  7.   INFORMATIVE REFERENCES ...........................................10 
  8.   INTELLECTUAL PROPERTY NOTICE .....................................11 
  9.   COPYRIGHT NOTICE .................................................11 
  10.  AUTHOR'S ADDRESS .................................................12 
  11.  APPENDIX A - CHANGES FROM RFC3030 ................................13 
      

  1. Overview 

     The MIME extensions to the Internet message format provides for the 
     transmission of many kinds of data that were previously unsupported in 
     Internet mail.  Anticipating the need to transport the new media more 
     efficiently, 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 

     Vaudreuil               Expires 12/17/03                   [Page 2] 



     Internet Draft            Binary ESMTP                June 17, 2003 


     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 an SMTP server ("receiver-
     SMTP") may declare support for the message chunking transmission mode 
     and support for the receiption of Binary messages, which the SMTP 
     client ("sender-SMTP") is then free to use. 

  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, BDAT, is defined 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] 

     5) Servers that offer the BDAT extension MUST continue to support the 
     regular SMTP DATA command. Clients are free to use DATA to transfer 
     appropriately encoded messages to servers that support the CHUNKING 
     extension if they wish to do so. 

     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. 

     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. 



     Vaudreuil               Expires 12/17/03                   [Page 3] 



     Internet Draft            Binary ESMTP                June 17, 2003 


     When also employing the pipelining extension, the BDAT commands may be 
     send immediately after sending the MAIL FROM and RCPT TO commands.  It 
     is not necessary to wait for the response to determine if there is a 
     valid recipient.  When pipelining, the sender-SMTP must interpret the 
     reply codes as received and terminate the sending of additional chunks 
     upon failure.  Receivers MUST accept the BDAT command even where there 
     are no valid recipients. 

          Note: If the receiver-SMTP is unable or unwilling to accept and 
          discard the BDAT segments in transit, it MAY terminate the 
          underlying TCP connection. 

     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 received by the sender-SMTP in response to a BDAT 
     chunk, the transaction should be considered failed and the sender-SMTP 
     SHOULD 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 

     Vaudreuil               Expires 12/17/03                   [Page 4] 



     Internet Draft            Binary ESMTP                June 17, 2003 


     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: 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 may 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 
          lexicographical parsers MUST be prepared to receive, process, 
          and reject lines of arbitrary octets. 



























     Vaudreuil               Expires 12/17/03                   [Page 5] 



     Internet Draft            Binary ESMTP                June 17, 2003 


  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] 

     8) The maximum length of a MAIL FROM command line is increased by 16 
     characters by the possible addition of the BODY=BINARYMIME keyword and 
     value;. 

     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. Once a receiver-SMTP 
     supporting the BINARYMIME service extension accepts a message 
     containing binary material, the receiver-SMTP MUST deliver or relay 
     the message in such a way as to preserve all bits in each octet. 

     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 especially important when using BINARYMIME 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 

     Vaudreuil               Expires 12/17/03                   [Page 6] 



     Internet Draft            Binary ESMTP                June 17, 2003 


     for a given MIME content-type.  In particular, text/* MUST be sent 
     with <CR><LF> terminated lines. 

     Note: Although CR and LF do not necessarily represent ends of text 
     lines in BDAT chunks and use of the binary transfer encoding is 
     allowed, the RFC 2781 prohibition against using a UTF-16 charset 
     within the text top-level media type remains. 

     The syntax of the extended MAIL command is identical to the MAIL 
     command in [RFC821], except that a BODY=BINARYMIME parameter and value 
     MUST be added. 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 three 
     options with which to forward the message. First, if the receiver-SMTP 
     supports the 8bit-MIMEtransport extension [8bit] and the content is 
     amenable to being encoded in 8bit, the sender-SMTP may implement a 
     gateway transformation to convert the message into valid 8bit-encoded 
     MIME. Second, it may implement a gateway transformation to convert the 
     message into valid 7bit-encoded MIME. Third, 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 8bit or 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 or 8bit MIME.  In 
          particular, the transformation MUST NOT result in nested Base-64 
          or Quoted-Printable content-transfer-encodings. 

     Note that at the time of this writing 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. 

     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 12/17/03                   [Page 7] 



     Internet Draft            Binary ESMTP                June 17, 2003 


  4. Examples 

  4.1 Simple Chunking 

     The following simple dialogue illustrates the use of the large message 
     extension to send a short pseudo-RFC822 message to one recipient using 
     the CHUNKING extension: 

     R: <wait for connection on TCP port 25> 
     S: <open connection to server> 
     R: 220 example.com SMTP service ready 
     S: EHLO example2.com 
     R: 250-example.com hello 
     R: 250 CHUNKING 
     S: MAIL FROM:<Sam@Example2.com> 
     R: 250 <Sam@Example.com> Sender ok 
     S: RCPT TO:<Susan@Example.com> 
     R: 250 <Susan@example.com> Recipient ok 
     S: BDAT 86 LAST 
     S: To: Susan@example.com<CR><LF> 
     S: From: Sam@example2.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 12/17/03                   [Page 8] 



     Internet Draft            Binary ESMTP                June 17, 2003 


  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 25> 
     S: <open connection to server> 
     R: 220 example.com SMTP service ready 
     S: EHLO ymir.example2.com 
     R: 250-example.com says hello 
     R: 250-PIPELINING 
     R: 250-BINARYMIME 
     R: 250 CHUNKING 
     S: MAIL FROM:<ned@example2.com> BODY=BINARYMIME 
     S: RCPT TO:<gvaudre@example.com> 
     S: RCPT TO:<jstewart@example.com> 
     R: 250 <ned@example2.com>... Sender and BINARYMIME ok 
     R: 250 <gvaudre@example.com>... Recipient ok 
     R: 250 <jstewart@example.com>... Recipient ok 
     S: BDAT 100000    
     S: (First 100000 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 12/17/03                   [Page 9] 



     Internet Draft            Binary ESMTP                June 17, 2003 


  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. Normative References 

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

     [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 2920, Innosoft, September 2000. 

     [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
     Requirement Levels", RFC 2119, Harvard, March 1997. 

  7. Informative References 

     [BINARY] Vaudreuil, G, " SMTP Service Extensions for Transmission of 
     Large and Binary MIME Messages", RFC 1830, August 1995.  

     [BINARY2] Vaudreuil, G, " SMTP Service Extensions for Transmission of 
     Large and Binary MIME Messages", RFC 3030, December 2000.  

     [SUBMIT] R. Gellens, and J. Klensin, "Message Submission", RFC 2476, 
     Qualcomm, MCI, December 1998. 









     Vaudreuil               Expires 12/17/03                  [Page 10] 



     Internet Draft            Binary ESMTP                June 17, 2003 


  8. Intellectual Property Notice 

     The IETF takes no position regarding the validity or scope of any 
     intellectual property or other rights that might be claimed to pertain 
     to the implementation or use of the technology described in this 
     document or the extent to which any license under such rights might or 
     might not be available; neither does it represent that it has made any 
     effort to identify any such rights.  Information on the IETF's 
     procedures with respect to rights in standards-track and standards-
     related documentation can be found in BCP-11.  Copies of claims of 
     rights made available for publication and any assurances of licenses 
     to be made available, or the result of an attempt made to obtain a 
     general license or permission for the use of such proprietary rights 
     by implementors or users of this specification can be obtained from 
     the IETF Secretariat. 

   
     The IETF invites any interested party to bring to its attention any 
     copyrights, patents or patent applications, or other proprietary 
     rights which may cover technology that may be required to practice 
     this standard.  Please address the information to the IETF Executive 
     Director. 

      

  9. Copyright Notice 

     "Copyright (C) The Internet Society (2003). 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."  




     Vaudreuil               Expires 12/17/03                  [Page 11] 



     Internet Draft            Binary ESMTP                June 17, 2003 


  10. Author's Address 

     Gregory M. Vaudreuil  
     Lucent Technologies 
     7291 Williamson Rd  
     Dallas, TX 75214 
     Voice: +1-214-823-9325 
     GregV@ieee.org 















































     Vaudreuil               Expires 12/17/03                  [Page 12] 



     Internet Draft            Binary ESMTP                June 17, 2003 


  11. Appendix A - Changes from RFC3030 

     Numerous editorial changes including revised authors contact 
     information. 

     Added clarifying text on the interaction between chunking and 
     pipelining. 

     Relaxed the "MUST NOT" to "SHOULD NOT" for the sending of BDAT 
     segments after receiving a 4xx or 5xx to the previous one.  To 
     prohibit the sending of a segment until a successful reply-code is 
     received effectively defeats the pipelining of BDAT commands. 

     Fixed typos in example in 4.2 (10000 =>100000) and append 25> to first 
     line. 

     Replace real domain names with fictions domain names in the examples. 

     Separated normative and informative references, added reference to RFC 
     3030 to the references and introduction 

     Added the required IPR notice 

      































     Vaudreuil               Expires 12/17/03                  [Page 13] 
