Network Working Group Keith Moore Internet Draft University of Tennessee SMTP Service Extension for Message Size Declaration 8 September 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 a sender- SMTP may declare to a receiver-SMTP the size of a particular message, thus giving the receiver-SMTP an opportunity to decline to accept the message (perhaps temporarily) based on its declared size. 3. Introduction The MIME extensions to the Internet message protocol [1] 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 Simple Mail Transfer Protocol [2] 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 receiver-SMTP. This memo uses the mechanism defined in [3] to define an extension to the SMTP service whereby a sender-SMTP may declare the size of a particular message to a receiver-SMTP, after which the receiver-SMTP may indicate to the sender-SMTP that it is or is not willing to accept the message based on the declared message size: (1) the name of the SMTP service extension is "Message Size Declaration"; (2) the EHLO keyword value associated with this extension is "MSGSIZE"; K. Moore Expires 8 March 1993 [Page 1] Internet Draft 8 September 1992 (3) no parameters are allowed with this EHLO keyword value; and, (4) the next section specifies how support for the extension affects the behavior of a sender-SMTP and receiver-SMTP. 4. The Message Size Declaration service extension A sender-SMTP that supports this service extension, when it wishes to send a large message, should issue an EHLO command, rather than a HELO command, to start the SMTP session. The receiver-SMTP's response to the EHLO command is examined to determine whether the receiver-SMTP supports the message size declaration service extension. If the receiver-SMTP does not support the message size declaration extension, (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value "MSGSIZE" in its response), then the sender-SMTP MAY NOT use the extended DATA command described below to transfer the message. (The DATA command as defined in [2] may still be used.) If the receiver-SMTP does support the message size declaration extension, then the sender-SMTP may issue an extended DATA command to inform the receiver-SMTP of the message size. 5. Definition of message size. The message size is defined as the number of octets required to express the message in the format defined by [1] and/or [4]. In particular, ends-of-line that appear in the transmitted message (represented by followed by ) count as two octets, regardless of the sender-SMTP's internal representation for such messages. Any leading '.' characters required for transmission via SMTP are considered part of the message for message size computation. The final '.' sequence used to terminate the message in SMTP is not counted as part of the message when computing message size. 6. The extended DATA command The extended DATA command is issued by a sender-SMTP when it wishes to inform a receiver-SMTP of the size of the message to be sent. The syntax for this command, using the augmented BNF notation defined in [4], is as follows: extended-data-command ::= "DATA" 1*digit The parameter to the extended DATA command is a decimal representation of the declared message size in octets. Ideally, the declared message size is equal to the message size as defined above. However, if the K. Moore Expires 8 March 1993 [Page 2] Internet Draft 8 September 1992 sender-SMTP cannot feasibly determine the exact message size, it may declare the message to be of any size greater than or equal to the message size as defined above. 6.1 Receiver-SMTP action on receipt of the extended DATA command Upon receipt of an extended DATA command, a receiver-SMTP should determine whether sufficient resources are available to buffer a message of the declared size and to maintain it in stable storage, if necessary, until the message can be delivered or relayed to its recipients. If possible, a receiver-SMTP should attempt to allocate the required amount of storage to queue the incoming message before returning a response code. NOTE: If a receiver-SMTP advertises the MSGSIZE extension in response to the EHLO command, it MUST check availability of system resources (memory and stable storage) upon receipt of an extended DATA command and issue an appropriate reply based on such availability. Implementations of the extended DATA command that (for example) always issue a successful response code without regard to the declared message size, or always impose a fixed limit on message size, are forbidden. (The Administrative Maximum Message Size service extension [6] applies to the latter case.) (1) If the receiver-SMTP is currently willing to accept a message of the indicated size, it responds with code "354 start mail input". (2) If the receiver-SMTP currently lacks sufficient resources to accept a message of the indicated size, but may be willing to accept the message at a later time, it responds with code "452 insufficient system storage". (3) If the indicated size is larger than the receiver-SMTP is willing to handle at any time (i.e. the administrative maximum message size), the receiver-SMTP responds with code "552 message exceeds administrative size limit". (4) As with any SMTP command, if the receiver-SMTP is "shutting down" for some reason, it may return "421 service shutting down" and close the TCP connection. 6.2 Sender-SMTP action on receiving response to extended DATA command The sender-SMTP, upon receiving the receiver-SMTP's response to the extended DATA command, acts as follows: (1) If the code "354 start mail input" was returned, it proceeds to transmit the message exactly as if it had sent the DATA command described in [2]; K. Moore Expires 8 March 1993 [Page 3] Internet Draft 8 September 1992 (2) If the code "452 insufficient system storage" is returned, the sender-SMTP should next send either a RSET command (if it wishes to attempt to send other, smaller messages) or a QUIT command (if it does not wish to attempt to send additional messages). If a particular message is too large to be sent, a sender-SMTP may attempt to relay the message via a different path, (as described in [5]), or to relay the message to the same receiver-SMTP at a later time. (3) If the code "552 message exceeds administrative size limit" is received, the sender-SMTP should immediately send either a RSET command (if it wishes to attempt to send other, smaller messages), or a QUIT command (if it does not wish to attempt to send additional messages). If a particular message exceeds the administrative size limit, the sender-SMTP may either (a) attempt to relay the message by another path, as described in [5]; (b) declare the message undeliverable and return appropriate notification to the sender (if a sender address was present in the MAIL, SAML, SEND, or SOML command); or (c) the sender-SMTP may behave as a translating gateway, by splitting the message into two or more MIME messages of content-type message/partial, that collectively contain the contents of the original message. (4) If the code "421 service shutting down" is received, the sender-SMTP should close the connection without attempting to send any further SMTP commands. It may then attempt to relay the message by another path (as described in [5]), or to relay the message to the same receiver-SMTP at a later time. 7. Interaction with Administrative Maximum Message Size. When a sender-SMTP supports both this service extension and the Administrative Maximum Message Size service extension [6], it should not attempt to send any command (either via the DATA command defined in [2] or the extended DATA command defined here) for a message which exceeds the receiver-SMTP's Administrative Maximum Message Size. A receiver-SMTP which supports both this service extension and the Administrative Maximum Message Size service extension should return a "552 message exceeds administrative size limit" code in response to an extended DATA command, if and only if that extended DATA command declares a message size larger than the administrative maximum message size. 9. References [1] N. S. Borenstein, N. Freed. Multipurpose Internet Mail Extensions. Request for Comments 1341, June 1992. K. Moore Expires 8 March 1993 [Page 4] Internet Draft 8 September 1992 [2] J. B. Postel. Simple Mail Transfer Protocol. Request for Comments 821, August 1982. [3] M. T. Rose, E. A. Stefferud, D. H. Crocker. SMTP Service Extensions. Internet-draft, September 1992. [4] D. H. Crocker. Standard for the Format of ARPA Internet Text Messages. Request for Comments 822, August 1982. [5] C. Partridge. Mail Routing and the Domain System. Request for Comments 974, January 1986. [6] D. H. Crocker, M. T. Rose, E. A. Stefferud. SMTP Service Extension for Administrative Maximum Message Size. Internet-draft, September 1992. 9. Author's address Keith Moore Computer Science Dept. University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 Internet: moore@cs.utk.edu K. Moore Expires 8 March 1993 [Page 5]