rfc1894.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

sender's environment                            recipient's environment
............................ ..........................................
                           : :
                       (1) : :                             (2)
  +-----+  +--------+  +--------+  +---------+  +---------+   +------+
  |     |  |        |  |        |  |Received-|  |         |   |      |
  |     |=>|Original|=>|        |->|  From   |->|Reporting|-->|Remote|
  | user|  |   MTA  |  |        |  |   MTA   |  |   MTA   |<No|  MTA |
  |agent|  +--------+  |Gateway |  +---------+  +----v----+   +------+
  |     |              |        |                    |
  |     | <============|        |<-------------------+
  +-----+              |        |(4)                (3)
                       +--------+
                           : :
...........................: :.........................................

              Figure 2.  DSNs in the presence of gateways

     (1) message is gatewayed into recipient's environment
     (2) attempt to relay message fails
     (3) reporting-mta (in recipient's environment) returns nondelivery
         notification
     (4) gateway translates foreign notification into a DSN



   The mta-name portion of the Reporting-MTA field is formatted
   according to the conventions indicated by the mta-name-type subfield.
   If an MTA functions as a gateway between dissimilar mail environments
   and thus is known by multiple names depending on the environment, the
   mta-name subfield SHOULD contain the name used by the environment
   from which the message was accepted by the Reporting-MTA.

   Because the exact spelling of an MTA name may be significant in a
   particular environment, MTA names are CASE-SENSITIVE.

2.2.3 The DSN-Gateway field

   The DSN-Gateway field indicates the name of the gateway or MTA which
   translated a foreign (non-Internet) delivery status notification into
   this DSN.  This field MUST appear in any DSN which was translated by
   a gateway from a foreign system into DSN format, and MUST NOT appear
   otherwise.

   dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name






Moore & Vaudreuil           Standards Track                    [Page 13]

RFC 1894             Delivery Status Notifications          January 1996


   For gateways into Internet mail, the MTA-name-type will normally be
   "smtp", and the mta-name will be the Internet domain name of the
   gateway.

2.2.4 The Received-From-MTA DSN field

   The optional Received-From-MTA field indicates the name of the MTA
   from which the message was received.

     received-from-mta-field =
          "Received-From-MTA" ":" mta-name-type ";" mta-name

   If the message was received from an Internet host via SMTP, the
   contents of the mta-name subfield SHOULD be the Internet domain name
   supplied in the HELO or EHLO command, and the network address used by
   the SMTP client SHOULD be included as a comment enclosed in
   parentheses.  (In this case, the MTA-name-type will be "smtp".)

   The mta-name portion of the Received-From-MTA field is formatted
   according to the conventions indicated by the MTA-name-type subfield.

   Since case is significant in some mail systems, the exact spelling,
   including case, of the MTA name SHOULD be preserved.

2.2.5 The Arrival-Date DSN field

   The optional Arrival-Date field indicates the date and time at which
   the message arrived at the Reporting MTA.  If the Last-Attempt-Date
   field is also provided in a per-recipient field, this can be used to
   determine the interval between when the message arrived at the
   Reporting MTA and when the report was issued for that recipient.

     arrival-date-field = "Arrival-Date" ":" date-time

   The date and time are expressed in RFC 822 'date-time' format, as
   modified by [8].  Numeric timezones ([+/-]HHMM format) MUST be used.

2.3 Per-Recipient DSN fields

   A DSN contains information about attempts to deliver a message to one
   or more recipients.  The delivery information for any particular
   recipient is contained in a group of contiguous per-recipient fields.
   Each group of per-recipient fields is preceded by a blank line.








Moore & Vaudreuil           Standards Track                    [Page 14]

RFC 1894             Delivery Status Notifications          January 1996


   The syntax for the group of per-recipient fields is as follows:


     per-recipient-fields =
          [ original-recipient-field CRLF ]
          final-recipient-field CRLF
          action-field CRLF
          status-field CRLF
          [ remote-mta-field CRLF ]
          [ diagnostic-code-field CRLF ]
          [ last-attempt-date-field CRLF ]
          [ will-retry-until-field CRLF ]
          *( extension-field CRLF )

2.3.1 Original-Recipient field

   The Original-Recipient field indicates the original recipient address
   as specified by the sender of the message for which the DSN is being
   issued.

     original-recipient-field =
          "Original-Recipient" ":" address-type ";" generic-address

     generic-address = *text

   The address-type field indicates the type of the original recipient
   address.  If the message originated within the Internet, the
   address-type field field will normally be "rfc822", and the address
   will be according to the syntax specified in [6].  The value
   "unknown" should be used if the Reporting MTA cannot determine the
   type of the original recipient address from the message envelope.

   This field is optional.  It should be included only if the sender-
   specified recipient address was present in the message envelope, such
   as by the SMTP extensions defined in [4].  This address is the same
   as that provided by the sender and can be used to automatically
   correlate DSN reports and message transactions.

2.3.2 Final-Recipient field

   The Final-Recipient field indicates the recipient for which this set
   of per-recipient fields applies.  This field MUST be present in each
   set of per-recipient data.








Moore & Vaudreuil           Standards Track                    [Page 15]

RFC 1894             Delivery Status Notifications          January 1996


   The syntax of the field is as follows:

     final-recipient-field =
          "Final-Recipient" ":" address-type ";" generic-address

   The generic-address subfield of the Final-Recipient field MUST
   contain the mailbox address of the recipient (from the transport
   envelope) as it was when the message was accepted for delivery by the
   Reporting MTA.

   The Final-Recipient address may differ from the address originally
   provided by the sender, because it may have been transformed during
   forwarding and gatewaying into an totally unrecognizable mess.
   However, in the absence of the optional Original-Recipient field, the
   Final-Recipient field and any returned content may be the only
   information available with which to correlate the DSN with a
   particular message submission.

   The address-type subfield indicates the type of address expected by
   the reporting MTA in that context.  Recipient addresses obtained via
   SMTP will normally be of address-type "rfc822".

   NOTE: The Reporting MTA is not expected to ensure that the address
   actually conforms to the syntax conventions of the address-type.
   Instead, it MUST report exactly the address received in the envelope,
   unless that address contains characters such as CR or LF which may
   not appear in a DSN field.

   Since mailbox addresses (including those used in the Internet) may be
   case sensitive, the case of alphabetic characters in the address MUST
   be preserved.

2.3.3 Action field

   The Action field indicates the action performed by the Reporting-MTA
   as a result of its attempt to deliver the message to this recipient
   address.  This field MUST be present for each recipient named in the
   DSN.

   The syntax for the action-field is:

     action-field = "Action" ":" action-value

     action-value =
          "failed" / "delayed" / "delivered" / "relayed" / "expanded"






Moore & Vaudreuil           Standards Track                    [Page 16]

RFC 1894             Delivery Status Notifications          January 1996


   The action-value may be spelled in any combination of upper and lower
   case characters.

"failed"     indicates that the message could not be delivered to the
             recipient.  The Reporting MTA has abandoned any attempts to
             deliver the message to this recipient.  No further
             notifications should be expected.

"delayed"    indicates that the Reporting MTA has so far been unable to
             deliver or relay the message, but it will continue to
             attempt to do so.  Additional notification messages may be
             issued as the message is further delayed or successfully
             delivered, or if delivery attempts are later abandoned.

"delivered"  indicates that the message was successfully delivered to
             the recipient address specified by the sender, which
             includes "delivery" to a mailing list exploder.  It does
             not indicate that the message has been read.  This is a
             terminal state and no further DSN for this recipient should
             be expected.

"relayed"    indicates that the message has been relayed or gatewayed
             into an environment that does not accept responsibility for
             generating DSNs upon successful delivery.  This action-
             value SHOULD NOT be used unless the sender has requested
             notification of successful delivery for this recipient.

"expanded"   indicates that the message has been successfully delivered
             to the recipient address as specified by the sender, and
             forwarded by the Reporting-MTA beyond that destination to
             multiple additional recipient addresses.  An action-value
             of "expanded" differs from "delivered" in that "expanded"
             is not a terminal state. Further "failed" and/or "delayed"
             notifications may be provided.

             Using the terms "mailing list" and "alias" as defined in
             [4], section 7.2.7:  An action-value of "expanded" is only
             to be used when the message is delivered to a multiple-
             recipient "alias".  An action-value of "expanded" SHOULD
             NOT be used with a DSN issued on delivery of a message to a
             "mailing list".

   NOTE ON ACTION VS. STATUS CODES:  Although the 'action' field might
   seem to be redundant with the 'status' field, this is not the case.
   In particular, a "temporary failure" ("4") status code could be used
   with an action-value of either "delayed" or "failed".  For example,
   assume that an SMTP client repeatedly tries to relay a message to the
   mail exchanger for a recipient, but fails because a query to a domain



Moore & Vaudreuil           Standards Track                    [Page 17]

RFC 1894             Delivery Status Notifications          January 1996


   name server timed out.  After a few hours, it might issue a "delayed"
   DSN to inform the sender that the message had not yet been delivered.
   After a few days, the MTA might abandon its attempt to deliver the
   message and return a "failed" DSN.  The status code (which would
   begin with a "4" to indicate "temporary failure") would be the same
   for both DSNs.

   Another example for which the action and status codes may appear
   contradictory:  If an MTA or mail gateway cannot deliver a message
   because doing so would entail conversions resulting in an
   unacceptable loss of information, it would issue a DSN with the
   'action' field of "failure" and a status code of 'XXX'.  If the
   message had instead been relayed, but with some loss of information,
   it might generate a DSN with the same XXX status-code, but with an
   action field of "relayed".

2.3.4 Status field

   The per-recipient Status field contains a transport-independent
   status code which indicates the delivery status of the message to
   that recipient.  This field MUST be present for each delivery attempt
   which is described by a DSN.

   The syntax of the status field is:

     status-field = "Status" ":" status-code

     status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT

          ; White-space characters and comments are NOT allowed within a
          ; status-code, though a comment enclosed in parentheses MAY follow
          ; the last numeric subfield of the status-code.  Each numeric
          ; subfield within the status-code MUST be expressed without
          ; leading zero digits.

   Status codes thus consist of three numerical fields separated by ".".
   The first sub-field indicates whether the delivery attempt was
   successful (2 = success, 4 = persistent temporary failure, 5 =
   permanent failure).  The second sub-field indicates the probable
   source of any delivery anomalies, and the third sub-field denotes a
   precise error condition, if known.

   The initial set of status-codes is defined in [5].








Moore & Vaudreuil           Standards Track                    [Page 18]

RFC 1894             Delivery Status Notifications          January 1996


2.3.5 Remote-MTA field

   The value associated with the Remote-MTA DSN field is a printable