Enhanced Mail System Status Codes
obsoleted by
- rfc-3463 — Enhanced Mail System Status Codes
Extracted elements (29)
SMTP reply codes were not suitable for delivery status notifications because SMTP provides only about 12 useful delivery codes, each overloaded to indicate several error conditions, and the remaining available code space is insufficient to cover MIME, media conversion, and security errors without incompatibility.
The new status code space redistributes error classifications relative to SMTP—notably separating mailbox errors from host errors—to better distribute conditions across the number space while retaining the success/transient-failure/permanent-failure semantics of the SMTP first digit.
Because the status code number space is large, published status codes are not intended to ever be redefined or eliminated. Clients must fall back to reporting the general subject-level error when an unrecognized detail sub-code is received, ensuring forward compatibility.
X.5.3 Too many recipients: more recipients were specified than the protocol could deliver. This should normally result in message segmentation across multiple delivery attempts; the code is provided for cases where segmentation is not possible.
A client MUST recognize and report the class sub-code even where subsequent subject sub-codes are unrecognized.
Servers should send only defined, registered status codes. System-specific errors and diagnostics should be carried by means other than status codes.
The code space is intended to be extensible only by standards track documents. Mail-system-specific status codes should be mapped as close as possible to the standard 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.
Class 2.X.X indicates Success: the DSN reports a positive delivery action. Detail sub-codes may provide notification of transformations required for delivery.
Class 4.X.X indicates Persistent Transient Failure: the message as sent is valid, but a temporary event prevents successful delivery. Sending in the future may succeed.
Class 5.X.X indicates Permanent Failure: the condition is not likely to be resolved by resending the message in its current form. Some change to the message or destination is required.
Subject X.1.X covers Addressing Status, reporting on originator or destination address syntax or validity. These errors can generally be corrected by the sender and retried.
Subject X.2.X covers Mailbox Status, indicating issues with the destination mailbox assumed to be under the general control of the recipient (e.g., disabled, full, or size-limited).
Subject X.3.X covers Mail System Status, indicating issues with the destination system assumed to be under control of the destination system administrator (e.g., storage full, not accepting messages).
Subject X.4.X covers Network and Routing Status, reporting failures in delivery infrastructure including directory and routing services. These are assumed to be under control of destination or intermediate system administrators.
Subject X.5.X covers Mail Delivery Protocol Status, reporting failures in the message delivery protocol itself, including implementation errors and unreliable connections. Responsibility may lie with originating, destination, or intermediate system administrators.
Subject X.6.X covers Message Content or Media Status, reporting translation, transcoding, or unsupported media failures. Both sender and receiver must support a common set of content types.
Subject X.7.X covers Security or Policy Status, reporting failures involving per-recipient or per-host filtering and cryptographic operations. Both sender and recipient must permit the exchange and arrange necessary keys and certificates.
X.1.1 Bad destination mailbox address: the mailbox specified does not exist (left of "@" is invalid for Internet mail). This code is only useful for permanent failures.
X.2.2 Mailbox full: the user has exceeded a per-mailbox administrative quota or physical capacity. Should be used as a persistent transient failure since the recipient can delete messages to free space.
X.4.4 Unable to route: the mail system could not determine the next hop because routing information was unavailable from the directory server. A DNS lookup returning only an SOA record is cited as an example. Useful for both permanent and persistent transient errors.
X.4.6 Routing loop detected: a routing loop caused the message to be forwarded too many times due to incorrect routing tables or a user forwarding loop. Useful only as a persistent transient error.
X.6.4 Conversion with loss performed: a warning sent to the sender when delivery succeeded but required a conversion in which some data was lost. May also be a permanent error if conversion with loss is prohibited by the sender.
X.7.1 Delivery not authorized, message refused: the sender is not authorized to send to the destination due to per-host or per-recipient filtering. Useful only as a permanent error.
X.7.5 Cryptographic failure: a transport system authorized to validate or decrypt a message was unable to do so because necessary key information was not available or was invalid.
X.7.7 Message integrity failure: a transport system authorized to validate a message was unable to do so because the message was corrupted or altered. May be used as permanent, transient persistent, or successful delivery code.
This document defines the Enhanced Mail System Status Codes registry, comprising a three-part numeric code space (class.subject.detail). The codes enumerate address, mailbox, mail system, network/routing, protocol, media, and security/policy statuses for use in delivery status notifications. The space is extensible only via 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 via SMTP reply codes, potentially exposing system internals to senders.
Status codes use the syntax `status-code = class "." subject "." detail` where class is "2", "4", or "5"; subject is 1–3 digits; and detail is 1–3 digits. White-space and comments are NOT allowed within a status-code, and each numeric sub-code MUST be expressed without leading zero digits.