SMTP Service Extension for Command Pipelining
obsoleted by
- rfc-2197 — SMTP Service Extension for Command Pipelining
Extracted elements (21)
NOOP is included in the group of commands that can only appear last in a pipeline so it can be used as a deliberate synchronization point, forcing the server to flush all pending responses before the client proceeds.
SMTP's intrinsic one command-one response structure is significantly penalized by high latency links, often to the point where turnaround time dominates overall connection time. Pipelining batches multiple commands into single TCP send operations to reduce these turnarounds.
The original SMTP specification did not explicitly require servers to support command pipelining, so a non-trivial number of deployed servers cannot handle it. This extension uses EHLO negotiation so clients can use pipelining only with servers that declare support.
The server requirements are explicitly designed to make it as easy as possible for servers to conform to the pipelining extension, favoring simplicity of implementation over prescribing complex buffering strategies.
Known flaws in deployed servers that break pipelining include: (1) losing data from TCP buffers during connection handoff/process forking mid-dialogue; (2) flushing the TCP input buffer when a command fails; (3) improper correlation of RCPT TO results with subsequent DATA command acceptance.
The actual transfer of message content (the final dot of a previous message body) is explicitly allowed to be the first 'command' in a pipeline group, so an RSET/MAIL FROM sequence for a new message can be batched with the final headers and body of the previous message.
A client SMTP confirms pipelining support by issuing EHLO and checking that the server responds with 250 and includes the keyword PIPELINING in the response.
A server 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.
A server MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, TURN, QUIT, NOOP, or unrecognized commands. It MUST send all pending responses immediately whenever the local TCP input buffer is emptied.
A server MUST NOT make assumptions about commands that are yet to be received. This prevents premature rejection or processing based on anticipated future client behavior.
A server offering pipelining MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever.
A server 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 be sent as a unit.
A server SHOULD issue a positive response to the DATA command if and only if one or more valid RCPT TO addresses have been previously received.
A server SHOULD issue response text that indicates, either implicitly or explicitly, what command the response matches, aiding client correlation of responses to pipelined commands.
Client SMTP implementations that employ pipelining MUST check ALL statuses associated with each command in a group. For example, if no RCPT TO commands succeeded, the client must still check the DATA command response and cannot assume DATA will be rejected.
Clients MUST NOT confuse responses to multiple commands with multiline responses. Each command requires one or more lines of response, where the last line does not contain a dash between the response code and string.
Command statuses MUST be coordinated with responses by counting each separate response and correlating that count with the number of commands issued. Multiline responses MUST be supported. Matching responses to commands based on error code value or associated text is expressly forbidden.
If nonblocking operation is not supported, client SMTP implementations MUST check the TCP window size and ensure each group of commands fits entirely within the window (usually 4K octets). Failure to do so can lead to deadlock conditions.
Commands RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO may appear anywhere in a pipelined command group. Commands EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP may only appear as the last command in a group because their success or failure changes state the client must accommodate.
The PIPELINING SMTP service extension is identified by the EHLO keyword PIPELINING. No parameters are used with this keyword, and no new SMTP verbs or additional parameters to MAIL FROM or RCPT TO are defined.
RFC 1854 does not introduce new security issues beyond those endemic to electronic mail and present in fully conforming SMTP implementations. No security concerns specific to pipelining are identified.