7Network Working Group N. Freed
8Request for Comments: 2920 Innosoft
11Category: Standards Track
14 SMTP Service Extension for Command Pipelining
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.
26 Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
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).
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:
58Freed Standards Track [Page 1]
60RFC 2920 SMTP for Command Pipelining September 2000
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.
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
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
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.
921.1. Requirements Notation
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
1022. Framework for the Command Pipelining Extension
104 The Command Pipelining extension is defined as follows:
106 (1) the name of the SMTP service extension is Pipelining;
114Freed Standards Track [Page 2]
116RFC 2920 SMTP for Command Pipelining September 2000
119 (3) no parameter is used with the PIPELINING EHLO keyword;
121 (4) no additional parameters are added to either the MAIL FROM or
124 (5) no additional SMTP verbs are defined by this extension; and,
126 (6) the next section specifies how support for the extension
127 affects the behavior of a server and client SMTP.
1293. The Pipelining Service Extension
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.
1373.1. Client use of pipelining
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.)
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.
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
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
170Freed Standards Track [Page 3]
172RFC 2920 SMTP for Command Pipelining September 2000
175 was accepted the client SMTP should send a single dot.
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.
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
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.
1983.2. Server support of pipelining
200 A server SMTP implementation that offers the pipelining extension:
202 (1) MUST respond to commands in the order they are received from
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.
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
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.
217 (5) MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, TURN,
220 (6) MUST NOT buffer responses to unrecognized commands.
226Freed Standards Track [Page 4]
228RFC 2920 SMTP for Command Pipelining September 2000
231 (7) MUST send all pending responses immediately whenever the local
232 TCP input buffer is emptied.
234 (8) MUST NOT make assumptions about commands that are yet to be
237 (9) MUST NOT flush or otherwise lose the contents of the TCP input
238 buffer under any circumstances whatsoever.
240 (10) SHOULD issue response text that indicates, either implicitly
241 or explicitly, what command the response matches.
243 The overriding intent of these server requirements is to make it as
244 easy as possible for servers to conform to these pipelining
249 Consider the following SMTP dialogue that does not use pipelining:
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
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
265 S: 354 enter mail, end with line containing only "."
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
276 S: <wait for open connection>
277 C: <open connection to server>
278 S: 220 innosoft.com SMTP service ready
282Freed Standards Track [Page 5]
284RFC 2920 SMTP for Command Pipelining September 2000
287 C: EHLO dbc.mtview.ca.us
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>
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 "."
306 The total number of turnarounds has been reduced from 9 to 4.
308 The next example illustrates one possible form of behavior when
309 pipelining is used and all recipients are rejected:
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
317 C: MAIL FROM:<mrose@dbc.mtview.ca.us>
318 C: RCPT TO:<nsb@thumper.bellcore.com>
319 C: RCPT TO:<galvin@tis.com>
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
329 server SMTP does not check for at least one valid recipient prior to
330 accepting the DATA command, the following dialogue would result:
332 S: <wait for open connection>
333 C: <open connection to server>
334 S: 220 innosoft.com SMTP service ready
338Freed Standards Track [Page 6]
340RFC 2920 SMTP for Command Pipelining September 2000
343 C: EHLO dbc.mtview.ca.us
346 C: MAIL FROM:<mrose@dbc.mtview.ca.us>
347 C: RCPT TO:<nsb@thumper.bellcore.com>
348 C: RCPT TO:<galvin@tis.com>
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 "."
356 S: 554 no valid recipients
3595. Security Considerations
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].
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.
374 [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
377 [RFC-1123] Braden, R., "Requirements for Internet Hosts --
378 Application and Support", STD 3, RFC 1123, October, 1989.
380 [RFC-1854] Freed, N., "SMTP Service Extension for Command
381 Pipelining", RFC 1854, October 1995.
383 [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
384 Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
387 [RFC-2197] Freed, N., "SMTP Service Extension for Command
388 Pipelining", RFC 2197, September 1997.
394Freed Standards Track [Page 7]
396RFC 2920 SMTP for Command Pipelining September 2000
402 Innosoft International, Inc.
404 West Covina, CA 91790
407 Phone: +1 626 919 3600
409 EMail: ned.freed@innosoft.com
411 This document is a product of work done by the Internet Engineering
412 Task Force Working Group on Messaging Extensions, Alan Cargille,
450Freed Standards Track [Page 8]
452RFC 2920 SMTP for Command Pipelining September 2000
4559. Full Copyright Statement
457 Copyright (C) The Internet Society (2000). All Rights Reserved.
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
473 The limited permissions granted above are perpetual and will not be
474 revoked by the Internet Society or its successors or assigns.
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.
487 Funding for the RFC Editor function is currently provided by the
506Freed Standards Track [Page 9]