RFC 3463
Enhanced Mail System Status Codes
Enhanced Mail System Status Codes ✨
(part 1 of 3)
Okay, so this RFC is by G. Vaudreuil from Lucent Technologies, published in the Network Working Group series as RFC 3463 in January 2003 🎀. It's a Standards Track doc, which means it's proposing an actual Internet standards track protocol for the community to discuss and improve. It obsoletes RFC 1893, so that older version is officially retired 🫶.
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📜. Distribution of this memo is unlimited 🌈.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
Abstract
This doc defines a set of extended status codes for the mail system to use in delivery status reports, tracking, and better diagnostics 📬. Combined with the other info in a Delivery Status Notification (DSN) delivery report, these codes make it possible to render message delivery status in any media and any language 🌸.
Table of Contents
1. Overview ......................................................2
2. Status Code Structure .........................................3
3. Enumerated Status Codes .......................................5
3.1 Other or Undefined Status ...................................6
3.2 Address Status ..............................................6
3.3 Mailbox Status ..............................................7
3.4 Mail system status ..........................................8
3.5 Network and Routing Status ..................................9
3.6 Mail Delivery Protocol Status ..............................10
3.7 Message Content or Message Media Status ....................11
3.8 Security or Policy Status ..................................12
4. References ...................................................13
5. Security Considerations ......................................13
Appendix A - Collected Status Codes ..........................14
Appendix B - Changes from RFC1893 ............................15
Author's Address .............................................15
Full Copyright Statement .....................................161. Overview ✨
Okay so, mail systems need a standard way to report errors that's way richer than the tiny set SMTP gives you, plus the random system-specific text that gets stuck in messages 💅. We really need a rich, machine-readable status code that doesn't depend on human language for Delivery Status Notifications [DSN] 🧚. That's what this doc proposes 🔥.
SMTP [SMTP] reply codes have historically been used to report mail system errors. Because of how the SMTP codes were designed, they aren't suitable for delivery status notifications 💀. SMTP only gives you about 12 useful codes for delivery reports, and most of its codes are protocol-specific responses, like the 354 response to the SMTP data command 🙈. Each of those 12 useful codes gets overloaded to mean several different error conditions. SMTP also has some scars from history, mainly the messy damage that uncontrolled use did to the reply code extension mechanism 😭. This proposal is more future-proof: clients have to interpret unknown error codes according to the theory of codes, and servers have to register new response codes 🫶.
The SMTP theory of reply codes splits up the number space in a way that means the codes left over won't be enough 😩. The scariest part is that only 5 codes are left for mail system errors. That classification covers both host and mailbox error conditions 🍓. The remaining third-digit space would be totally used up just for MIME and media conversion errors and security system errors 💔.
Revising the SMTP theory of reply codes to spread the error conditions out better would necessarily be incompatible with SMTP 🚫. Using up the leftover reply-code number space for delivery notification reporting would also leave fewer codes for new ESMTP extensions 🥲.
So the status code set in this doc is based on the SMTP theory of reply codes 🎀. It keeps the success, permanent error, and transient error meanings of the first value, and adds more description and classification in the second value 👑. This proposal rearranges the classifications so the error conditions are spread out better, like separating mailbox errors from host errors ✨.
Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] 🩷.
2. Status Code Structure 🦋
This doc defines a brand new set of status codes for reporting mail system conditions 🌷. They're meant for media and language independent status reporting, not for system-specific diagnostics 💅.
The syntax of the new status codes is defined as:
status-code = class "." subject "." detail
class = "2"/"4"/"5"
subject = 1*3digit
detail = 1*3digitWhite-space characters and comments are NOT allowed within a status-code 🙅. Each numeric sub-code within the status-code MUST be expressed without leading zero digits 🔢.
Status codes are made of three numerical fields separated by ".". The first sub-code says whether the delivery attempt was successful 🎉. The second sub-code shows the probable source of any delivery anomalies, and the third sub-code gives a precise error condition 🔍.
Example: 2.1.23
The code space is meant to be extended only by standards track documents 📚. Mail system specific status codes should be mapped as close as possible to the standard status codes 🧩. Servers should send only defined, registered status codes 🫶. System specific errors and diagnostics should be carried by means other than status codes 💜.
New subject and detail codes will be added over time 🌈. Because the number space is huge, published status codes are not intended to ever be redefined or eliminated 💎. Clients should keep the code space extensible by reporting the general error described in the subject sub-code whenever the specific detail isn't recognized 🤝.
The class sub-code gives a broad classification of the status. The enumerated values for each class are:
2.XXX.XXX Success
4.XXX.XXX Persistent Transient Failure
5.XXX.XXX Permanent FailureFor the Success class, the DSN is reporting a positive delivery action 🥳. Detail sub-codes may give notice of transformations required for delivery ✨.
For the Persistent Transient Failure class, the message as sent is valid, but some temporary condition has persisted and caused the attempts to send the message to be abandoned or delayed ⏳. If this code comes with a delivery failure report, sending in the future may succeed 🌤️.
For the Permanent Failure class, the failure is one that isn't likely to be fixed by resending the message in its current form 🛑. Some change to the message or the destination has to be made for delivery to succeed 🔧.
A client must recognize and report the class sub-code even where the later subject sub-codes aren't recognized 💅.
The subject sub-code classifies the status. This value applies to each of the three classifications 🏷️. The subject sub-code, if recognized, must be reported even if the detail sub-code's extra info isn't recognized 🫶. The enumerated values for the subject sub-code are:
X.0.XXX Other or Undefined Status
X.1.XXX Addressing Status
X.2.XXX Mailbox Status
X.3.XXX Mail System Status
X.4.XXX Network and Routing Status
X.5.XXX Mail Delivery Protocol Status
X.6.XXX Message Content or Media Status
X.7.XXX Security or Policy StatusFor X.0.XXX (Other or Undefined Status), there's no extra subject info available 🤷♀️.
For X.1.XXX (Addressing Status), the status reports on the originator or destination address 📍. It can include address syntax or validity. The sender can usually fix these errors and retry 🔁.
For X.2.XXX (Mailbox Status), something to do with the mailbox caused this DSN 📭. Mailbox issues are assumed to be under the general control of the recipient 💌.
For X.3.XXX (Mail System Status), something to do with the destination system caused this DSN 🖥️. System issues are assumed to be under the general control of the destination system administrator 🧑💻.
For X.4.XXX (Network and Routing Status), these codes report status about the delivery system itself 🛤️. The components include any necessary infrastructure, like directory and routing services 🗺️. Network issues are assumed to be under the control of the destination or intermediate system administrator 🌐.
For X.5.XXX (Mail Delivery Protocol Status), these codes report failures involving the message delivery protocol 📡. The failures cover the full range of problems from implementation errors or an unreliable connection 😵💫.
For X.6.XXX (Message Content or Media Status), these codes report failures involving the content of the message 🎨. They report failures from translation, transcoding, or otherwise unsupported message media 🎬. Message content or media issues are under the control of both the sender and the receiver, and both of them must support a common set of supported content-types 🤝.
For X.7.XXX (Security or Policy Status), these codes report failures involving policies, like per-recipient or per-host filtering, and cryptographic operations 🔐. These issues are assumed to be under the control of either or both the sender and recipient 🛡️. Both the sender and recipient must permit the exchange of messages and arrange the exchange of necessary keys and certificates for cryptographic operations 🗝️.
3. Enumerated Status Codes 💖
This section defines and describes the detail sub-code 🎀. The detail value gives more info about the status and is defined relative to the subject of the status 🌟.
3.1 Other or Undefined Status
X.0.0 (Other undefined Status) is the only undefined error code 🫠. It should be used for all errors where only the class of the error is known 💜.
3.2 Address Status ✨
okay so this section is all about the address 💌. X.1.x codes tell the sender what went wrong with where the message was going (or where it came from) 🎀
X.1.0 Other address status
Something about the address in the message caused this DSN 🙈
X.1.1 Bad destination mailbox address
The mailbox doesn't exist 💀 For Internet mail names, this means the part to the left of the @ is invalid. This code is only useful for permanent failures, bestie 🫶
X.1.2 Bad destination system address
The destination system doesn't exist, or it just can't accept mail 😭 For Internet mail names, the part to the right of the @ is invalid for mail. This code is only useful for permanent failures.
X.1.3 Bad destination mailbox address syntax
The destination address was syntactically invalid, and this can apply to any field in the address 🧚 This code is only useful for permanent failures.
X.1.4 Destination mailbox address ambiguous
The mailbox address matches one or more recipients on the destination system, so it's giving "which one do you mean?" 👀 This can happen if a heuristic address mapping algorithm is used to map the specified address to a local mailbox name.
X.1.5 Destination address valid
The mailbox address was valid as specified 🌈 Use this status code for positive delivery reports, because it's the "yay, it worked" one ✨
X.1.6 Destination mailbox has moved, No forwarding address
This address was valid at some point, but mail isn't being accepted for it anymore 🥲 This code is only useful for permanent failures.
X.1.7 Bad sender's mailbox address syntax
The sender's address was syntactically invalid 💅 This can apply to any field in the address.
X.1.8 Bad sender's system address
The sender's system doesn't exist, or it can't accept return mail 🙃 For domain names, the part to the right of the @ is invalid for mail.
3.3 Mailbox Status 📬
this section is about the mailbox itself (the X.2.x codes) 🦋
X.2.0 Other or undefined mailbox status
The mailbox exists, but something about it caused this DSN to get sent 🤷♀️
X.2.1 Mailbox disabled, not accepting messages
The mailbox exists but isn't accepting messages right now 🥺 This might be a permanent error if the mailbox will never be re-enabled, or a transient error if it's only temporarily disabled.
X.2.2 Mailbox full
The mailbox is full because the user went over a per-mailbox administrative quota or the physical capacity 📦 The general vibe is that the recipient can delete messages to make space. Use this code as a persistent transient failure.
X.2.3 Message length exceeds administrative limit
A per-mailbox administrative message length limit got exceeded 🚫 Use this status code when that per-mailbox limit is less than the general system limit. This code should be used as a permanent failure.
X.2.4 Mailing list expansion problem
The mailbox is a mailing list address, and the list couldn't be expanded 😵💫 This code may be a permanent failure or a persistent transient failure.
3.4 Mail system status 🖥️
this one is all about the system (X.3.x) 💜
X.3.0 Other or undefined mail system status
The destination system exists and normally accepts mail, but something about the system caused this DSN 🌸
X.3.1 Mail system full
Mail system storage has been exceeded 💾 The general semantics imply that the individual recipient may not be able to delete material to make room, so this is only useful as a persistent transient error.
X.3.2 System not accepting network messages
The host where the mailbox lives isn't accepting messages right now 😴 Examples of this include an immanent shutdown, excessive load, or system maintenance. This is useful for both permanent and persistent transient errors.
X.3.3 System not capable of selected features
The features the message asked for aren't supported by the destination system 🙅♀️ This can happen in gateways, when features from one domain can't be mapped onto the supported feature in another.
X.3.4 Message too big for system
The message is bigger than the per-message size limit 🐘 That limit might be for physical or administrative reasons. This is only useful as a permanent error.
X.3.5 System incorrectly configured
The system isn't configured in a way that lets it accept this message 🛠️
3.5 Network and Routing Status 🗺️
okay this section is about the networking and routing drama (X.4.x) 🌊
X.4.0 Other or undefined network or routing status
Something went wrong with the networking, but it's not clear what, or none of the other detail codes can describe it well 🌀
X.4.1 No answer from host
The outbound connection attempt wasn't answered, because the remote system was either busy or couldn't take a call 📞 This is only useful as a persistent transient error.
X.4.2 Bad connection
The outbound connection was established, but it couldn't finish the message transaction, either because of a time-out or inadequate connection quality 📶 This is only useful as a persistent transient error.
X.4.3 Directory server failure
The network system couldn't forward the message because a directory server was unavailable 🫠 This is only useful as a persistent transient error.
The inability to connect to an Internet DNS server is one example of the directory server failure error 🌐
X.4.4 Unable to route
The mail system couldn't figure out the next hop for the message, because the routing information it needed wasn't available from the directory server 🧭 This is useful for both permanent and persistent transient errors.
A DNS lookup that only returns an SOA (Start of Administration) record for a domain name is one example of the unable to route error 👀
X.4.5 Mail system congestion
The mail system couldn't deliver the message because it was congested 🚗💨 This is only useful as a persistent transient error.
X.4.6 Routing loop detected
The message got forwarded too many times because of a routing loop 🔁 This can be caused by incorrect routing tables or a user-forwarding loop. This is only useful as a persistent transient error.
X.4.7 Delivery time expired
The rejecting system thought the message was too old ⌛ That's either because it sat on that host too long, or because the time-to-live value the sender set got exceeded. If possible, the code for the actual problem found when delivery was attempted should be returned instead of this one 💖
3.6 Mail Delivery Protocol Status 📮
this section covers the protocol itself (X.5.x) 🎀
X.5.0 Other or undefined protocol status
Something was wrong with the protocol needed to deliver the message to the next hop, and none of the other detail codes can describe it well 😩
X.5.1 Invalid command
A mail transaction protocol command was issued that was either out of sequence or unsupported 🙅♀️ This is only useful as a permanent error.
X.5.2 Syntax error
A mail transaction protocol command was issued that couldn't be interpreted, either because the syntax was wrong or the command isn't recognized 🤔 This is only useful as a permanent error.
X.5.3 Too many recipients
More recipients were specified for the message than the protocol could have delivered to 👥 This error should normally result in the message being split into two, with the remaining recipients delivered on a later delivery attempt. It's included in this list in case that splitting isn't possible ✂️
X.5.4 Invalid command arguments
A valid mail transaction protocol command was issued with invalid arguments, either because they were out of range or they represented features nobody recognizes 🫣 This is only useful as a permanent error.
X.5.5 Wrong protocol version
A protocol version mismatch happened that the communicating parties couldn't resolve automatically 🥴
3.7 Message Content or Message Media Status 🎞️
last but not least, this section is about the content and media of the message (X.6.x) 💅✨
X.6.0 Other or undefined media error
Something about the message content made it undeliverable, and none of the other detail codes can describe it well 🌪️
X.6.1 Media not supported
The message's media isn't supported by either the delivery protocol or the next system in the forwarding path 📵 This is only useful as a permanent error.
X.6.2 Conversion required and prohibited
The content has to be converted before it can be delivered, but conversion isn't allowed 🚷 That prohibition might come from the sender in the message itself, or from the policy of the sending host.
X.6.3 Conversion required but not supported
The message content has to be converted to be forwarded, but no host in the forwarding path can do it, or it isn't possible or practical 🧱 This can happen when an ESMTP gateway supports 8bit transport but can't downgrade the message to 7 bit, which the next hop requires.
X.6.4 Conversion with loss performed
This is a warning for the sender 🐣 The delivery worked, but it needed a conversion that lost some data. This might also be a permanent error if the sender said conversion with loss is prohibited for the message.
X.6.5 Conversion Failed
A conversion was required, but it didn't work 💔 This may be useful as a permanent or persistent temporary notification.
3.8 Security or Policy Status 🔐
X.7.0 Other or undefined security status 💀 Something security-related caused the message to bounce, and none of the other detail codes can really describe it. This one also works when the condition can't be explained any further because of security policies in force.
X.7.1 Delivery not authorized, message refused 🚫 The sender isn't allowed to send to this destination. That can happen with per-host or per-recipient filtering. This memo doesn't weigh in on whether any of that filtering is a good idea 🙈, it just gives you a way to report it. Only useful as a permanent error.
X.7.2 Mailing list expansion prohibited 📬 The sender isn't authorized to send a message to the mailing list they're aiming for. Only useful as a permanent error.
X.7.3 Security conversion required but not possible 🔄 Delivery needed a conversion from one secure messaging protocol to another, and that conversion just wasn't possible. Only useful as a permanent error.
X.7.4 Security features not supported ⛔ The message had security features, like secure authentication, that the delivery protocol couldn't support. Only useful as a permanent error.
X.7.5 Cryptographic failure 🔑 A transport system that's otherwise allowed to validate or decrypt a message in transit couldn't do it, because necessary information like a key was missing or invalid.
X.7.6 Cryptographic algorithm not supported 🧩 A transport system that's otherwise allowed to validate or decrypt a message couldn't do it, because the algorithm it needed isn't supported.
X.7.7 Message integrity failure 🫠 A transport system that's otherwise allowed to validate a message couldn't, because the message was corrupted or altered. This may be useful as a permanent, transient persistent, or successful delivery code.
4. Normative References ✨
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
- [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
5. Security Considerations 🚨
Okay bestie, this part is SERIOUS 😭 This document describes a status code system with increased precision. And that extra precision can disclose more about how an internal mail system is put together than what's already out there. So use these status codes with care, because you could be handing over details you didn't mean to share 🫶
Appendix A - Collected Status Codes 🗂️
X.1.0 Other address status
X.1.1 Bad destination mailbox address
X.1.2 Bad destination system address
X.1.3 Bad destination mailbox address syntax
X.1.4 Destination mailbox address ambiguous
X.1.5 Destination mailbox address valid
X.1.6 Mailbox has moved
X.1.7 Bad sender's mailbox address syntax
X.1.8 Bad sender's system address
X.2.0 Other or undefined mailbox status
X.2.1 Mailbox disabled, not accepting messages
X.2.2 Mailbox full
X.2.3 Message length exceeds administrative limit.
X.2.4 Mailing list expansion problem
X.3.0 Other or undefined mail system status
X.3.1 Mail system full
X.3.2 System not accepting network messages
X.3.3 System not capable of selected features
X.3.4 Message too big for system
X.4.0 Other or undefined network or routing status
X.4.1 No answer from host
X.4.2 Bad connection
X.4.3 Routing server failure
X.4.4 Unable to route
X.4.5 Network congestion
X.4.6 Routing loop detected
X.4.7 Delivery time expired
X.5.0 Other or undefined protocol status
X.5.1 Invalid command
X.5.2 Syntax error
X.5.3 Too many recipients
X.5.4 Invalid command arguments
X.5.5 Wrong protocol version
X.6.0 Other or undefined media error
X.6.1 Media not supported
X.6.2 Conversion required and prohibited
X.6.3 Conversion required but not supported
X.6.4 Conversion with loss performed
X.6.5 Conversion failed
X.7.0 Other or undefined security status
X.7.1 Delivery not authorized, message refused
X.7.2 Mailing list expansion prohibited
X.7.3 Security conversion required but not possible
X.7.4 Security features not supported
X.7.5 Cryptographic failure
X.7.6 Cryptographic algorithm not supported
X.7.7 Message integrity failureAppendix B - Changes from RFC1893 🔁
- Changed Authors contact information.
- Updated required standards boilerplate.
- Edited the text to make it spell-checker and grammar checker compliant.
- Modified the text describing the persistent transient failure to more closely reflect current practice and understanding.
- Eliminated the restriction on the X.4.7 codes limiting them to persistent transient errors.
Author's Address 💌
Gregory M. Vaudreuil
Lucent Technologies
7291 Williamson Rd
Dallas, Tx. 75214
Phone: +1 214 823 9325
EMail: GregV@ieee.orgFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3463 2003-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms