📄 rfc1893.txt
字号:
Network Working Group G. VaudreuilRequest for Comments: 1893 Octel Network ServicesCategory: Standards Track January 1996 Enhanced Mail System Status CodesStatus 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 numberVaudreuil 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 19963. 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⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -