GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1830

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
 is sent in response to a BDAT chunk the message should be considered
 failed and, the sender SMTP must not send any additional BDAT
 segments.  If using the ESMTP pipelining extensions [PIPE], the
 sender SMTP must complete the sending of the current segment and not
 send any more BDATs.  When streaming, the receiver SMTP must accept
 and discard additional BDAT chunks after the failed BDAT.  After
 receiving a 5XX error in response to a BDAT command, the resulting
 state is indeterminate.  A RSET command must be issued to clear the
 transaction before additional commands may be sent.
    Note that an error on the receiver SMTP such as disk full or
    imminent shutdown can only be reported after the BDAT segment has
    been sent.  It is therefore important to choose a reasonable chunk
    size given the expected end to end bandwidth.
 The RSET command when issued during 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 too many bytes
    are indicated by the sender SMTP, the receiver SMTP will continue
    to wait for the remainder of the data or 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.

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

    If too few bytes are indicated by the sender SMTP, 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 lexigraphical parsers must be prepared to
    receive, process, and reject lines of arbitrary octets.

4. 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) One additional parameter to the BODY keyword defined
       [8BIT] for the MAIL FROM command is defined, "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.
 A sender SMTP may request that a binary MIME message be sent without
 transport encoding by sending a BINARYMIME parameter with the MAIL
 FROM 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.
 BINARYMIME cannot be used with the DATA command.  If a DATA command
 is issued after a MAIL FROM 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>

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

    <LF>.  Any transformation of text into non-canonical MIME to
    observe local storage conventions must be reversed before sending
    as BINARYMIME.  The usual line-oriented shortcuts will break if
    used with BINARYMIME.
 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 support the BINARYMIME message format
 (either by not responding with code 250 to the EHLO command, or by
 rejecting the BINARYMIME parameter to the MAIL FROM command, then the
 client SMTP must not, under any circumstances, send binary data using
 the DATA or BDAT commands.
 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 in this case: first, it may implement a gateway
 transformation to convert the message into valid 7bit encoded MIME,
 or second, it may treat this as a permanent error and handle it in
 the usual manner for delivery failures.  The specifics of the
 transformation from Binary MIME to 7bit MIME are not described by
 this RFC; the conversion is nevertheless constrained in the following
 ways:
   o  The conversion must cause no loss of information; MIME
      transport encodings must be employed as needed to insure this
      is the case.
   o  The resulting message must be valid 7bit MIME.
 As of present there are no mechanisms for converting a binary MIME
 object into a 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 Experimental [Page 5] RFC 1830 Binary and Large Message Transport August 1995

5. Examples

5.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 69 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, 69 octets received
        S: QUIT
        R: 221 Goodbye

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

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

        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

6. Security Considerations

 This RFC does not discuss security issues and is not believed to
 raise any security issues not already endemic in electronic mail and
 present in fully conforming implementations of [RFC821], or otherwise
 made possible by [MIME].

7. Acknowledgments

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

8. 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] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
      Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
   [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
      Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC
      1425, United Nations University, Innosoft International,
      Inc., Dover Beach Consulting, Inc., Network Management
      Associates, Inc., The Branch Office, February 1993.
   [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
      Stefferud, E., and D. Crocker, "SMTP Service Extension for
      8bit-MIMEtransport" RFC 1426, United Nations University,
      Innosoft International, Inc., Dover Beach Consulting, Inc.,
      Network Management Associates, Inc., The Branch Office,
      February 1993.
   [PIPE] Freed, N., "SMTP Service Extensions for Command
      Pipelining", Innosoft International, Work in Progress.

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

9. Author's Address

 Gregory M. Vaudreuil
 Octel Network Services
 17060 Dallas Parkway
 Suite 214
 Dallas, TX 75248-1905
 Voice/Fax: 214-733-2722
 EMail: Greg.Vaudreuil@Octel.com

Vaudreuil Experimental [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1830.txt · Last modified: 1995/08/15 23:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki