Visual RFC.
ALL RFCs / RFC 2033
Read the RFC ↗
RFC 2033 / LOCAL MAIL TRANSFER

Keep received results when the connection closes

05

Process recipient results as they arrive. A connection closing partway through does not erase the replies already received.

DIAGRAMRead RFC section 5 ↗
RFC 2033 · § 5EXAMPLE
4 / 4
Keep received results when the connection closesFour states after three successful RCPT commands and content. Initially Ana,Bo,Cy await final results. Final250for Ana arrives and transfers responsibility, then final550for Bo is a permanent failure. Connection closes before Cy reply: retain250and550and treat only Cy as temporary failure. This fulfills client MUST processing, does not undo received results and does not guarantee absence of duplicate delivery after an uncertain lost reply.Retain the received prefix of resultsAfter content · three successful RCPT slotsAna250 · responsibilityBo550 · permanentCyno reply · temporaryconnection closesMUST keep received results; rest temporaryLost replies can still lead to duplicate delivery
04
Close with only the remainder temporary.

The connection closes before Cy’s final reply. The client MUST retain the received250/550 outcomes and treat Cy as a temporary failure. No unconditional resend to all three recipients is illustrated.

Source for this drawing: RFC 2033 · Read RFC section 5 ↗

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

RFC 5321 SMTP RFC 5322 Email message format RFC 3848 Mail transport traces

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

Keep the received prefix; treat the unreplied remainder as temporary failures.

  • The server SHOULD send each reply promptly and flush buffered output before spending nontrivial time on the next recipient. The client SHOULD process replies as they arrive rather than wait for the whole list.
  • If the connection closes after some but not all replies, the client MUST process those received and treat the rest as temporary failures. It must not discard a known positive result or invent success for an unreplied recipient.
  • LMTP can aggravate duplicate-message synchronization problems; it is not an exactly-once guarantee. A server that can quickly accept multiple recipients and send required notifications SHOULD NOT implement LMTP; keep the intended limited deployment scope.
DETAILS

Three successful RCPT commands are assumed here. Chosen final 250 for Ana and550 for Bo arrive before the connection closes without Cy’s result. Ana’s responsibility transfer and Bo’s permanent result survive; Cy is temporary failure. This does not prove Cy never received mail: loss of a reply can leave uncertainty, so retry can duplicate delivery.

Read the RFC section ↗

All chapters in RFC 2033

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 ↗