1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1427.txt b/doc/rfc/rfc1427.txt
new file mode 100644
index 0000000..3538fef
--- /dev/null
+++ b/doc/rfc/rfc1427.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                               J. Klensin, WG Chair
+Request for Comments: 1427                     United Nations University
+                                                        N. Freed, Editor
+                                            Innosoft International, Inc.
+                                                                K. Moore
+                                                 University of Tennessee
+                                                           February 1993
+
+
+                         SMTP Service Extension
+                      for Message Size Declaration
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+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 accept to a client ("sender-SMTP").
+
+3.  Framework for the Size Declaration Extension
+
+   The following service extension is therefore defined:
+
+
+
+
+Klensin, Freed & Moore                                          [Page 1]
+
+RFC 1427                 SMTP Size Declaration             February 1993
+
+
+(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.
+
+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
+   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
+
+
+
+Klensin, Freed & Moore                                          [Page 2]
+
+RFC 1427                 SMTP Size Declaration             February 1993
+
+
+   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.
+
+   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
+
+
+
+Klensin, Freed & Moore                                          [Page 3]
+
+RFC 1427                 SMTP Size Declaration             February 1993
+
+
+   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.
+
+   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.
+
+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:
+
+
+
+Klensin, Freed & Moore                                          [Page 4]
+
+RFC 1427                 SMTP Size Declaration             February 1993
+
+
+(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.
+
+   (2) If a 552 code is returned, the client may not requeue the message
+       for later delivery to the same recipient.
+
+
+
+
+
+Klensin, Freed & Moore                                          [Page 5]
+
+RFC 1427                 SMTP Size Declaration             February 1993
+
+
+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>
+
+
+
+Klensin, Freed & Moore                                          [Page 6]
+
+RFC 1427                 SMTP Size Declaration             February 1993
+
+
+      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] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+       USC/Information Sciences Institute, August 1982.
+
+   [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+       Messages", STD 11, RFC 822, UDEL, August 1982.
+
+   [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+       Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
+
+   [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
+       Headers", RFC 1342, University of Tennessee, June 1992.
+
+
+
+
+
+
+Klensin, Freed & Moore                                          [Page 7]
+
+RFC 1427                 SMTP Size Declaration             February 1993
+
+
+   [5] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+       E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
+       Nations University, Innosoft International, Inc., Dover Beach
+       Consulting, Inc., Network Management Associates, Inc., The Branch
+       Office, February 1993.
+
+   [6] Partridge, C., "Mail Routing and the Domain System", RFC 974,
+       BBN, January 1986.
+
+12.  Chair, Editor, and Author's Addresses
+
+       John Klensin, WG Chair
+       United Nations University
+       PO Box 500, Charles Street Station
+       Boston, MA 02114-0500  USA
+
+       Phone: +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
+
+       Phone: +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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, Freed & Moore                                          [Page 8]
+
+\ No newline at end of file