summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2034.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2034.txt')
-rw-r--r--doc/rfc/rfc2034.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2034.txt b/doc/rfc/rfc2034.txt
new file mode 100644
index 0000000..14f0ab3
--- /dev/null
+++ b/doc/rfc/rfc2034.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group N. Freed
+Request for Comments: RFC 2034 Innosoft
+Category: Standards Track October 1996
+
+
+ SMTP Service Extension for
+ Returning Enhanced Error 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. Abstract
+
+ This memo defines an extension to the SMTP service [RFC-821, RFC-
+ 1869] whereby an SMTP server augments its responses with the enhanced
+ mail system status codes defined in RFC 1893. These codes can then
+ be used to provide more informative explanations of error conditions,
+ especially in the context of the delivery status notifications format
+ defined in RFC 1894.
+
+2. Introduction
+
+ Although SMTP is widely and robustly deployed, various extensions
+ have been requested by parts of the Internet community. In
+ particular, in the modern, international, and multilingual Internet a
+ need exists to assign codes to specific error conditions that can be
+ translated into different languages. RFC 1893 defines such a set of
+ status codes and RFC 1894 defines a mechanism to send such coded
+ material to users. However, in many cases the agent creating the RFC
+ 1894 delivery status notification is doing so in response to errors
+ it received from a remote SMTP server.
+
+ As such, remote servers need a mechanism for embedding enhanced
+ status codes in their responses as well as a way to indicate to a
+ client when they are in fact doing this. This memo uses the SMTP
+ 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 Extension
+
+ The enhanced error statuses transport extension is laid out as
+ follows:
+
+ (1) the name of the SMTP service extension defined here is
+ Enhanced-Status-Codes;
+
+ (2) the EHLO keyword value associated with the extension is
+ ENHANCEDSTATUSCODES;
+
+ (3) no parameter is used with the ENHANCEDSTATUSCODES EHLO
+ keyword;
+
+ (4) the text part of all 2xx, 4xx, and 5xx SMTP responses
+ other than the initial greeting and any response to
+ HELO or EHLO are prefaced with a status code as defined
+ in RFC 1893. This status code is always followed by one
+ or more spaces.
+
+ (5) no additional SMTP verbs are defined by this extension;
+ and,
+
+ (6) the next section specifies how support for the
+ extension affects the behavior of a server and client
+ SMTP.
+
+4. The Enhanced-Status-Codes service extension
+
+ Servers supporting the Enhanced-Status-Codes extension must preface
+ the text part of almost all response lines with a status code. As in
+ RFC 1893, the syntax of these status codes is given by the ABNF:
+
+ status-code ::= class "." subject "." detail
+ class ::= "2" / "4" / "5"
+ subject ::= 1*3digit
+ detail ::= 1*3digit
+
+ These codes must appear in all 2xx, 4xx, and 5xx response lines other
+ than initial greeting and any response to HELO or EHLO. Note that 3xx
+ responses are NOT included in this list.
+
+ All status codes returned by the server must agree with the primary
+ 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 must
+ 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 status
+ code must appear at the beginning of the text in each line of the
+ response.
+
+ Servers supporting this extension must attach enhanced status codes
+ to their responses regardless of whether or not EHLO is employed by
+ the client.
+
+5. Status Codes and Negotiation
+
+ This specification does not provide a means for clients to request
+ that status codes be returned or that they not be returned; a
+ compliant server includes these codes in the responses it sends
+ regardless of whether or not the client expects them. This is
+ somewhat different from most other SMTP extensions, where generally
+ speaking a client must specifically make a request before the
+ extended server behaves any differently than an unextended server.
+ The omission of client negotiation in this case is entirely
+ intentional: Given the generally poor state of SMTP server error code
+ implementation it is felt that any step taken towards more
+ comprehensible error codes is something that all clients, extended or
+ not, should benefit from.
+
+ IMPORTANT NOTE: The use of this approach in this extension should be
+ seen as a very special case. It MUST NOT be taken as a license for
+ future SMTP extensions to dramatically change the nature of SMTP
+ client-server interaction without proper announcement from the server
+ and a corresponding enabling command from the client.
+
+6. Usage Example
+
+ The following dialogue illustrates the use of enhanced status codes
+ by a server:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250-dbc.mtview.ca.us says hello
+ S: 250 ENHANCEDSTATUSCODES
+ C: MAIL FROM:<ned@ymir.claremont.edu>
+ S: 250 2.1.0 Originator <ned@ymir.claremont.edu> ok
+ C: RCPT TO:<mrose@dbc.mtview.ca.us>
+ S: 250 2.1.5 Recipient <mrose@dbc.mtview.ca.us> ok
+ C: RCPT TO:<nosuchuser@dbc.mtview.ca.us>
+ S: 550 5.1.1 Mailbox "nosuchuser" does not exist
+ C: RCPT TO:<remoteuser@isi.edu>
+ S: 551-5.7.1 Forwarding to remote hosts disabled
+
+
+
+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 forwarder
+ C: DATA
+ S: 354 Send message, ending in CRLF.CRLF.
+ ...
+ C: .
+ S: 250 2.6.0 Message accepted
+ C: QUIT
+ S: 221 2.0.0 Goodbye
+
+ The client that receives these responses might then send a
+ nondelivery notification of the general form:
+
+ Date: Mon, 11 Mar 1996 09:21:47 -0400
+ From: Mail Delivery Subsystem <mailer-daemon@ymir.claremont.edu>
+ Subject: Returned mail
+ To: <ned@ymir.claremont.edu>
+ MIME-Version: 1.0
+ Content-Type: multipart/report; report-type=delivery-status;
+ boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU"
+
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU
+ content-type: text/plain; charset=us-ascii
+
+ ----- Mail was successfully relayed to
+ the following addresses -----
+
+ <mrose@dbc.mtview.ca.us>
+
+ ----- The following addresses had delivery problems -----
+ <nosuchuser@dbc.mtview.ca.us>
+ (Mailbox "nosuchuser" does not exist)
+ <remoteuser@isi.edu>
+ (Forwarding to remote hosts disabled)
+
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU
+ content-type: message/delivery-status
+
+ Reporting-MTA: dns; ymir.claremont.edu
+
+ Original-Recipient: rfc822;mrose@dbc.mtview.ca.us
+ Final-Recipient: rfc822;mrose@dbc.mtview.ca.us
+ Action: relayed
+ Status: 2.1.5 (Destination address valid)
+ Diagnostic-Code: smtp;
+ 250 Recipient <mrose@dbc.mtview.ca.us> ok
+ Remote-MTA: dns; dbc.mtview.ca.us
+
+
+
+
+
+Freed Standards Track [Page 4]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+ Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
+ Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
+ Action: failed
+ Status: 5.1.1 (Bad destination mailbox address)
+ Diagnostic-Code: smtp;
+ 550 Mailbox "nosuchuser" does not exist
+ Remote-MTA: dns; dbc.mtview.ca.us
+
+ Original-Recipient: rfc822;remoteuser@isi.edu
+ Final-Recipient: rfc822;remoteuser@isi.edu
+ Action: failed
+ Status: 5.7.1 (Delivery not authorized, message refused)
+ Diagnostic-Code: smtp;
+ 551 Forwarding to remote hosts disabled
+ Select another host to act as your forwarder
+ Remote-MTA: dns; dbc.mtview.ca.us
+
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU
+ content-type: message/rfc822
+
+ [original message goes here]
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU--
+
+ Note that in order to reduce clutter the reporting MTA has omitted
+ enhanced status code information from the diagnostic-code fields it
+ has generated.
+
+7. Security Considerations
+
+ Additional detail in server responses axiomatically provides
+ additional information about the server. It is conceivable that
+ additional information of this sort may be of assistance in
+ circumventing server security. The advantages of provides additional
+ information must always be weighed against the security implications
+ of doing so.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 5]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+8. References
+
+ [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", RFC
+ 1893, January, 1996.
+
+ [RFC-1894]
+ Moore, K., Vaudreuil, G., "An Extensible Message Format
+ for Delivery Status Notifications", RFC 1894, January,
+ 1996.
+
+9. Author Address
+
+ Ned Freed
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+ tel: +1 818 919 3600 fax: +1 818 919 3614
+ email: ned@innosoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 6]
+