SMTP Service Extension for Message Size Declaration
RFC 1653

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

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 EHLO