Enhanced Mail System Status Codes
obsoletes
- rfc-1893 — Enhanced Mail System Status Codes
updated by
- rfc-3886 — An Extensible Message Format for Message Tracking Responses
- rfc-4468 — Message Submission BURL Extension
- rfc-4865 — SMTP Submission Service Extension for Future Message Release
- rfc-4954 — SMTP Service Extension for Authentication
- rfc-5248 — A Registry for SMTP Enhanced Mail System Status Codes
Extracted elements (25)
A separate enhanced status code space was created rather than extending SMTP reply codes to avoid consuming the remaining SMTP reply-code number space needed for new ESMTP extensions, and because any redistribution of SMTP codes would necessarily be incompatible with SMTP.
SMTP reply codes were found insufficient for DSN use: only about 12 useful codes exist, all are overloaded to indicate multiple conditions, and the remaining available code space is too small to accommodate mail system errors plus MIME/security categories without incompatible changes to SMTP.
The enhanced status code structure mirrors the SMTP theory of reply codes by adopting its success/transient-failure/permanent-failure semantics in the first field, while redistributing the subject classifications to better separate distinct failure categories such as mailbox vs. host errors.
The X.7.0 code may be used when the condition cannot be further described because of security policies in force, providing a way to report security-related failures without disclosing policy details.
X.1.4 (destination mailbox address ambiguous) may result when a heuristic address mapping algorithm maps a specified address to one or more local mailbox names, indicating a non-fatal condition that may require disambiguation.
X.5.3 (too many recipients) should normally result in segmentation of the message for delivery across multiple attempts; it is listed as a permanent error only for cases where such segmentation is not possible.
X.6.3 (conversion required but not supported) may occur at ESMTP gateways that support 8-bit transport but cannot downgrade messages to 7-bit as required for the next hop, illustrating a gateway interoperability boundary.
A client must recognize and report the class sub-code even where the subsequent subject sub-codes are unrecognized.
Each numeric sub-code within the status code MUST be expressed without leading zero digits, and whitespace characters and comments are NOT allowed within a status code.
New subject and detail codes will be added over time, and published status codes are not intended to ever be redefined or eliminated, ensuring backward compatibility as the code space evolves.
The code space is intended to be extensible only by standards track documents; servers should send only defined, registered status codes; system-specific errors and diagnostics should be carried by means other than status codes.
The subject sub-code, if recognized, must be reported even if the additional detail provided by the detail sub-code is not recognized; clients should preserve extensibility by reporting the general error described in the subject sub-code when the specific detail is unrecognized.
Address status codes X.1.0–X.1.8 cover conditions such as bad destination mailbox address (X.1.1), bad destination system address (X.1.2), address syntax errors (X.1.3), ambiguous address (X.1.4), valid address (X.1.5), moved mailbox with no forwarding (X.1.6), and bad sender address or system (X.1.7, X.1.8).
Mail delivery protocol status codes X.5.0–X.5.5 cover: invalid command (X.5.1), syntax error (X.5.2), too many recipients (X.5.3), invalid command arguments (X.5.4), and wrong protocol version (X.5.5); most are useful only as permanent errors.
Mail system status codes X.3.0–X.3.5 cover system-level conditions: mail system storage exceeded (X.3.1, persistent transient), system not accepting network messages (X.3.2), unsupported features (X.3.3), message too big for system (X.3.4, permanent), and system misconfiguration (X.3.5).
Mailbox status codes X.2.0–X.2.4 cover conditions including mailbox disabled (X.2.1), mailbox full exceeding quota (X.2.2, should be used as persistent transient failure), per-mailbox message length limit exceeded (X.2.3, permanent failure), and mailing list expansion problem (X.2.4).
Message content and media status codes X.6.0–X.6.5 cover: media not supported (X.6.1), conversion required and prohibited (X.6.2), conversion required but not supported (X.6.3), conversion with loss performed (X.6.4, a warning on successful delivery), and conversion failed (X.6.5).
Network and routing status codes X.4.0–X.4.7 cover: no answer from host (X.4.1), bad connection (X.4.2), directory server failure (X.4.3), unable to route (X.4.4), mail system congestion (X.4.5), routing loop detected (X.4.6), and delivery time expired (X.4.7).
Security and policy status codes X.7.0–X.7.7 cover: delivery not authorized (X.7.1), mailing list expansion prohibited (X.7.2), security conversion not possible (X.7.3), security features not supported (X.7.4), cryptographic failure due to missing/invalid keys (X.7.5), unsupported cryptographic algorithm (X.7.6), and message integrity failure (X.7.7).
The class sub-code has three enumerated values: 2.XXX.XXX indicates success (positive delivery); 4.XXX.XXX indicates persistent transient failure (temporary condition, retry may succeed); 5.XXX.XXX indicates permanent failure (resending in current form will not succeed).
The subject sub-code classifies the source of the condition into eight categories: X.0 (other/undefined), X.1 (addressing), X.2 (mailbox), X.3 (mail system), X.4 (network/routing), X.5 (delivery protocol), X.6 (content/media), X.7 (security/policy).
X.0.0 (other undefined status) is the only status code for errors where only the class is known; it is intended as a catch-all for conditions that cannot be more precisely classified.
This document defines the registry of Enhanced Mail System Status Codes, comprising class codes (2, 4, 5), subject sub-codes (0–7), and detail sub-codes as enumerated in Section 3 and Appendix A; the code space is extensible only by standards track documents.
Use of these enhanced status codes may disclose additional information about how an internal mail system is implemented beyond what is currently available through standard SMTP codes, potentially aiding an attacker in mapping system internals.
Enhanced status codes use the syntax 'class.subject.detail' where class is '2', '4', or '5'; subject and detail are 1–3 digit numeric fields; no leading zeros are permitted and no whitespace is allowed within a status code.