Count replies at the end of a chunked message
04If the server supports CHUNKING, BDAT sends counted content chunks. A LAST parameter identifies the final chunk; that command gets per-recipient results.
Compare the separate DATA command with zero successful recipients: one 503 rejection, no content. Do not transfer the BDAT LAST zero-reply rule to DATA.
Source for this drawing: RFC 2033 · Read RFC section 4.3 ↗
New to this? Start hereA quick picture + helpful background
The envelope and the letter do different jobs.
Mail transport moves a message between servers. The message format describes its contents. Authentication adds checks; it does not make every message safe.
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.
Nonfinal BDAT gets one reply; BDAT LAST gets one per successful RCPT.
- This chapter is conditional on server support for the separate ESMTP CHUNKING extension. RFC 2033 does not require that extension.
- BDAT without LAST still returns exactly one reply. With LAST it returns one reply per previously successful RCPT command in order, including repeated addresses; a multiline reply is still one reply.
- With zero successful RCPT commands, BDAT LAST returns zero replies. This differs from DATA without successful RCPT, which MUST return503. These edge cases describe reply rules, not a recommended client transaction.
BDAT’s byte-count framing and extension negotiation are not fully reproduced. The shown abc is a three-octet chunk fragment, not a complete message. For BDAT LAST, a positive recipient result carries the same serious delivery responsibility as a final DATA result.
Read the RFC section ↗