From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1427.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc1427.txt (limited to 'doc/rfc/rfc1427.txt') 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: + 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: + + + +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: + 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: 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 -- cgit v1.2.3