SMTP Service Extension for Command Pipelining
obsoleted by
- rfc-2920 — SMTP Service Extension for Command Pipelining
obsoletes
- rfc-1854 — SMTP Service Extension for Command Pipelining
Extracted elements (20)
The extension was motivated by three known flaws in deployed SMTP servers: (1) loss of buffered data during mid-dialogue process handoff; (2) flushing the TCP input buffer on command failure; (3) improper handling of RCPT TO failures when deciding whether to accept a DATA command. These bugs made unsafe deploying pipelining without server opt-in.
The pipelining mechanism reduces turnaround count dramatically on high-latency links. The worked example shows a simple three-recipient message exchange dropping from 9 server wait-points to 4, cutting overall transfer time dominated by latency.
The actual transfer of message content (the DATA body) is explicitly allowed to be the first 'command' in a pipeline group, permitting a RSET/MAIL FROM sequence for a new transaction to be grouped with the final content transfer of the previous message.
The original SMTP specification (RFC 821) did not explicitly require servers to support command pipelining, resulting in a non-trivial number of deployed servers that cannot adequately handle pipelined commands. The PIPELINING extension provides an explicit opt-in mechanism to avoid compatibility issues.
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, and NOOP. It MUST NOT buffer responses to unrecognized commands.
A server MUST NOT make assumptions about commands that are yet to be received.
A server MUST send all pending responses immediately whenever the local TCP input buffer is emptied.
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 response text that indicates, either implicitly or explicitly, what command the response matches, to help clients correlate pipelined responses.
A server SMTP SHOULD issue a positive response to the DATA command if and only if one or more valid RCPT TO addresses have been previously received.
Client SMTP implementations that employ pipelining MUST check ALL statuses associated with each command in a group. For example, if no RCPT TO addresses were accepted, the client must still check the DATA command response and cannot assume it will be rejected.
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. Matching on the basis of either error code value or associated text is expressly forbidden.
Commands added by other SMTP extensions may only appear as the last command in a pipelined group unless otherwise specified by the extension defining those commands.
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.
Multiline responses MUST be supported by clients. Clients MUST NOT confuse responses to multiple commands with multiline responses; each command requires one or more lines, the last not containing a dash between the response code and string.
Commands RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO may appear anywhere in a pipelined command group. EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP may only appear as the last command in a group because their success or failure produces a state change the client must accommodate.
The PIPELINING SMTP service extension is identified by the EHLO keyword 'PIPELINING' with no associated parameters. No new SMTP verbs, and no new parameters to MAIL FROM or RCPT TO are defined.
RFC 2197 does not introduce new security issues beyond those endemic to electronic mail. The pipelining extension does not alter authentication, authorization, or message integrity properties of conforming SMTP implementations.