Distinguish success, temporary conditions and permanent failure
02The leading field carries the broad outcome even when a reader does not know the rest. It guides interpretation rather than specifying an automatic retry schedule.
5.1.1 means a nonexistent destination mailbox address and is only useful for permanent failures. Resending unchanged is unlikely to resolve it.
Source for this drawing: RFC 3463 · Read RFC section 2 ↗
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.
A failure class does not become success because its detail is unfamiliar.
- Class 2 reports a positive delivery action. It does not assert that a human has read the message.
- Class 4 reports a persistent transient failure: the message as sent is valid, but a temporary condition caused delay or abandonment. Future sending may succeed; no retry interval or guarantee is defined here.
- Class 5 is a permanent failure unlikely to be resolved by resending the message in its current form. Some message or destination change is needed; it does not mean the address can never work after correction.
These are separate examples, not successive outcomes of one message. RFC 3463 recommends persistent transient use for Mailbox full. The examples deliberately keep codes in their described classes; the parser used in the illustration only checks grammar, not all class-specific registry constraints.
Read the RFC section ↗