rfc1894.txt

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

   DSN could be issued even though the message actually reached the
   recipient.











































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


5. Appendix - collected grammar

   NOTE:  The following lexical tokens are defined in RFC 822:  atom,
   CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text.
   The date-time lexical token is defined in [8].

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

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

address-type = atom

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

delivery-status-content =
     per-message-fields 1*( CRLF per-recipient-fields )

diagnostic-code-field =
     "Diagnostic-Code" ":" diagnostic-type ";" *text

diagnostic-type = atom

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

envelope-id = *text

extension-field = extension-field-name ":" *text

extension-field-name = atom

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

generic-address = *text

last-attempt-date-field = "Last-Attempt-Date" ":" date-time

mta-name = *text

mta-name-type = atom

original-envelope-id-field =
     "Original-Envelope-Id" ":" envelope-id

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




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


per-message-fields =
     [ original-envelope-id-field CRLF ]
     reporting-mta-field CRLF
     [ dsn-gateway-field CRLF ]
     [ received-from-mta-field CRLF ]
     [ arrival-date-field CRLF ]
     *( extension-field CRLF )

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 )

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

remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name

reporting-mta-field =
     "Reporting-MTA" ":" mta-name-type ";" mta-name

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-field = "Status" ":" status-code

will-retry-until-field = "Will-Retry-Until" ":" date-time













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


6. Appendix - Guidelines for gatewaying DSNs

   NOTE:  This section provides non-binding recommendations for the
   construction of mail gateways that wish to provide semi-transparent
   delivery reports between the Internet and another electronic mail
   system.  Specific DSN gateway requirements for a particular pair of
   mail systems may be defined by other documents.

6.1 Gatewaying from other mail systems to DSNs

   A mail gateway may issue a DSN to convey the contents of a "foreign"
   delivery or non-delivery notification over Internet mail.  When there
   are appropriate mappings from the foreign notification elements to
   DSN fields, the information may be transmitted in those DSN fields.
   Additional information (such as might be useful in a trouble ticket
   or needed to tunnel the foreign notification through the Internet)
   may be defined in extension DSN fields.  (Such fields should be given
   names that identify the foreign mail protocol, e.g. X400-* for X.400
   NDN or DN protocol elements)

   The gateway must attempt to supply reasonable values for the
   Reporting-MTA, Final-Recipient, Action, and Status fields.  These
   will normally be obtained by translating the values from the remote
   delivery or non-delivery notification into their Internet-style
   equivalents.  However, some loss of information is to be expected.
   For example, the set of status-codes defined for DSNs may not be
   adequate to fully convey the delivery diagnostic code from the
   foreign system.  The gateway should assign the most precise code
   which describes the failure condition, falling back on "generic"
   codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0
   (permanent failure) when necessary.  The actual foreign diagnostic
   code should be retained in the Diagnostic-Code field (with an
   appropriate diagnostic-type value) for use in trouble tickets or
   tunneling.

   The sender-specified recipient address, and the original envelope-id,
   if present in the foreign transport envelope, should be preserved in
   the Original-Recipient and Original-Envelope-ID fields.

   The gateway should also attempt to preserve the "final" recipient
   addresses and MTA names from the foreign system.  Whenever possible,
   foreign protocol elements should be encoded as meaningful printable
   ASCII strings.

   For DSNs produced from foreign delivery or nondelivery notifications,
   the name of the gateway MUST appear in the DSN-Gateway field of the
   DSN.




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


6.2 Gatewaying from DSNs to other mail systems

   It may be possible to gateway DSNs from the Internet into a foreign
   mail system.  The primary purpose of such gatewaying is to convey
   delivery status information in a form that is usable by the
   destination system.  A secondary purpose is to allow "tunneling" of
   DSNs through foreign mail systems, in case the DSN may be gatewayed
   back into the Internet.

   In general, the recipient of the DSN (i.e., the sender of the
   original message) will want to know, for each recipient: the closest
   available approximation to the original recipient address, the
   delivery status (success, failure, or temporary failure), and for
   failed deliveries, a diagnostic code that describes the reason for
   the failure.

   If possible, the gateway should attempt to preserve the Original-
   Recipient address and Original-Envelope-ID (if present), in the
   resulting foreign delivery status report.

   When reporting delivery failures, if the diagnostic-type subfield of
   the Diagnostic-Code field indicates that the original diagnostic code
   is understood by the destination environment, the information from
   the Diagnostic-Code field should be used.  Failing that, the
   information in the Status field should be mapped into the closest
   available diagnostic code used in the destination environment.

   If it is possible to tunnel a DSN through the destination
   environment, the gateway specification may define a means of
   preserving the DSN information in the delivery status reports used by
   that environment.




















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


7. Appendix - Guidelines for use of DSNs by mailing list exploders

   NOTE: This section pertains only to the use of DSNs by "mailing
   lists" as defined in [4], section 7.2.7.

   DSNs are designed to be used by mailing list exploders to allow them
   to detect and automatically delete recipients for whom mail delivery
   fails repeatedly.

   When forwarding a message to list subscribers, the mailing list
   exploder should always set the envelope return address (e.g. SMTP
   MAIL FROM address) to point to a special address which is set up to
   received nondelivery reports.  A "smart" mailing list exploder can
   therefore intercept such nondelivery reports, and if they are in the
   DSN format, automatically examine them to determine for which
   recipients a message delivery failed or was delayed.

   The Original-Recipient field should be used if available, since it
   should exactly match the subscriber address known to the list.  If
   the Original-Recipient field is not available, the recipient field
   may resemble the list subscriber address.  Often, however, the list
   subscriber will have forwarded his mail to a different address, or
   the address may be subject to some re-writing, so heuristics may be
   required to successfully match an address from the recipient field.
   Care is needed in this case to minimize the possibility of false
   matches.

   The reason for delivery failure can be obtained from the Status and
   Action fields, and from the Diagnostic-Code field (if the status-type
   is recognized).  Reports for recipients with action values other than
   "failed" can generally be ignored; in particular, subscribers should
   not be removed from a list due to "delayed" reports.

   In general, almost any failure status code (even a "permanent" one)
   can result from a temporary condition.  It is therefore recommended
   that a list exploder not delete a subscriber based on any single
   failure DSN (regardless of the status code), but only on the
   persistence of delivery failure over a period of time.

   However, some kinds of failures are less likely than others to have
   been caused by temporary conditions, and some kinds of failures are
   more likely to be noticed and corrected quickly than others.  Once
   more precise status codes are defined, it may be useful to
   differentiate between the status codes when deciding whether to
   delete a subscriber.  For example, on a list with a high message
   volume, it might be desirable to temporarily suspend delivery to a
   recipient address which causes repeated "temporary" failures, rather
   than simply deleting the recipient.  The duration of the suspension



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


   might depend on the type of error.  On the other hand, a "user
   unknown" error which persisted for several days could be considered a
   reliable indication that address were no longer valid.

8. Appendix - IANA registration forms for DSN types

   The forms below are for use when registering a new address-type,
   diagnostic-type, or MTA-name-type with the Internet Assigned Numbers
   Authorit