home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2034.txt < prev    next >
Text File  |  1996-10-27  |  10KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       N. Freed
  8. Request for Comments: RFC 2034                              Innosoft
  9. Category: Standards Track                               October 1996
  10.  
  11.  
  12.                        SMTP Service Extension for
  13.                      Returning Enhanced Error Codes
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. 1.  Abstract
  24.  
  25.    This memo defines an extension to the SMTP service [RFC-821, RFC-
  26.    1869] whereby an SMTP server augments its responses with the enhanced
  27.    mail system status codes defined in RFC 1893.  These codes can then
  28.    be used to provide more informative explanations of error conditions,
  29.    especially in the context of the delivery status notifications format
  30.    defined in RFC 1894.
  31.  
  32. 2.  Introduction
  33.  
  34.    Although SMTP is widely and robustly deployed, various extensions
  35.    have been requested by parts of the Internet community. In
  36.    particular, in the modern, international, and multilingual Internet a
  37.    need exists to assign codes to specific error conditions that can be
  38.    translated into different languages. RFC 1893 defines such a set of
  39.    status codes and RFC 1894 defines a mechanism to send such coded
  40.    material to users. However, in many cases the agent creating the RFC
  41.    1894 delivery status notification is doing so in response to errors
  42.    it received from a remote SMTP server.
  43.  
  44.    As such, remote servers need a mechanism for embedding enhanced
  45.    status codes in their responses as well as a way to indicate to a
  46.    client when they are in fact doing this. This memo uses the SMTP
  47.    extension mechanism described in RFC 1869 to define such a mechanism.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Freed                       Standards Track                     [Page 1]
  59.  
  60. RFC 2034               SMTP Enhanced Error Codes            October 1996
  61.  
  62.  
  63. 3.  Framework for the Enhanced Error Statuses Extension
  64.  
  65.    The enhanced error statuses transport extension is laid out as
  66.    follows:
  67.  
  68.    (1)   the name of the SMTP service extension defined here is
  69.          Enhanced-Status-Codes;
  70.  
  71.    (2)   the EHLO keyword value associated with the extension is
  72.          ENHANCEDSTATUSCODES;
  73.  
  74.    (3)   no parameter is used with the ENHANCEDSTATUSCODES EHLO
  75.          keyword;
  76.  
  77.    (4)   the text part of all 2xx, 4xx, and 5xx SMTP responses
  78.          other than the initial greeting and any response to
  79.          HELO or EHLO are prefaced with a status code as defined
  80.          in RFC 1893. This status code is always followed by one
  81.          or more spaces.
  82.  
  83.    (5)   no additional SMTP verbs are defined by this extension;
  84.          and,
  85.  
  86.    (6)   the next section specifies how support for the
  87.          extension affects the behavior of a server and client
  88.          SMTP.
  89.  
  90. 4.  The Enhanced-Status-Codes service extension
  91.  
  92.    Servers supporting the Enhanced-Status-Codes extension must preface
  93.    the text part of almost all response lines with a status code. As in
  94.    RFC 1893, the syntax of these status codes is given by the ABNF:
  95.  
  96.         status-code ::= class "." subject "." detail
  97.         class       ::= "2" / "4" / "5"
  98.         subject     ::= 1*3digit
  99.         detail      ::= 1*3digit
  100.  
  101.    These codes must appear in all 2xx, 4xx, and 5xx response lines other
  102.    than initial greeting and any response to HELO or EHLO. Note that 3xx
  103.    responses are NOT included in this list.
  104.  
  105.    All status codes returned by the server must agree with the primary
  106.    response code, that is, a 2xx response must incorporate a 2.X.X code,
  107.    a 4xx response must incorporate a 4.X.X code, and a 5xx response must
  108.    incorporate a 5.X.X code.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Freed                       Standards Track                     [Page 2]
  115.  
  116. RFC 2034               SMTP Enhanced Error Codes            October 1996
  117.  
  118.  
  119.    When responses are continued across multiple lines the same status
  120.    code must appear at the beginning of the text in each line of the
  121.    response.
  122.  
  123.    Servers supporting this extension must attach enhanced status codes
  124.    to their responses regardless of whether or not EHLO is employed by
  125.    the client.
  126.  
  127. 5.  Status Codes and Negotiation
  128.  
  129.    This specification does not provide a means for clients to request
  130.    that status codes be returned or that they not be returned; a
  131.    compliant server includes these codes in the responses it sends
  132.    regardless of whether or not the client expects them.  This is
  133.    somewhat different from most other SMTP extensions, where generally
  134.    speaking a client must specifically make a request before the
  135.    extended server behaves any differently than an unextended server.
  136.    The omission of client negotiation in this case is entirely
  137.    intentional: Given the generally poor state of SMTP server error code
  138.    implementation it is felt that any step taken towards more
  139.    comprehensible error codes is something that all clients, extended or
  140.    not, should benefit from.
  141.  
  142.    IMPORTANT NOTE:  The use of this approach in this extension should be
  143.    seen as a very special case.  It MUST NOT be taken as a license for
  144.    future SMTP extensions to dramatically change the nature of SMTP
  145.    client-server interaction without proper announcement from the server
  146.    and a corresponding enabling command from the client.
  147.  
  148. 6.  Usage Example
  149.  
  150.    The following dialogue illustrates the use of enhanced status codes
  151.    by a server:
  152.  
  153.    S: <wait for connection on TCP port 25>
  154.    C: <open connection to server>
  155.    S: 220 dbc.mtview.ca.us SMTP service ready
  156.    C: EHLO ymir.claremont.edu
  157.    S: 250-dbc.mtview.ca.us says hello
  158.    S: 250 ENHANCEDSTATUSCODES
  159.    C: MAIL FROM:<ned@ymir.claremont.edu>
  160.    S: 250 2.1.0 Originator <ned@ymir.claremont.edu> ok
  161.    C: RCPT TO:<mrose@dbc.mtview.ca.us>
  162.    S: 250 2.1.5 Recipient <mrose@dbc.mtview.ca.us> ok
  163.    C: RCPT TO:<nosuchuser@dbc.mtview.ca.us>
  164.    S: 550 5.1.1 Mailbox "nosuchuser" does not exist
  165.    C: RCPT TO:<remoteuser@isi.edu>
  166.    S: 551-5.7.1 Forwarding to remote hosts disabled
  167.  
  168.  
  169.  
  170. Freed                       Standards Track                     [Page 3]
  171.  
  172. RFC 2034               SMTP Enhanced Error Codes            October 1996
  173.  
  174.  
  175.    S: 551 5.7.1 Select another host to act as your forwarder
  176.    C: DATA
  177.    S: 354 Send message, ending in CRLF.CRLF.
  178.     ...
  179.    C: .
  180.    S: 250 2.6.0 Message accepted
  181.    C: QUIT
  182.    S: 221 2.0.0 Goodbye
  183.  
  184.    The client that receives these responses might then send a
  185.    nondelivery notification of the general form:
  186.  
  187.       Date: Mon, 11 Mar 1996 09:21:47 -0400
  188.       From: Mail Delivery Subsystem <mailer-daemon@ymir.claremont.edu>
  189.       Subject: Returned mail
  190.       To: <ned@ymir.claremont.edu>
  191.       MIME-Version: 1.0
  192.       Content-Type: multipart/report; report-type=delivery-status;
  193.             boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU"
  194.  
  195.       --JAA13167.773673707/YMIR.CLAREMONT.EDU
  196.       content-type: text/plain; charset=us-ascii
  197.  
  198.          ----- Mail was successfully relayed to
  199.                the following addresses -----
  200.  
  201.       <mrose@dbc.mtview.ca.us>
  202.  
  203.          ----- The following addresses had delivery problems -----
  204.       <nosuchuser@dbc.mtview.ca.us>
  205.         (Mailbox "nosuchuser" does not exist)
  206.       <remoteuser@isi.edu>
  207.         (Forwarding to remote hosts disabled)
  208.  
  209.       --JAA13167.773673707/YMIR.CLAREMONT.EDU
  210.       content-type: message/delivery-status
  211.  
  212.       Reporting-MTA: dns; ymir.claremont.edu
  213.  
  214.       Original-Recipient: rfc822;mrose@dbc.mtview.ca.us
  215.       Final-Recipient: rfc822;mrose@dbc.mtview.ca.us
  216.       Action: relayed
  217.       Status: 2.1.5 (Destination address valid)
  218.       Diagnostic-Code: smtp;
  219.        250 Recipient <mrose@dbc.mtview.ca.us> ok
  220.       Remote-MTA: dns; dbc.mtview.ca.us
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Freed                       Standards Track                     [Page 4]
  227.  
  228. RFC 2034               SMTP Enhanced Error Codes            October 1996
  229.  
  230.  
  231.       Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
  232.       Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
  233.       Action: failed
  234.       Status: 5.1.1 (Bad destination mailbox address)
  235.       Diagnostic-Code: smtp;
  236.        550 Mailbox "nosuchuser" does not exist
  237.       Remote-MTA: dns; dbc.mtview.ca.us
  238.  
  239.       Original-Recipient: rfc822;remoteuser@isi.edu
  240.       Final-Recipient: rfc822;remoteuser@isi.edu
  241.       Action: failed
  242.       Status: 5.7.1 (Delivery not authorized, message refused)
  243.       Diagnostic-Code: smtp;
  244.         551 Forwarding to remote hosts disabled
  245.         Select another host to act as your forwarder
  246.       Remote-MTA: dns; dbc.mtview.ca.us
  247.  
  248.       --JAA13167.773673707/YMIR.CLAREMONT.EDU
  249.       content-type: message/rfc822
  250.  
  251.       [original message goes here]
  252.       --JAA13167.773673707/YMIR.CLAREMONT.EDU--
  253.  
  254.    Note that in order to reduce clutter the reporting MTA has omitted
  255.    enhanced status code information from the diagnostic-code fields it
  256.    has generated.
  257.  
  258. 7.  Security Considerations
  259.  
  260.    Additional detail in server responses axiomatically provides
  261.    additional information about the server.  It is conceivable that
  262.    additional information of this sort may be of assistance in
  263.    circumventing server security.  The advantages of provides additional
  264.    information must always be weighed against the security implications
  265.    of doing so.
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Freed                       Standards Track                     [Page 5]
  283.  
  284. RFC 2034               SMTP Enhanced Error Codes            October 1996
  285.  
  286.  
  287. 8.  References
  288.  
  289.    [RFC-821]
  290.         Postel, J., "Simple Mail Transfer Protocol", RFC 821,
  291.         August, 1982.  (August, 1982).
  292.  
  293.    [RFC-1869]
  294.         Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed,
  295.         N., "SMTP Service Extensions", RFC 1869, November, 1995.
  296.  
  297.    [RFC-1893]
  298.         Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
  299.         1893, January, 1996.
  300.  
  301.    [RFC-1894]
  302.         Moore, K., Vaudreuil, G., "An Extensible Message Format
  303.         for Delivery Status Notifications", RFC 1894, January,
  304.         1996.
  305.  
  306. 9.  Author Address
  307.  
  308.    Ned Freed
  309.    Innosoft International, Inc.
  310.    1050 East Garvey Avenue South
  311.    West Covina, CA 91790
  312.    USA
  313.     tel: +1 818 919 3600           fax: +1 818 919 3614
  314.     email: ned@innosoft.com
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Freed                       Standards Track                     [Page 6]
  339.  
  340.