Visual RFC.
ALL RFCs / RFC 2920
Read the RFC ↗

RFC 2920 / START HERE

SMTP PIPELINING, before the details

SMTP PIPELINING

SMTP means Simple Mail Transfer Protocol, the conversation used to hand email between systems. PIPELINING is its command-batching extension: a sender can issue a permitted group before waiting for individual replies.

Start the guide See the 5 chapters ↓

The idea in one picture

  1. Advertise batching

  2. Match replies in order

  3. Wait before content

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

Waiting after each short command costs time on a slow round trip. This extension announces support, sets safe batch boundaries and preserves a reply for every command. It does not send a message body before DATA permission.

A familiar example

A fictional sending mail server can ask about two recipients in one batch. If only one recipient is accepted, replies must still be read in order; batching does not mean both recipients or final delivery succeeded.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

SMTPRFC 5321 · beginner overview ↗TCPRFC 9293 · beginner overview ↗LMTP local deliveryRFC 2033 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Ask before batching SMTP commandsSMTP means Simple Mail Transfer Protocol. PIPELINING lets a sending client batch commands after a receiving server advertises support in a successful EHLO reply.
  2. Put state-changing commands at a batch boundaryA command group may contain several envelope commands, but commands such as DATA that change the client’s next action belong at the end.
  3. Match whole replies to the command queueReplies belong to commands by order and count. A multiline reply contains several lines but consumes only one command from the queue.
  4. Preserve input and flush replies at the right timeThe server may combine some replies in a buffer, while preserving both command order and unread input. Buffering must not turn into deadlock.
  5. Check failure paths before sending any bodyWhen every recipient fails, the client must still read DATA’s actual reply. Recovery from an unexpected 354 is different from sending an ordinary message.
Start with chapter one →

This introduction explains RFC 2920 (2000). Read the original RFC ↗