Network Working Group Greg Vaudreuil Internet Draft Tigon Corporation Expires: 4/18/94 October 18, 1993 SMTP Service Extensions for Binary Transmission of Large MIME Messages 1.Status of this Memo 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". 2.Abstract This memo defines an extension to the SMTP service whereby an SMTP client and server may negotiate the use of an alternate DATA command "BDAT" for sending unencoded binary MIME messages. 3.Introduction The MIME extensions to the Internet message protocol provide for the transmission of many kinds of data which were previously unsupported in Internet mail. One expected result of the use of MIME is that the Internet mail system will be expected to carry large binary mail messages, often into the megabytes. There is a need avoid the overhead of base64 and quoted-printable encoding of binary objects sent using the MIME message format over SMTP including the requirement that the message be scanned for "CR LF . CR LF" sequences upon sending. This memo uses the mechanism defined in [4] to define extensions to the SMTP service whereby a client ("sender-SMTP") may declare support for the binary transmission mode and the BDAT command. 4.Framework for the Binary Extensions The following service extension is hereby defined: 1) The name of the service extension is "Binary" 2) The EHLO keyword value associated with this extension is "BINARY" 3) No parameter is used with the BINARY keyword Internet Draft Expires 4/18/94 4) One additional parameter to the BODY keyword defined [5] 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 [3]) with arbitrary octet content is being sent. The revised syntax of the value is as follows, using the ABNF notation of [2]: body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME" 5) A new SMTP verb is defined "BDAT" as an alternative to the "DATA" command of [1] 5.The Binary service extension When a client SMTP wishes to submit (using the MAIL command) a content body consisting of a MIME message containing arbitrary octet-aligned material, 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 BINARY, then the server SMTP is indicating that it supports the extended MAIL command and will accept MIME messages containing arbitrary octet-aligned material. The extended MAIL command is issued by a client SMTP when it wishes to transmit a content body consisting of a MIME message containing arbitrary octet-aligned material. The syntax for this command is identical to the MAIL command in [1], except that a BODY parameter must appear after the address. The complete syntax of this extended command is defined in [4]. The ESMTP-keyword is BODY and the syntax for ESMTP-value is given by the syntax for body-value shown above. A server which supports the BINARY transport service extension shall preserve all bits in each octet passed using the DATA command. After all MAIL FROM and RCPT TO responses are collected and processed, the BDAT command is sent. The BDAT command is an alternative to the DATA command. The BDAT command takes one argument, the exact length of the sent message in octets. After receiving the 354 reply code, the message data is sent as a octet stream. Once the receiver-SMTP receives the specified number of octets, it will return a 250 reply code. Note: 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 CR LF terminated line format. If a server SMTP does not support the BINARY transport extension (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value BINARY in its response), then the client SMTP must not, under any circumstances, send binary data using the DATA command. Vaudreuil [Page 2] Internet Draft Expires 4/18/94 If the receiver-SMTP does not support BINARY 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: (1) it must cause no loss of information; MIME transport encodings must be employed as needed to insure this is the case, and (2) the resulting message must be valid 7bit MIME. As of present there are no mechanisms for converting a binary MIME object into a 8bit-MIME object. Such a transformation will require the specification of a new MIME content-transfer-encoding, the standardization of which is discouraged. 6.Usage Examples The following dialogue illustrates the use of the High Performance and Binary service extension to send a BINARY object to three recipients without the stop and wait for an explicit 250 for each recipient: S: C: S: 220 cnri.reston.va.us SMTP service ready C: EHLO ymir.claremont.edu S: 250-cnri.reston.va.us says hello S: 250 8BITMIME S: 250 BINARY C: MAIL FROM: BINARYMIME S: 250 ... Sender and BINARYMIME ok C: RCPT TO: S: 250 ... Recipient ok C: RCPT TO: S: 250 ... Recipient ok C: BDAT 1324 S: 354 Send BINARYMIME message of 1324 Octets. ... S: 250 OK C: QUIT S: 250 Goodbye Vaudreuil [Page 3] Internet Draft Expires 4/18/94 7.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 [1]. 8.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. Text for this document was liberally copied from RFC 1426 by John Klensin, Marshall Rose, Need Freed, Dave Crocker, and Einar Stefferud. 9.References [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1341, Bellcore, Innosoft, June 1992. [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC 1425, [5] 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. 10. Author's Address Gregory M. Vaudreuil The Tigon Corporation 17080 Dallas Parkway Dallas, TX 75248-1905 214-733-2722 Gvaudre@cnri.reston.va.us Vaudreuil [Page 4] Internet Draft Expires 4/18/94 Appendix - Changes from previous version o The streaming (High Performance) function was separated into a new capability. This is described in a companion document o Several editorial changes, including significant revision of the examples, were made. Appendix - Todo o SMTP senders may not be able to know the full size of the message before sending due to memory size limitations or a streaming data model. Use of a series of BDAT commands, each with a segment of the message may make facilitate use of BDAT in these environments. This needs to be explored. Vaudreuil [Page 5]