rfc1870_SizeExtention.txt
上传用户:horngjaan
上传日期:2009-12-12
资源大小:2882k
文件大小:18k
- 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]