| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group N. Freed |
| 8 | Request for Comments: 2920 Innosoft |
| 9 | STD: 60 September 2000 |
| 10 | Obsoletes: 2197 |
| 11 | Category: Standards Track |
| 12 | |
| 13 | |
| 14 | SMTP Service Extension for Command Pipelining |
| 15 | |
| 16 | Status of this Memo |
| 17 | |
| 18 | This document specifies an Internet standards track protocol for the |
| 19 | Internet community, and requests discussion and suggestions for |
| 20 | improvements. Please refer to the current edition of the "Internet |
| 21 | Official Protocol Standards" (STD 1) for the standardization state |
| 22 | and status of this protocol. Distribution of this memo is unlimited. |
| 23 | |
| 24 | Copyright Notice |
| 25 | |
| 26 | Copyright (C) The Internet Society (2000). All Rights Reserved. |
| 27 | |
| 28 | Abstract |
| 29 | |
| 30 | This memo defines an extension to the Simple Mail Transfer Protocol |
| 31 | (SMTP) service whereby a server can indicate the extent of its |
| 32 | ability to accept multiple commands in a single Transmission Control |
| 33 | Protocol (TCP) send operation. Using a single TCP send operation for |
| 34 | multiple commands can improve SMTP performance significantly. |
| 35 | |
| 36 | 1. Introduction |
| 37 | |
| 38 | Although SMTP is widely and robustly deployed, certain extensions may |
| 39 | nevertheless prove useful. In particular, many parts of the Internet |
| 40 | make use of high latency network links. SMTP's intrinsic one |
| 41 | command-one response structure is significantly penalized by high |
| 42 | latency links, often to the point where the factors contributing to |
| 43 | overall connection time are dominated by the time spent waiting for |
| 44 | responses to individual commands (turnaround time). |
| 45 | |
| 46 | In the best of all worlds it would be possible to simply deploy SMTP |
| 47 | client software that makes use of command pipelining: batching up |
| 48 | multiple commands into single TCP send operations. Unfortunately, the |
| 49 | original SMTP specification [RFC-821] did not explicitly state that |
| 50 | SMTP servers must support this. As a result a non-trivial number of |
| 51 | Internet SMTP servers cannot adequately handle command pipelining. |
| 52 | Flaws known to exist in deployed servers include: |
| 53 | |
| 54 | |
| 55 | |
| 56 | |
| 57 | |
| 58 | Freed Standards Track [Page 1] |
| 59 | |
| 60 | RFC 2920 SMTP for Command Pipelining September 2000 |
| 61 | |
| 62 | |
| 63 | (1) Connection handoff and buffer flushes in the middle of the |
| 64 | SMTP dialogue. Creation of server processes for incoming SMTP |
| 65 | connections is a useful, obvious, and harmless implementation |
| 66 | technique. However, some SMTP servers defer process forking |
| 67 | and connection handoff until some intermediate point in the |
| 68 | SMTP dialogue. When this is done material read from the TCP |
| 69 | connection and kept in process buffers can be lost. |
| 70 | |
| 71 | (2) Flushing the TCP input buffer when an SMTP command fails. SMTP |
| 72 | commands often fail but there is no reason to flush the TCP |
| 73 | input buffer when this happens. Nevertheless, some SMTP |
| 74 | servers do this. |
| 75 | |
| 76 | (3) Improper processing and promulgation of SMTP command failures. |
| 77 | For example, some SMTP servers will refuse to accept a DATA |
| 78 | command if the last RCPT TO command fails, paying no attention |
| 79 | to the success or failure of prior RCPT TO command results. |
| 80 | Other servers will accept a DATA command even when all |
| 81 | previous RCPT TO commands have failed. Although it is possible |
| 82 | to accommodate this sort of behavior in a client that employs |
| 83 | command pipelining, it does complicate the construction of the |
| 84 | client unnecessarily. |
| 85 | |
| 86 | This memo uses the mechanism described in [RFC-1869] to define an |
| 87 | extension to the SMTP service whereby an SMTP server can declare that |
| 88 | it is capable of handling pipelined commands. The SMTP client can |
| 89 | then check for this declaration and use pipelining only when the |
| 90 | server declares itself capable of handling it. |
| 91 | |
| 92 | 1.1. Requirements Notation |
| 93 | |
| 94 | This document occasionally uses terms that appear in capital letters. |
| 95 | When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" |
| 96 | appear capitalized, they are being used to indicate particular |
| 97 | requirements of this specification. A discussion of the meanings of |
| 98 | the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the |
| 99 | terms "MUST NOT" and "SHOULD NOT" are logical extensions of this |
| 100 | usage. |
| 101 | |
| 102 | 2. Framework for the Command Pipelining Extension |
| 103 | |
| 104 | The Command Pipelining extension is defined as follows: |
| 105 | |
| 106 | (1) the name of the SMTP service extension is Pipelining; |
| 107 | |
| 108 | (2) the EHLO keyword value associated with the extension is |
| 109 | PIPELINING; |
| 110 | |
| 111 | |
| 112 | |
| 113 | |
| 114 | Freed Standards Track [Page 2] |
| 115 | |
| 116 | RFC 2920 SMTP for Command Pipelining September 2000 |
| 117 | |
| 118 | |
| 119 | (3) no parameter is used with the PIPELINING EHLO keyword; |
| 120 | |
| 121 | (4) no additional parameters are added to either the MAIL FROM or |
| 122 | RCPT TO commands. |
| 123 | |
| 124 | (5) no additional SMTP verbs are defined by this extension; and, |
| 125 | |
| 126 | (6) the next section specifies how support for the extension |
| 127 | affects the behavior of a server and client SMTP. |
| 128 | |
| 129 | 3. The Pipelining Service Extension |
| 130 | |
| 131 | When a client SMTP wishes to employ command pipelining, it first |
| 132 | issues the EHLO command to the server SMTP. If the server SMTP |
| 133 | responds with code 250 to the EHLO command, and the response includes |
| 134 | the EHLO keyword value PIPELINING, then the server SMTP has indicated |
| 135 | that it can accommodate SMTP command pipelining. |
| 136 | |
| 137 | 3.1. Client use of pipelining |
| 138 | |
| 139 | Once the client SMTP has confirmed that support exists for the |
| 140 | pipelining extension, the client SMTP may then elect to transmit |
| 141 | groups of SMTP commands in batches without waiting for a response to |
| 142 | each individual command. In particular, the commands RSET, MAIL FROM, |
| 143 | SEND FROM, SOML FROM, SAML FROM, and RCPT TO can all appear anywhere |
| 144 | in a pipelined command group. The EHLO, DATA, VRFY, EXPN, TURN, |
| 145 | QUIT, and NOOP commands can only appear as the last command in a |
| 146 | group since their success or failure produces a change of state which |
| 147 | the client SMTP must accommodate. (NOOP is included in this group so |
| 148 | it can be used as a synchronization point.) |
| 149 | |
| 150 | Additional commands added by other SMTP extensions may only appear as |
| 151 | the last command in a group unless otherwise specified by the |
| 152 | extensions that define the commands. |
| 153 | |
| 154 | The actual transfer of message content is explicitly allowed to be |
| 155 | the first "command" in a group. That is, a RSET/MAIL FROM sequence |
| 156 | used to initiate a new message transaction can be placed in the same |
| 157 | group as the final transfer of the headers and body of the previous |
| 158 | message. |
| 159 | |
| 160 | Client SMTP implementations that employ pipelining MUST check ALL |
| 161 | statuses associated with each command in a group. For example, if |
| 162 | none of the RCPT TO recipient addresses were accepted the client must |
| 163 | then check the response to the DATA command -- the client cannot |
| 164 | assume that the DATA command will be rejected just because none of |
| 165 | the RCPT TO commands worked. If the DATA command was properly |
| 166 | rejected the client SMTP can just issue RSET, but if the DATA command |
| 167 | |
| 168 | |
| 169 | |
| 170 | Freed Standards Track [Page 3] |
| 171 | |
| 172 | RFC 2920 SMTP for Command Pipelining September 2000 |
| 173 | |
| 174 | |
| 175 | was accepted the client SMTP should send a single dot. |
| 176 | |
| 177 | Command statuses MUST be coordinated with responses by counting each |
| 178 | separate response and correlating that count with the number of |
| 179 | commands known to have been issued. Multiline responses MUST be |
| 180 | supported. Matching on the basis of either the error code value or |
| 181 | associated text is expressly forbidden. |
| 182 | |
| 183 | Client SMTP implementations MAY elect to operate in a nonblocking |
| 184 | fashion, processing server responses immediately upon receipt, even |
| 185 | if there is still data pending transmission from the client's |
| 186 | previous TCP send operation. If nonblocking operation is not |
| 187 | supported, however, client SMTP implementations MUST also check the |
| 188 | TCP window size and make sure that each group of commands fits |
| 189 | entirely within the window. The window size is usually, but not |
| 190 | always, 4K octets. Failure to perform this check can lead to |
| 191 | deadlock conditions. |
| 192 | |
| 193 | Clients MUST NOT confuse responses to multiple commands with |
| 194 | multiline responses. Each command requires one or more lines of |
| 195 | response, the last line not containing a dash between the response |
| 196 | code and the response string. |
| 197 | |
| 198 | 3.2. Server support of pipelining |
| 199 | |
| 200 | A server SMTP implementation that offers the pipelining extension: |
| 201 | |
| 202 | (1) MUST respond to commands in the order they are received from |
| 203 | the client. |
| 204 | |
| 205 | (2) SHOULD elect to store responses to grouped RSET, MAIL FROM, |
| 206 | SEND FROM, SOML FROM, SAML FROM, and RCPT TO commands in an |
| 207 | internal buffer so they can sent as a unit. |
| 208 | |
| 209 | (3) SHOULD issue a positive response to the DATA command if and |
| 210 | only if one or more valid RCPT TO addresses have been |
| 211 | previously received. |
| 212 | |
| 213 | (4) MUST NOT, after issuing a positive response to a DATA command |
| 214 | with no valid recipients and subsequently receiving an empty |
| 215 | message, send any message whatsoever to anybody. |
| 216 | |
| 217 | (5) MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, TURN, |
| 218 | QUIT, and NOOP. |
| 219 | |
| 220 | (6) MUST NOT buffer responses to unrecognized commands. |
| 221 | |
| 222 | |
| 223 | |
| 224 | |
| 225 | |
| 226 | Freed Standards Track [Page 4] |
| 227 | |
| 228 | RFC 2920 SMTP for Command Pipelining September 2000 |
| 229 | |
| 230 | |
| 231 | (7) MUST send all pending responses immediately whenever the local |
| 232 | TCP input buffer is emptied. |
| 233 | |
| 234 | (8) MUST NOT make assumptions about commands that are yet to be |
| 235 | received. |
| 236 | |
| 237 | (9) MUST NOT flush or otherwise lose the contents of the TCP input |
| 238 | buffer under any circumstances whatsoever. |
| 239 | |
| 240 | (10) SHOULD issue response text that indicates, either implicitly |
| 241 | or explicitly, what command the response matches. |
| 242 | |
| 243 | The overriding intent of these server requirements is to make it as |
| 244 | easy as possible for servers to conform to these pipelining |
| 245 | extensions. |
| 246 | |
| 247 | 4. Examples |
| 248 | |
| 249 | Consider the following SMTP dialogue that does not use pipelining: |
| 250 | |
| 251 | S: <wait for open connection> |
| 252 | C: <open connection to server> |
| 253 | S: 220 Innosoft.com SMTP service ready |
| 254 | C: HELO dbc.mtview.ca.us |
| 255 | S: 250 Innosoft.com |
| 256 | C: MAIL FROM:<mrose@dbc.mtview.ca.us> |
| 257 | S: 250 sender <mrose@dbc.mtview.ca.us> OK |
| 258 | C: RCPT TO:<ned@innosoft.com> |
| 259 | S: 250 recipient <ned@innosoft.com> OK |
| 260 | C: RCPT TO:<dan@innosoft.com> |
| 261 | S: 250 recipient <dan@innosoft.com> OK |
| 262 | C: RCPT TO:<kvc@innosoft.com> |
| 263 | S: 250 recipient <kvc@innosoft.com> OK |
| 264 | C: DATA |
| 265 | S: 354 enter mail, end with line containing only "." |
| 266 | ... |
| 267 | C: . |
| 268 | S: 250 message sent |
| 269 | C: QUIT |
| 270 | S: 221 goodbye |
| 271 | |
| 272 | The client waits for a server response a total of 9 times in this |
| 273 | simple example. But if pipelining is employed the following dialogue |
| 274 | is possible: |
| 275 | |
| 276 | S: <wait for open connection> |
| 277 | C: <open connection to server> |
| 278 | S: 220 innosoft.com SMTP service ready |
| 279 | |
| 280 | |
| 281 | |
| 282 | Freed Standards Track [Page 5] |
| 283 | |
| 284 | RFC 2920 SMTP for Command Pipelining September 2000 |
| 285 | |
| 286 | |
| 287 | C: EHLO dbc.mtview.ca.us |
| 288 | S: 250-innosoft.com |
| 289 | S: 250 PIPELINING |
| 290 | C: MAIL FROM:<mrose@dbc.mtview.ca.us> |
| 291 | C: RCPT TO:<ned@innosoft.com> |
| 292 | C: RCPT TO:<dan@innosoft.com> |
| 293 | C: RCPT TO:<kvc@innosoft.com> |
| 294 | C: DATA |
| 295 | S: 250 sender <mrose@dbc.mtview.ca.us> OK |
| 296 | S: 250 recipient <ned@innosoft.com> OK |
| 297 | S: 250 recipient <dan@innosoft.com> OK |
| 298 | S: 250 recipient <kvc@innosoft.com> OK |
| 299 | S: 354 enter mail, end with line containing only "." |
| 300 | ... |
| 301 | C: . |
| 302 | C: QUIT |
| 303 | S: 250 message sent |
| 304 | S: 221 goodbye |
| 305 | |
| 306 | The total number of turnarounds has been reduced from 9 to 4. |
| 307 | |
| 308 | The next example illustrates one possible form of behavior when |
| 309 | pipelining is used and all recipients are rejected: |
| 310 | |
| 311 | S: <wait for open connection> |
| 312 | C: <open connection to server> |
| 313 | S: 220 innosoft.com SMTP service ready |
| 314 | C: EHLO dbc.mtview.ca.us |
| 315 | S: 250-innosoft.com |
| 316 | S: 250 PIPELINING |
| 317 | C: MAIL FROM:<mrose@dbc.mtview.ca.us> |
| 318 | C: RCPT TO:<nsb@thumper.bellcore.com> |
| 319 | C: RCPT TO:<galvin@tis.com> |
| 320 | C: DATA |
| 321 | S: 250 sender <mrose@dbc.mtview.ca.us> OK |
| 322 | S: 550 remote mail to <nsb@thumper.bellore.com> not allowed |
| 323 | S: 550 remote mail to <galvin@tis.com> not allowed |
| 324 | S: 554 no valid recipients given |
| 325 | C: QUIT |
| 326 | S: 221 goodbye |
| 327 | |
| 328 | The client SMTP waits for the server 4 times here as well. If the |
| 329 | server SMTP does not check for at least one valid recipient prior to |
| 330 | accepting the DATA command, the following dialogue would result: |
| 331 | |
| 332 | S: <wait for open connection> |
| 333 | C: <open connection to server> |
| 334 | S: 220 innosoft.com SMTP service ready |
| 335 | |
| 336 | |
| 337 | |
| 338 | Freed Standards Track [Page 6] |
| 339 | |
| 340 | RFC 2920 SMTP for Command Pipelining September 2000 |
| 341 | |
| 342 | |
| 343 | C: EHLO dbc.mtview.ca.us |
| 344 | S: 250-innosoft.com |
| 345 | S: 250 PIPELINING |
| 346 | C: MAIL FROM:<mrose@dbc.mtview.ca.us> |
| 347 | C: RCPT TO:<nsb@thumper.bellcore.com> |
| 348 | C: RCPT TO:<galvin@tis.com> |
| 349 | C: DATA |
| 350 | S: 250 sender <mrose@dbc.mtview.ca.us> OK |
| 351 | S: 550 remote mail to <nsb@thumper.bellore.com> not allowed |
| 352 | S: 550 remote mail to <galvin@tis.com> not allowed |
| 353 | S: 354 enter mail, end with line containing only "." |
| 354 | C: . |
| 355 | C: QUIT |
| 356 | S: 554 no valid recipients |
| 357 | S: 221 goodbye |
| 358 | |
| 359 | 5. Security Considerations |
| 360 | |
| 361 | This RFC does not discuss security issues and is not believed |
| 362 | to raise any security issues not endemic in electronic mail |
| 363 | and present in fully conforming implementations of [RFC-821]. |
| 364 | |
| 365 | 6. Acknowledgements |
| 366 | |
| 367 | This document is based on the SMTP service extension model |
| 368 | presented in RFC 1425. Marshall Rose's description of SMTP |
| 369 | command pipelining in his book "The Internet Message" also |
| 370 | served as a source of inspiration for this extension. |
| 371 | |
| 372 | 7. References |
| 373 | |
| 374 | [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC |
| 375 | 821, August 1982. |
| 376 | |
| 377 | [RFC-1123] Braden, R., "Requirements for Internet Hosts -- |
| 378 | Application and Support", STD 3, RFC 1123, October, 1989. |
| 379 | |
| 380 | [RFC-1854] Freed, N., "SMTP Service Extension for Command |
| 381 | Pipelining", RFC 1854, October 1995. |
| 382 | |
| 383 | [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. |
| 384 | Crocker, "SMTP Service Extensions", STD 10, RFC 1869, |
| 385 | November 1995. |
| 386 | |
| 387 | [RFC-2197] Freed, N., "SMTP Service Extension for Command |
| 388 | Pipelining", RFC 2197, September 1997. |
| 389 | |
| 390 | |
| 391 | |
| 392 | |
| 393 | |
| 394 | Freed Standards Track [Page 7] |
| 395 | |
| 396 | RFC 2920 SMTP for Command Pipelining September 2000 |
| 397 | |
| 398 | |
| 399 | 8. Author's Address |
| 400 | |
| 401 | Ned Freed |
| 402 | Innosoft International, Inc. |
| 403 | 1050 Lakes Drive |
| 404 | West Covina, CA 91790 |
| 405 | USA |
| 406 | |
| 407 | Phone: +1 626 919 3600 |
| 408 | Fax: +1 626 919 361 |
| 409 | EMail: ned.freed@innosoft.com |
| 410 | |
| 411 | This document is a product of work done by the Internet Engineering |
| 412 | Task Force Working Group on Messaging Extensions, Alan Cargille, |
| 413 | chair. |
| 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 | Freed Standards Track [Page 8] |
| 451 | |
| 452 | RFC 2920 SMTP for Command Pipelining September 2000 |
| 453 | |
| 454 | |
| 455 | 9. Full Copyright Statement |
| 456 | |
| 457 | Copyright (C) The Internet Society (2000). All Rights Reserved. |
| 458 | |
| 459 | This document and translations of it may be copied and furnished to |
| 460 | others, and derivative works that comment on or otherwise explain it |
| 461 | or assist in its implementation may be prepared, copied, published |
| 462 | and distributed, in whole or in part, without restriction of any |
| 463 | kind, provided that the above copyright notice and this paragraph are |
| 464 | included on all such copies and derivative works. However, this |
| 465 | document itself may not be modified in any way, such as by removing |
| 466 | the copyright notice or references to the Internet Society or other |
| 467 | Internet organizations, except as needed for the purpose of |
| 468 | developing Internet standards in which case the procedures for |
| 469 | copyrights defined in the Internet Standards process must be |
| 470 | followed, or as required to translate it into languages other than |
| 471 | English. |
| 472 | |
| 473 | The limited permissions granted above are perpetual and will not be |
| 474 | revoked by the Internet Society or its successors or assigns. |
| 475 | |
| 476 | This document and the information contained herein is provided on an |
| 477 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
| 478 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
| 479 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
| 480 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
| 481 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
| 482 | |
| 483 | |
| 484 | |
| 485 | Acknowledgement |
| 486 | |
| 487 | Funding for the RFC Editor function is currently provided by the |
| 488 | Internet Society. |
| 489 | |
| 490 | |
| 491 | |
| 492 | |
| 493 | |
| 494 | |
| 495 | |
| 496 | |
| 497 | |
| 498 | |
| 499 | |
| 500 | |
| 501 | |
| 502 | |
| 503 | |
| 504 | |
| 505 | |
| 506 | Freed Standards Track [Page 9] |
| 507 | |