RFC 2920

SMTP Service Extension for Command Pipelining

📅 published September 2000, from ietf

Title Block 🎀

Okay bestie, let's start with the vibes ✨ This is RFC 2920, SMTP Service Extension for Command Pipelining, written by N. Freed at Innosoft and published by the Network Working Group in September 2000. It's a Standards Track document (STD 60), and it obsoletes RFC 2197 💖

Status of This Memo 🌸

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🦋

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that lets a server say how well it can accept multiple commands in a single Transmission Control Protocol (TCP) send operation 🚀 Sending several commands in one TCP send can seriously boost SMTP performance.

1. Introduction ✨

Okay so SMTP is literally everywhere and super reliable 💅 but some extensions could still be really useful 🧚 A lot of the Internet runs over high latency links, and SMTP's whole thing is one command, one response. On a slow link, the connection time gets eaten up by waiting for each reply (that's the turnaround time) 😭

In a perfect world, SMTP clients could just batch multiple commands into single TCP send operations. That's command pipelining 🍓 The catch is that the original SMTP spec [RFC-821] never explicitly said servers have to support it. So a bunch of real SMTP servers can't handle pipelining properly 💀 Here are the known flaws in deployed servers:

  1. Connection handoff and buffer flushes in the middle of the dialogue. Forking off a server process for each incoming connection is a totally normal, obvious, harmless trick. But some servers wait to fork and hand off the connection until a later point in the SMTP dialogue. When that happens, data already read from the TCP connection and sitting in process buffers can get lost.
  2. Flushing the TCP input buffer when a command fails. Commands fail all the time, but there's no good reason to flush the TCP input buffer when they do. Some servers do it anyway 🙈
  3. Messy handling of command failures. For example, some servers refuse a DATA command if the last RCPT TO failed, ignoring whether the earlier RCPT TO commands worked. Others accept DATA even when every previous RCPT TO failed. A pipelining client can handle that behavior, but it makes the client way more complicated than it needs to be 😤

This memo uses the mechanism described in [RFC-1869] to define an SMTP service extension where a server can declare that it's capable of handling pipelined commands 🫶 The client checks for that declaration and only pipelines when the server says it's ready.

1.1. Requirements Notation 📝

This document occasionally uses terms that appear in capital letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" appear capitalized, they're being used to indicate particular requirements of this specification. A discussion of the meanings of the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]. The terms "MUST NOT" and "SHOULD NOT" are logical extensions of this usage 💜

2. Framework for the Command Pipelining Extension 🎀

The Command Pipelining extension is defined like this:

  1. the name of the SMTP service extension is Pipelining;
  2. the EHLO keyword value associated with the extension is PIPELINING;
  3. no parameter is used with the PIPELINING EHLO keyword;
  4. no additional parameters are added to either the MAIL FROM or RCPT TO commands.
  5. no additional SMTP verbs are defined by this extension; and,
  6. the next section specifies how support for the extension affects the behavior of a server and client SMTP.

3. The Pipelining Service Extension 🦋

When a client SMTP wants to use command pipelining, it first sends the EHLO command to the server SMTP. If the server SMTP replies with code 250 to EHLO, and the reply includes the EHLO keyword value PIPELINING, then the server SMTP has indicated that it can accommodate SMTP command pipelining 🎉

3.1. Client use of pipelining 💜

Once the client SMTP has confirmed that the pipelining extension is supported, it can choose to send groups of SMTP commands in batches without waiting for a response to each individual command 🚀 Specifically, RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO can all appear anywhere in a pipelined command group. EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP can only be the last command in a group, since their success or failure produces a change of state that the client SMTP has to deal with. (NOOP is in this group so it can be used as a synchronization point 🎯)

Additional commands added by other SMTP extensions are only allowed as the last command in a group, unless the extensions that define those commands say otherwise 📌

Message content transfer is explicitly allowed to be the first "command" in a group. That means an RSET/MAIL FROM sequence that starts a new message transaction can be placed in the same group as the final transfer of the headers and body of the previous message 💌

Client SMTP implementations that use pipelining MUST check ALL statuses associated with each command in a group 👀 For example, if none of the RCPT TO recipient addresses were accepted, the client then has to check the response to the DATA command. The client cannot assume that DATA will be rejected just because none of the RCPT TO commands worked. If DATA was properly rejected, the client SMTP can just issue RSET. But if DATA was accepted, the client SMTP should send a single dot.

Command statuses MUST be coordinated with responses by counting each separate response and correlating that count with the number of commands known to have been issued. Multiline responses MUST be supported. Matching on the basis of either the error code value or the associated text is expressly forbidden 🚫

Client SMTP implementations MAY elect to operate in a nonblocking fashion, processing server responses immediately upon receipt, even if there is still data pending transmission from the client's previous TCP send operation. If nonblocking operation is not supported, however, client SMTP implementations MUST also check the TCP window size and make sure that each group of commands fits entirely within the window. The window size is usually, but not always, 4K octets. Failure to perform this check can lead to deadlock conditions 💀

