1
2
3
4
5
6
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
13 November 1995
14
15
16 SMTP Service Extension
17 for Message Size Declaration
18
19Status of this Memo
20
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.
26
271. Abstract
28
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.
33
342. Introduction
35
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.
42
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").
50
51
52
53
54
55
56
57
58Klensin, et al Standards Track [Page 1]
59
60RFC 1870 SMTP Size Declaration November 1995
61
62
633. Framework for the Size Declaration Extension
64
65 The following service extension is therefore defined:
66
67 (1) the name of the SMTP service extension is "Message Size
68 Declaration";
69
70 (2) the EHLO keyword value associated with this extension is "SIZE"; ../smtpserver/server.go:884
71
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]:
76
77 size-param ::= [1*DIGIT] ../smtpclient/client.go:747
78
79 A parameter value of 0 (zero) indicates that no fixed maximum ../smtpclient/client.go:1154
80 message size is in force. If the parameter is omitted no
81 information is conveyed about the server's fixed maximum message
82 size;
83
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]:
89
90 size-value ::= 1*20DIGIT ../smtpserver/server.go:1399
91
92 (5) the maximum length of a MAIL FROM command line is increased by 26 5321:3500 4954:134 6152:90 6531:231 ../smtpserver/server.go:1350
93 characters by the possible addition of the SIZE keyword and
94 value;
95
96 (6) no additional SMTP verbs are defined by this extension.
97
98 The remainder of this memo specifies how support for the extension
99 affects the behavior of an SMTP client and server.
100
1014. The Message Size Declaration service extension
102
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.
109
110
111
112
113
114Klensin, et al Standards Track [Page 2]
115
116RFC 1870 SMTP Size Declaration November 1995
117
118
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
124 attempted.
125
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.
131
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
136 permanent failure (552) reply code. 3463:382 ../smtpserver/server.go:1401 ../smtpserver/server.go:1769
137
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.
145
1465. Definitions
147
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.
152
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.
159
160 The declared message size is defined as a client's estimate of the
161 message size for a particular message.
162
163
164
165
166
167
168
169
170Klensin, et al Standards Track [Page 3]
171
172RFC 1870 SMTP Size Declaration November 1995
173
174
1756. The extended MAIL command
176
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.
181
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.
185
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
191 single MAIL command.
192
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
199 academic point.)
200
201 NOTE: Servers MUST NOT use the SIZE parameter to determine end of
202 content in the DATA command.
203
2046.1 Server action on receipt of the extended MAIL command
205
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
213 recipients.
214
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:
218
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
222 system storage".
223
224
225
226Klensin, et al Standards Track [Page 4]
227
228RFC 1870 SMTP Size Declaration November 1995
229
230
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".
234
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.
239
2406.2 Client action on receiving response to extended MAIL command
241
242 The client, upon receiving the server's response to the extended MAIL
243 command, acts as follows:
244
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
249 at a later time.
250
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).
257
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.
264
2656.3 Messages larger than the declared size.
266
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.
273
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.
279
280
281
282Klensin, et al Standards Track [Page 5]
283
284RFC 1870 SMTP Size Declaration November 1995
285
286
2876.4 Per-recipient rejection based on message size.
288
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.
292
293 (1) If a 452 code is returned, the client may requeue the message for
294 later delivery to the same recipient.
295
296 (2) If a 552 code is returned, the client may not requeue the message
297 for later delivery to the same recipient.
298
2997. Minimal usage
300
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
309 message size.
310
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.
318
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
329 message.
330
331
332
333
334
335
336
337
338Klensin, et al Standards Track [Page 6]
339
340RFC 1870 SMTP Size Declaration November 1995
341
342
3438. Example
344
345 The following example illustrates the use of size declaration with
346 some permanent and temporary failures.
347
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
353 S: 250-EXPN
354 S: 250-HELP
355 S: 250 SIZE 1000000
356 C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
357 S: 250 Address Ok.
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
364 C: DATA
365 S: 354 Send message, ending in CRLF.CRLF.
366 ...
367 C: .
368 S: 250 Some recipients OK
369 C: QUIT
370 S: 221 Goodbye
371
3729. Security Considerations
373
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.
383
38410. Acknowledgements
385
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
390 the previous memo.
391
392
393
394Klensin, et al Standards Track [Page 7]
395
396RFC 1870 SMTP Size Declaration November 1995
397
398
39911. References
400
401 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
402 USC/Information Sciences Institute, August 1982.
403
404 [2] Crocker, D., "Standard for the Format of ARPA Internet Text
405 Messages", STD 11, RFC 822, UDEL, August 1982.
406
407 [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
408 Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
409
410 [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
411 Headers", RFC 1522, University of Tennessee, September 1993.
412
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
417 1995.
418
419 [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
420 974, BBN, January 1986.
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450Klensin, et al Standards Track [Page 8]
451
452RFC 1870 SMTP Size Declaration November 1995
453
454
45512. Chair, Editor, and Author Addresses
456
457 John Klensin, WG Chair
458 MCI
459 2100 Reston Parkway
460 Reston, VA 22091
461
462 Phone: +1 703 715-7361
463 Fax: +1 703 715-7436
464 EMail: klensin@mci.net
465
466
467 Ned Freed, Editor
468 Innosoft International, Inc.
469 1050 East Garvey Avenue South
470 West Covina, CA 91790
471 USA
472
473 Phone: +1 818 919 3600
474 Fax: +1 818 919 3614
475 EMail: ned@innosoft.com
476
477
478 Keith Moore
479 Computer Science Dept.
480 University of Tennessee
481 107 Ayres Hall
482 Knoxville, TN 37996-1301
483 USA
484
485 EMail: moore@cs.utk.edu
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506Klensin, et al Standards Track [Page 9]
507
508