rfc1894.txt

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

   ASCII representation of the name of the "remote" MTA that reported
   delivery status to the "reporting" MTA.

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

   NOTE: The Remote-MTA field preserves the "while talking to"
   information that was provided in some pre-existing nondelivery
   reports.

   This field is optional.  It MUST NOT be included if no remote MTA was
   involved in the attempted delivery of the message to that recipient.

2.3.6 Diagnostic-Code field

   For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field
   contains the actual diagnostic code issued by the mail transport.
   Since such codes vary from one mail transport to another, the
   diagnostic-type subfield is needed to specify which type of
   diagnostic code is represented.

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

   NOTE:  The information in the Diagnostic-Code field may be somewhat
   redundant with that from the Status field.  The Status field is
   needed so that any DSN, regardless of origin, may be understood by
   any user agent or gateway that parses DSNs.  Since the Status code
   will sometimes be less precise than the actual transport diagnostic
   code, the Diagnostic-Code field is provided to retain the latter
   information.  Such information may be useful in a trouble ticket sent
   to the administrator of the Reporting MTA, or when tunneling foreign
   nondelivery reports through DSNs.

   If the Diagnostic Code was obtained from a Remote MTA during an
   attempt to relay the message to that MTA, the Remote-MTA field should
   be present.  When interpreting a DSN, the presence of a Remote-MTA
   field indicates that the Diagnostic Code was issued by the Remote
   MTA.  The absence of a Remote-MTA indicates that the Diagnostic Code
   was issued by the Reporting MTA.

   In addition to the Diagnostic-Code itself, additional textual
   description of the diagnostic, MAY appear in a comment enclosed in
   parentheses.





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


   This field is optional, because some mail systems supply no
   additional information beyond that which is returned in the 'action'
   and 'status' fields.  However, this field SHOULD be included if
   transport-specific diagnostic information is available.

2.3.7 Last-Attempt-Date field

   The Last-Attempt-Date field gives the date and time of the last
   attempt to relay, gateway, or deliver the message (whether successful
   or unsuccessful) by the Reporting MTA.  This is not necessarily the
   same as the value of the Date field from the header of the message
   used to transmit this delivery status notification: In cases where
   the DSN was generated by a gateway, the Date field in the message
   header contains the time the DSN was sent by the gateway and the DSN
   Last-Attempt-Date field contains the time the last delivery attempt
   occurred.

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

   This field is optional.  It MUST NOT be included if the actual date
   and time of the last delivery attempt are not available (which might
   be the case if the DSN were being issued by a gateway).

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

   3.2.1.5 final-log-id field

   The "final-log-id" field gives the final-log-id of the message that
   was used by the final-mta.  This can be useful as an index to the
   final-mta's log entry for that delivery attempt.

     final-log-id-field = "Final-Log-ID" ":" *text

   This field is optional.

2.3.8 Will-Retry-Until field

   For DSNs of type "delayed", the Will-Retry-Until field gives the date
   after which the Reporting MTA expects to abandon all attempts to
   deliver the message to that recipient.  The Will-Retry-Until field is
   optional for "delay" DSNs, and MUST NOT appear in other DSNs.

     will-retry-until-field = "Will-Retry-Until" ":" 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.




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


2.4 Extension fields

   Additional per-message or per-recipient DSN fields may be defined in
   the future by later revisions or extensions to this specification.
   Extension-field names beginning with "X-" will never be defined as
   standard fields; such names are reserved for experimental use.  DSN
   field names NOT beginning with "X-" MUST be registered with the
   Internet Assigned Numbers Authority (IANA) and published in an RFC.

   Extension DSN fields may be defined for the following reasons:

   (a) To allow additional information from foreign delivery status
       reports to be tunneled through Internet DSNs.  The names of such
       DSN fields should begin with an indication of the foreign
       environment name (e.g.  X400-Physical-Forwarding-Address).

   (b) To allow the transmission of diagnostic information which is
       specific to a particular mail transport protocol.  The names of
       such DSN fields should begin with an indication of the mail
       transport being used (e.g. SMTP-Remote-Recipient-Address).  Such
       fields should be used for diagnostic purposes only and not by
       user agents or mail gateways.

   (c) To allow transmission of diagnostic information which is specific
       to a particular message transfer agent (MTA).  The names of such
       DSN fields should begin with an indication of the MTA
       implementation which produced the DSN.  (e.g. Foomail-Queue-ID).

   MTA implementors are encouraged to provide adequate information, via
   extension fields if necessary, to allow an MTA maintainer to
   understand the nature of correctable delivery failures and how to fix
   them.  For example, if message delivery attempts are logged, the DSN
   might include information which allows the MTA maintainer to easily
   find the log entry for a failed delivery attempt.

   If an MTA developer does not wish to register the meanings of such
   extension fields, "X-" fields may be used for this purpose.  To avoid
   name collisions, the name of the MTA implementation should follow the
   "X-", (e.g.  "X-Foomail-Log-ID").

