home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1800s / rfc1891.txt < prev    next >
Text File  |  1996-01-09  |  65KB  |  1,740 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           K. Moore
  8. Request for Comments: 1891                       University of Tennessee
  9. Category: Standards Track                                   January 1996
  10.  
  11.  
  12.                          SMTP Service Extension
  13.                    for Delivery Status Notifications
  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, which allows an
  26.    SMTP client to specify (a) that delivery status notifications (DSNs)
  27.    should be generated under certain conditions, (b) whether such
  28.    notifications should return the contents of the message, and (c)
  29.    additional information, to be returned with a DSN, that allows the
  30.    sender to identify both the recipient(s) for which the DSN was
  31.    issued, and the transaction in which the original message was sent.
  32.  
  33.    Any questions, comments, and reports of defects or ambiguities in
  34.    this specification may be sent to the mailing list for the NOTARY
  35.    working group of the IETF, using the address
  36.    <notifications@cs.utk.edu>.  Requests to subscribe to the mailing
  37.    list should be addressed to <notifications-request@cs.utk.edu>.
  38.    Implementors of this specification are encouraged to subscribe to the
  39.    mailing list, so that they will quickly be informed of any problems
  40.    which might hinder interoperability.
  41.  
  42.    NOTE: This document is a Proposed Standard.  If and when this
  43.    protocol is submitted for Draft Standard status, any normative text
  44.    (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in
  45.    this document will be re-evaluated in light of implementation
  46.    experience, and are thus subject to change.
  47.  
  48. 2. Introduction
  49.  
  50.    The SMTP protocol [1] requires that an SMTP server provide
  51.    notification of delivery failure, if it determines that a message
  52.    cannot be delivered to one or more recipients.  Traditionally, such
  53.    notification consists of an ordinary Internet mail message (format
  54.    defined by [2]), sent to the envelope sender address (the argument of
  55.  
  56.  
  57.  
  58. Moore                       Standards Track                     [Page 1]
  59.  
  60. RFC 1891           SMTP Delivery Status Notifications       January 1996
  61.  
  62.  
  63.    the SMTP MAIL command), containing an explanation of the error and at
  64.    least the headers of the failed message.
  65.  
  66.    Experience with large mail distribution lists [3] indicates that such
  67.    messages are often insufficient to diagnose problems, or even to
  68.    determine at which host or for which recipients a problem occurred.
  69.    In addition, the lack of a standardized format for delivery
  70.    notifications in Internet mail makes it difficult to exchange such
  71.    notifications with other message handling systems.
  72.  
  73.    Such experience has demonstrated a need for a delivery status
  74.    notification service for Internet electronic mail, which:
  75.  
  76. (a) is reliable, in the sense that any DSN request will either be
  77.     honored at the time of final delivery, or result in a response
  78.     that indicates that the request cannot be honored,
  79.  
  80. (b) when both success and failure notifications are requested,
  81.     provides an unambiguous and nonconflicting indication of whether
  82.     delivery of a message to a recipient succeeded or failed,
  83.  
  84. (c) is stable, in that a failed attempt to deliver a DSN should never
  85.     result in the transmission of another DSN over the network,
  86.  
  87. (d) preserves sufficient information to allow the sender to identify
  88.     both the mail transaction and the recipient address which caused
  89.     the notification, even when mail is forwarded or gatewayed to
  90.     foreign environments, and
  91.  
  92. (e) interfaces acceptably with non-SMTP and non-822-based mail
  93.     systems, both so that notifications returned from foreign mail
  94.     systems may be useful to Internet users, and so that the
  95.     notification requests from foreign environments may be honored.
  96.     Among the requirements implied by this goal are the ability to
  97.     request non-return-of-content, and the ability to specify whether
  98.     positive delivery notifications, negative delivery notifications,
  99.     both, or neither, should be issued.
  100.  
  101.    In an attempt to provide such a service, this memo uses the mechanism
  102.    defined in [4] to define an extension to the SMTP protocol.  Using
  103.    this mechanism, an SMTP client may request that an SMTP server issue
  104.    or not issue a delivery status notification (DSN) under certain
  105.    conditions.  The format of a DSN is defined in [5].
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Moore                       Standards Track                     [Page 2]
  115.  
  116. RFC 1891           SMTP Delivery Status Notifications       January 1996
  117.  
  118.  
  119. 3. Framework for the Delivery Status Notification Extension
  120.  
  121.    The following service extension is therefore defined:
  122.  
  123. (1) The name of the SMTP service extension is "Delivery Status
  124.     Notification";
  125.  
  126. (2) the EHLO keyword value associated with this extension is "DSN",
  127.     the meaning of which is defined in section 4 of this memo;
  128.  
  129. (3) no parameters are allowed with this EHLO keyword value;
  130.  
  131. (4) two optional parameters are added to the RCPT command, and two
  132.     optional parameters are added to the MAIL command:
  133.  
  134.     An optional parameter for the RCPT command, using the
  135.     esmtp-keyword "NOTIFY", (to specify the conditions under which a
  136.     delivery status notification should be generated), is defined in
  137.     section 5.1,
  138.  
  139.     An optional parameter for the RCPT command, using the
  140.     esmtp-keyword "ORCPT", (used to convey the "original"
  141.     (sender-specified) recipient address), is defined in section 5.2,
  142.     and
  143.  
  144.     An optional parameter for the MAIL command, using the
  145.     esmtp-keyword "RET", (to request that DSNs containing an
  146.     indication of delivery failure either return the entire contents
  147.     of a message or only the message headers), is defined in section
  148.     5.3,
  149.  
  150.     An optional parameter for the MAIL command, using the
  151.     esmtp-keyword "ENVID", (used to propagate an identifier for this
  152.     message transmission envelope, which is also known to the sender
  153.     and will, if present, be returned in any DSNs issued for this
  154.     transmission), is defined in section 5.4;
  155.  
  156. (5) no additional SMTP verbs are defined by this extension.
  157.  
  158.    The remainder of this memo specifies how support for the extension
  159.    effects the behavior of a message transfer agent.
  160.  
  161. 4.  The Delivery Status Notification service extension
  162.  
  163.    An SMTP client wishing to request a DSN for a message may issue the
  164.    EHLO command to start an SMTP session, to determine if the server
  165.    supports any of several service extensions.  If the server responds
  166.    with code 250 to the EHLO command, and the response includes the EHLO
  167.  
  168.  
  169.  
  170. Moore                       Standards Track                     [Page 3]
  171.  
  172. RFC 1891           SMTP Delivery Status Notifications       January 1996
  173.  
  174.  
  175.    keyword DSN, then the Delivery Status Notification extension (as
  176.    described in this memo) is supported.
  177.  
  178.    Ordinarily, when an SMTP server returns a positive (2xx) reply code
  179.    in response to a RCPT command, it agrees to accept responsibility for
  180.    either delivering the message to the named recipient, or sending a
  181.    notification to the sender of the message indicating that delivery
  182.    has failed.  However, an extended SMTP ("ESMTP") server which
  183.    implements this service extension will accept an optional NOTIFY
  184.    parameter with the RCPT command. If present, the NOTIFY parameter
  185.    alters the conditions for generation of delivery status notifications
  186.    from the default (issue notifications only on failure) specified in
  187.    [1].  The ESMTP client may also request (via the RET parameter)
  188.    whether the entire contents of the original message should be
  189.    returned (as opposed to just the headers of that message), along with
  190.    the DSN.
  191.  
  192.    In general, an ESMTP server which implements this service extension
  193.    will propagate delivery status notification requests when relaying
  194.    mail to other SMTP-based MTAs which also support this extension, and
  195.    make a "best effort" to ensure that such requests are honored when
  196.    messages are passed into other environments.
  197.  
  198.    In order that any delivery status notifications thus generated will
  199.    be meaningful to the sender, any ESMTP server which supports this
  200.    extension will attempt to propagate the following information to any
  201.    other MTAs that are used to relay the message, for use in generating
  202.    DSNs:
  203.  
  204. (a) for each recipient, a copy of the original recipient address, as
  205.     used by the sender of the message.
  206.  
  207.     This address need not be the same as the mailbox specified in the
  208.     RCPT command.  For example, if a message was originally addressed
  209.     to A@B.C and later forwarded to A@D.E, after such forwarding has
  210.     taken place, the RCPT command will specify a mailbox of A@D.E.
  211.     However, the original recipient address remains A@B.C.
  212.  
  213.     Also, if the message originated from an environment which does not
  214.     use Internet-style user@domain addresses, and was gatewayed into
  215.     SMTP, the original recipient address will preserve the original
  216.     form of the recipient address.
  217.  
  218. (b) for the entire SMTP transaction, an envelope identification
  219.     string, which may be used by the sender to associate any delivery
  220.     status notifications with the transaction used to send the
  221.     original message.
  222.  
  223.  
  224.  
  225.  
  226. Moore                       Standards Track                     [Page 4]
  227.  
  228. RFC 1891           SMTP Delivery Status Notifications       January 1996
  229.  
  230.  
  231. 5.  Additional parameters for RCPT and MAIL commands
  232.  
  233.    The extended RCPT and MAIL commands are issued by a client when it
  234.    wishes to request a DSN from the server, under certain conditions,
  235.    for a particular recipient.  The extended RCPT and MAIL commands are
  236.    identical to the RCPT and MAIL commands defined in [1], except that
  237.    one or more of the following parameters appear after the sender or
  238.    recipient address, respectively.  The general syntax for extended
  239.    SMTP commands is defined in [4].
  240.  
  241.    NOTE: Although RFC 822 ABNF is used to describe the syntax of these
  242.    parameters, they are not, in the language of that document,
  243.    "structured field bodies".  Therefore, while parentheses MAY appear
  244.    within an emstp-value, they are not recognized as comment delimiters.
  245.  
  246.    The syntax for "esmtp-value" in [4] does not allow SP, "=", control
  247.    characters, or characters outside the traditional ASCII range of 1-
  248.    127 decimal to be transmitted in an esmtp-value.  Because the ENVID
  249.    and ORCPT parameters may need to convey values outside this range,
  250.    the esmtp-values for these parameters are encoded as "xtext".
  251.    "xtext" is formally defined as follows:
  252.  
  253.      xtext = *( xchar / hexchar )
  254.  
  255.      xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
  256.           except for "+" and "=".
  257.  
  258. ; "hexchar"s are intended to encode octets that cannot appear
  259. ; as ASCII characters within an esmtp-value.
  260.  
  261.      hexchar = ASCII "+" immediately followed by two upper case
  262.           hexadecimal digits
  263.  
  264. When encoding an octet sequence as xtext:
  265.  
  266. + Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=",
  267.   MAY be encoded as itself.  (A CHAR in this range MAY instead be
  268.   encoded as a "hexchar", at the implementor's discretion.)
  269.  
  270. + ASCII CHARs that fall outside the range above must be encoded as
  271.   "hexchar".
  272.  
  273. 5.1  The NOTIFY parameter of the ESMTP RCPT command
  274.  
  275.    A RCPT command issued by a client may contain the optional esmtp-
  276.    keyword "NOTIFY", to specify the conditions under which the SMTP
  277.    server should generate DSNs for that recipient.  If the NOTIFY
  278.    esmtp-keyword is used, it MUST have an associated esmtp-value,
  279.  
  280.  
  281.  
  282. Moore                       Standards Track                     [Page 5]
  283.  
  284. RFC 1891           SMTP Delivery Status Notifications       January 1996
  285.  
  286.  
  287.    formatted according to the following rules, using the ABNF of RFC
  288.    822:
  289.  
  290.      notify-esmtp-value = "NEVER" / 1#notify-list-element
  291.  
  292.      notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"
  293.  
  294. Notes:
  295.  
  296. a. Multiple notify-list-elements, separated by commas, MAY appear in a
  297.    NOTIFY parameter; however, the NEVER keyword MUST appear by itself.
  298.  
  299. b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled
  300.    in any combination of upper and lower case letters.
  301.  
  302. The meaning of the NOTIFY parameter values is generally as follows:
  303.  
  304. + A NOTIFY parameter value of "NEVER" requests that a DSN not be
  305.   returned to the sender under any conditions.
  306.  
  307. + A NOTIFY parameter value containing the "SUCCESS" or "FAILURE"
  308.   keywords requests that a DSN be issued on successful delivery or
  309.   delivery failure, respectively.
  310.  
  311. + A NOTIFY parameter value containing the keyword "DELAY" indicates the
  312.   sender's willingness to receive "delayed" DSNs.  Delayed DSNs may be
  313.   issued if delivery of a message has been delayed for an unusual amount
  314.   of time (as determined by the MTA at which the message is delayed),
  315.   but the final delivery status (whether successful or failure) cannot
  316.   be determined.  The absence of the DELAY keyword in a NOTIFY parameter
  317.   requests that a "delayed" DSN NOT be issued under any conditions.
  318.  
  319.    The actual rules governing interpretation of the NOTIFY parameter are
  320.    given in section 6.
  321.  
  322.    For compatibility with SMTP clients that do not use the NOTIFY
  323.    facility, the absence of a NOTIFY parameter in a RCPT command may be
  324.    interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.
  325.  
  326. 5.2 The ORCPT parameter to the ESMTP RCPT command
  327.  
  328.    The ORCPT esmtp-keyword of the RCPT command is used to specify an
  329.    "original" recipient address that corresponds to the actual recipient
  330.    to which the message is to be delivered.  If the ORCPT esmtp-keyword
  331.    is used, it MUST have an associated esmtp-value, which consists of
  332.    the original recipient address, encoded according to the rules below.
  333.    The ABNF for the ORCPT parameter is:
  334.  
  335.  
  336.  
  337.  
  338. Moore                       Standards Track                     [Page 6]
  339.  
  340. RFC 1891           SMTP Delivery Status Notifications       January 1996
  341.  
  342.  
  343.      orcpt-parameter = "ORCPT=" original-recipient-address
  344.  
  345.      original-recipient-address = addr-type ";" xtext
  346.  
  347.      addr-type = atom
  348.  
  349.    The "addr-type" portion MUST be an IANA-registered electronic mail
  350.    address-type (as defined in [5]), while the "xtext" portion contains
  351.    an encoded representation of the original recipient address using the
  352.    rules in section 5 of this document.  The entire ORCPT parameter MAY
  353.    be up to 500 characters in length.
  354.  
  355.    When initially submitting a message via SMTP, if the ORCPT parameter
  356.    is used, it MUST contain the same address as the RCPT TO address
  357.    (unlike the RCPT TO address, the ORCPT parameter will be encoded as
  358.    xtext).  Likewise, when a mailing list submits a message via SMTP to
  359.    be distributed to the list subscribers, if ORCPT is used, the ORCPT
  360.    parameter MUST match the new RCPT TO address of each recipient, not
  361.    the address specified by the original sender of the message.)
  362.  
  363.    The "addr-type" portion of the original-recipient-address is used to
  364.    indicate the "type" of the address which appears in the ORCPT
  365.    parameter value.  However, the address associated with the ORCPT
  366.    keyword is NOT constrained to conform to the syntax rules for that
  367.    "addr-type".
  368.  
  369.    Ideally, the "xtext" portion of the original-recipient-address should
  370.    contain, in encoded form, the same sequence of characters that the
  371.    sender used to specify the recipient.  However, for a message
  372.    gatewayed from an environment (such as X.400) in which a recipient
  373.    address is not a simple string of printable characters, the
  374.    representation of recipient address must be defined by a
  375.    specification for gatewaying between DSNs and that environment.
  376.  
  377. 5.3 The RET parameter of the ESMTP MAIL command
  378.  
  379.    The RET esmtp-keyword on the extended MAIL command specifies whether
  380.    or not the message should be included in any failed DSN issued for
  381.    this message transmission.  If the RET esmtp-keyword is used, it MUST
  382.    have an associated esmtp-value, which is one of the following
  383.    keywords:
  384.  
  385.    FULL  requests that the entire message be returned in any "failed"
  386.          delivery status notification issued for this recipient.
  387.  
  388.    HDRS  requests that only the headers of the message be returned.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Moore                       Standards Track                     [Page 7]
  395.  
  396. RFC 1891           SMTP Delivery Status Notifications       January 1996
  397.  
  398.  
  399.    The FULL and HDRS keywords may be spelled in any combination of upper
  400.    and lower case letters.
  401.  
  402.    If no RET parameter is supplied, the MTA MAY return either the
  403.    headers of the message or the entire message for any DSN containing
  404.    indication of failed deliveries.
  405.  
  406.    Note that the RET parameter only applies to DSNs that indicate
  407.    delivery failure for at least one recipient.  If a DSN contains no
  408.    indications of delivery failure, only the headers of the message
  409.    should be returned.
  410.  
  411. 5.4  The ENVID parameter to the ESMTP MAIL command
  412.  
  413.    The ENVID esmtp-keyword of the SMTP MAIL command is used to specify
  414.    an "envelope identifier" to be transmitted along with the message and
  415.    included in any DSNs issued for any of the recipients named in this
  416.    SMTP transaction.  The purpose of the envelope identifier is to allow
  417.    the sender of a message to identify the transaction for which the DSN
  418.    was issued.
  419.  
  420.    The ABNF for the ENVID parameter is:
  421.  
  422.      envid-parameter = "ENVID=" xtext
  423.  
  424.    The ENVID esmtp-keyword MUST have an associated esmtp-value.  No
  425.    meaning is assigned by the mail system to the presence or absence of
  426.    this parameter or to any esmtp-value associated with this parameter;
  427.    the information is used only by the sender or his user agent.  The
  428.    ENVID parameter MAY be up to 100 characters in length.
  429.  
  430. 5.5 Restrictions on the use of Delivery Status Notification parameters
  431.  
  432.    The RET and ENVID parameters MUST NOT appear more than once each in
  433.    any single MAIL command.  If more than one of either of these
  434.    parameters appears in a MAIL command, the ESMTP server SHOULD respond
  435.    with "501 syntax error in parameters or arguments".
  436.  
  437.    The NOTIFY and ORCPT parameters MUST NOT appear more than once in any
  438.    RCPT command.  If more than one of either of these parameters appears
  439.    in a RCPT command, the ESMTP server SHOULD respond with "501 syntax
  440.    error in parameters or arguments".
  441.  
  442. 6. Conformance requirements
  443.  
  444.    The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer
  445.    Agents (MTAs) when accepting, relaying, or gatewaying mail, as well
  446.    as User Agents (UAs) when submitting mail to the mail transport
  447.  
  448.  
  449.  
  450. Moore                       Standards Track                     [Page 8]
  451.  
  452. RFC 1891           SMTP Delivery Status Notifications       January 1996
  453.  
  454.  
  455.    system.  The DSN extension to SMTP may be used to allow UAs to convey
  456.    the sender's requests as to when DSNs should be issued.  A UA which
  457.    claims to conform to this specification must meet certain
  458.    requirements as described below.
  459.  
  460.    Typically, a message transfer agent (MTA) which supports SMTP will
  461.    assume, at different times, both the role of a SMTP client and an
  462.    SMTP server, and may also provide local delivery, gatewaying to
  463.    foreign environments, forwarding, and mailing list expansion.  An MTA
  464.    which, when acting as an SMTP server, issues the DSN keyword in
  465.    response to the EHLO command, MUST obey the rules below for a
  466.    "conforming SMTP client" when acting as a client, and a "conforming
  467.    SMTP server" when acting as a server.  The term "conforming MTA"
  468.    refers to an MTA which conforms to this specification, independent of
  469.    its role of client or server.
  470.  
  471. 6.1 SMTP protocol interactions
  472.  
  473.    The following rules apply to SMTP transactions in which any of the
  474.    ENVID, NOTIFY, RET, or ORCPT keywords are used:
  475.  
  476. (a) If an SMTP client issues a MAIL command containing a valid ENVID
  477.     parameter and associated esmtp-value and/or a valid RET parameter
  478.     and associated esmtp-value, a conforming SMTP server MUST return
  479.     the same reply-code as it would to the same MAIL command without
  480.     the ENVID and/or RET parameters.  A conforming SMTP server MUST
  481.     NOT refuse a MAIL command based on the absence or presence of
  482.     valid ENVID or RET parameters, or on their associated
  483.     esmtp-values.
  484.  
  485.     However, if the associated esmtp-value is not valid (i.e. contains
  486.     illegal characters), or if there is more than one ENVID or RET
  487.     parameter in a particular MAIL command, the server MUST issue the
  488.     reply-code 501 with an appropriate message (e.g.  "syntax error in
  489.     parameter").
  490.  
  491. (b) If an SMTP client issues a RCPT command containing any valid
  492.     NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST
  493.     return the same response as it would to the same RCPT command
  494.     without those NOTIFY and/or ORCPT parameters.  A conforming SMTP
  495.     server MUST NOT refuse a RCPT command based on the presence or
  496.     absence of any of these parameters.
  497.  
  498.     However, if any of the associated esmtp-values are not valid, or
  499.     if there is more than one of any of these parameters in a
  500.     particular RCPT command, the server SHOULD issue the response "501
  501.     syntax error in parameter".
  502.  
  503.  
  504.  
  505.  
  506. Moore                       Standards Track                     [Page 9]
  507.  
  508. RFC 1891           SMTP Delivery Status Notifications       January 1996
  509.  
  510.  
  511. 6.2 Handling of messages received via SMTP
  512.  
  513.    This section describes how a conforming MTA should handle any
  514.    messages received via SMTP.
  515.  
  516.    NOTE: A DSN MUST NOT be returned to the sender for any message for
  517.    which the return address from the SMTP MAIL command was NULL ("<>"),
  518.    even if the sender's address is available from other sources (e.g.
  519.    the message header).  However, the MTA which would otherwise issue a
  520.    DSN SHOULD inform the local postmaster of delivery failures through
  521.    some appropriate mechanism that will not itself result in the
  522.    generation of DSNs.
  523.  
  524.    DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to
  525.    be sent with a NULL return address ("reverse-path").  This creates an
  526.    interesting situation when a message arrives with one or more
  527.    nonfunctional recipient addresses in addition to a nonfunctional
  528.    return address.  When delivery to one of the recipient addresses
  529.    fails, the MTA will attempt to send a nondelivery notification to the
  530.    return address, setting the return address on the notification to
  531.    NULL.  When the delivery of this notification fails, the MTA
  532.    attempting delivery of that notification sees a NULL return address.
  533.    If that MTA were not to inform anyone of the situation, the original
  534.    message would be silently lost.  Furthermore, a nonfunctional return
  535.    address is often indicative of a configuration problem in the
  536.    sender's MTA.  Reporting the condition to the local postmaster may
  537.    help to speed correction of such errors.
  538.  
  539. 6.2.1 Relay of messages to other conforming SMTP servers
  540.  
  541.    The following rules govern the behavior of a conforming MTA, when
  542.    relaying a message which was received via the SMTP protocol, to an
  543.    SMTP server that supports the Delivery Status Notification service
  544.    extension:
  545.  
  546. (a) Any ENVID parameter included in the MAIL command when a message was
  547.     received, MUST also appear on the MAIL command with which the
  548.     message is relayed, with the same associated esmtp-value.  If no
  549.     ENVID parameter was included in the MAIL command when the message
  550.     was received, the ENVID parameter MUST NOT be supplied when the
  551.     message is relayed.
  552.  
  553. (b) Any RET parameter included in the MAIL command when a message was
  554.     received, MUST also appear on the MAIL command with which the
  555.     message is relayed, with the same associated esmtp-value.  If no RET
  556.     parameter was included in the MAIL command when the message was
  557.     received, the RET parameter MUST NOT supplied when the message is
  558.     relayed.
  559.  
  560.  
  561.  
  562. Moore                       Standards Track                    [Page 10]
  563.  
  564. RFC 1891           SMTP Delivery Status Notifications       January 1996
  565.  
  566.  
  567. (c) If the NOTIFY parameter was supplied for a recipient when the
  568.     message was received, the RCPT command issued when the message is
  569.     relayed MUST also contain the NOTIFY parameter along with its
  570.     associated esmtp-value.  If the NOTIFY parameter was not supplied
  571.     for a recipient when the message was received, the NOTIFY parameter
  572.     MUST NOT be supplied for that recipient when the message is relayed.
  573.  
  574. (d) If any ORCPT parameter was present in the RCPT command for a
  575.     recipient when the message was received, an ORCPT parameter with the
  576.     identical original-recipient-address MUST appear in the RCPT command
  577.     issued for that recipient when relaying the message.  (For example,
  578.     the MTA therefore MUST NOT change the case of any alphabetic
  579.     characters in an ORCPT parameter.)
  580.  
  581.     If no ORCPT parameter was present in the RCPT command when the
  582.     message was received, an ORCPT parameter MAY be added to the RCPT
  583.     command when the message is relayed.  If an ORCPT parameter is added
  584.     by the relaying MTA, it MUST contain the recipient address from the
  585.     RCPT command used when the message was received by that MTA.
  586.  
  587. 6.2.2  Relay of messages to non-conforming SMTP servers
  588.  
  589.    The following rules govern the behavior of a conforming MTA (in the
  590.    role of client), when relaying a message which was received via the
  591.    SMTP protocol, to an SMTP server that does not support the Delivery
  592.    Status Notification service extension:
  593.  
  594. (a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when
  595.     relaying the message.
  596.  
  597. (b) If the NOTIFY parameter was supplied for a recipient, with an esmtp-
  598.     value containing the keyword SUCCESS, and the SMTP server returns a
  599.     success (2xx) reply-code in response to the RCPT command, the client
  600.     MUST issue a "relayed" DSN for that recipient.
  601.  
  602. (c) If the NOTIFY parameter was supplied for a recipient with an esmtp-
  603.     value containing the keyword FAILURE, and the SMTP server returns a
  604.     permanent failure (5xx) reply-code in response to the RCPT command,
  605.     the client MUST issue a "failed" DSN for that recipient.
  606.  
  607. (d) If the NOTIFY parameter was supplied for a recipient with an esmtp-
  608.     value of NEVER, the client MUST NOT issue a DSN for that recipient,
  609.     regardless of the reply-code returned by the SMTP server.  However,
  610.     if the server returned a failure (5xx) reply-code, the client MAY
  611.     inform the local postmaster of the delivery failure via an
  612.     appropriate mechanism that will not itself result in the generation
  613.     of DSNs.
  614.  
  615.  
  616.  
  617.  
  618. Moore                       Standards Track                    [Page 11]
  619.  
  620. RFC 1891           SMTP Delivery Status Notifications       January 1996
  621.  
  622.  
  623.     When attempting to relay a message to an SMTP server that does not
  624.     support this extension, and if NOTIFY=NEVER was specified for some
  625.     recipients of that message, a conforming SMTP client MAY relay the
  626.     message for those recipients in a separate SMTP transaction, using
  627.     an empty reverse-path in the MAIL command.  This will prevent DSNs
  628.     from being issued for those recipients by MTAs that conform to [1].
  629.  
  630. (e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP
  631.     server returns a success (2xx) reply-code in response to a RCPT
  632.     command, the client MUST NOT issue any DSN for that recipient.
  633.  
  634. (f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP
  635.     server returns a permanent failure (5xx) reply-code in response to a
  636.     RCPT command, the client MUST issue a "failed" DSN for that
  637.     recipient.
  638.  
  639. 6.2.3  Local delivery of messages
  640.  
  641.    The following rules govern the behavior of a conforming MTA upon
  642.    successful delivery of a message that was received via the SMTP
  643.    protocol, to a local recipient's mailbox:
  644.  
  645.    "Delivery" means that the message has been placed in the recipient's
  646.    mailbox.  For messages which are transmitted to a mailbox for later
  647.    retrieval via IMAP [6], POP [7] or a similar message access protocol,
  648.    "delivery" occurs when the message is made available to the IMAP
  649.    (POP, etc.) service, rather than when the message is retrieved by the
  650.    recipient's user agent.
  651.  
  652.    Similarly, for a recipient address which corresponds to a mailing
  653.    list exploder, "delivery" occurs when the message is made available
  654.    to that list exploder, even though the list exploder might refuse to
  655.    deliver that message to the list recipients.
  656.  
  657. (a) If the NOTIFY parameter was supplied for that recipient, with an
  658.     esmtp-value containing the SUCCESS keyword, the MTA MUST issue a
  659.     "delivered" DSN for that recipient.
  660.  
  661. (b) If the NOTIFY parameter was supplied for that recipient which did
  662.     not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for
  663.     that recipient.
  664.  
  665. (c) If the NOTIFY parameter was not supplied for that recipient, the MTA
  666.     MUST NOT issue a DSN.
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Moore                       Standards Track                    [Page 12]
  675.  
  676. RFC 1891           SMTP Delivery Status Notifications       January 1996
  677.  
  678.  
  679. 6.2.4  Gatewaying a message into a foreign environment
  680.  
  681.    The following rules govern the behavior of a conforming MTA, when
  682.    gatewaying a message that was received via the SMTP protocol, into a
  683.    foreign (non-SMTP) environment:
  684.  
  685. (a) If the the foreign environment is capable of issuing appropriate
  686.     notifications under the conditions requested by the NOTIFY
  687.     parameter, and the conforming MTA can ensure that any notification
  688.     thus issued will be translated into a DSN and delivered to the
  689.     original sender, then the MTA SHOULD gateway the message into the
  690.     foreign environment, requesting notification under the desired
  691.     conditions, without itself issuing a DSN.
  692.  
  693. (b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the
  694.     destination environment cannot return an appropriate notification on
  695.     successful delivery, the MTA SHOULD issue a "relayed" DSN for that
  696.     recipient.
  697.  
  698. (c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a
  699.     DSN MUST NOT be issued.  If possible, the MTA SHOULD direct the
  700.     destination environment to not issue delivery notifications for that
  701.     recipient.
  702.  
  703. (d) If the NOTIFY parameter was not supplied for a particular recipient,
  704.     a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD
  705.     attempt to ensure that appropriate notification will be provided by
  706.     the foreign mail environment if eventual delivery failure occurs,
  707.     and that no notification will be issued on successful delivery.
  708.  
  709. (e) When gatewaying a message into a foreign environment, the return-of-
  710.     content conditions specified by any RET parameter are nonbinding;
  711.     however, the MTA SHOULD attempt to honor the request using whatever
  712.     mechanisms exist in the foreign environment.
  713.  
  714. 6.2.5  Delays in delivery
  715.  
  716.    If a conforming MTA receives a message via the SMTP protocol, and is
  717.    unable to deliver or relay the message to one or more recipients for
  718.    an extended length of time (to be determined by the MTA), it MAY
  719.    issue a "delayed" DSN for those recipients, subject to the following
  720.    conditions:
  721.  
  722. (a) If the NOTIFY parameter was supplied for a recipient and its value
  723.     included the DELAY keyword, a "delayed" DSN MAY be issued.
  724.  
  725. (b) If the NOTIFY parameter was not supplied for a recipient, a
  726.     "delayed" DSN MAY be issued.
  727.  
  728.  
  729.  
  730. Moore                       Standards Track                    [Page 13]
  731.  
  732. RFC 1891           SMTP Delivery Status Notifications       January 1996
  733.  
  734.  
  735. (c) If the NOTIFY parameter was supplied which did not contain the DELAY
  736.     keyword, a "delayed" DSN MUST NOT be issued.
  737.  
  738.    NOTE: Although delay notifications are common in present-day
  739.    electronic mail, a conforming MTA is never required to issue
  740.    "delayed" DSNs.  The DELAY keyword of the NOTIFY parameter is
  741.    provided to allow the SMTP client to specifically request (by
  742.    omitting the DELAY parameter) that "delayed" DSNs NOT be issued.
  743.  
  744. 6.2.6  Failure of a conforming MTA to deliver a message
  745.  
  746.    The following rules govern the behavior of a conforming MTA which
  747.    received a message via the SMTP protocol, and is unable to deliver a
  748.    message to a recipient specified in the SMTP transaction:
  749.  
  750. (a) If a NOTIFY parameter was supplied for the recipient with an esmtp-
  751.     keyword containing the value FAILURE, a "failed" DSN MUST be issued
  752.     by the MTA.
  753.  
  754. (b) If a NOTIFY parameter was supplied for the recipient which did not
  755.     contain the value FAILURE, a DSN MUST NOT be issued for that
  756.     recipient.  However, the MTA MAY inform the local postmaster of the
  757.     delivery failure via some appropriate mechanism which does not
  758.     itself result in the generation of DSNs.
  759.  
  760. (c) If no NOTIFY parameter was supplied for the recipient, a "failed"
  761.     DSN MUST be issued.
  762.  
  763.    NOTE: Some MTAs are known to forward undeliverable messages to the
  764.    local postmaster or "dead letter" mailbox.  This is still considered
  765.    delivery failure, and does not diminish the requirement to issue a
  766.    "failed" DSN under the conditions defined elsewhere in this memo.  If
  767.    a DSN is issued for such a recipient, the Action value MUST be
  768.    "failed".
  769.  
  770. 6.2.7 Forwarding, aliases, and mailing lists
  771.  
  772.    Delivery of a message to a local email address usually causes the
  773.    message to be stored in the recipient's mailbox.  However, MTAs
  774.    commonly provide a facility where a local email address can be
  775.    designated as an "alias" or "mailing list"; delivery to that address
  776.    then causes the message to be forwarded to each of the (local or
  777.    remote) recipient addresses associated with the alias or list.  It is
  778.    also common to allow a user to optionally "forward" her mail to one
  779.    or more alternate addresses.  If this feature is enabled, her mail is
  780.    redistributed to those addresses instead of being deposited in her
  781.    mailbox.
  782.  
  783.  
  784.  
  785.  
  786. Moore                       Standards Track                    [Page 14]
  787.  
  788. RFC 1891           SMTP Delivery Status Notifications       January 1996
  789.  
  790.  
  791.    Following the example of [9] (section 5.3.6), this document defines
  792.    the difference between an "alias" and "mailing list" as follows: When
  793.    forwarding a message to the addresses associated with an "alias", the
  794.    envelope return address (e.g. SMTP MAIL FROM) remains intact.
  795.    However, when forwarding a message to the addresses associated with a
  796.    "mailing list", the envelope return address is changed to that of the
  797.    administrator of the mailing list.  This causes DSNs and other
  798.    nondelivery reports resulting from delivery to the list members to be
  799.    sent to the list administrator rather than the sender of the original
  800.    message.
  801.  
  802.    The DSN processing for aliases and mailing lists is as follows:
  803.  
  804. 6.2.7.1 mailing lists
  805.  
  806.    When a message is delivered to a list submission address (i.e. placed
  807.    in the list's mailbox for incoming mail, or accepted by the process
  808.    that redistributes the message to the list subscribers), this is
  809.    considered final delivery for the original message.  If the NOTIFY
  810.    parameter for the list submission address contained the SUCCESS
  811.    keyword, a "delivered" DSN MUST be returned to the sender of the
  812.    original message.
  813.  
  814.    NOTE: Some mailing lists are able to reject message submissions,
  815.    based on the content of the message, the sender's address, or some
  816.    other criteria.  While the interface between such a mailing list and
  817.    its MTA is not well-defined, it is important that DSNs NOT be issued
  818.    by both the MTA (to report successful delivery to the list), and the
  819.    list (to report message rejection using a "failure" DSN.)
  820.  
  821.    However, even if a "delivered" DSN was issued by the MTA, a mailing
  822.    list which rejects a message submission MAY notify the sender that
  823.    the message was rejected using an ordinary message instead of a DSN.
  824.  
  825.    Whenever a message is redistributed to an mailing list,
  826.  
  827. (a) The envelope return address is rewritten to point to the list
  828.     maintainer.  This address MAY be that of a process that recognizes
  829.     DSNs and processes them automatically, but it MUST forward
  830.     unrecognized messages to the human responsible for the list.
  831.  
  832. (b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the
  833.     redistributed message MUST NOT be derived from those of the original
  834.     message.
  835.  
  836. (c) The NOTIFY and RET parameters MAY be specified by the local
  837.     postmaster or the list administrator.  If ORCPT parameters are
  838.     supplied during redistribution to the list subscribers, they SHOULD
  839.  
  840.  
  841.  
  842. Moore                       Standards Track                    [Page 15]
  843.  
  844. RFC 1891           SMTP Delivery Status Notifications       January 1996
  845.  
  846.  
  847.     contain the addresses of the list subscribers in the format used by
  848.     the mailing list.
  849.  
  850. 6.2.7.2 single-recipient aliases
  851.  
  852.    Under normal circumstances, when a message arrives for an "alias"
  853.    which has a single forwarding address, a DSN SHOULD NOT be issued.
  854.    Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with
  855.    the message as it is redistributed to the forwarding address.
  856.  
  857. 6.2.7.3 multiple-recipient aliases
  858.  
  859.    An "alias" with multiple recipient addresses may be handled in any of
  860.    the following ways:
  861.  
  862. (a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when
  863.     relaying the message to any of the forwarding addresses.  If the
  864.     NOTIFY parameter for the alias contained the SUCCESS keyword, the
  865.     MTA issues a "relayed" DSN.  (In effect, the MTA treats the message
  866.     as if it were being relayed into an environment that does not
  867.     support DSNs.)
  868.  
  869. (b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent
  870.     requests if the message is gatewayed) are propagated to EXACTLY one
  871.     of the forwarding addresses.  No DSN is issued.  (This is
  872.     appropriate when aliasing is used to forward a message to a
  873.     "vacation" auto-responder program in addition to the local mailbox.)
  874.  
  875. (c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding
  876.     addresses associated with that alias.  The NOTIFY parameter is
  877.     propagated to the forwarding addresses, except that it any SUCCESS
  878.     keyword is removed.  If the original NOTIFY parameter for the alias
  879.     contained the SUCCESS keyword, an "expanded" DSN is issued for the
  880.     alias.  If the NOTIFY parameter for the alias did not contain the
  881.     SUCCESS keyword, no DSN is issued for the alias.
  882.  
  883. 6.2.7.4 confidential forwarding addresses
  884.  
  885.    If it is desired to maintain the confidentiality of a recipient's
  886.    forwarding address, the forwarding may be treated as if it were a
  887.    mailing list.  A DSN will be issued, if appropriate, upon "delivery"
  888.    to the recipient address specified by the sender.  When the message
  889.    is forwarded it will have a new envelope return address. Any DSNs
  890.    which result from delivery failure of the forwarded message will not
  891.    be returned to the original sender of the message and thus not expose
  892.    the recipient's forwarding address.
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Moore                       Standards Track                    [Page 16]
  899.  
  900. RFC 1891           SMTP Delivery Status Notifications       January 1996
  901.  
  902.  
  903. 6.2.8 DSNs describing delivery to multiple recipients
  904.  
  905.    A single DSN may describe attempts to deliver a message to multiple
  906.    recipients of that message.  If a DSN is issued for some recipients
  907.    in an SMTP transaction and not for others according to the rules
  908.    above, the DSN SHOULD NOT contain information for recipients for whom
  909.    DSNs would not otherwise have been issued.
  910.  
  911. 6.3 Handling of messages from other sources
  912.  
  913.    For messages which originated from "local" users (whatever that
  914.    means), the specifications under which DSNs should be generated can
  915.    be communicated to the MTA via any protocol agreed on between the
  916.    sender's mail composer (user agent) and the MTA.  The local MTA can
  917.    then either relay the message, or issue appropriate delivery status
  918.    notifications.  However, if such requests are transmitted within the
  919.    message itself (for example in the message headers), the requests
  920.    MUST be removed from the message before it is transmitted via SMTP.
  921.  
  922.    For messages gatewayed from non-SMTP sources and further relayed by
  923.    SMTP, the gateway SHOULD, using the SMTP extensions described here,
  924.    attempt to provide the delivery reporting conditions expected by the
  925.    source mail environment.  If appropriate, any DSNs returned to the
  926.    source environment SHOULD be translated into the format expected in
  927.    that environment.
  928.  
  929. 6.4  Implementation limits
  930.  
  931.    A conforming MTA MUST accept ESMTP parameters of at least the
  932.    following sizes:
  933.  
  934.    (a) ENVID parameter: 100 characters.
  935.  
  936.    (b) NOTIFY parameter: 28 characters.
  937.  
  938.    (c) ORCPT parameter: 500 characters.
  939.  
  940.    (d) RET parameter: 8 characters.
  941.  
  942.    The maximum sizes for the ENVID and ORCPT parameters are intended to
  943.    be adequate for the transmission of "foreign" envelope identifier and
  944.    original recipient addresses.  However, user agents which use SMTP as
  945.    a message submission protocol SHOULD NOT generate ENVID parameters
  946.    which are longer than 38 characters in length.
  947.  
  948.    A conforming MTA MUST be able to accept SMTP command-lines which are
  949.    at least 1036 characters long (530 characters for the ORCPT and
  950.    NOTIFY parameters of the RCPT command, in addition to the 512
  951.  
  952.  
  953.  
  954. Moore                       Standards Track                    [Page 17]
  955.  
  956. RFC 1891           SMTP Delivery Status Notifications       January 1996
  957.  
  958.  
  959.    characters required by [1]).  If other SMTP extensions are supported
  960.    by the MTA, the MTA MUST be able to accept a command-line large
  961.    enough for each SMTP command and any combination of ESMTP parameters
  962.    which may be used with that command.
  963.  
  964. 7.  Format of delivery notifications
  965.  
  966.    The format of delivery status notifications is defined in [5], which
  967.    uses the framework defined in [8].  Delivery status notifications are
  968.    to be returned to the sender of the original message as outlined
  969.    below.
  970.  
  971. 7.1 SMTP Envelope to be used with delivery status notifications
  972.  
  973.    The DSN sender address (in the SMTP MAIL command) MUST be a null
  974.    reverse-path ("<>"), as required by section 5.3.3 of [9].  The DSN
  975.    recipient address (in the RCPT command) is copied from the MAIL
  976.    command which accompanied the message for which the DSN is being
  977.    issued.  When transmitting a DSN via SMTP, the RET parameter MUST NOT
  978.    be used.  The NOTIFY parameter MAY be used, but its value MUST be
  979.    NEVER.  The ENVID parameter (with a newly generated envelope-id)
  980.    and/or ORCPT parameter MAY be used.
  981.  
  982. 7.2 Contents of the DSN
  983.  
  984.    A DSN is transmitted as a MIME message with a top-level content-type
  985.    of multipart/report (as defined in [5]).
  986.  
  987.    The multipart/report content-type may be used for any of several
  988.    kinds of reports generated by the mail system.  When multipart/report
  989.    is used to convey a DSN, the report-type parameter of the
  990.    multipart/report content-type is "delivery-status".
  991.  
  992.    As described in [8], the first component of a multipart/report
  993.    content-type is a human readable explanation of the report.  For a
  994.    DSN, the second component of the multipart/report is of content-type
  995.    message/delivery-status (defined in [5]).  The third component of the
  996.    multipart/report consists of the original message or some portion
  997.    thereof.  When the value of the RET parameter is FULL, the full
  998.    message SHOULD be returned for any DSN which conveys notification of
  999.    delivery failure.  (However, if the length of the message is greater
  1000.    than some implementation-specified length, the MTA MAY return only
  1001.    the headers even if the RET parameter specified FULL.)  If a DSN
  1002.    contains no notifications of delivery failure, the MTA SHOULD return
  1003.    only the headers.
  1004.  
  1005.    The third component must have an appropriate content-type label.
  1006.    Issues concerning selection of the content-type are discussed in [8].
  1007.  
  1008.  
  1009.  
  1010. Moore                       Standards Track                    [Page 18]
  1011.  
  1012. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1013.  
  1014.  
  1015. 7.3 Message/delivery-status fields
  1016.  
  1017.    The message/delivery-status content-type defines a number of fields,
  1018.    with general specifications for their contents.  The following
  1019.    requirements for any DSNs generated in response to a message received
  1020.    by the SMTP protocol by a conforming SMTP server, are in addition to
  1021.    the requirements defined in [5] for the message/delivery-status type.
  1022.  
  1023.    When generating a DSN for a message which was received via the SMTP
  1024.    protocol, a conforming MTA will generate the following fields of the
  1025.    message/delivery-status body part:
  1026.  
  1027. (a) if an ENVID parameter was present on the MAIL command, an Original-
  1028.     Envelope-ID field MUST be supplied, and the value associated with
  1029.     the ENVID parameter must appear in that field.  If the message was
  1030.     received via SMTP with no ENVID parameter, the Original-Envelope-ID
  1031.     field MUST NOT be supplied.
  1032.  
  1033.     Since the ENVID parameter is encoded as xtext, but the Original-
  1034.     Envelope-ID header is NOT encoded as xtext, the MTA must decode the
  1035.     xtext encoding when copying the ENVID value to the Original-
  1036.     Envelope-ID field.
  1037.  
  1038. (b) The Reporting-MTA field MUST be supplied.  If Reporting MTA can
  1039.     determine its fully-qualified Internet domain name, the MTA-name-
  1040.     type subfield MUST be "dns", and the field MUST contain the fully-
  1041.     qualified domain name of the Reporting MTA. If the fully-qualified
  1042.     Internet domain name of the Reporting MTA is not known (for example,
  1043.     for an SMTP server which is not directly connected to the Internet),
  1044.     the Reporting-MTA field may contain any string identifying the MTA,
  1045.     however, in this case the MTA-name-type subfield MUST NOT be "dns".
  1046.     A MTA-name-type subfield value of "x-local-hostname" is suggested.
  1047.  
  1048. (c) Other per-message fields as defined in [5] MAY be supplied as
  1049.     appropriate.
  1050.  
  1051. (d) If the ORCPT parameter was provided for this recipient, the
  1052.     Original-Recipient field MUST be supplied, with its value taken from
  1053.     the ORCPT parameter.  If no ORCPT parameter was provided for this
  1054.     recipient, the Original-Recipient field MUST NOT appear.
  1055.  
  1056. (e) The Final-Recipient field MUST be supplied. It MUST contain the
  1057.     recipient address from the message envelope.  If the message was
  1058.     received via SMTP, the address-type will be "rfc822".
  1059.  
  1060. (f) The Action field MUST be supplied.
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Moore                       Standards Track                    [Page 19]
  1067.  
  1068. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1069.  
  1070.  
  1071. (g) The Status field MUST be supplied, using a status-code from [10].
  1072.     If there is no specific code which suitably describes a delivery
  1073.     failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent
  1074.     failure) MUST be used.
  1075.  
  1076. (h) For DSNs resulting from attempts to relay a message to one or more
  1077.     recipients via SMTP, the Remote-MTA field MUST be supplied for each
  1078.     of those recipients.  The mta-name-type subfields of those Remote-
  1079.     MTA fields will be "dns".
  1080.  
  1081. (i) For DSNs resulting from attempts to relay a message to one or more
  1082.     recipients via SMTP, the Diagnostic-Code MUST be supplied for each
  1083.     of those recipients.  The diagnostic-type subfield will be "smtp".
  1084.     See section 9.2(a) of this document for a description of the "smtp"
  1085.     diagnostic-code.
  1086.  
  1087. (j) For DSNs resulting from attempts to relay a message to one or more
  1088.     recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be
  1089.     supplied for each recipient, which contains the address of that
  1090.     recpient which was presented to the remote SMTP server.
  1091.  
  1092. (k) Other per-recipient fields defined in [5] MAY appear, as
  1093.     appropriate.
  1094.  
  1095. 8. Acknowledgments
  1096.  
  1097.    The author wishes to thank Eric Allman, Harald Alvestrand, Jim
  1098.    Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned
  1099.    Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios
  1100.    Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall
  1101.    Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for
  1102.    improvement of this document.
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Moore                       Standards Track                    [Page 20]
  1123.  
  1124. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1125.  
  1126.  
  1127. 9. Appendix - Type-Name Definitions
  1128.  
  1129.    The following type names are defined for use in DSN fields generated
  1130.    by conforming SMTP-based MTAs:
  1131.  
  1132. 9.1 "rfc822" address-type
  1133.  
  1134.    The "rfc822" address-type is to be used when reporting Internet
  1135.    electronic mail address in the Original-Recipient and Final-Recipient
  1136.    DSN fields.
  1137.  
  1138. (a) address-type name: rfc822
  1139.  
  1140. (b) syntax for mailbox addresses
  1141.  
  1142.     RFC822 mailbox addresses are generally expected to be of the form
  1143.  
  1144.     [route] addr-spec
  1145.  
  1146.     where "route" and "addr-spec" are defined in [2], and the "domain"
  1147.     portions of both "route" and "addr-spec" are fully-qualified domain
  1148.     names that are registered in the DNS.  However, an MTA MUST NOT
  1149.     modify an address obtained from the message envelope to force it to
  1150.     conform to syntax rules.
  1151.  
  1152. (c) If addresses of this type are not composed entirely of graphic
  1153. characters from the US-ASCII repertoire, a specification for how they
  1154. are to be encoded as graphic US-ASCII characters in a DSN Original-
  1155. Recipient or Final-Recipient DSN field.
  1156.  
  1157.     RFC822 addresses consist entirely of graphic characters from the US-
  1158.     ASCII repertoire, so no translation is necessary.
  1159.  
  1160. 9.2 "smtp" diagnostic-type
  1161.  
  1162.    The "smtp" diagnostic-type is to be used when reporting SMTP reply-
  1163.    codes in Diagnostic-Code DSN fields.
  1164.  
  1165. (a) diagnostic-type name: SMTP
  1166.  
  1167. (b) A description of the syntax to be used for expressing diagnostic
  1168. codes of this type as graphic characters from the US-ASCII repertoire.
  1169.  
  1170.     An SMTP diagnostic-code is of the form
  1171.  
  1172.     *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Moore                       Standards Track                    [Page 21]
  1179.  
  1180. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1181.  
  1182.  
  1183.     For a single-line SMTP reply to an SMTP command, the diagnostic-code
  1184.     SHOULD be an exact transcription of the reply.  For multi-line SMTP
  1185.     replies, it is necessary to insert a SPACE before each line after
  1186.     the first.  For example, an SMTP reply of:
  1187.  
  1188.     550-mailbox unavailable
  1189.     550 user has moved with no forwarding address
  1190.  
  1191.     could appear as follows in a Diagnostic-Code DSN field:
  1192.  
  1193.     Diagnostic-Code: smtp ; 550-mailbox unavailable
  1194.      550 user has moved with no forwarding address
  1195.  
  1196. (c) A list of valid diagnostic codes of this type and the meaning of
  1197. each code.
  1198.  
  1199.     SMTP reply-codes are currently defined in [1], [4], and [9].
  1200.     Additional codes may be defined by other RFCs.
  1201.  
  1202. 9.3 "dns" MTA-name-type
  1203.  
  1204.    The "dns" MTA-name-type should be used in the Reporting-MTA field.
  1205.    An MTA-name of type "dns" is a fully-qualified domain name.  The name
  1206.    must be registered in the DNS, and the address Postmaster@{mta-name}
  1207.    must be valid.
  1208.  
  1209. (a) MTA-name-type name: dns
  1210.  
  1211. (b) A description of the syntax of MTA names of this type, using BNF,
  1212. regular expressions, ASN.1, or other non-ambiguous language.
  1213.  
  1214.     MTA names of type "dns" SHOULD be valid Internet domain names.  If
  1215.     such domain names are not available, a domain-literal containing the
  1216.     internet protocol address is acceptable.  Such domain names
  1217.     generally conform to the following syntax:
  1218.  
  1219.     domain = real-domain / domain-literal
  1220.  
  1221.     real-domain = sub-domain *("." sub-domain)
  1222.  
  1223.     sub-domain = atom
  1224.  
  1225.     domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
  1226.  
  1227.     where "atom" and "DIGIT" are defined in [2].
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Moore                       Standards Track                    [Page 22]
  1235.  
  1236. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1237.  
  1238.  
  1239. (c) If MTA names of this type do not consist entirely of graphic
  1240. characters from the US-ASCII repertoire, a specification for how an MTA
  1241. name of this type should be expressed as a sequence of graphic US-ASCII
  1242. characters.
  1243.  
  1244.     MTA names of type "dns" consist entirely of graphic US-ASCII
  1245.     characters, so no translation is needed.
  1246.  
  1247. 10. Appendix - Example
  1248.  
  1249.    This example traces the flow of a single message addressed to
  1250.    multiple recipients.  The message is sent by Alice@Pure-Heart.ORG to
  1251.    Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU,
  1252.    Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a
  1253.    variety of per-recipient options.  The message is successfully
  1254.    delivered to Bob, Dana (via a gateway), Eric, and Fred.  Delivery
  1255.    fails for Carol and George.
  1256.  
  1257.    NOTE: Formatting rules for RFCs require that no line be longer than
  1258.    72 characters.  Therefore, in the following examples, some SMTP
  1259.    commands longer than 72 characters are printed on two lines, with the
  1260.    first line ending in "\".  In an actual SMTP transaction, such a
  1261.    command would be sent as a single line (i.e. with no embedded CRLFs),
  1262.    and without the "\" character that appears in these examples.
  1263.  
  1264. 10.1 Submission
  1265.  
  1266.    Alice's user agent sends the message to the SMTP server at Pure-
  1267.    Heart.ORG.  Note that while this example uses SMTP as a mail
  1268.    submission protocol, other protocols could also be used.
  1269.  
  1270. <<< 220 Pure-Heart.ORG SMTP server here
  1271. >>> EHLO Pure-Heart.ORG
  1272. <<< 250-Pure-Heart.ORG
  1273. <<< 250-DSN
  1274. <<< 250-EXPN
  1275. <<< 250 SIZE
  1276. >>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
  1277. <<< 250 <Alice@Pure-Heart.ORG> sender ok
  1278. >>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
  1279.     ORCPT=rfc822;Bob@Big-Bucks.COM
  1280. <<< 250 <Bob@Big-Bucks.COM> recipient ok
  1281. >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
  1282.     ORCPT=rfc822;Carol@Ivory.EDU
  1283. <<< 250 <Carol@Ivory.EDU> recipient ok
  1284. >>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
  1285.     ORCPT=rfc822;Dana@Ivory.EDU
  1286. <<< 250 <Dana@Ivory.EDU> recipient ok
  1287.  
  1288.  
  1289.  
  1290. Moore                       Standards Track                    [Page 23]
  1291.  
  1292. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1293.  
  1294.  
  1295. >>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
  1296.     ORCPT=rfc822;Eric@Bombs.AF.MIL
  1297. <<< 250 <Eric@Bombs.AF.MIL> recipient ok
  1298. >>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
  1299. <<< 250 <Fred@Bombs.AF.MIL> recipient ok
  1300. >>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
  1301.     ORCPT=rfc822;George@Tax-ME.GOV
  1302. <<< 250 <George@Tax-ME.GOV> recipient ok
  1303. >>> DATA
  1304. <<< 354 okay, send message
  1305. >>> (message goes here)
  1306. >>> .
  1307. <<< 250 message accepted
  1308. >>> QUIT
  1309. <<< 221 goodbye
  1310.  
  1311. 10.2 Relay to Big-Bucks.COM
  1312.  
  1313.    The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM.
  1314.    (For the purpose of this example, mail.Big-Bucks.COM is the primary
  1315.    mail exchanger for Big-Bucks.COM).
  1316.  
  1317. <<< 220 mail.Big-Bucks.COM says hello
  1318. >>> EHLO Pure-Heart.ORG
  1319. <<< 250-mail.Big-Bucks.COM
  1320. <<< 250 DSN
  1321. >>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
  1322. <<< 250 sender okay
  1323. >>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
  1324.     ORCPT=rfc822;Bob@Big-Bucks.COM
  1325. <<< 250 recipient okay
  1326. >>> DATA
  1327. <<< 354 send message
  1328. >>> (message goes here)
  1329. >>> .
  1330. <<< 250 message received
  1331. >>> QUIT
  1332. <<< 221 bcnu
  1333.  
  1334. 10.3 Relay to Ivory.EDU
  1335.  
  1336.    The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as
  1337.    it happens) is a gateway to a LAN-based mail system that accepts SMTP
  1338.    mail and supports the DSN extension.
  1339.  
  1340. <<< 220 Ivory.EDU gateway to FooMail(tm) here
  1341. >>> EHLO Pure-Heart.ORG
  1342. <<< 250-Ivory.EDU
  1343.  
  1344.  
  1345.  
  1346. Moore                       Standards Track                    [Page 24]
  1347.  
  1348. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1349.  
  1350.  
  1351. <<< 250 DSN
  1352. >>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
  1353. <<< 250 ok
  1354. >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
  1355.     ORCPT=rfc822;Carol@Ivory.EDU
  1356. <<< 550 error - no such recipient
  1357. >>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
  1358.     ORCPT=rfc822;Dana@Ivory.EDU
  1359. <<< 250 recipient ok
  1360. >>> DATA
  1361. <<< 354 send message, end with '.'
  1362. >>> (message goes here)
  1363. >>> .
  1364. <<< 250 message received
  1365. >>> QUIT
  1366. <<< 221 bye
  1367.  
  1368.    Note that since the Ivory.EDU refused to accept mail for
  1369.    Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the
  1370.    sender-SMTP (in this case Pure-Heart.ORG) must generate a DSN.
  1371.  
  1372. 10.4 Relay to Bombs.AF.MIL
  1373.  
  1374.    The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which
  1375.    does not support the SMTP extension.  Because the sender specified
  1376.    NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure-
  1377.    Heart.ORG chooses to send the message for that recipient in a
  1378.    separate transaction with a reverse-path of <>.
  1379.  
  1380. <<< 220-Bombs.AF.MIL reporting for duty.
  1381. <<< 220 Electronic mail is to be used for official business only.
  1382. >>> EHLO Pure-Heart.ORG
  1383. <<< 502 command not implemented
  1384. >>> RSET
  1385. <<< 250 reset
  1386. >>> HELO Pure-Heart.ORG
  1387. <<< 250 Bombs.AF.MIL
  1388. >>> MAIL FROM:<Alice@Pure-Heart.ORG>
  1389. <<< 250 ok
  1390. >>> RCPT TO:<Eric@Bombs.AF.MIL>
  1391. <<< 250 ok
  1392. >>> DATA
  1393. <<< 354 send message
  1394. >>> (message goes here)
  1395. >>> .
  1396. <<< 250 message accepted
  1397. >>> MAIL FROM:<>
  1398. <<< 250 ok
  1399.  
  1400.  
  1401.  
  1402. Moore                       Standards Track                    [Page 25]
  1403.  
  1404. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1405.  
  1406.  
  1407. >>> RCPT TO:<Fred@Bombs.AF.MIL>
  1408. <<< 250 ok
  1409. >>> DATA
  1410. <<< 354 send message
  1411. >>> (message goes here)
  1412. >>> .
  1413. <<< 250 message accepted
  1414. >>> QUIT
  1415. <<< 221 Bombs.AF.MIL closing connection
  1416.  
  1417. 10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV
  1418.  
  1419.    The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV.  (this
  1420.    step is not shown).  MTA Tax-ME.GOV then forwards the message to
  1421.    Sam@Boondoggle.GOV (shown below).  Both Tax-ME.GOV and Pure-Heart.ORG
  1422.    support the SMTP DSN extension.  Note that RET, ENVID, and ORCPT all
  1423.    retain their original values.
  1424.  
  1425. <<< 220 BoonDoggle.GOV says hello
  1426. >>> EHLO Pure-Heart.ORG
  1427. <<< 250-mail.Big-Bucks.COM
  1428. <<< 250 DSN
  1429. >>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
  1430. <<< 250 sender okay
  1431. >>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
  1432.     ORCPT=rfc822;George@Tax-ME.GOV
  1433. <<< 250 recipient okay
  1434. >>> DATA
  1435. <<< 354 send message
  1436. >>> (message goes here)
  1437. >>> .
  1438. <<< 250 message received
  1439. >>> QUIT
  1440. <<< 221 bcnu
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Moore                       Standards Track                    [Page 26]
  1459.  
  1460. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1461.  
  1462.  
  1463. 10.6 "Delivered" DSN for Bob@Big-Bucks.COM
  1464.  
  1465.    MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big-
  1466.    Bucks.COM.  Because the sender specified NOTIFY=SUCCESS, mail.Big-
  1467.    Bucks.COM issues the following DSN, and sends it to Alice@Pure-
  1468.    Heart.ORG.
  1469.  
  1470. To: Alice@Pure-Heart.ORG
  1471. From: postmaster@mail.Big-Bucks.COM
  1472. Subject: Delivery Notification (success) for Bob@Big-Bucks.COM
  1473. Content-Type: multipart/report; report-type=delivery-status;
  1474.     boundary=abcde
  1475. MIME-Version: 1.0
  1476.  
  1477. --abcde
  1478. Content-type: text/plain; charset=us-ascii
  1479.  
  1480. Your message (id QQ314159) was successfully delivered to
  1481. Bob@Big-Bucks.COM.
  1482.  
  1483. --abcde
  1484. Content-type: message/delivery-status
  1485.  
  1486. Reporting-MTA: dns; mail.Big-Bucks.COM
  1487. Original-Envelope-ID: QQ314159
  1488.  
  1489. Original-Recipient: rfc822;Bob@Big-Bucks.COM
  1490. Final-Recipient: rfc822;Bob@Big-Bucks.COM
  1491. Action: delivered
  1492. Status: 2.0.0
  1493.  
  1494. --abcde
  1495. Content-type: message/rfc822
  1496.  
  1497. (headers of returned message go here)
  1498.  
  1499. --abcde--
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Moore                       Standards Track                    [Page 27]
  1515.  
  1516. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1517.  
  1518.  
  1519. 10.7 Failed DSN for Carol@Ivory.EDU
  1520.  
  1521.    Because delivery to Carol failed and the sender specified
  1522.    NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP
  1523.    client to which the failure was reported via SMTP) issues the
  1524.    following DSN.
  1525.  
  1526. To: Alice@Pure-Heart.ORG
  1527. From: postmaster@Pure-Heart.ORG
  1528. Subject: Delivery Notification (failure) for Carol@Ivory.EDU
  1529. Content-Type: multipart/report; report-type=delivery-status;
  1530.               boundary=bcdef
  1531. MIME-Version: 1.0
  1532.  
  1533. --bcdef
  1534. Content-type: text/plain; charset=us-ascii
  1535.  
  1536. Your message (id QQ314159) could not be delivered to
  1537. Carol@Ivory.EDU.
  1538.  
  1539. A transcript of the session follows:
  1540.  
  1541. (while talking to Ivory.EDU)
  1542. >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE
  1543. <<< 550 error - no such recipient
  1544.  
  1545. --bcdef
  1546. Content-type: message/delivery-status
  1547.  
  1548. Reporting-MTA: dns; Pure-Heart.ORG
  1549. Original-Envelope-ID: QQ314159
  1550.  
  1551. Original-Recipient: rfc822;Carol@Ivory.EDU
  1552. Final-Recipient: rfc822;Carol@Ivory.EDU
  1553. SMTP-Remote-Recipient: Carol@Ivory.EDU
  1554. Diagnostic-Code: smtp; 550 error - no such recipient
  1555. Action: failed
  1556. Status: 5.0.0
  1557.  
  1558. --bcdef
  1559. Content-type: message/rfc822
  1560.  
  1561. (headers of returned message go here)
  1562.  
  1563. --bcdef--
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Moore                       Standards Track                    [Page 28]
  1571.  
  1572. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1573.  
  1574.  
  1575. 10.8 Relayed DSN For Dana@Ivory.EDU
  1576.  
  1577.    Although the mail gateway Ivory.EDU supports the DSN SMTP extension,
  1578.    the LAN mail system attached to its other side does not generate
  1579.    positive delivery confirmations.  So Ivory.EDU issues a "relayed"
  1580.    DSN:
  1581.  
  1582. To: Alice@Pure-Heart.ORG
  1583. From: postmaster@Ivory.EDU
  1584. Subject: mail relayed for Dana@Ivory.EDU
  1585. Content-Type: multipart/report; report-type=delivery-status;
  1586.     boundary=cdefg
  1587. MIME-Version: 1.0
  1588.  
  1589. --cdefg
  1590. Content-type: text/plain; charset=us-ascii
  1591.  
  1592. Your message (addressed to Dana@Ivory.EDU) was successfully
  1593. relayed to:
  1594.  
  1595. ymail!Dana
  1596.  
  1597. by the FooMail gateway at Ivory.EDU.
  1598.  
  1599. Unfortunately, the remote mail system does not support
  1600. confirmation of actual delivery.  Unless delivery to ymail!Dana
  1601. fails, this will be the only delivery status notification sent.
  1602.  
  1603. --cdefg
  1604. Content-type: message/delivery-status
  1605.  
  1606. Reporting-MTA: dns; Ivory.EDU
  1607. Original-Envelope-ID: QQ314159
  1608.  
  1609. Original-Recipient: rfc822;Dana@Ivory.EDU
  1610. Final-Recipient: rfc822;Dana@Ivory.EDU
  1611. Action: relayed
  1612. Status: 2.0.0
  1613.  
  1614. --cdefg
  1615. Content-type: message/rfc822
  1616.  
  1617. (headers of returned message go here)
  1618.  
  1619. --cdefg--
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Moore                       Standards Track                    [Page 29]
  1627.  
  1628. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1629.  
  1630.  
  1631. 10.9 Failure notification for Sam@Boondoggle.GOV
  1632.  
  1633.    The message originally addressed to George@Tax-ME.GOV was forwarded
  1634.    to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to
  1635.    deliver the message due to a lack of disk space in Sam's mailbox.
  1636.    After trying for several days, Boondoggle.GOV returned the following
  1637.    DSN:
  1638.  
  1639. To: Alice@BigHeart.ORG
  1640. From: Postmaster@Boondoggle.GOV
  1641. Subject: Delivery failure for Sam@Boondoggle.GOV
  1642. Content-Type: multipart/report; report-type=delivery-status;
  1643.               boundary=defgh
  1644. MIME-Version: 1.0
  1645.  
  1646. --defgh
  1647. Your message, originally addressed to George@Tax-ME.GOV, and forwarded
  1648. from there to Sam@Boondoggle.GOV could not be delivered, for the
  1649. following reason:
  1650.  
  1651. write error to mailbox, disk quota exceeded
  1652.  
  1653. --defgh
  1654. Content-type: message/delivery-status
  1655.  
  1656. Reporting-MTA: Boondoggle.GOV
  1657. Original-Envelope-ID: QQ314159
  1658.  
  1659. Original-Recipient: rfc822;George@Tax-ME.GOV
  1660. Final-Recipient: rfc822;Sam@Boondoggle.GOV
  1661. Action: failed
  1662. Status: 4.2.2 (disk quota exceeded)
  1663.  
  1664. --defgh
  1665. Content-type: message/rfc822
  1666.  
  1667. (headers of returned message go here)
  1668.  
  1669. --defgh--
  1670.  
  1671.  
  1672.  
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Moore                       Standards Track                    [Page 30]
  1683.  
  1684. RFC 1891           SMTP Delivery Status Notifications       January 1996
  1685.  
  1686.  
  1687. 11. References
  1688.  
  1689.    [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  1690.        USC/Information Sciences Institute, August 1982.
  1691.  
  1692.    [2] Crocker, D., "Standard for the Format of ARPA Internet Text
  1693.        Messages", STD 11, RFC 822, UDEL, August 1982.
  1694.  
  1695.    [3] Westine, A., and J. Postel, "Problems with the Maintenance of
  1696.        Large Mailing Lists.", RFC 1211, USC/Information Sciences
  1697.        Institute, March 1991.
  1698.  
  1699.    [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
  1700.        "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
  1701.        Consulting, Inc., Network Management Associates, Inc., Silicon
  1702.        Graphics, Inc., July 1994.
  1703.  
  1704.    [5] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
  1705.        Delivery Status Notifications", RFC 1894, University of Tennessee,
  1706.        Octel Network Services, January 1996.
  1707.  
  1708.    [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
  1709.        1730, University of Washington, 20 December 1994.
  1710.  
  1711.    [7] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
  1712.        1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
  1713.  
  1714.    [8] Vaudreuil, G., "The Multipart/Report Content Type for the
  1715.        Reporting of Mail System Administrative Messages", RFC 1892, Octel
  1716.        Network Services, January 1996.
  1717.  
  1718.    [9] Braden, R., Editor, "Requirements for Internet Hosts - Application
  1719.        and Support", STD 3, RFC 1123, IETF, October 1989.
  1720.  
  1721.    [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
  1722.         Octel Network Services, January 1996.
  1723.  
  1724. 12. Author's Address
  1725.  
  1726.    Keith Moore
  1727.    University of Tennessee
  1728.    107 Ayres Hall
  1729.    Knoxville, TN 37996-1301
  1730.    USA
  1731.  
  1732.    EMail: moore@cs.utk.edu
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Moore                       Standards Track                    [Page 31]
  1739.  
  1740.