Clients MUST NOT confuse responses to multiple commands with multiline responses. Each command requires one or more lines of response, and the last line does not contain a dash between the response code and the response string 🫶

3.2. Server support of pipelining 🌈

A server SMTP implementation that offers the pipelining extension:

  1. MUST respond to commands in the order they are received from the client.
  2. SHOULD elect to store responses to grouped RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO commands in an internal buffer so they can sent as a unit.
  3. SHOULD issue a positive response to the DATA command if and only if one or more valid RCPT TO addresses have been previously received.
  4. MUST NOT, after issuing a positive response to a DATA command with no valid recipients and subsequently receiving an empty message, send any message whatsoever to anybody.
  5. MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP.
  6. MUST NOT buffer responses to unrecognized commands.
  7. MUST send all pending responses immediately whenever the local TCP input buffer is emptied.
  8. MUST NOT make assumptions about commands that are yet to be received.
  9. MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever.
  10. SHOULD issue response text that indicates, either implicitly or explicitly, what command the response matches.

The overriding intent of these server requirements is to make it as easy as possible for servers to conform to these pipelining extensions 💖

4. Examples ✨

Okay bestie, let's look at a basic SMTP chat without pipelining first 👀

S: <wait for open connection>
C: <open connection to server>
S: 220 Innosoft.com SMTP service ready
C: HELO dbc.mtview.ca.us
S: 250 Innosoft.com
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
S: 250 sender <mrose@dbc.mtview.ca.us> OK
C: RCPT TO:<ned@innosoft.com>
S: 250 recipient <ned@innosoft.com> OK
C: RCPT TO:<dan@innosoft.com>
S: 250 recipient <dan@innosoft.com> OK
C: RCPT TO:<kvc@innosoft.com>
S: 250 recipient <kvc@innosoft.com> OK
C: DATA
S: 354 enter mail, end with line containing only "."
 ...
C: .
S: 250 message sent
C: QUIT
S: 221 goodbye

The client waits for a server response a total of 9 times in this simple example. That's a lot of waiting, ngl 🙈 But if pipelining is employed, the following dialogue is possible:

S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
C: RCPT TO:<ned@innosoft.com>
C: RCPT TO:<dan@innosoft.com>
C: RCPT TO:<kvc@innosoft.com>
C: DATA
S: 250 sender <mrose@dbc.mtview.ca.us> OK
S: 250 recipient <ned@innosoft.com> OK
S: 250 recipient <dan@innosoft.com> OK
S: 250 recipient <kvc@innosoft.com> OK
S: 354 enter mail, end with line containing only "."
 ...
C: .
C: QUIT
S: 250 message sent
S: 221 goodbye

The total number of turnarounds has been reduced from 9 to 4. That's giving efficiency 🦋✨

Next up is one possible way things can go when pipelining is used and all the recipients get rejected. Oof 💀

S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
C: RCPT TO:<nsb@thumper.bellcore.com>
C: RCPT TO:<galvin@tis.com>
C: DATA
S: 250 sender <mrose@dbc.mtview.ca.us> OK
S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
S: 550 remote mail to <galvin@tis.com> not allowed
S: 554 no valid recipients given
C: QUIT
S: 221 goodbye

The client SMTP waits for the server 4 times here as well 😭 Now, if the server SMTP does not check for at least one valid recipient before accepting the DATA command, this dialogue would happen instead:

S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
C: RCPT TO:<nsb@thumper.bellcore.com>
C: RCPT TO:<galvin@tis.com>
C: DATA
S: 250 sender <mrose@dbc.mtview.ca.us> OK
S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
S: 550 remote mail to <galvin@tis.com> not allowed
S: 354 enter mail, end with line containing only "."
C: .
C: QUIT
S: 554 no valid recipients
S: 221 goodbye

5. Security Considerations 🔐

This RFC does not discuss security issues. It also doesn't claim to raise any security issues beyond the ones already endemic to electronic mail and present in fully conforming implementations of [RFC-821]. So the vibe is: the security drama lives in SMTP itself, not in this extension 💀

6. Acknowledgements 🫶

This document is based on the SMTP service extension model presented in RFC 1425. Marshall Rose's description of SMTP command pipelining in his book "The Internet Message" also served as a source of inspiration for this extension. Iconic behaviour from the people who came before us 👑

7. References 📚

  • [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
  • [RFC-1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October, 1989.
  • [RFC-1854] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995.
  • [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
  • [RFC-2197] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.

8. Author's Address 🖊️

Ned Freed
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790
USA

Phone: +1 626 919 3600
Fax:   +1 626 919 361
EMail: ned.freed@innosoft.com

This document is a product of work done by the Internet Engineering Task Force Working Group on Messaging Extensions, Alan Cargille, chair. The working group crew 🧚

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, legends 💖

📦 where this page comes from