SMTP Pipelining
What is SMTP Pipelining?
SMTP pipelining is the PIPELINING service extension from RFC 2920: a server that advertises it in its EHLO reply lets the client send a group of commands, such as MAIL FROM and several RCPT TO, without waiting for each reply, and answers them in order. AdminKit's SMTP status code decoder explains each reply code those commands return.
By AdminKit team, Netbase JSC · Updated
Base SMTP, as specified in RFC 5321, is a lockstep dialogue: the client sends a command and waits for the server’s reply before sending the next one. On a slow or long-distance link every round trip adds delay, and a message for many recipients needs one RCPT TO, and one wait, per address. RFC 2920 removes that wait. A server that offers the extension includes the keyword PIPELINING in its EHLO reply, and the client may then send groups of commands in one batch without waiting for each response. PIPELINING is listed with RFC 2920 as its reference in IANA’s SMTP Service Extensions registry.
How does a pipelined SMTP exchange work?
A typical group is MAIL FROM, several RCPT TO commands and DATA, sent together. DATA must be last, because the client sends the message content only after the server has answered DATA with a 354 reply. RFC 2920 section 3.2 requires the server to answer commands in the order received and never to discard what is waiting in its TCP input buffer. The server may buffer replies to MAIL FROM and RCPT TO, but must not buffer replies to EHLO, DATA, VRFY, EXPN, TURN, QUIT and NOOP. The client then reads the replies in order and pairs each with its command: a rejected RCPT TO in the middle of the batch shows up as one 5xx reply among several 250s, often with an enhanced status code next to it. Servers can also refuse clients that pipeline when they should not: Postfix’s reject_unauth_pipelining restriction rejects a client that sends commands ahead of time where this is not allowed, or without knowing that the server supports pipelining.
AdminKit’s SMTP status code decoder explains any reply line you paste, entirely in your browser; it never connects to a mail server. SMTP pipelining is part of AdminKit’s email authentication cluster; the full AdminKit glossary lists other related terms.
Frequently asked questions
How does a client know a server supports pipelining?
The server lists the keyword PIPELINING, which takes no parameters, in its reply to EHLO. RFC 2920 says a client may batch commands only after it has seen that keyword; a server that only answered HELO, or did not advertise it, gets one command at a time.
Which SMTP commands must end a pipelined group?
RFC 2920 section 3.1 says EHLO, DATA, VRFY, EXPN, TURN, QUIT and NOOP can only appear as the last command in a group, because their replies change what the client does next. RSET, MAIL FROM and RCPT TO may appear anywhere in a group.
In what order do the replies come back?
In the same order as the commands. RFC 2920 section 3.2 requires a pipelining server to respond to commands in the order they were received, so the client matches the first reply to the first command, the second to the second, and so on.
Does pipelining change what the reply codes mean?
No. Each command still gets an ordinary RFC 5321 reply code, such as 250 for an accepted recipient or a 5xx code for a rejected one; pipelining only removes the wait between sending commands, so the client has to check every reply in the batch.