File: rfc1870.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (507 lines) | stat: -rw-r--r-- 18,226 bytes parent folder | download | duplicates (12)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
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
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507






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]