Enhanced Mail System Status Codes
RFC 1893

 
Document Type RFC - Proposed Standard (January 1996; No errata)
Obsoleted by RFC 3463
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1893 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)

Email authors IPR References Referenced by Nits Search lists

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
Show full document text