[1] 編集上の差異を除いた RFC1893 と RFC3463 の差分です。

整形が行われているため、単純に diff しただけでは大量に意味の無い差分が出てきます。

 -Network Working Group                                        G. Vaudreuil
 -Request for Comments: 1893                         Octel Network Services
 -Category: Standards Track                                    January 1996
 +Network Working Group                                       G. Vaudreuil
 +Request for Comments: 3463                           Lucent Technologies
 +Obsoletes: 1893                                             January 2003
 +Category: Standards Track

「Copyright Notice」, 「Abstract」, 「Table of Contents」追加

There currently is not is a need for a standard mechanism for the reporting of mail system errors except for richer than 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, human language independent status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose.

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. 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 are] partitioned in the number space in 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 following proposal status code set 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 Structure

This document defines a new set of status codes to report mail system conditions. These status codes are intended to be used used for media and language independent status reporting. They are not intended for system specific diagnostics.

The class sub-code provides a broad classification of the status. The enumerated values the for each class are defined as:

2.XXX.XXX Success

4.XXX.XXX Persistent Transient Failure

A persistent transient failure is one in which the message as sent is valid, but persistence of some temporary event prevents the successful sending of condition has caused abandonment or delay of attempts to send the message. If this code accompanies a delivery failure report, Sending in the future may be successful.

5.XXX.XXX Permanent Failure

X.0.XX]X 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

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.XXX 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 which must support a common set of supported content-types.

X.7.XXX Security or Policy Status

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.

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.

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.

The message content must be converted in order 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 downgrade the message to 7 bit as required for the next hop.

4. Normative 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 RFC 3464, January 2003.