RFC 3030

SMTP Service Extensions for Transmission of Large and Binary MIME Messages

📅 published December 2000, from ietf

RFC 3030 🎀

Okay bestie, here are the deets 📋. This is RFC 3030, called SMTP Service Extensions for Transmission of Large and Binary MIME Messages 💌. G. Vaudreuil from Lucent Technologies wrote it in the Network Working Group, and it's dated December 2000. It's a Standards Track doc 🔥, and it obsoletes RFC 1830 (the Abstract says it updates and obsoletes that one 🙌).

Status of This Memo ✨

So this is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🗣️. To check the standardization state and status, look at the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌍.

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

Abstract 🦋

Okay so this memo defines two extensions to SMTP (Simple Mail Transfer Protocol) service 📬. The first one lets an SMTP client and server negotiate an alternative to the DATA command, called "BDAT", for efficiently sending large MIME (Multipurpose Internet Mail Extensions) messages 🚀. The second one uses the BDAT command to allow the negotiated sending of MIME messages that use the binary transfer encoding 🫶. This document is intended to update and obsolete RFC 1830 💅.

Working Group Summary 🌸

This protocol isn't the product of an IETF working group, but the spec came out of discussions in the ESMTP working group 🧚. RFC 1830 was classified as experimental back then because people had questions about how robust the Binary Content-Transfer-Encoding was in the MIME implementations that existed at the time 🤔. MIME matured, other uses of the Binary Content-Transfer-Encoding got deployed, and those concerns were allayed ✨. With this document, Binary ESMTP is expected to become standards-track 👑.

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]. These are the magic words 🪄.

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 ✨

Okay so the MIME extensions to the Internet message format let us send all kinds of data that Internet mail couldn't handle before 🌈. Since we need to move this new media more efficiently, SMTP got extended to carry new message types 📦. RFC 1652 defines one of those extensions, for sending unencoded 8-bit MIME messages [8BIT] 💌. This service extension lets the receiver SMTP declare support for 8-bit body parts, and lets the sender ask for 8-bit transmission of a particular message 🎀.

Since MIME is a thing now, the Internet mail system is going to be expected to carry very large mail messages 🐘. In those transactions there's a performance-based desire to get rid of the requirement that the message be scanned for "CR LF . CR LF" sequences when sending and receiving, just to detect the end of the message 👀.

Internet mail is also getting more multimedia, and that's a whole vibe 🎨. We want to avoid the overhead of base64 and quoted-printable encoding for binary objects that get 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 🧚. An SMTP server ("receiver-SMTP") can declare support for the message chunking transmission mode and for the reception of Binary messages, and the SMTP client ("sender-SMTP") is then free to use them 🫶.

2. Framework for the Large Message Extensions 📦

Here's the first extension, the one for large messages 💖. 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"
  1. This extension may be used for SMTP message submission. [Submit]
  2. 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 it's 7-bit, 8BITMIME or BINARYMIME ✨.

When a sender-SMTP wants to send a large message using the CHUNKING extension (using the MAIL command), 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 messages sent in chunks 💅.

After all the 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 returns 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, which means there's 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 clear the transaction before continuing. There's no prohibition on using DATA and BDAT in the same session, as long as they aren't mixed in the same transaction 🌸.

The local storage size of a message may not accurately reflect the actual size of the message sent, because of local storage conventions. In particular, text messages sent with the BDAT command MUST be sent in the canonical MIME format, with lines delimited by <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 ✨

okay bestie, this is where BINARYMIME gets its whole personality 💖 Here's the setup:

  1. The name of the binary service extension is "BINARYMIME".
  2. The EHLO keyword value for this extension is "BINARYMIME".
  3. BINARYMIME can only be used with the "CHUNKING" service extension. 🧩
  4. No parameter is used with the BINARYMIME keyword.
  5. [8BIT] already defines the BODY parameter for the MAIL command, and this extension adds one new value for it, "BINARYMIME" 🎀 That value says the message is a Binary MIME message (in strict compliance with [MIME]) and that arbitrary octet content is being sent. The revised syntax, written in the ABNF notation of [RFC822], looks like this:
body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
  1. No new verbs are defined for the BINARYMIME extension.
  2. This extension may be used for SMTP message submission. [Submit]
  3. The maximum length of a MAIL FROM command line goes up by 16 characters because of the possible addition of the BODY=BINARYMIME keyword and value;.

A sender-SMTP can ask for a binary MIME message to go out without transport encoding by sending a BODY parameter with the value "BINARYMIME" on the MAIL command. When the receiver-SMTP accepts a MAIL command with the BINARYMIME body-value, it's promising to preserve all bits in each octet passed using the BDAT command 🫶 Once a receiver-SMTP that supports BINARYMIME accepts a message with binary material, the receiver-SMTP MUST deliver or relay the message in a way that preserves all bits in each octet. no skipping, no dropping bits 😭

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

Using BINARYMIME means you have to make sure the MIME message itself is properly formed, and honestly that part is so important 🙈 Text has to be canonically encoded, with each line properly terminated with <CR><LF>. Any transformation of text into non-canonical MIME to match local storage conventions MUST be reversed before sending as BINARYMIME. Some line-oriented shortcuts will break if you use them 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: even though CR and LF don't necessarily mark the ends of text lines in BDAT chunks, and the binary transfer encoding is allowed, the RFC 2781 prohibition against using a UTF-16 charset within the text top-level media type still applies 🌸

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 for the BINARYMIME message format, then the sender-SMTP MUST NOT, under any circumstances, send binary data. no exceptions, bestie 🚫

Now, if the receiver-SMTP doesn't support BINARYMIME and the message is a MIME object with a binary encoding, the sender-SMTP has three options 🦋 First, if the receiver-SMTP supports the 8bit-MIMEtransport extension [8bit] and the content can be 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 the usual way 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 still constrained in these 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. 🙅‍♀️

4. Examples 🎀

4.1 Simple Chunking

okay so this little dialogue shows the large message extension sending a short pseudo-RFC 822 message to one recipient using CHUNKING 💅

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

4.2 Pipelining BINARYMIME

this one is the main character 🦋 It sends a BINARYMIME object to two recipients using CHUNKING and PIPELINING together 👑

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

5. Security Considerations 🔐

okay, serious moment (but make it cute) 🙈 This extension is not known to present any additional security issues beyond the ones already endemic to electronic mail and present in fully conforming implementations of [RFC821], or otherwise made possible by [MIME]. so no new drama from this one, just the classic email drama 💀

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, August 1982.
  • [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
  • [MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
  • [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
  • [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
  • [PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining", RFC 2920, September 2000.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

7. Author's Address 💌

Gregory M. Vaudreuil
Lucent Technologies
17080 Dallas Parkway
Dallas, TX 75248-1905

Phone/Fax: +1-972-733-2722
EMail: GregV@ieee.org

Appendix A - Changes from RFC 1830 🌈

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

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

okay, the legal bit, but make it readable 💖 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.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from