rfc3030.txt

最新的RFC

Network Working Group                                       G. Vaudreuil
Request for Comments: 3030                           Lucent Technologies
Obsolete: 1830                                             December 2000
Category: Standards Track


                        SMTP Service Extensions
                       for Transmission of Large
                        and Binary MIME Messages

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   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.

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.  As MIME has matured and other uses of the Binary
   Content-Transfer-Encoding have been deployed, these concerns have
   been allayed.  With this document, Binary ESMTP is expected to become
   standards-track.







Vaudreuil                   Standards Track                     [Page 1]

RFC 3030                      Binary ESMTP                 December 2000


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 .................  5
   4.   Examples ...................................................  8
     4.1  Simple Chunking ..........................................  8
     4.2  Pipelining BINARYMIME ....................................  8
   5.   Security Considerations ....................................  9
   6.   References .................................................  9
   7.   Author's Address ........................................... 10
   8.   Appendix A - Changes from RFC 1830 ......................... 11
   9.   Full Copyright Statement ................................... 12

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
   base64 and quoted-printable encoding of binary objects sent using the
   MIME message format over SMTP between hosts that support binary
   message processing.








Vaudreuil                   Standards Track                     [Page 2]

RFC 3030                      Binary ESMTP                 December 2000


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

   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




Vaudreuil                   Standards Track                     [Page 3]

RFC 3030                      Binary ESMTP                 December 2000


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




Vaudreuil                   Standards Track                     [Page 4]

RFC 3030                      Binary ESMTP                 December 2000


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

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





Vaudreuil                   Standards Track                     [Page 5]

RFC 3030                      Binary ESMTP                 December 2000


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







Vaudreuil                   Standards Track                     [Page 6]