Network Working Group John Klensin, WG Chair Internet Draft Ned Freed, Editor Marshall Rose Einar Stefferud David Crocker SMTP Service Extension for 8bit-MIMEtransport Tue Nov 24 12:30:01 1992 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. (The file 1id-abstracts.txt on nic.ddn.mil describes the current status of each Internet Draft.) It is not appropriate 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 content body containing octets outside of the US ASCII octet range (hex 00-7F) may be relayed using SMTP. 3. Introduction Although SMTP is widely and robustly deployed, various extensions have been requested by some parts of the Internet community. In particular, a significant portion of the Internet community wishes to exchange messages in which the content body consists of a MIME message [3] containing arbitrary octet-aligned material. This memo uses the mechanism Internet Draft SMTP 8bit-MIMEtransport Nov 1992 described in [5] to define an extension to the SMTP service whereby such contents may be exchanged. Note that this extension does NOT eliminate the possibility of an SMTP server limiting line length; servers are free to implement this extension but nevertheless set a line length limit no lower than 1000 octets. 4. Framework for the 8bit MIME Transport Extension The 8bit MIME transport extension is defined as follows: (1) the name of the SMTP service extension is 8bit- MIMEtransport; (2) the EHLO keyword value associated with the extension is 8BITMIME; (3) no parameter is used with the 8BITMIME EHLO keyword; (4) one optional parameter using the keyword BODY is added to the MAIL FROM command. The value associated with this parameter is a keyword indicating whether a 7bit message (in strict compliance with [1]) or a MIME message (in struct compliance with [3]) with arbitrary octet content is being sent. The syntax of the value is as follows, using the ABNF notation of [2]: body-value ::= "7BIT" / "8BITMIME" (5) no additional SMTP verbs are defined by this extension; and, (6) the next section specifies how support for the extension affects the behavior of a server and client SMTP. 5. The 8bit-MIMEtransport 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 8BITMIME, then the server SMTP is indicating that it Expires April 16, 1993 [Page 2] Internet Draft SMTP 8bit-MIMEtransport Nov 1992 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 [5]. The esmtp-keyword is BODY and the syntax for esmtp-value is given by the syntax for body-value shown above. The value associated with the BODY parameter indicates whether the content body which will be passed using the DATA command consists of a MIME message containing some arbitrary octet- aligned material ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT"). A server which supports the 8-bit MIME transport service extension shall preserve all bits in each octet passed using the DATA command. Naturally, the usual SMTP data-stuffing algorithm applies so that a content which contains the five-character sequence of or a content that begins with the three-character sequence of does not prematurely terminate the transfer of the content. Further, it should be noted that the CR-LF pair immediately preceeding the final dot is considered part of the content. Finally, although the content body contains arbitrary octet- aligned material, the length of each line (number of octets between two CR-LF pairs), is still subject to SMTP server line length restrictions (which may allow as few as 1000 octets on a single line). Once a server SMTP supporting the 8bit-MIMEtransport service extension accepts a content body containing octets with the high-order (8th) bit set, the server SMTP must deliver or relay the content in such a way as to preserve all bits in Expires April 16, 1993 [Page 3] Internet Draft SMTP 8bit-MIMEtransport Nov 1992 each octet. If a server SMTP does not support the 8-bit MIME transport extension (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value 8BITMIME in its response), then the client SMTP must not, under any circumstances, attempt to transfer a content which contains characters outside the US ASCII octet range (hex 00-7F). A client SMTP has two options in this case: first, it may implement a gateway transformation to convert the message into valid 7bit MIME, or second, or may treat this as a permanent error and handle it in the usual manner for delivery failures. The specifics of the transformation from 8bit 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. 6. Security Considerations This RFC does not discuss security issues and is not believed to raise any security issues not endemic in electronic mail and present in fully conforming implementations of [1]. 7. Acknowledgements This document represents a synthesis of the ideas of many people and reactions to the ideas and proposals of others. Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas and text sufficient to be considered co-authors. Other important suggestions, text, or encouragement came from Harald Alvestrand, Jim Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John Wagner, Rayan Zachariassen, and the contributions of the entire IETF SMTP Working Group. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here. Indeed, in some cases, the response to Expires April 16, 1993 [Page 4] Internet Draft SMTP 8bit-MIMEtransport Nov 1992 a particular criticism was to accept the problem identification but to include an entirely different solution from the one originally proposed. 8. References [1] J.B. Postel. Simple Mail Transfer Protocol. Request for Comments 821, (August, 1982). [2] D.H. Crocker. Standard for the Format of ARPA Internet Text Messages. Request for Comments 822, (August, 1982). [3] N.S. Borenstein, N. Freed. Multipurpose Internet Mail Extensions. Request for Comments 1341, (June, 1992). [4] K. Moore. Representation of Non-ASCII Text in Internet Message Headers. Request for Comments 1342, (June, 1992). [5] M.T. Rose, E.A. Stefferud, D.H. Crocker, J.C. Klensin, N. Freed. SMTP Service Extensions. Internet-Draft, (November, 1992). [6] C. Partridge. Mail Routing and the Domain System. Request for Comments 974, (January, 1986). Expires April 16, 1993 [Page 5] Internet Draft SMTP 8bit-MIMEtransport Nov 1992 9. Chair, Editor, and Author Addresses John Klensin, WG Chair United Nations University PO Box 500, Charles Street Station Boston, MA 02114-0500 tel: +1 617 227 8747 fax: +1 617 491 6266 email: klensin@infoods.unu.edu Ned Freed, Editor Innosoft International, Inc. 250 West First Street, Suite 240 Claremont, CA 91711 USA tel: +1 909 624 7907 fax: +1 909 621 5319 email: ned@innosoft.com Marshall T. Rose Dover Beach Consulting, Inc. email: mrose@dbc.mtview.ca.us Einar A. Stefferud Network Management Associates, Inc. email: stef@nma.com David H. Crocker The Branch Office email: dcrocker@mordor.stanford.edu Expires April 16, 1993 [Page 6] --Boundary (ID R6WHsPyZxfktHEZAXeZCyQ) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Network Working Group John Klensin, WG Chair Internet Draft Ned Freed, Editor Keith Moore SMTP Service Extension for Message Size Declaration 24 November 1992 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. (The file 1id-abstracts.txt, available via anonymous ftp from nic.ddn.mil, describes the current status of each Internet Draft.) It is not appropriate 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 interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. 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 a much wider range of message sizes than was previously the case. This has an impact on the amount of resources (e.g. disk space) required by a system acting as a server. This memo uses the mechanism defined in [5] to define extensions to the SMTP service whereby a client ("sender-SMTP") may declare the size of a particular message to a server ("receiver-SMTP"), after which the server may indicate to the client that it is or is not willing to accept the message based on the declared message size and whereby a server ("receiver-SMTP") may declare the maximum message size it is willing to accept to a client ("sender-SMTP"). Expires 24 April 1993 [Page 1] Internet Draft SMTP Size Declaration Nov 1992 4. Framework for the Size Declaration Extension The following service extension is therefore defined: (1) the name of the SMTP service extension is "Message Size Declaration"; (2) the EHLO keyword value associated with this extension is "SIZE"; (3) one optional parameter is allowed with this EHLO keyword value, a decimal number indicating the fixed maximum message size that the server will accept. The syntax of the parameter is as follows, using the augmented BNF notation of [2]: size-param ::= [1*DIGIT] A parameter value of 0 (zero) indicates that no fixed maximum message size is in force. If the parameter is omitted no information is conveyed about the server's fixed maximum message size; (4) one optional parameter using the keyword "SIZE" is added to the MAIL FROM command. The value associated with this parameter is a decimal number indicating the size of the message that is to be transmitted. The syntax of the value is as follows, using the augmented BNF notation of [2]: size-value ::= 1*DIGIT (5) no additional SMTP verbs are defined by this extension. The remainder of this memo specifies how support for the extension affects the behavior of an SMTP client and server. 5. The Message Size Declaration service extension An SMTP server may have a fixed upper limit on message size. Any attempt by a client to transfer a message which is larger than this fixed upper limit will fail. In addition, a server normally has limited space with which to store incoming messages. Transfer of a message may therefore also fail due to a lack of storage space, but might succeed at a later time. A client using the unextended SMTP protocol defined in [1], can only be informed of such failures after transmitting the entire message to the server (which discards the transferred message). If, however, both client and server support the Message Size Declaration service extension, such conditions may be detected before any transfer is attemped. Expires 24 April 1993 [Page 2] Internet Draft SMTP Size Declaration Nov 1992 An SMTP client wishing to relay a large content may issue the EHLO command to start an SMTP session, to determine if the server supports any of several service extensions. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword value SIZE, the Message Size Declaration extension is supported. If a numeric parameter follows the SIZE keyword value of the EHLO response, it indicates the size of the largest message that the server is willing to accept. Any attempt by a client to transfer a message which is larger than this limit will be rejected with a permanent failure (552) reply code. A server that supports the Message Size Declaration extension will accept the extended version of the MAIL command described below. When supported by the server, a client may use the extended MAIL command (instead of the MAIL command as defined in [1]) to declare an estimate of the size of a message it wishes to transfer. The server may then return an appropriate error code if it determines that an attempt to transfer a message of that size would fail. 6. Definitions The message size is defined as the number of octets, including CR-LF pairs, up to, but not including, the final dot, to be transmitted by the SMTP client after receiving reply code 354 to the DATA command. The fixed maximum message size is defined as the message size of the largest message that a server is ever willing to accept. An attempt to transfer any message larger than the fixed maximum message size will always fail. The fixed maximum message size may be an implementation artifact of the SMTP server, or it may be chosen by the administrator of the server. The declared message size is defined as a client's estimate of the message size for a particular message. 7. The extended MAIL command The extended MAIL command is issued by a client when it wishes to inform a server of the size of the message to be sent. The extended MAIL command is identical to the MAIL command as defined in [1], except that a SIZE parameter appears after the address. The complete syntax of this extended command is defined in [5]. The esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by the syntax for size-value shown above. The value associated with the SIZE parameter is a decimal representation of the declared message size in octets. This number should include the Expires 24 April 1993 [Page 3] Internet Draft SMTP Size Declaration Nov 1992 message header, body, and the CR-LF sequences between lines, but not the SMTP DATA command's terminating dot or doubled quoting dots. Ideally, the declared message size is equal to the true message size. However, since exact computation of the message size may be infeasable, the client may use a heuristically-derived estimate. Such heuristics should be chosen so that the declared message size is usually larger than the actual message size. (This has the effect of making the counting or non-counting of SMTP DATA dots largely an academic point.) NOTE: Servers MUST NOT use the SIZE parameter to determine end of content in the DATA command. 7.1 Server action on receipt of the extended MAIL command Upon receipt of an extended MAIL command containing a SIZE parameter, a server should determine whether the declared message size exceeds its fixed maximum message size. If the declared message size is smaller than the fixed maximum message size, the server may also wish to determine whether sufficient resources are available to buffer a message of the declared message size and to maintain it in stable storage, until the message can be delivered or relayed to each of its recipients. A server may respond to the extended MAIL command with any of the error codes defined in [1] for the MAIL command. In addition, the following error codes are returned: (1) If the server currently lacks sufficient resources to accept a message of the indicated size, but may be able to accept the message at a later time, it responds with code "452 insufficient system storage". (2) If the indicated size is larger than the server's fixed maximum message size, the server responds with code "552 message size exceeds fixed maximium message size". A server is permitted, but not required, to accept a message which is, in fact, larger than declared in the extended MAIL command, such as might occur if the client employed a size-estimation heuristic which was inaccurate. 7.2 Client action on receiving response to extended MAIL command The client, upon receiving the server's response to the extended MAIL command, acts as follows: (1) If the code "452 insufficient system storage" is returned, the client should next send either a RSET command (if it wishes to attempt to send other messages) or a QUIT command. The client should Expires 24 April 1993 [Page 4] Internet Draft SMTP Size Declaration Nov 1992 then repeat the attempt to send the message to the server at a later time. (2) If the code "552 message exceeds fixed maximum message size" is received, the client should immediately send either a RSET command (if it wishes to attempt to send additional messages), or a QUIT command. The client should then declare the message undeliverable and return appropriate notification to the sender (if a sender address was present in the MAIL command). A successful (250) reply code in response to the extended MAIL command does not constitute an absolute guarantee that the message transfer will succeed. SMTP clients using the extended MAIL command must still be prepared to handle both temporary and permanent error reply codes (including codes 452 and 552), either immediately after issuing the DATA command, or after transfer of the message. 7.3 Messages larger than the declared size. Once a server has agreed (via the extended MAIL command) to accept a message of a particular size, it should not return a 552 reply code after the transfer phase of the DATA command, unless the actual size of the message transferred is greater than the declared message size. A server may also choose to accept a message which is somewhat larger than the declared message size. A client is permitted to declare a message to be smaller than its actual size. However, in this case, a successful (250) reply code is no assurance that the server will accept the message or has sufficient resources to do so. The server may reject such a message after its DATA transfer. 7.4 Per-recipient rejection based on message size. A server that implements this extension may return a 452 or 552 reply code in response to a RCPT command, based on its unwillingness to accept a message of the declared size for a particular recipient. (1) If a 452 code is returned, the client may requeue the message for later delivery to the same recipient. (2) If a 552 code is returned, the client may not requeue the message for later delivery to the same recipient. 8. Minimal usage A "minimal" client may use this extension to simply compare its (perhaps estimated) size of the message that it wishes to relay, with Expires 24 April 1993 [Page 5] Internet Draft SMTP Size Declaration Nov 1992 the server's fixed maximum message size (from the parameter to the SIZE keyword in the EHLO response), to determine whether the server will ever accept the message. Such an implementation need not declare message sizes via the extended MAIL command. However, neither will it be able to discover temporary limits on message size due to server resource limitations, nor per-recipient limitations on message size. A minimal server that employs this service extension may simply use the SIZE keyword value to inform the client of the size of the largest message it will accept, or to inform the client that there is no fixed limit on message size. Such a server must accept the extended MAIL command and return a 552 reply code if the client's declared size exceeds its fixed size limit (if any), but it need not detect "temporary" limitations on message size. The numeric parameter to the EHLO SIZE keyword is optional. If the parameter is omitted entirely it indicates that the server does not advertise a fixed maximum message size. A server that returns the SIZE keyword with no parameter in response to the EHLO command may not issue a positive (250) response to an extended MAIL command containing a SIZE specification without first checking to see if sufficient resources are available to transfer a message of the declared size, and to retain it in stable storage until it can be relayed or delivered to its recipients. If possible, the server should actually reserve sufficient storage space to transfer the message. 9. Security considerations The size declaration extensions described in this memo can conceivably be used to facilitate crude service denial attacks. Specifically, both the information contained in the SIZE parameter and use of the extended MAIL command make it somewhat quicker and easier to devise an efficacious service denial attack. However, unless implementations are very weak, these extensions do not create any vulnerability that has not always existed with SMTP. In addition, no issues are addressed involving trusted systems and possible release of information via the mechanisms described in this RFC. 10. Acknowledgements This document was derived from an earlier Working Group draft contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot Lear, Marshall T. Rose, and Einar Stefferud provided extensive comments in response to earlier drafts of both this and the previous memo. Expires 24 April 1993 [Page 6] Internet Draft SMTP Size Declaration Nov 1992 10. References [1] J. B. Postel. Simple Mail Transfer Protocol. Request for Comments 821, August 1982. [2] D. H. Crocker. Standard for the Format of ARPA Internet Text Messages. Request for Comments 822, August 1982. [3] N. S. Borenstein, N. Freed. Multipurpose Internet Mail Extensions. Request for Comments 1341, June 1992. [4] K. Moore. Representation of Non-ASCII Text in Internet Message Headers. Request for Comments 1342, June 1992. [5] M. T. Rose, E. A. Stefferud, D. H. Crocker, John C. Klensin, Ned Freed. SMTP Service Extensions. Internet-draft, 24 November 1992. [6] C. Partridge. Mail Routing and the Domain System. Request for Comments 974, January 1986. 11. Chair, editor, and author ddresses John Klensin, WG Chair United Nations University PO Box 500, Charles Street Station Boston, MA 02114-0500 tel: +1 617 227 8747 fax: +1 617 491 6266 email: klensin@infoods.unu.edu Ned Freed, Editor Innosoft International, Inc. 250 West First Street, Suite 240 Claremont, CA 91711 USA tel: +1 909 624 7907 fax: +1 909 621 5319 email: ned@innosoft.com Keith Moore Computer Science Dept. University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA email: moore@cs.utk.edu Expires 24 April 1993 [Page 7]