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.
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
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
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