Visual RFC.
ALL RFCs / RFC 3030
Read the RFC ↗
RFC 3030 / SMTP CHUNKS AND BINARY MIME

Drain failed chunks before resetting

04

Length framing still matters after an error. The receiver consumes and discards the failed chunk’s declared data before replying, so those bytes are not mistaken for commands.

RFC 3030 · § 2EXAMPLE
4 / 4
Drain failed chunks before resettingRSET clears failed transaction after pending replies; no delivery success claimed.Failed BDAT still has a counted payload to drainSenderReceiverRSET after accounting for pending replies250 reset completeFailed transaction segments clearedConnection can continue; no message delivered4XX or 5XX BDAT failure needs RSET, not another new chunk
04
Clear the failed transaction with RSET

After pending replies are accounted for, the sender issues RSET and receives 250. The failed transaction’s accumulated segments are cleared; this is recovery, not successful message delivery.

Source for this drawing: RFC 3030 · Read RFC section 2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

After a failure on a BDAT command, the receiver MUST accept and discard its associated message data before sending the appropriate 4XX or 5XX reply.

  • After a failure on a BDAT command, the receiver MUST accept and discard its associated message data before sending the appropriate 4XX or 5XX reply.
  • On receiving a 4XX or 5XX reply to BDAT, the sender treats the transaction as failed and MUST NOT send additional BDAT segments. Existing pipelined chunks are a separate case.
  • A receiver advertising PIPELINING MUST be prepared to accept and discard additional BDAT chunks already in the pipeline after the failed one. Do not confuse already sent bytes with permission to send new chunks after observing failure.
  • The failed state is indeterminate. The sender MUST issue RSET before additional commands. RSET clears the transaction; a new envelope would be needed to send another message. Chunk size is a resource choice, not a fixed RFC constant.
DETAILS

Fictional example.com mail peers. Counts and byte excerpts are illustrative, not a full MIME message or a deployment configuration. Separate comparisons reset state. This companion is not an SMTP parser or implementation.

Read the RFC section ↗

All chapters in RFC 3030

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