Remove RFCs from the trunk, since we don't distribute them anyways. All of the removed RFCs are listed in the design-notes.html file, with the exception of NNTP (RFC977). Also add a link to the "LAN Mail Protocols" document to the design-notes.html file.

svn path=/trunk/; revision=4013

1 files changed, 0 insertions, 507 deletions

diff --git a/RFC/rfc1870.txt b/RFC/rfc1870.txt
deleted file mode 100644
index e24ccec6..00000000
--- a/RFC/rfc1870.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-

-

-

-

-

-

-Network Working Group                               J. Klensin, WG Chair

-Request For Comments: 1870                                           MCI

-STD: 10                                                 N. Freed, Editor

-Obsoletes: 1653                             Innosoft International, Inc.

-Category: Standards Track                                       K. Moore

-                                                 University of Tennessee

-                                                           November 1995

-

-

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

-

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

-

-

-

-

-

-

-

-

-Klensin, et al              Standards Track                     [Page 1]

-

-RFC 1870                 SMTP Size Declaration             November 1995

-

-

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

-

-

-

-

-

-Klensin, et al              Standards Track                     [Page 2]

-

-RFC 1870                 SMTP Size Declaration             November 1995

-

-

-   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

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

-

-

-

-

-

-

-

-

-Klensin, et al              Standards Track                     [Page 3]

-

-RFC 1870                 SMTP Size Declaration             November 1995

-

-

-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

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

-

-

-

-Klensin, et al              Standards Track                     [Page 4]

-

-RFC 1870                 SMTP Size Declaration             November 1995

-

-

-   (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:

-

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

-

-

-

-Klensin, et al              Standards Track                     [Page 5]

-

-RFC 1870                 SMTP Size Declaration             November 1995

-

-

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

-

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

-

-

-

-

-

-

-

-

-Klensin, et al              Standards Track                     [Page 6]

-

-RFC 1870                 SMTP Size Declaration             November 1995

-

-

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

-   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: 221 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 work in

-   progess contribution.  Jim Conklin, Dave Crocker, Neil Katin, Eliot

-   Lear, Marshall T. Rose, and Einar Stefferud provided extensive

-   comments in response to earlier works in progress of both this and

-   the previous memo.

-

-

-

-Klensin, et al              Standards Track                     [Page 7]

-

-RFC 1870                 SMTP Size Declaration             November 1995

-

-

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

-

-   [4] Moore, K., "Representation of Non-ASCII Text in Internet Message

-       Headers", RFC 1522, University of Tennessee, September 1993.

-

-   [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,

-       "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft

-       International, Inc., Dover Beach Consulting, Inc., Network

-       Management Associates, Inc., Brandenburg Consulting, November

-       1995.

-

-   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC

-       974, BBN, January 1986.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Klensin, et al              Standards Track                     [Page 8]

-

-RFC 1870                 SMTP Size Declaration             November 1995

-

-

-12.  Chair, Editor, and Author Addresses

-

-   John Klensin, WG Chair

-   MCI

-   2100 Reston Parkway

-   Reston, VA 22091

-

-   Phone: +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

-

-   Phone: +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

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Klensin, et al              Standards Track                     [Page 9]

-