rfcs/rfc2920.txt -rw-r--r-- 16.7 KiB
1
2
3
4
5
6
7Network Working Group N. Freed
8Request for Comments: 2920 Innosoft
9STD: 60 September 2000
10Obsoletes: 2197
11Category: Standards Track
12
13
14 SMTP Service Extension for Command Pipelining
15
16Status 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
24Copyright Notice
25
26 Copyright (C) The Internet Society (2000). All Rights Reserved.
27
28Abstract
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
361. 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
58Freed Standards Track [Page 1]
59
60RFC 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
921.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
1022. 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
114Freed Standards Track [Page 2]
115
116RFC 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
1293. 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
1373.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
170Freed Standards Track [Page 3]
171
172RFC 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
1983.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
226Freed Standards Track [Page 4]
227
228RFC 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
2474. 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
282Freed Standards Track [Page 5]
283
284RFC 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
338Freed Standards Track [Page 6]
339
340RFC 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
3595. 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
3656. 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
3727. 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
394Freed Standards Track [Page 7]
395
396RFC 2920 SMTP for Command Pipelining September 2000
397
398
3998. 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
450Freed Standards Track [Page 8]
451
452RFC 2920 SMTP for Command Pipelining September 2000
453
454
4559. 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
485Acknowledgement
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
506Freed Standards Track [Page 9]
507