SMTP Service Extension for Command Pipelining
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS-TRACK]
Replaces RFC 1854: SMTP Service Extension for Command Pipelining, RFC 2197: SMTP Service Extension for Command Pipelining.
What it is
Command pipelining: sending a group of SMTP commands without waiting for each reply.
What it solves
SMTP is a lockstep conversation, and over a long round trip the waiting dominates. A transatlantic delivery spent most of its time idle.
What it means to operate
This is most of the throughput difference between a tuned MTA and an untuned one on high-latency routes. The rule that bites: you may only pipeline commands whose failure does not change the meaning of what follows, so the client must still stop and read after DATA.
Bounce classifier turns an SMTP response into the action it calls for. Open bounce classifier
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from.
1.1 Requirements Notation
- MUSTWhen the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification.
- MUSTA 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.
3.1 Client use of pipelining
- MUSTClient SMTP implementations that employ pipelining MUST check ALL statuses associated with each command in a group.
- MUSTCommand 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.
- MUSTMultiline responses MUST be supported.
- MAYClient 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.
- MUSTIf 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.
- MUST NOTClients MUST NOT confuse responses to multiple commands with multiline responses.
3.2 Server support of pipelining
- MUST(1) MUST respond to commands in the order they are received from the client.
- SHOULD(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.
- SHOULD(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.
- MUST NOT(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.
- MUST NOT(5) MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP.
- MUST NOT(6) MUST NOT buffer responses to unrecognized commands.
- MUST(7) MUST send all pending responses immediately whenever the local TCP input buffer is emptied.
- MUST NOT(8) MUST NOT make assumptions about commands that are yet to be received.
- MUST NOT(9) MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever.
- SHOULD(10) SHOULD issue response text that indicates, either implicitly or explicitly, what command the response matches.