3. Conformance and Usage Requirements

   An MTA or gateway conforms to this specification if it generates DSNs
   according to the protocol defined in this memo.  For MTAs and
   gateways that do not support requests for positive delivery
   notification (such as in [4]), it is sufficient that delivery failure
   reports use this protocol.




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


   A minimal implementation of this specification need generate only the
   Reporting-MTA per-message field, and the Final-Recipient, Action, and
   Status fields for each attempt to deliver a message to a recipient
   described by the DSN.  Generation of the other fields, when
   appropriate, is strongly recommended.

   MTAs and gateways MUST NOT generate the Original-Recipient field of a
   DSN unless the mail transfer protocol provides the address originally
   specified by the sender at the time of submission. (Ordinary SMTP
   does not make that guarantee, but the SMTP extension defined in [4]
   permits such information to be carried in the envelope if it is
   available.)

   Each sender-specified recipient address SHOULD result in at most one
   "delivered" or "failed" DSN for that recipient.  If a positive DSN is
   requested (e.g. one using NOTIFY=SUCCESS in SMTP) for a recipient
   that is forwarded to multiple recipients of an "alias" (as defined in
   [4], section 7.2.7), the forwarding MTA SHOULD normally issue a
   "expanded" DSN for the originally-specified recipient and not
   propagate the request for a DSN to the forwarding addresses.
   Alternatively, the forwarding MTA MAY relay the request for a DSN to
   exactly one of the forwarding addresses and not propagate the request
   to the others.

   By contrast, successful submission of a message to a mailing list
   exploder is considered final delivery of the message.  Upon delivery
   of a message to a recipient address corresponding to a mailing list
   exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly
   as if the recipient address were that of an ordinary mailbox.

   NOTE:  This is actually intended to make DSNs usable by mailing lists
   themselves.  Any message sent to a mailing list subscriber should
   have its envelope return address pointing to the list maintainer [see
   RFC 1123, section 5.3.7(E)].  Since DSNs are sent to the envelope
   return address, all DSNs resulting from delivery to the recipients of
   a mailing list will be sent to the list maintainer.  The list
   maintainer may elect to mechanically process DSNs upon receipt, and
   thus automatically delete invalid addresses from the list.  (See
   section 7 of this memo.)

   This specification places no restrictions on the processing of DSNs
   received by user agents or distribution lists.

4. Security Considerations

   The following security considerations apply when using DSNs:





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


4.1 Forgery

   DSNs may be forged as easily as ordinary Internet electronic mail.
   User agents and automatic mail handling facilities (such as mail
   distribution list exploders) that wish to make automatic use of DSNs
   should take appropriate precautions to minimize the potential damage
   from denial-of-service attacks.

   Security threats related to forged DSNs include the sending of:

(a) A falsified delivery notification when the message is not delivered
    to the indicated recipient,
(b) A falsified non-delivery notification when the message was in fact
    delivered to the indicated recipient,
(c) A falsified Final-Recipient address,
(d) A falsified Remote-MTA identification,
(e) A falsified relay notification when the message is "dead ended".
(f) Unsolicited DSNs

4.2 Confidentiality

   Another dimension of security is confidentiality.  There may be cases
   in which a message recipient is autoforwarding messages but does not
   wish to divulge the address to which the messages are autoforwarded.
   The desire for such confidentiality will probably be heightened as
   "wireless mailboxes", such as pagers, become more widely used as
   autoforward addresses.

   MTA authors are encouraged to provide a mechanism which enables the
   end user to preserve the confidentiality of a forwarding address.
   Depending on the degree of confidentiality required, and the nature
   of the environment to which a message were being forwarded, this
   might be accomplished by one or more of:

(a) issuing a "relayed" DSN (if a positive DSN was requested) when a
    message is forwarded to a confidential forwarding address, and
    disabling requests for positive DSNs for the forwarded message,

(b) declaring the message to be delivered, issuing a "delivered" DSN,
    re-sending the message to the confidential forwarding address, and
    arranging for no DSNs to be issued for the re-sent message,

(c) omitting "Remote-*" or extension fields of a DSN whenever they would
    otherwise contain confidential information (such as a confidential
    forwarding address),

(d) for messages forwarded to a confidential address, setting the
    envelope return address (e.g. SMTP MAIL FROM address) to the NULL



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


    reverse-path ("<>") (so that no DSNs would be sent from a downstream
    MTA to the original sender),

(e) for messages forwarded to a confidential address, disabling delivery
    notifications for the forwarded message (e.g. if the "next-hop" MTA
    uses ESMTP and supports the DSN extension, by using the NOTIFY=NEVER
    parameter to the RCPT command), or

(f) when forwarding mail to a confidential address, having the
    forwarding MTA rewrite the envelope return address for the forwarded
    message and attempt delivery of that message as if the forwarding
    MTA were the originator.  On its receipt of final delivery status,
    the forwarding MTA would issue a DSN to the original sender.

   In general, any optional DSN field may be omitted if the Reporting
   MTA site determines that inclusion of the field would impose too
   great a compromise of site confidentiality.  The need for such
   confidentiality must be balanced against the utility of the omitted
   information in trouble reports and DSNs gatewayed to foreign
   environments.

   Implementors are cautioned that many existing MTAs will send
   nondelivery notifications to a return address in the message header
   (rather than to the one in the envelope), in violation of SMTP and
   other protocols.  If a message is forwarded through such an MTA, no
   reasonable action on the part of the forwarding MTA will prevent the
   downstream MTA from compromising the forwarding address.  Likewise,
   if the recipient's MTA automatically responds to messages based on a
   request in the message header (such as the nonstandard, but widely
   used, Return-Receipt-To extension header), it will also compromise
   the forwarding address.

4.3 Non-Repudiation

   Within the framework of today's internet mail, the DSNs defined in
   this memo provide valuable information to the mail user; however,
   even a "failed" DSN can not be relied upon as a guarantee that a
   message was not received by the recipient.  Even if DSNs are not
   actively forged, conditions exist under which a message can be
   delivered despite the fact that a failure DSN was issued.











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


   For example, a race condition in the SMTP protocol allows for the
   duplication of messages if the connection is dropped following a
   completed DATA command, but before a response is seen by the SMTP
   client.  This will cause the SMTP client to retransmit the message,
   even though the SMTP server has already accepted it.[9] If one of
   those delivery attempts succeeds and the other one fails, a "failed"