From fdec8d6cf10bfd061d98d8b790bb71985ed36e3a Mon Sep 17 00:00:00 2001 From: Graham Wilson Date: Mon, 29 Nov 2004 16:40:04 +0000 Subject: 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 --- RFC/rfc1870.txt | 507 -------------------------------------------------------- 1 file changed, 507 deletions(-) delete mode 100644 RFC/rfc1870.txt (limited to 'RFC/rfc1870.txt') 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: - C: - 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: SIZE=500000 - S: 250 Address Ok. - C: RCPT TO: - S: 250 ned@innosoft.com OK; can accomodate 500000 byte message - C: RCPT TO: - S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU - C: RCPT TO: - 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] - -- cgit v1.2.3