7Network Working Group J. Klensin, WG Chair
8Request For Comments: 1870 MCI
9STD: 10 N. Freed, Editor
10Obsoletes: 1653 Innosoft International, Inc.
11Category: Standards Track K. Moore
12 University of Tennessee
16 SMTP Service Extension
17 for Message Size Declaration
21 This document specifies an Internet standards track protocol for the
22 Internet community, and requests discussion and suggestions for
23 improvements. Please refer to the current edition of the "Internet
24 Official Protocol Standards" (STD 1) for the standardization state
25 and status of this protocol. Distribution of this memo is unlimited.
29 This memo defines an extension to the SMTP service whereby an SMTP
30 client and server may interact to give the server an opportunity to
31 decline to accept a message (perhaps temporarily) based on the
32 client's estimate of the message size.
36 The MIME extensions to the Internet message protocol provide for the
37 transmission of many kinds of data which were previously unsupported
38 in Internet mail. One expected result of the use of MIME is that
39 SMTP will be expected to carry a much wider range of message sizes
40 than was previously the case. This has an impact on the amount of
41 resources (e.g. disk space) required by a system acting as a server.
43 This memo uses the mechanism defined in [5] to define extensions to
44 the SMTP service whereby a client ("sender-SMTP") may declare the
45 size of a particular message to a server ("receiver-SMTP"), after
46 which the server may indicate to the client that it is or is not
47 willing to accept the message based on the declared message size and
48 whereby a server ("receiver-SMTP") may declare the maximum message
49 size it is willing to accept to a client ("sender-SMTP").
58Klensin, et al Standards Track [Page 1]
60RFC 1870 SMTP Size Declaration November 1995
633. Framework for the Size Declaration Extension
65 The following service extension is therefore defined:
67 (1) the name of the SMTP service extension is "Message Size
72 (3) one optional parameter is allowed with this EHLO keyword value, a
73 decimal number indicating the fixed maximum message size in bytes
74 that the server will accept. The syntax of the parameter is as
75 follows, using the augmented BNF notation of [2]:
77 size-param ::= [1*DIGIT]
79 A parameter value of 0 (zero) indicates that no fixed maximum
80 message size is in force. If the parameter is omitted no
81 information is conveyed about the server's fixed maximum message
84 (4) one optional parameter using the keyword "SIZE" is added to the
85 MAIL FROM command. The value associated with this parameter is a
86 decimal number indicating the size of the message that is to be
87 transmitted. The syntax of the value is as follows, using the
88 augmented BNF notation of [2]:
93 characters by the possible addition of the SIZE keyword and
96 (6) no additional SMTP verbs are defined by this extension.
98 The remainder of this memo specifies how support for the extension
99 affects the behavior of an SMTP client and server.
1014. The Message Size Declaration service extension
103 An SMTP server may have a fixed upper limit on message size. Any
104 attempt by a client to transfer a message which is larger than this
105 fixed upper limit will fail. In addition, a server normally has
106 limited space with which to store incoming messages. Transfer of a
107 message may therefore also fail due to a lack of storage space, but
108 might succeed at a later time.
114Klensin, et al Standards Track [Page 2]
116RFC 1870 SMTP Size Declaration November 1995
119 A client using the unextended SMTP protocol defined in [1], can only
120 be informed of such failures after transmitting the entire message to
121 the server (which discards the transferred message). If, however,
122 both client and server support the Message Size Declaration service
123 extension, such conditions may be detected before any transfer is
126 An SMTP client wishing to relay a large content may issue the EHLO
127 command to start an SMTP session, to determine if the server supports
128 any of several service extensions. If the server responds with code
129 250 to the EHLO command, and the response includes the EHLO keyword
130 value SIZE, then the Message Size Declaration extension is supported.
132 If a numeric parameter follows the SIZE keyword value of the EHLO
133 response, it indicates the size of the largest message that the
134 server is willing to accept. Any attempt by a client to transfer a
135 message which is larger than this limit will be rejected with a
138 A server that supports the Message Size Declaration extension will
139 accept the extended version of the MAIL command described below.
140 When supported by the server, a client may use the extended MAIL
141 command (instead of the MAIL command as defined in [1]) to declare an
142 estimate of the size of a message it wishes to transfer. The server
143 may then return an appropriate error code if it determines that an
144 attempt to transfer a message of that size would fail.
148 The message size is defined as the number of octets, including CR-LF
149 pairs, but not the SMTP DATA command's terminating dot or doubled
150 quoting dots, to be transmitted by the SMTP client after receiving
151 reply code 354 to the DATA command.
153 The fixed maximum message size is defined as the message size of the
154 largest message that a server is ever willing to accept. An attempt
155 to transfer any message larger than the fixed maximum message size
156 will always fail. The fixed maximum message size may be an
157 implementation artifact of the SMTP server, or it may be chosen by
158 the administrator of the server.
160 The declared message size is defined as a client's estimate of the
161 message size for a particular message.
170Klensin, et al Standards Track [Page 3]
172RFC 1870 SMTP Size Declaration November 1995
1756. The extended MAIL command
177 The extended MAIL command is issued by a client when it wishes to
178 inform a server of the size of the message to be sent. The extended
179 MAIL command is identical to the MAIL command as defined in [1],
180 except that a SIZE parameter appears after the address.
182 The complete syntax of this extended command is defined in [5]. The
183 esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by
184 the syntax for size-value shown above.
186 The value associated with the SIZE parameter is a decimal
187 representation of the declared message size in octets. This number
188 should include the message header, body, and the CR-LF sequences
189 between lines, but not the SMTP DATA command's terminating dot or
190 doubled quoting dots. Only one SIZE parameter may be specified in a
193 Ideally, the declared message size is equal to the true message size.
194 However, since exact computation of the message size may be
195 infeasable, the client may use a heuristically-derived estimate.
196 Such heuristics should be chosen so that the declared message size is
197 usually larger than the actual message size. (This has the effect of
198 making the counting or non-counting of SMTP DATA dots largely an
201 NOTE: Servers MUST NOT use the SIZE parameter to determine end of
202 content in the DATA command.
2046.1 Server action on receipt of the extended MAIL command
206 Upon receipt of an extended MAIL command containing a SIZE parameter,
207 a server should determine whether the declared message size exceeds
208 its fixed maximum message size. If the declared message size is
209 smaller than the fixed maximum message size, the server may also wish
210 to determine whether sufficient resources are available to buffer a
211 message of the declared message size and to maintain it in stable
212 storage, until the message can be delivered or relayed to each of its
215 A server may respond to the extended MAIL command with any of the
216 error codes defined in [1] for the MAIL command. In addition, one of
217 the following error codes may be returned:
219 (1) If the server currently lacks sufficient resources to accept a
220 message of the indicated size, but may be able to accept the
221 message at a later time, it responds with code "452 insufficient
226Klensin, et al Standards Track [Page 4]
228RFC 1870 SMTP Size Declaration November 1995
231 (2) If the indicated size is larger than the server's fixed maximum
232 message size, the server responds with code "552 message size
233 exceeds fixed maximium message size".
235 A server is permitted, but not required, to accept a message which
236 is, in fact, larger than declared in the extended MAIL command, such
237 as might occur if the client employed a size-estimation heuristic
238 which was inaccurate.
2406.2 Client action on receiving response to extended MAIL command
242 The client, upon receiving the server's response to the extended MAIL
243 command, acts as follows:
245 (1) If the code "452 insufficient system storage" is returned, the
246 client should next send either a RSET command (if it wishes to
247 attempt to send other messages) or a QUIT command. The client
248 should then repeat the attempt to send the message to the server
251 (2) If the code "552 message exceeds fixed maximum message size" is
252 received, the client should immediately send either a RSET command
253 (if it wishes to attempt to send additional messages), or a QUIT
254 command. The client should then declare the message undeliverable
255 and return appropriate notification to the sender (if a sender
256 address was present in the MAIL command).
258 A successful (250) reply code in response to the extended MAIL
259 command does not constitute an absolute guarantee that the message
260 transfer will succeed. SMTP clients using the extended MAIL command
261 must still be prepared to handle both temporary and permanent error
262 reply codes (including codes 452 and 552), either immediately after
263 issuing the DATA command, or after transfer of the message.
2656.3 Messages larger than the declared size.
267 Once a server has agreed (via the extended MAIL command) to accept a
268 message of a particular size, it should not return a 552 reply code
269 after the transfer phase of the DATA command, unless the actual size
270 of the message transferred is greater than the declared message size.
271 A server may also choose to accept a message which is somewhat larger
272 than the declared message size.
274 A client is permitted to declare a message to be smaller than its
275 actual size. However, in this case, a successful (250) reply code is
276 no assurance that the server will accept the message or has
277 sufficient resources to do so. The server may reject such a message
278 after its DATA transfer.
282Klensin, et al Standards Track [Page 5]
284RFC 1870 SMTP Size Declaration November 1995
2876.4 Per-recipient rejection based on message size.
289 A server that implements this extension may return a 452 or 552 reply
290 code in response to a RCPT command, based on its unwillingness to
291 accept a message of the declared size for a particular recipient.
293 (1) If a 452 code is returned, the client may requeue the message for
294 later delivery to the same recipient.
296 (2) If a 552 code is returned, the client may not requeue the message
297 for later delivery to the same recipient.
301 A "minimal" client may use this extension to simply compare its
302 (perhaps estimated) size of the message that it wishes to relay, with
303 the server's fixed maximum message size (from the parameter to the
304 SIZE keyword in the EHLO response), to determine whether the server
305 will ever accept the message. Such an implementation need not
306 declare message sizes via the extended MAIL command. However,
307 neither will it be able to discover temporary limits on message size
308 due to server resource limitations, nor per-recipient limitations on
311 A minimal server that employs this service extension may simply use
312 the SIZE keyword value to inform the client of the size of the
313 largest message it will accept, or to inform the client that there is
314 no fixed limit on message size. Such a server must accept the
315 extended MAIL command and return a 552 reply code if the client's
316 declared size exceeds its fixed size limit (if any), but it need not
317 detect "temporary" limitations on message size.
319 The numeric parameter to the EHLO SIZE keyword is optional. If the
320 parameter is omitted entirely it indicates that the server does not
321 advertise a fixed maximum message size. A server that returns the
322 SIZE keyword with no parameter in response to the EHLO command may
323 not issue a positive (250) response to an extended MAIL command
324 containing a SIZE specification without first checking to see if
325 sufficient resources are available to transfer a message of the
326 declared size, and to retain it in stable storage until it can be
327 relayed or delivered to its recipients. If possible, the server
328 should actually reserve sufficient storage space to transfer the
338Klensin, et al Standards Track [Page 6]
340RFC 1870 SMTP Size Declaration November 1995
345 The following example illustrates the use of size declaration with
346 some permanent and temporary failures.
348 S: <wait for connection on TCP port 25>
349 C: <open connection to server>
350 S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
351 C: EHLO ymir.claremont.edu
352 S: 250-sigurd.innosoft.com
356 C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
358 C: RCPT TO:<ned@innosoft.com>
359 S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
360 C: RCPT TO:<ned@ymir.claremont.edu>
361 S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
362 C: RCPT TO:<ned@hmcvax.claremont.edu>
363 S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
365 S: 354 Send message, ending in CRLF.CRLF.
368 S: 250 Some recipients OK
3729. Security Considerations
374 The size declaration extensions described in this memo can
375 conceivably be used to facilitate crude service denial attacks.
376 Specifically, both the information contained in the SIZE parameter
377 and use of the extended MAIL command make it somewhat quicker and
378 easier to devise an efficacious service denial attack. However,
379 unless implementations are very weak, these extensions do not create
380 any vulnerability that has not always existed with SMTP. In addition,
381 no issues are addressed involving trusted systems and possible
382 release of information via the mechanisms described in this RFC.
386 This document was derived from an earlier Working Group work in
387 progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot
388 Lear, Marshall T. Rose, and Einar Stefferud provided extensive
389 comments in response to earlier works in progress of both this and
394Klensin, et al Standards Track [Page 7]
396RFC 1870 SMTP Size Declaration November 1995
401 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
402 USC/Information Sciences Institute, August 1982.
404 [2] Crocker, D., "Standard for the Format of ARPA Internet Text
405 Messages", STD 11, RFC 822, UDEL, August 1982.
407 [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
408 Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
410 [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
411 Headers", RFC 1522, University of Tennessee, September 1993.
413 [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
414 "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
415 International, Inc., Dover Beach Consulting, Inc., Network
416 Management Associates, Inc., Brandenburg Consulting, November
419 [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
420 974, BBN, January 1986.
450Klensin, et al Standards Track [Page 8]
452RFC 1870 SMTP Size Declaration November 1995
45512. Chair, Editor, and Author Addresses
457 John Klensin, WG Chair
462 Phone: +1 703 715-7361
464 EMail: klensin@mci.net
468 Innosoft International, Inc.
469 1050 East Garvey Avenue South
470 West Covina, CA 91790
473 Phone: +1 818 919 3600
475 EMail: ned@innosoft.com
479 Computer Science Dept.
480 University of Tennessee
482 Knoxville, TN 37996-1301
485 EMail: moore@cs.utk.edu
506Klensin, et al Standards Track [Page 9]