Network Working Group Greg Vaudreuil Internet Draft Tigon Corporation Expires: 4/18/94 October 18, 1993 SMTP Service Extensions for High Performance and 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 large potentially binary objects. Further, this option will signal the ability of the server SMTP receiver to accept the streaming of all commands up to the data command. 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 SMTP will be expected to carry very large 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. A second source of inefficiency in the use of SMTP is the implicit requirement to send the full SMTP command stream, including each RCPT TO command sychronously, that is, to wait for a response to the previous command before sending the next. This stop and wait interaction often adds minutes to the length of a SMTP session, partly by requiring validation of addresses one at a time. 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 streaming SMTP implementation model and the BDAT command. Internet Draft Expires 4/18/94 4.Framework for the High Performance Extensions The following service extension is hereby defined: 1) The name of the service extension is "High Performance Binary" 2) The EHLO keyword value associated with this extension is "HP- BINARY" 3) No parameter is used with the HP-BINARY keyword 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 a replacement for the "DATA" command of [1] 5.The High Performance 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 HP-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 HP- BINARY transport service extension shall preserve all bits in each octet passed using the DATA command. After receiving the 250 response to the EHLO command with the HP- BINARY keyword, the MAIL FROM and RCPT TO commands can optionally be sent as a block. If the MAIL FROM address is invalid or otherwise unavailable, the following RCPT TO commands should be answered with the 503 command out of sequence error. Note: While SMTP does not explicitly require the stop and wait behavior, and while the protocol as defined will work in a streaming model, the examples have led implementors to build SMTP Vaudreuil [Page 2] Internet Draft Expires 4/18/94 servers in such a manner as to require this behavior. This service extension recognizes the desire to use a streaming implementation model and explicitly encourages its use. After all MAIL FROM and RCPT TO responses are collected and processed, the BDAT command is sent. The BDAT command is a replacement for 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 HP-BINARY transport extension (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value HP-BINARY in its response), then the client SMTP must not, under any circumstances, send binary data using the DATA command. If the receiver-SMTP does not support HP-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. Vaudreuil [Page 3] Internet Draft Expires 4/18/94 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 HP-BINARY C: MAIL FROM: BINARYMIME S: 250 ... Sender and BINARYMIME ok C: RCPT TO: C: RCPT TO: C: RCPT TO: S: 250 ... Recipient ok S: 250 ... Recipient ok S: 250 ... Recipient ok C: BDAT 1324 S: 354 Send BINARYMIME message of 1324 Octets. ... S: 250 OK C: QUIT S: 250 Goodbye The following dialogue illustrates the use of the High Performance and Binary service extension to send a large 7 bit plain text object to one recipient without the dot-stuffing overhead of the DATA command: 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 HP-BINARY C: MAIL FROM: BODY=7BIT S: 250 ... Sender and 7BIT C: RCPT TO: S: 250 ... Recipient ok C: BDAT 1324 S: 354 Send 7BIT message of 78324 Octets. ... S: 250 OK C: QUIT S: 250 Goodbye Vaudreuil [Page 4] 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.Acknowledgements 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, Ned 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 5]