As per Relevance of the word delivery, we have this rfc below:
Network Working Group N.
Request for Comments: RFC 2034
Category: Standards Track October 1996
SMTP Service Extension
Returning Enhanced Error
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1.
This memo defines an extension to the SMTP service [RFC-821, RFC
1869] whereby an SMTP server augments its responses with the
mail system status codes defined in RFC 1893. These codes can
be used to provide more informative explanations of error conditions
especially in the context of the delivery status notifications
defined in RFC 1894.
2.
Although SMTP is widely and robustly deployed, various
have been requested by parts of the Internet community.
particular, in the modern, international, and multilingual Internet
need exists to assign codes to specific error conditions that can
translated into different languages. RFC 1893 defines such a set
status codes and RFC 1894 defines a mechanism to send such
material to users. However, in many cases the agent creating the
1894 delivery status notification is doing so in response to
it received from a remote SMTP server
As such, remote servers need a mechanism for embedding
status codes in their responses as well as a way to indicate to
client when they are in fact doing this. This memo uses the
extension mechanism described in RFC 1869 to define such a mechanism
Freed Standards Track [Page 1]
RFC 2034 SMTP Enhanced Error Codes October 1996
3. Framework for the Enhanced Error Statuses
The enhanced error statuses transport extension is laid out
follows
(1) the name of the SMTP service extension defined here
Enhanced-Status-Codes
(2) the EHLO keyword value associated with the extension
ENHANCEDSTATUSCODES
(3) no parameter is used with the ENHANCEDSTATUSCODES
keyword
(4) the text part of all 2xx, 4xx, and 5xx SMTP
other than the initial greeting and any response
HELO or EHLO are prefaced with a status code as
in RFC 1893. This status code is always followed by
or more spaces
(5) no additional SMTP verbs are defined by this extension
and
(6) the next section specifies how support for
extension affects the behavior of a server and
SMTP
4. The Enhanced-Status-Codes service
Servers supporting the Enhanced-Status-Codes extension must
the text part of almost all response lines with a status code. As
RFC 1893, the syntax of these status codes is given by the ABNF
status-code ::= class "." subject "."
class ::= "2" / "4" / "5"
subject ::= 1*3
detail ::= 1*3
These codes must appear in all 2xx, 4xx, and 5xx response lines
than initial greeting and any response to HELO or EHLO. Note that 3
responses are NOT included in this list
All status codes returned by the server must agree with the
response code, that is, a 2xx response must incorporate a 2.X.X code
a 4xx response must incorporate a 4.X.X code, and a 5xx response
incorporate a 5.X.X code
Freed Standards Track [Page 2]
RFC 2034 SMTP Enhanced Error Codes October 1996
When responses are continued across multiple lines the same
code must appear at the beginning of the text in each line of
response
Servers supporting this extension must attach enhanced status
to their responses regardless of whether or not EHLO is employed
the client
5. Status Codes and
This specification does not provide a means for clients to
that status codes be returned or that they not be returned;
compliant server includes these codes in the responses it
regardless of whether or not the client expects them. This
somewhat different from most other SMTP extensions, where
speaking a client must specifically make a request before
extended server behaves any differently than an unextended server
The omission of client negotiation in this case is
intentional: Given the generally poor state of SMTP server error
implementation it is felt that any step taken towards
comprehensible error codes is something that all clients, extended
not, should benefit from
IMPORTANT NOTE: The use of this approach in this extension should
seen as a very special case. It MUST NOT be taken as a license
future SMTP extensions to dramatically change the nature of
client-server interaction without proper announcement from the
and a corresponding enabling command from the client
6. Usage
The following dialogue illustrates the use of enhanced status
by a server
S: connection on TCP port 25>
C: connection to server
S: 220 dbc.mtview.ca.us SMTP service
C: EHLO ymir.claremont.
S: 250-dbc.mtview.ca.us says
S: 250
C: MAIL FROM:
S: 250 2.1.0 Originator
C: RCPT TO:
S: 250 2.1.5 Recipient
C: RCPT TO:
S: 550 5.1.1 Mailbox "nosuchuser" does not
C: RCPT TO:
S: 551-5.7.1 Forwarding to remote hosts
Freed Standards Track [Page 3]
RFC 2034 SMTP Enhanced Error Codes October 1996
S: 551 5.7.1 Select another host to act as your
C:
S: 354 Send message, ending in CRLF.CRLF
...
C: .
S: 250 2.6.0 Message
C:
S: 221 2.0.0
The client that receives these responses might then send
nondelivery notification of the general form
Date: Mon, 11 Mar 1996 09:21:47 -0400
From: Mail Delivery Subsystem
Subject: Returned
To:
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status
boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU
--JAA13167.773673707/YMIR.CLAREMONT.
content-type: text/plain; charset=us-
----- Mail was successfully relayed
the following addresses -----
----- The following addresses had delivery problems -----
(Mailbox "nosuchuser" does not exist
(Forwarding to remote hosts disabled
--JAA13167.773673707/YMIR.CLAREMONT.
content-type: message/delivery-
Reporting-MTA: dns; ymir.claremont.
Original-Recipient: rfc822;mrose@dbc.mtview.ca.
Final-Recipient: rfc822;mrose@dbc.mtview.ca.
Action:
Status: 2.1.5 (Destination address valid
Diagnostic-Code: smtp
250 Recipient
Remote-MTA: dns; dbc.mtview.ca.
Freed Standards Track [Page 4]
RFC 2034 SMTP Enhanced Error Codes October 1996
Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.
Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.
Action:
Status: 5.1.1 (Bad destination mailbox address
Diagnostic-Code: smtp
550 Mailbox "nosuchuser" does not
Remote-MTA: dns; dbc.mtview.ca.
Original-Recipient: rfc822;remoteuser@isi.
Final-Recipient: rfc822;remoteuser@isi.
Action:
Status: 5.7.1 (Delivery not authorized, message refused
Diagnostic-Code: smtp
551 Forwarding to remote hosts
Select another host to act as your
Remote-MTA: dns; dbc.mtview.ca.
--JAA13167.773673707/YMIR.CLAREMONT.
content-type: message/rfc822
[original message goes here
--JAA13167.773673707/YMIR.CLAREMONT.EDU--
Note that in order to reduce clutter the reporting MTA has
enhanced status code information from the diagnostic-code fields
has generated
7. Security
Additional detail in server responses axiomatically
additional information about the server. It is conceivable
additional information of this sort may be of assistance
circumventing server security. The advantages of provides
information must always be weighed against the security
of doing so
Freed Standards Track [Page 5]
RFC 2034 SMTP Enhanced Error Codes October 1996
8.
[RFC-821]
Postel, J., "Simple Mail Transfer Protocol", RFC 821,
August, 1982. (August, 1982).
[RFC-1869]
Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed
N., "SMTP Service Extensions", RFC 1869, November, 1995.
[RFC-1893]
Vaudreuil, G., "Enhanced Mail System Status Codes",
1893, January, 1996.
[RFC-1894]
Moore, K., Vaudreuil, G., "An Extensible Message
for Delivery Status Notifications", RFC 1894, January
1996.
9. Author
Ned
Innosoft International, Inc
1050 East Garvey Avenue
West Covina, CA 91790
tel: +1 818 919 3600 fax: +1 818 919 3614
email: ned@innosoft.
Freed Standards Track [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
