SMTP Service Extension for Command Pipelining
Extracted elements (18)
Although clients could simply pipeline commands, the original RFC 821 did not explicitly require servers to support pipelining, resulting in a non-trivial number of deployed servers that cannot handle it. The extension mechanism allows clients to pipeline only against servers that have declared capability, avoiding interoperability failures.
NOOP is included in the group of commands that can only appear last in a pipeline group (alongside EHLO, DATA, QUIT, etc.) so that it can serve as an explicit synchronization point when the client needs to drain all pending responses before proceeding.
The actual transfer of message content (headers and body) is explicitly allowed to be the first 'command' in a pipeline group, permitting a RSET/MAIL FROM sequence for a new message to be batched together with the final dot-termination of the previous message, maximizing throughput.
Known flaws in deployed SMTP servers that break pipelining include: (1) losing data from process buffers during mid-dialogue connection handoff; (2) flushing the TCP input buffer on command failure; and (3) improperly handling RCPT TO failures, either refusing DATA after any RCPT failure or accepting DATA when all RCPT TO commands failed.
A server SMTP offering the pipelining extension MUST respond to commands in the order they are received from the client.
Client SMTP implementations that employ pipelining MUST check ALL statuses associated with each command in a group; for example, the client must still check the DATA response even if no RCPT TO commands succeeded, 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, with the last line not containing a dash between the response code and the response 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 on the basis of 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 perform this check can lead to deadlock conditions.
The 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.
The server MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP commands, nor to unrecognized commands, because these commands change state that requires immediate client acknowledgment.
The server MUST NOT make assumptions about commands that are yet to be received, and MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever.
The server MUST send all pending responses immediately whenever the local TCP input buffer is emptied.
The 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.
The server SHOULD 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.
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 outcome changes state the client must handle.
The PIPELINING SMTP service extension is declared via the EHLO keyword 'PIPELINING'. No parameters are used with the keyword, and no additional parameters are added to MAIL FROM or RCPT TO commands, and no new SMTP verbs are defined.
RFC 2920 does not introduce security issues beyond those already endemic to electronic mail and present in fully conforming implementations of RFC 821. No new attack surface is identified for the pipelining extension itself.