| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group J. Klensin, WG Chair |
| 8 | Request For Comments: 1870 MCI |
| 9 | STD: 10 N. Freed, Editor |
| 10 | Obsoletes: 1653 Innosoft International, Inc. |
| 11 | Category: Standards Track K. Moore |
| 12 | University of Tennessee |
| 13 | November 1995 |
| 14 | |
| 15 | |
| 16 | SMTP Service Extension |
| 17 | for Message Size Declaration |
| 18 | |
| 19 | Status 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 | |
| 27 | 1. 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 | |
| 34 | 2. 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 | |
| 58 | Klensin, et al Standards Track [Page 1] |
| 59 | |
| 60 | RFC 1870 SMTP Size Declaration November 1995 |
| 61 | |
| 62 | |
| 63 | 3. 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"; |
| 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] |
| 78 | |
| 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 |
| 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 |
| 91 | |
| 92 | (5) the maximum length of a MAIL FROM command line is increased by 26 |
| 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 | |
| 101 | 4. 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 | |
| 114 | Klensin, et al Standards Track [Page 2] |
| 115 | |
| 116 | RFC 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. |
| 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 | |
| 146 | 5. 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 | |
| 170 | Klensin, et al Standards Track [Page 3] |
| 171 | |
| 172 | RFC 1870 SMTP Size Declaration November 1995 |
| 173 | |
| 174 | |
| 175 | 6. 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 | |
| 204 | 6.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 | |
| 226 | Klensin, et al Standards Track [Page 4] |
| 227 | |
| 228 | RFC 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 | |
| 240 | 6.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 | |
| 265 | 6.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 | |
| 282 | Klensin, et al Standards Track [Page 5] |
| 283 | |
| 284 | RFC 1870 SMTP Size Declaration November 1995 |
| 285 | |
| 286 | |
| 287 | 6.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 | |
| 299 | 7. 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 | |
| 338 | Klensin, et al Standards Track [Page 6] |
| 339 | |
| 340 | RFC 1870 SMTP Size Declaration November 1995 |
| 341 | |
| 342 | |
| 343 | 8. 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 | |
| 372 | 9. 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 | |
| 384 | 10. 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 | |
| 394 | Klensin, et al Standards Track [Page 7] |
| 395 | |
| 396 | RFC 1870 SMTP Size Declaration November 1995 |
| 397 | |
| 398 | |
| 399 | 11. 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 | |
| 450 | Klensin, et al Standards Track [Page 8] |
| 451 | |
| 452 | RFC 1870 SMTP Size Declaration November 1995 |
| 453 | |
| 454 | |
| 455 | 12. 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 | |
| 506 | Klensin, et al Standards Track [Page 9] |
| 507 | |