SMTP Service Extensions for Transmission of Large and Binary MIME Messages
RFC 1830

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                       G. Vaudreuil
Request for Comments: 1830                        Octel Network Services
Category: Experimental                                       August 1995

                        SMTP Service Extensions
                       for Transmission of Large
                        and Binary MIME Messages

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

1. 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
   alternate DATA command "BDAT" for efficiently sending large MIME
   messages.  The second extension takes advantage of the BDAT command
   to permit the negotiated sending of unencoded binary data.

2. Introduction

   The MIME extensions to the Internet message protocol provides for the
   transmission of many kinds of data which 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
   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 need 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 which support binary
   message processing.

Vaudreuil                     Experimental                      [Page 1]
RFC 1830           Binary and Large Message Transport        August 1995

   This memo uses the mechanism defined in [ESMTP] to define two
   extensions to the SMTP service whereby a client ("sender-SMTP") may
   declare support for the message chunking transmission mode using the
   BDAT command and support for the sending of Binary messages.

3. 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 of the
          binary data packet.  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"

   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 argument, the exact length of the data segment
   in octets.  The message data is sent immediately after the BDAT
   command.  Once the receiver-SMTP receives the specified number of
   octets, it will return a 250 reply code.

   The 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

Vaudreuil                     Experimental                      [Page 2]
RFC 1830           Binary and Large Message Transport        August 1995

   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 5XX code