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