Preserve what is known when a detail is unfamiliar
04A reader may encounter a well-formed code whose specific detail or subject it does not recognize. Report the broader meaning that remains known.
For the chosen input 4.98.7, this reader does not know subject 98. It still reports persistent transient failure, not success and not a made-up cause.
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.
Unknown detail loses precision, not the known failure class.
- Clients must recognize and report the class even if later subject values are unrecognized. A recognized subject must still be reported when its detail is unrecognized.
- For an unrecognized detail, report the general subject condition. If the subject is also unrecognized, retain the class rather than fabricate a specific diagnosis.
- The unfamiliar-detail and unfamiliar-subject values drawn here are chosen inputs to a reader with a limited teaching dictionary. They are not claimed registered assignments or examples that servers should emit.
Reporting a broader interpretation does not mean rewriting the received status code. Keep the original code available for investigation under appropriate privacy controls. Syntax validity does not grant registration, trust or permission to retry forever.
Read the RFC section ↗