Ask before batching SMTP commands
01SMTP means Simple Mail Transfer Protocol. PIPELINING lets a sending client batch commands after a receiving server advertises support in a successful EHLO reply.
Separate server: successful EHLO does not list PIPELINING. The client waits for MAIL’s reply before the next ordinary command.
Source for this drawing: RFC 2920 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
First receive the SMTP greeting, then send EHLO. Only a successful 250 EHLO reply containing the case-insensitive PIPELINING keyword establishes this extension’s support; PIPELINING has no parameter.
- First receive the SMTP greeting, then send EHLO. Only a successful 250 EHLO reply containing the case-insensitive PIPELINING keyword establishes this extension’s support; PIPELINING has no parameter.
- The client may choose batching after support is confirmed. Support is permission, not an obligation to batch. Without the advertisement, use ordinary command/reply waiting.
- This extension adds no SMTP verb and no MAIL FROM or RCPT TO parameters. It reduces some waiting, not the number of required command replies.
- A TCP send operation is not an IP-packet boundary or simultaneous execution. The server still processes commands and responds in received order; no universal speedup is promised.
Fictional ASCII SMTP examples. PIPELINING batches commands, not delivery guarantees or security. Packet boundaries and wall-clock timing are schematic.
Read the RFC section ↗