Put state-changing commands at a batch boundary
02A command group may contain several envelope commands, but commands such as DATA that change the client’s next action belong at the end.
Illustrative group length 91 octets and available window 64: a blocking client cannot use this group as-is. Choose a smaller valid group or suitable nonblocking handling; no constant 4K assumption.
Source for this drawing: RFC 2920 · Read RFC section 3.1 ↗
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.
MAIL FROM, RCPT TO and RSET can appear anywhere in a group. RFC 2920 also lists the historical SEND, SOML and SAML verbs; this guide’s modern example uses MAIL and RCPT only.
- MAIL FROM, RCPT TO and RSET can appear anywhere in a group. RFC 2920 also lists the historical SEND, SOML and SAML verbs; this guide’s modern example uses MAIL and RCPT only.
- EHLO, DATA, VRFY, EXPN, TURN, QUIT and NOOP can only be last in a group. NOOP provides a synchronization point. Other-extension commands are last unless their defining extension explicitly permits otherwise.
- Putting DATA last does not authorize sending message content with it. Wait for its 354 intermediate reply before starting content; a rejection is not permission to send the body (SMTP RFC 5321 sections 3.3 and 4.1.1.4).
- Clients MAY read replies nonblockingly while a previous send is still pending. If not, they MUST check that the complete command group fits the TCP window. The RFC’s usual 4K observation is not a fixed guaranteed window.
- After content is already authorized, RFC 2920 permits its final transfer first in a group with the next transaction’s RSET/MAIL sequence. That cross-transaction optimization is distinct from sending a new body before DATA acceptance and is not implemented in these bounded examples.
Fictional ASCII SMTP examples. PIPELINING batches commands, not delivery guarantees or security. Packet boundaries and wall-clock timing are schematic.
Read the RFC section ↗