SMTP Service Extension for Message Size Declaration
RFC 1653
Document | Type |
RFC - Draft Standard
(July 1994; No errata)
Obsoleted by RFC 1870
Obsoletes RFC 1427
|
|
---|---|---|---|
Authors | Ned Freed , John Klensin , Keith Moore | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1653 (Draft Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group J. Klensin, WG Chair Request for Comments: 1653 MCI Obsoletes: 1427 N. Freed, Editor Category: Standards Track Innosoft K. Moore University of Tennessee July 1994 SMTP Service Extension for Message Size Declaration Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 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. 1. 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"). Klensin, Freed & Moore [Page 1] RFC 1653 SMTP Size Declaration July 1994 2. 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 in bytes 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. 3. 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 Klensin, Freed & Moore [Page 2] RFC 1653 SMTP Size Declaration July 1994 attempted. 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, then the Message Size Declaration extension is supported. If a numeric parameter follows the SIZE keyword value of the EHLOShow full document text