idnits 2.17.1 draft-freed-smtp-pipe-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-2197], [RFC-1854]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 167: '...ions that employ pipelining MUST check...' RFC 2119 keyword, line 177: '...Command statuses MUST be coordinated w...' RFC 2119 keyword, line 180: '...tiline responses MUST be supported. Ma...' RFC 2119 keyword, line 184: '... implementations MAY elect to operate ...' RFC 2119 keyword, line 189: '...implementations MUST also check the TC...' (11 more instances...) -- The draft header indicates that this document obsoletes RFC1854, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2197, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 398 has weird spacing: '...rnished to ot...' == Line 399 has weird spacing: '...herwise expla...' == Line 401 has weird spacing: '...without restr...' == Line 402 has weird spacing: '... notice and t...' == Line 404 has weird spacing: '... in any way, ...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2000) is 8802 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1854 (Obsoleted by RFC 2197) ** Obsolete normative reference: RFC 1869 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2197 (Obsoleted by RFC 2920) Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ned Freed 2 Internet Draft Innosoft 3 Obsoletes: 2197, 1854 5 SMTP Service Extension 6 for Command Pipelining 8 March 2000 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed 30 at http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2000). All Rights 35 Reserved. 37 1. Abstract 39 This memo defines an extension to the SMTP service whereby a 40 server can indicate the extent of its ability to accept 41 multiple commands in a single TCP send operation. Using a 42 single TCP send operation for multiple commands can improve 43 SMTP performance significantly. 45 The present document is an updated version of [RFC-2197], 46 which in turn was a revision of [RFC-1854]. Only textual and 47 editorial changes have been made; the protocol has not changed 48 in any way. 50 2. Introduction 52 Although SMTP is widely and robustly deployed, certain 53 extensions may nevertheless prove useful. In particular, many 54 parts of the Internet make use of high latency network links. 55 SMTP's intrinsic one command-one response structure is 56 significantly penalized by high latency links, often to the 57 point where the factors contributing to overall connection 58 time are dominated by the time spent waiting for responses to 59 individual commands (turnaround time). 61 In the best of all worlds it would be possible to simply 62 deploy SMTP client software that makes use of command 63 pipelining: batching up multiple commands into single TCP send 64 operations. Unfortunately, the original SMTP specification 65 [RFC-821] did not explicitly state that SMTP servers must 66 support this. As a result a non-trivial number of Internet 67 SMTP servers cannot adequately handle command pipelining. 68 Flaws known to exist in deployed servers include: 70 (1) Connection handoff and buffer flushes in the middle of 71 the SMTP dialogue. Creation of server processes for 72 incoming SMTP connections is a useful, obvious, and 73 harmless implementation technique. However, some SMTP 74 servers defer process forking and connection handoff 75 until some intermediate point in the SMTP dialogue. 76 When this is done material read from the TCP connection 77 and kept in process buffers can be lost. 79 (2) Flushing the TCP input buffer when an SMTP command 80 fails. SMTP commands often fail but there is no reason 81 to flush the TCP input buffer when this happens. 82 Nevertheless, some SMTP servers do this. 84 (3) Improper processing and promulgation of SMTP command 85 failures. For example, some SMTP servers will refuse to 86 accept a DATA command if the last RCPT TO command 87 fails, paying no attention to the success or failure of 88 prior RCPT TO command results. Other servers will 90 accept a DATA command even when all previous RCPT TO commands 91 have failed. Although it is possible to accommodate 92 this sort of behavior in a client that employs command 93 pipelining, it does complicate the construction of the 94 client unnecessarily. 96 This memo uses the mechanism described in [RFC-1869] to define 97 an extension to the SMTP service whereby an SMTP server can 98 declare that it is capable of handling pipelined commands. The 99 SMTP client can then check for this declaration and use 100 pipelining only when the server declares itself capable of 101 handling it. 103 2.1. Requirements Notation 105 This document occasionally uses terms that appear in capital 106 letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD 107 NOT", and "MAY" appear capitalized, they are being used to 108 indicate particular requirements of this specification. A 109 discussion of the meanings of the terms "MUST", "SHOULD", and 110 "MAY" appears in [RFC-1123]; the terms "MUST NOT" and "SHOULD 111 NOT" are logical extensions of this usage. 113 3. Framework for the Command Pipelining Extension 115 The Command Pipelining extension is defined as follows: 117 (1) the name of the SMTP service extension is Pipelining; 119 (2) the EHLO keyword value associated with the extension is 120 PIPELINING; 122 (3) no parameter is used with the PIPELINING EHLO keyword; 124 (4) no additional parameters are added to either the MAIL 125 FROM or RCPT TO commands. 127 (5) no additional SMTP verbs are defined by this extension; 128 and, 130 (6) the next section specifies how support for the 131 extension affects the behavior of a server and client 132 SMTP. 134 4. The Pipelining Service Extension 136 When a client SMTP wishes to employ command pipelining, it 137 first issues the EHLO command to the server SMTP. If the 138 server SMTP responds with code 250 to the EHLO command, and 139 the response includes the EHLO keyword value PIPELINING, then 140 the server SMTP has indicated that it can accommodate SMTP 141 command pipelining. 143 4.1. Client use of pipelining 145 Once the client SMTP has confirmed that support exists for the 146 pipelining extension, the client SMTP may then elect to 147 transmit groups of SMTP commands in batches without waiting 148 for a response to each individual command. In particular, the 149 commands RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, and 150 RCPT TO can all appear anywhere in a pipelined command group. 151 The EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP commands can 152 only appear as the last command in a group since their success 153 or failure produces a change of state which the client SMTP 154 must accommodate. (NOOP is included in this group so it can be 155 used as a synchronization point.) 157 Additional commands added by other SMTP extensions may only 158 appear as the last command in a group unless otherwise 159 specified by the extensions that define the commands. 161 The actual transfer of message content is explicitly allowed 162 to be the first "command" in a group. That is, a RSET/MAIL 163 FROM sequence used to initiate a new message transaction can 164 be placed in the same group as the final transfer of the 165 headers and body of the previous message. 167 Client SMTP implementations that employ pipelining MUST check 168 ALL statuses associated with each command in a group. For 169 example, if none of the RCPT TO recipient addresses were 170 accepted the client must then check the response to the DATA 171 command -- the client cannot assume that the DATA command will 172 be rejected just because none of the RCPT TO commands worked. 173 If the DATA command was properly rejected the client SMTP can 174 just issue RSET, but if the DATA command was accepted the 175 client SMTP should send a single dot. 177 Command statuses MUST be coordinated with responses by 178 counting each separate response and correlating that count 179 with the number of commands known to have been issued. 180 Multiline responses MUST be supported. Matching on the basis 181 of either the error code value or associated text is expressly 182 forbidden. 184 Client SMTP implementations MAY elect to operate in a 185 nonblocking fashion, processing server responses immediately 186 upon receipt, even if there is still data pending transmission 187 from the client's previous TCP send operation. If nonblocking 188 operation is not supported, however, client SMTP 189 implementations MUST also check the TCP window size and make 190 sure that each group of commands fits entirely within the 191 window. The window size is usually, but not always, 4K octets. 192 Failure to perform this check can lead to deadlock conditions. 194 Clients MUST NOT confuse responses to multiple commands with 195 multiline responses. Each command requires one or more lines 196 of response, the last line not containing a dash between the 197 response code and the response string. 199 4.2. Server support of pipelining 201 A server SMTP implementation that offers the pipelining 202 extension: 204 (1) MUST respond to commands in the order they are received 205 from the client. 207 (2) SHOULD elect to store responses to grouped RSET, MAIL 208 FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO 209 commands in an internal buffer so they can sent as a 210 unit. 212 (3) SHOULD issue a positive response to the DATA command if 213 and only if one or more valid RCPT TO addresses have 214 been previously received. 216 (4) MUST NOT, after issuing a positive response to a DATA 217 command with no valid recipients and subsequently 218 receiving an empty message, send any message whatsoever 219 to anybody. 221 (5) MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, 222 TURN, QUIT, and NOOP. 224 (6) MUST NOT buffer responses to unrecognized commands. 226 (7) MUST send all pending responses immediately whenever 227 the local TCP input buffer is emptied. 229 (8) MUST NOT make assumptions about commands that are yet 230 to be received. 232 (9) MUST NOT flush or otherwise lose the contents of the 233 TCP input buffer under any circumstances whatsoever. 235 (10) SHOULD issue response text that indicates, either 236 implicitly or explicitly, what command the response 237 matches. 239 The overriding intent of these server requirements is to make 240 it as easy as possible for servers to conform to these 241 pipelining extensions. 243 5. Examples 245 Consider the following SMTP dialogue that does not use 246 pipelining: 248 S: 249 C: 250 S: 220 innosoft.com SMTP service ready 251 C: HELO dbc.mtview.ca.us 252 S: 250 innosoft.com 253 C: MAIL FROM: 254 S: 250 sender OK 255 C: RCPT TO: 256 S: 250 recipient OK 257 C: RCPT TO: 258 S: 250 recipient OK 259 C: RCPT TO: 260 S: 250 recipient OK 261 C: DATA 262 S: 354 enter mail, end with line containing only "." 263 ... 264 C: . 266 S: 250 message sent 267 C: QUIT 268 S: 221 goodbye 270 The client waits for a server response a total of 9 times in 271 this simple example. But if pipelining is employed the 272 following dialogue is possible: 274 S: 275 C: 276 S: 220 innosoft.com SMTP service ready 277 C: EHLO dbc.mtview.ca.us 278 S: 250-innosoft.com 279 S: 250 PIPELINING 280 C: MAIL FROM: 281 C: RCPT TO: 282 C: RCPT TO: 283 C: RCPT TO: 284 C: DATA 285 S: 250 sender OK 286 S: 250 recipient OK 287 S: 250 recipient OK 288 S: 250 recipient OK 289 S: 354 enter mail, end with line containing only "." 290 ... 291 C: . 292 C: QUIT 293 S: 250 message sent 294 S: 221 goodbye 296 The total number of turnarounds has been reduced from 9 to 4. 298 The next example illustrates one possible form of behavior 299 when pipelining is used and all recipients are rejected: 301 S: 302 C: 303 S: 220 innosoft.com SMTP service ready 304 C: EHLO dbc.mtview.ca.us 305 S: 250-innosoft.com 306 S: 250 PIPELINING 307 C: MAIL FROM: 308 C: RCPT TO: 309 C: RCPT TO: 310 C: DATA 311 S: 250 sender OK 312 S: 550 remote mail to not allowed 313 S: 550 remote mail to not allowed 314 S: 554 no valid recipients given 315 C: QUIT 316 S: 221 goodbye 318 The client SMTP waits for the server 4 times here as well. If 319 the server SMTP does not check for at least one valid 320 recipient prior to accepting the DATA command, the following 321 dialogue would result: 323 S: 324 C: 325 S: 220 innosoft.com SMTP service ready 326 C: EHLO dbc.mtview.ca.us 327 S: 250-innosoft.com 328 S: 250 PIPELINING 329 C: MAIL FROM: 330 C: RCPT TO: 331 C: RCPT TO: 332 C: DATA 333 S: 250 sender OK 334 S: 550 remote mail to not allowed 335 S: 550 remote mail to not allowed 336 S: 354 enter mail, end with line containing only "." 337 C: . 338 C: QUIT 339 S: 554 no valid recipients 340 S: 221 goodbye 342 6. Security Considerations 344 This RFC does not discuss security issues and is not believed 345 to raise any security issues not endemic in electronic mail 346 and present in fully conforming implementations of [RFC-821]. 348 7. Acknowledgements 350 This document is based on the SMTP service extension model 351 presented in RFC 1425. Marshall Rose's description of SMTP 352 command pipelining in his book "The Internet Message" also 353 served as a source of inspiration for this extension. 355 8. References 357 [RFC-821] 358 Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 359 821, August, 1982. 361 [RFC-1123] 362 Braden, R., "Requirements for Internet Hosts -- 363 Application and Support", STD 3, RFC 1123, October, 1989. 365 [RFC-1854] 366 Freed, N., "SMTP Service Extension for Command 367 Pipelining", RFC 1854, October, 1995. 369 [RFC-1869] 370 "Klensin, J., Freed, N., Rose, M., Stefferud, E., 371 Crocker, D., "SMTP Service Extensions", STD 10, RFC 1869, 372 November, 1995. 374 [RFC-2197] 375 Freed, N., "SMTP Service Extension for Command 376 Pipelining", RFC 2197, September, 1997. 378 9. Author's Address 380 Ned Freed 381 Innosoft International, Inc. 382 1050 Lakes Drive 383 West Covina, CA 91790 384 USA 385 tel: +1 626 919 3600 fax: +1 626 919 3614 386 email: ned.freed@innosoft.com 388 This document is a product of work done by the Internet 389 Engineering Task Force Working Group on Messaging Extensions, 390 Alan Cargille, chair. 392 10. Full Copyright Statement 394 Copyright (C) The Internet Society (2000). All Rights 395 Reserved. 397 This document and translations of it may be copied and 398 furnished to others, and derivative works that comment on or 399 otherwise explain it or assist in its implementation may be 400 prepared, copied, published and distributed, in whole or in 401 part, without restriction of any kind, provided that the 402 above copyright notice and this paragraph are included on all 403 such copies and derivative works. However, this document 404 itself may not be modified in any way, such as by removing 405 the copyright notice or references to the Internet Society or 406 other Internet organizations, except as needed for the purpose 407 of developing Internet standards in which case the procedures 408 for copyrights defined in the Internet Standards process must 409 be followed, or as required to translate it into languages 410 other than English. 412 The limited permissions granted above are perpetual and will 413 not be revoked by the Internet Society or its successors or 414 assigns. 416 This document and the information contained herein is provided 417 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 418 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 419 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 420 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 421 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 422 PARTICULAR PURPOSE.