summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1893.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1893.txt')
-rw-r--r--doc/rfc/rfc1893.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc1893.txt b/doc/rfc/rfc1893.txt
new file mode 100644
index 0000000..9ca4efb
--- /dev/null
+++ b/doc/rfc/rfc1893.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group G. Vaudreuil
+Request for Comments: 1893 Octel Network Services
+Category: Standards Track January 1996
+
+
+ Enhanced Mail System Status Codes
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Overview
+
+ There currently is not a standard mechanism for the reporting of mail
+ system errors except for the limited set offered by SMTP and the
+ system specific text descriptions sent in mail messages. There is a
+ pressing need for a rich machine readable status code for use in
+ delivery status notifications [DSN]. This document proposes a new
+ set of status codes for this purpose.
+
+ SMTP [SMTP] error codes have historically been used for reporting
+ mail system errors. Because of limitations in the SMTP code design,
+ these are not suitable for use in delivery status notifications.
+ SMTP provides about 12 useful codes for delivery reports. The
+ majority of the codes are protocol specific response codes such as
+ the 354 response to the SMTP data command. Each of the 12 useful
+ codes are each overloaded to indicate several error conditions each.
+ SMTP suffers some scars from history, most notably the unfortunate
+ damage to the reply code extension mechanism by uncontrolled use.
+ This proposal facilitates future extensibility by requiring the
+ client to interpret unknown error codes according to the theory of
+ codes while requiring servers to register new response codes.
+
+ The SMTP theory of reply codes partitioned in the number space such a
+ manner that the remaining available codes will not provide the space
+ needed. The most critical example is the existence of only 5
+ remaining codes for mail system errors. The mail system
+ classification includes both host and mailbox error conditions. The
+ remaining third digit space would be completely consumed as needed to
+ indicate MIME and media conversion errors and security system errors.
+
+ A revision to the SMTP theory of reply codes to better distribute the
+ error conditions in the number space will necessarily be incompatible
+ with SMTP. Further, consumption of the remaining reply-code number
+
+
+
+Vaudreuil Standards Track [Page 1]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ space for delivery notification reporting will reduce the available
+ codes for new ESMTP extensions.
+
+ The following proposal is based on the SMTP theory of reply codes.
+ It adopts the success, permanent error, and transient error semantics
+ of the first value, with a further description and classification in
+ the second. This proposal re-distributes the classifications to
+ better distribute the error conditions, such as separating mailbox
+ from host errors.
+
+2. Status Codes
+
+ This document defines a new set of status codes to report mail system
+ conditions. These status codes are intended to be used for media and
+ language independent status reporting. They are not intended 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*3digit
+
+ White-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 consist of three numerical fields separated by ".". The
+ first sub-code indicates whether the delivery attempt was successful.
+ The second sub-code indicates the probable source of any delivery
+ anomalies, and the third sub-code indicates a precise error
+ condition.
+
+ The codes space defined 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. 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 large, it is not intended that published status codes
+ will ever be redefined or eliminated. Clients should preserve the
+ extensibility of the code space by reporting the general error
+ described in the subject sub-code when the specific detail is
+ unrecognized.
+
+
+
+
+Vaudreuil Standards Track [Page 2]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ The class sub-code provides a broad classification of the status.
+ The enumerated values the class are defined as:
+
+ 2.X.X Success
+
+ Success specifies that the DSN is reporting a positive delivery
+ action. Detail sub-codes may provide notification of
+ transformations required for delivery.
+
+ 4.X.X Persistent Transient Failure
+
+ A persistent transient failure is one in which the message as
+ sent is valid, but some temporary event prevents the successful
+ sending of the message. Sending in the future may be successful.
+
+ 5.X.X Permanent Failure
+
+ A permanent failure is one which is not likely to be resolved by
+ resending the message in the current form. Some change to the
+ message or the destination must be made for successful delivery.
+
+ A client must recognize and report class sub-code even where
+ subsequent subject sub-codes are unrecognized.
+
+ 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 additional detail provided
+ by the detail sub-code is not recognized. The enumerated values for
+ the subject sub-code are:
+
+ X.0.X Other or Undefined Status
+
+ There is no additional subject information available.
+
+ X.1.X Addressing Status
+
+ The address status reports on the originator or destination
+ address. It may include address syntax or validity. These
+ errors can generally be corrected by the sender and retried.
+
+ X.2.X Mailbox Status
+
+ Mailbox status indicates that something having to do with the
+ mailbox has cause this DSN. Mailbox issues are assumed to be
+ under the general control of the recipient.
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 3]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.3.X Mail System Status
+
+ Mail system status indicates that something having to do
+ with the destination system has caused this DSN. System
+ issues are assumed to be under the general control of the
+ destination system administrator.
+
+ X.4.X Network and Routing Status
+
+ The networking or routing codes report status about the
+ delivery system itself. These system components include any
+ necessary infrastructure such as directory and routing
+ services. Network issues are assumed to be under the
+ control of the destination or intermediate system
+ administrator.
+
+ X.5.X Mail Delivery Protocol Status
+
+ The mail delivery protocol status codes report failures
+ involving the message delivery protocol. These failures
+ include the full range of problems resulting from
+ implementation errors or an unreliable connection. Mail
+ delivery protocol issues may be controlled by many parties
+ including the originating system, destination system, or
+ intermediate system administrators.
+
+ X.6.X Message Content or Media Status
+
+ The message content or media status codes report failures
+ involving the content of the message. These codes report
+ failures due to translation, transcoding, or otherwise
+ unsupported message media. Message content or media issues
+ are under the control of both the sender and the receiver,
+ both of whom must support a common set of supported
+ content-types.
+
+ X.7.X Security or Policy Status
+
+ The security or policy status codes report failures
+ involving policies such as per-recipient or per-host
+ filtering and cryptographic operations. Security and policy
+ status 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.
+
+
+
+
+
+Vaudreuil Standards Track [Page 4]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+3. Enumerated Status Codes
+
+ The following section defines and describes the detail sub-code. The
+ detail value provides more information 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
+
+ Other undefined status is the only undefined error code. It
+ should be used for all errors for which only the class of the
+ error is known.
+
+ 3.2 Address Status
+
+ X.1.0 Other address status
+
+ Something about the address specified in the message caused
+ this DSN.
+
+ X.1.1 Bad destination mailbox address
+
+ The mailbox specified in the address does not exist. For
+ Internet mail names, this means the address portion to the
+ left of the "@" sign is invalid. This code is only useful
+ for permanent failures.
+
+ X.1.2 Bad destination system address
+
+ The destination system specified in the address does not
+ exist or is incapable of accepting mail. For Internet mail
+ names, this means the address portion to the right of the
+ "@" is invalid for mail. This codes is only useful for
+ permanent failures.
+
+ X.1.3 Bad destination mailbox address syntax
+
+ The destination address was syntactically invalid. 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 as specified matches one or more
+ recipients on the destination system. This may result if a
+ heuristic address mapping algorithm is used to map the
+ specified address to a local mailbox name.
+
+
+
+Vaudreuil Standards Track [Page 5]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.1.5 Destination address valid
+
+ This mailbox address as specified was valid. This status
+ code should be used for positive delivery reports.
+
+ X.1.6 Destination mailbox has moved, No forwarding address
+
+ The mailbox address provided was at one time valid, but mail
+ is no longer being accepted for that address. 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 specified in the address does not exist
+ or is incapable of accepting return mail. For domain names,
+ this means the address portion to the right of the "@" is
+ invalid for mail.
+
+ 3.3 Mailbox Status
+
+ X.2.0 Other or undefined mailbox status
+
+ The mailbox exists, but something about the destination
+ mailbox has caused the sending of this DSN.
+
+ X.2.1 Mailbox disabled, not accepting messages
+
+ The mailbox exists, but is not accepting messages. This may
+ be a permanent error if the mailbox will never be re-enabled
+ or a transient error if the mailbox is only temporarily
+ disabled.
+
+ X.2.2 Mailbox full
+
+ The mailbox is full because the user has exceeded a
+ per-mailbox administrative quota or physical capacity. The
+ general semantics implies that the recipient can delete
+ messages to make more space available. This code should be
+ used as a persistent transient failure.
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 6]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.2.3 Message length exceeds administrative limit
+
+ A per-mailbox administrative message length limit has been
+ exceeded. This status code should be used when the
+ per-mailbox message length 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 mailing list
+ was unable to be expanded. This code may represent a
+ permanent failure or a persistent transient failure.
+
+ 3.4 Mail system status
+
+ X.3.0 Other or undefined mail system status
+
+ The destination system exists and normally accepts mail, but
+ something about the system has caused the generation of 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 for additional
+ messages. This is useful only as a persistent transient
+ error.
+
+ X.3.2 System not accepting network messages
+
+ The host on which the mailbox is resident is not accepting
+ messages. Examples of such conditions include an immanent
+ shutdown, excessive load, or system maintenance. This is
+ useful for both permanent and permanent transient errors.
+
+ X.3.3 System not capable of selected features
+
+ Selected features specified for the message are not
+ supported by the destination system. This can occur in
+ gateways when features from one domain cannot be mapped onto
+ the supported feature in another.
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 7]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.3.4 Message too big for system
+
+ The message is larger than per-message size limit. This
+ limit may either be for physical or administrative reasons.
+ This is useful only as a permanent error.
+
+ X.3.5 System incorrectly configured
+
+ The system is not configured in a manner which will permit
+ it to accept this message.
+
+ 3.5 Network and Routing Status
+
+ X.4.0 Other or undefined network or routing status
+
+ Something went wrong with the networking, but it is not
+ clear what the problem is, or the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.4.1 No answer from host
+
+ The outbound connection attempt was not answered, either
+ because the remote system was busy, or otherwise unable to
+ take a call. This is useful only as a persistent transient
+ error.
+
+ X.4.2 Bad connection
+
+ The outbound connection was established, but was otherwise
+ unable to complete the message transaction, either because
+ of time-out, or inadequate connection quality. This is
+ useful only as a persistent transient error.
+
+ X.4.3 Directory server failure
+
+ The network system was unable to forward the message,
+ because a directory server was unavailable. This is useful
+ only 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 was unable to determine the next hop for the
+ message because the necessary routing information was
+ unavailable from the directory server. This is useful for
+ both permanent and persistent transient errors.
+
+
+
+Vaudreuil Standards Track [Page 8]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ A DNS lookup returning only 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 was unable to deliver the message because
+ the mail system was congested. This is useful only as a
+ persistent transient error.
+
+ X.4.6 Routing loop detected
+
+ A routing loop caused the message to be forwarded too many
+ times, either because of incorrect routing tables or a user
+ forwarding loop. This is useful only as a persistent
+ transient error.
+
+ X.4.7 Delivery time expired
+
+ The message was considered too old by the rejecting system,
+ either because it remained on that host too long or because
+ the time-to-live value specified by the sender of the
+ message was exceeded. If possible, the code for the actual
+ problem found when delivery was attempted should be returned
+ rather than this code. This is useful only as a persistent
+ transient error.
+
+ 3.6 Mail Delivery Protocol Status
+
+ X.5.0 Other or undefined protocol status
+
+ Something was wrong with the protocol necessary to deliver
+ the message to the next hop and the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.5.1 Invalid command
+
+ A mail transaction protocol command was issued which was
+ either out of sequence or unsupported. This is useful only
+ as a permanent error.
+
+ X.5.2 Syntax error
+
+ A mail transaction protocol command was issued which could
+ not be interpreted, either because the syntax was wrong or
+ the command is unrecognized. This is useful only as a
+ permanent error.
+
+
+
+
+Vaudreuil Standards Track [Page 9]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.5.3 Too many recipients
+
+ More recipients were specified for the message than could
+ have been delivered by the protocol. This error should
+ normally result in the segmentation of the message into two,
+ the remainder of the recipients to be delivered on a
+ subsequent delivery attempt. It is included in this list in
+ the event that such segmentation is not possible.
+
+ X.5.4 Invalid command arguments
+
+ A valid mail transaction protocol command was issued with
+ invalid arguments, either because the arguments were out of
+ range or represented unrecognized features. This is useful
+ only as a permanent error.
+
+ X.5.5 Wrong protocol version
+
+ A protocol version mis-match existed which could not be
+ automatically resolved by the communicating parties.
+
+ 3.7 Message Content or Message Media Status
+
+ X.6.0 Other or undefined media error
+
+ Something about the content of a message caused it to be
+ considered undeliverable and the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.6.1 Media not supported
+
+ The media of the message is not supported by either the
+ delivery protocol or the next system in the forwarding path.
+ This is useful only as a permanent error.
+
+ X.6.2 Conversion required and prohibited
+
+ The content of the message must be converted before it can
+ be delivered and such conversion is not permitted. Such
+ prohibitions may be the expression of the sender in the
+ message itself or the policy of the sending host.
+
+ X.6.3 Conversion required but not supported
+
+ The message content must be converted to be forwarded but
+ such conversion is not possible or is not practical by a
+ host in the forwarding path. This condition may result when
+ an ESMTP gateway supports 8bit transport but is not able to
+
+
+
+Vaudreuil Standards Track [Page 10]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ downgrade the message to 7 bit as required for the next hop.
+
+ X.6.4 Conversion with loss performed
+
+ This is a warning sent to the sender when message delivery
+ was successfully but when the delivery required a conversion
+ in which some data was lost. This may also be a permanant
+ error if the sender has indicated that conversion with loss
+ is prohibited for the message.
+
+ X.6.5 Conversion Failed
+
+ A conversion was required but was unsuccessful. 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 related to security caused the message to be
+ returned, and the problem cannot be well expressed with any
+ of the other provided detail codes. This status code may
+ also be used when the condition cannot be further described
+ because of security policies in force.
+
+ X.7.1 Delivery not authorized, message refused
+
+ The sender is not authorized to send to the destination.
+ This can be the result of per-host or per-recipient
+ filtering. This memo does not discuss the merits of any
+ such filtering, but provides a mechanism to report such.
+ This is useful only as a permanent error.
+
+ X.7.2 Mailing list expansion prohibited
+
+ The sender is not authorized to send a message to the
+ intended mailing list. This is useful only as a permanent
+ error.
+
+ X.7.3 Security conversion required but not possible
+
+ A conversion from one secure messaging protocol to another
+ was required for delivery and such conversion was not
+ possible. This is useful only as a permanent error.
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 11]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.7.4 Security features not supported
+
+ A message contained security features such as secure
+ authentication which could not be supported on the delivery
+ protocol. This is useful only as a permanent error.
+
+ X.7.5 Cryptographic failure
+
+ A transport system otherwise authorized to validate or
+ decrypt a message in transport was unable to do so because
+ necessary information such as key was not available or such
+ information was invalid.
+
+ X.7.6 Cryptographic algorithm not supported
+
+ A transport system otherwise authorized to validate or
+ decrypt a message was unable to do so because the necessary
+ algorithm was not supported.
+
+ X.7.7 Message integrity failure
+
+ A transport system otherwise authorized to validate a
+ message was unable to do so because the message was
+ corrupted or altered. This may be useful as a permanent,
+ transient persistent, or successful delivery code.
+
+4. References
+
+ [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+ Delivery Status Notifications", RFC 1894, University of
+ Tennessee, Octel Network Services, January 1996.
+
+5. Security Considerations
+
+ This document describes a status code system with increased
+ precision. Use of these status codes may disclose additional
+ information about how an internal mail system is implemented beyond
+ that currently available.
+
+6. Acknowledgments
+
+ The author wishes to offer special thanks to Harald Alvestrand, Marko
+ Kaittola, and Keith Moore for their extensive review and constructive
+ suggestions.
+
+
+
+
+Vaudreuil Standards Track [Page 12]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+7. Author's Address
+
+ Gregory M. Vaudreuil
+ Octel Network Services
+ 17060 Dallas Parkway
+ Suite 214
+ Dallas, TX 75248-1905
+
+ Voice/Fax: +1-214-733-2722
+ EMail: Greg.Vaudreuil@Octel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 13]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+8. Appendix - 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
+
+
+
+
+
+Vaudreuil Standards Track [Page 14]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ 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 failure
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 15]
+