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.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 14 must, 3 should, 1 may.
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.