[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 rfc1870                                                 
Network Working Group                             John Klensin, WG Chair
Internet Draft                                         Ned Freed, Editor
<draft-ietf-smtpext-size-01.txt>                             Keith Moore


                         SMTP Service Extension
                      for Message Size Declaration

                             April 17, 1995


                          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 draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by other
documents at any time.  It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a working draft or work
in progress.

   To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

   This draft is intended to supercede RFC 1653.


1.  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.


2.  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



                         Expires November 1995                  [Page 1]


Internet Draft           SMTP Size Declaration                  May 1995



accept to a client ("sender-SMTP").


3.  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*20DIGIT

(5) the maximum length of a MAIL FROM command line is increased by 26
    characters by the possible addition of the SIZE keyword and value;

(6) 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.


4.  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



                         Expires November 1995                  [Page 2]


Internet Draft           SMTP Size Declaration                  May 1995



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
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
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.


5.  Definitions

   The message size is defined as the number of octets, including CR-LF
pairs, but not the SMTP DATA command's terminating dot or doubled
quoting dots, 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.


6.  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.



                         Expires November 1995                  [Page 3]


Internet Draft           SMTP Size Declaration                  May 1995



   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 message header, body, and the CR-LF sequences between
lines, but not the SMTP DATA command's terminating dot or doubled
quoting dots. Only one SIZE parameter may be specified in a single MAIL
command.

   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.


6.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, one of
the following error codes may be 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.





                         Expires November 1995                  [Page 4]


Internet Draft           SMTP Size Declaration                  May 1995



6.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
    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.


6.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.


6.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.




                         Expires November 1995                  [Page 5]


Internet Draft           SMTP Size Declaration                  May 1995



(2) If a 552 code is returned, the client may not requeue the message
    for later delivery to the same recipient.


7.  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
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.


8. Example

The following example illustrates the use of size declaration with some
permanent and temporary failures.

   S: <wait for connection on TCP port 25>
   C: <open connection to server>
   S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
   C: EHLO ymir.claremont.edu
   S: 250-sigurd.innosoft.com
   S: 250-EXPN
   S: 250-HELP
   S: 250 SIZE 1000000
   C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
   S: 250 Address Ok.
   C: RCPT TO:<ned@innosoft.com>



                         Expires November 1995                  [Page 6]


Internet Draft           SMTP Size Declaration                  May 1995



   S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
   C: RCPT TO:<ned@ymir.claremont.edu>
   S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
   C: RCPT TO:<ned@hmcvax.claremont.edu>
   S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
   C: DATA
   S: 354 Send message, ending in CRLF.CRLF.
    ...
   C: .
   S: 250 Some recipients OK
   C: QUIT
   S: 250 Goodbye


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.


11.  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 1521, September 1993.

[4] K. Moore. Representation of Non-ASCII Text in Internet Message
    Headers.  Request for Comments 1522, September 1993.

[5] M. T. Rose, E. A. Stefferud, D. H. Crocker, John C. Klensin, Ned
    Freed.  SMTP Service Extensions.  Internet-draft, April 1995.



                         Expires November 1995                  [Page 7]


Internet Draft           SMTP Size Declaration                  May 1995



[6] C. Partridge.  Mail Routing and the Domain System.  Request for
    Comments 974, January 1986.


12.  Chair, editor, and author addresses

John Klensin, WG Chair
MCI
2100 Reston Parkway
Reston, VA 22091
 tel: +1 703 715-7361           fax: +1 703 715-7436
 email: klensin@mci.net

Ned Freed, Editor
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
 tel: +1 818 919 3600           fax: +1 818 919 3614
 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 November 1995                  [Page 8]