rfc1891.txt

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

(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a
    DSN MUST NOT be issued.  If possible, the MTA SHOULD direct the
    destination environment to not issue delivery notifications for that
    recipient.

(d) If the NOTIFY parameter was not supplied for a particular recipient,
    a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD
    attempt to ensure that appropriate notification will be provided by
    the foreign mail environment if eventual delivery failure occurs,
    and that no notification will be issued on successful delivery.

(e) When gatewaying a message into a foreign environment, the return-of-
    content conditions specified by any RET parameter are nonbinding;
    however, the MTA SHOULD attempt to honor the request using whatever
    mechanisms exist in the foreign environment.

6.2.5  Delays in delivery

   If a conforming MTA receives a message via the SMTP protocol, and is
   unable to deliver or relay the message to one or more recipients for
   an extended length of time (to be determined by the MTA), it MAY
   issue a "delayed" DSN for those recipients, subject to the following
   conditions:

(a) If the NOTIFY parameter was supplied for a recipient and its value
    included the DELAY keyword, a "delayed" DSN MAY be issued.

(b) If the NOTIFY parameter was not supplied for a recipient, a
    "delayed" DSN MAY be issued.



Moore                       Standards Track                    [Page 13]

RFC 1891           SMTP Delivery Status Notifications       January 1996


(c) If the NOTIFY parameter was supplied which did not contain the DELAY
    keyword, a "delayed" DSN MUST NOT be issued.

   NOTE: Although delay notifications are common in present-day
   electronic mail, a conforming MTA is never required to issue
   "delayed" DSNs.  The DELAY keyword of the NOTIFY parameter is
   provided to allow the SMTP client to specifically request (by
   omitting the DELAY parameter) that "delayed" DSNs NOT be issued.

6.2.6  Failure of a conforming MTA to deliver a message

   The following rules govern the behavior of a conforming MTA which
   received a message via the SMTP protocol, and is unable to deliver a
   message to a recipient specified in the SMTP transaction:

(a) If a NOTIFY parameter was supplied for the recipient with an esmtp-
    keyword containing the value FAILURE, a "failed" DSN MUST be issued
    by the MTA.

(b) If a NOTIFY parameter was supplied for the recipient which did not
    contain the value FAILURE, a DSN MUST NOT be issued for that
    recipient.  However, the MTA MAY inform the local postmaster of the
    delivery failure via some appropriate mechanism which does not
    itself result in the generation of DSNs.

(c) If no NOTIFY parameter was supplied for the recipient, a "failed"
    DSN MUST be issued.

   NOTE: Some MTAs are known to forward undeliverable messages to the
   local postmaster or "dead letter" mailbox.  This is still considered
   delivery failure, and does not diminish the requirement to issue a
   "failed" DSN under the conditions defined elsewhere in this memo.  If
   a DSN is issued for such a recipient, the Action value MUST be
   "failed".

6.2.7 Forwarding, aliases, and mailing lists

   Delivery of a message to a local email address usually causes the
   message to be stored in the recipient's mailbox.  However, MTAs
   commonly provide a facility where a local email address can be
   designated as an "alias" or "mailing list"; delivery to that address
   then causes the message to be forwarded to each of the (local or
   remote) recipient addresses associated with the alias or list.  It is
   also common to allow a user to optionally "forward" her mail to one
   or more alternate addresses.  If this feature is enabled, her mail is
   redistributed to those addresses instead of being deposited in her
   mailbox.




Moore                       Standards Track                    [Page 14]

RFC 1891           SMTP Delivery Status Notifications       January 1996


   Following the example of [9] (section 5.3.6), this document defines
   the difference between an "alias" and "mailing list" as follows: When
   forwarding a message to the addresses associated with an "alias", the
   envelope return address (e.g. SMTP MAIL FROM) remains intact.
   However, when forwarding a message to the addresses associated with a
   "mailing list", the envelope return address is changed to that of the
   administrator of the mailing list.  This causes DSNs and other
   nondelivery reports resulting from delivery to the list members to be
   sent to the list administrator rather than the sender of the original
   message.

   The DSN processing for aliases and mailing lists is as follows:

6.2.7.1 mailing lists

   When a message is delivered to a list submission address (i.e. placed
   in the list's mailbox for incoming mail, or accepted by the process
   that redistributes the message to the list subscribers), this is
   considered final delivery for the original message.  If the NOTIFY
   parameter for the list submission address contained the SUCCESS
   keyword, a "delivered" DSN MUST be returned to the sender of the
   original message.

   NOTE: Some mailing lists are able to reject message submissions,
   based on the content of the message, the sender's address, or some
   other criteria.  While the interface between such a mailing list and
   its MTA is not well-defined, it is important that DSNs NOT be issued
   by both the MTA (to report successful delivery to the list), and the
   list (to report message rejection using a "failure" DSN.)

   However, even if a "delivered" DSN was issued by the MTA, a mailing
   list which rejects a message submission MAY notify the sender that
   the message was rejected using an ordinary message instead of a DSN.

   Whenever a message is redistributed to an mailing list,

(a) The envelope return address is rewritten to point to the list
    maintainer.  This address MAY be that of a process that recognizes
    DSNs and processes them automatically, but it MUST forward
    unrecognized messages to the human responsible for the list.

(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the
    redistributed message MUST NOT be derived from those of the original
    message.

(c) The NOTIFY and RET parameters MAY be specified by the local
    postmaster or the list administrator.  If ORCPT parameters are
    supplied during redistribution to the list subscribers, they SHOULD



Moore                       Standards Track                    [Page 15]

RFC 1891           SMTP Delivery Status Notifications       January 1996


    contain the addresses of the list subscribers in the format used by
    the mailing list.

6.2.7.2 single-recipient aliases

   Under normal circumstances, when a message arrives for an "alias"
   which has a single forwarding address, a DSN SHOULD NOT be issued.
   Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with
   the message as it is redistributed to the forwarding address.

6.2.7.3 multiple-recipient aliases

   An "alias" with multiple recipient addresses may be handled in any of
   the following ways:

(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when
    relaying the message to any of the forwarding addresses.  If the
    NOTIFY parameter for the alias contained the SUCCESS keyword, the
    MTA issues a "relayed" DSN.  (In effect, the MTA treats the message
    as if it were being relayed into an environment that does not
    support DSNs.)

(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent
    requests if the message is gatewayed) are propagated to EXACTLY one
    of the forwarding addresses.  No DSN is issued.  (This is
    appropriate when aliasing is used to forward a message to a
    "vacation" auto-responder program in addition to the local mailbox.)

(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding
    addresses associated with that alias.  The NOTIFY parameter is
    propagated to the forwarding addresses, except that it any SUCCESS
    keyword is removed.  If the original NOTIFY parameter for the alias
    contained the SUCCESS keyword, an "expanded" DSN is issued for the
    alias.  If the NOTIFY parameter for the alias did not contain the
    SUCCESS keyword, no DSN is issued for the alias.

6.2.7.4 confidential forwarding addresses

   If it is desired to maintain the confidentiality of a recipient's
   forwarding address, the forwarding may be treated as if it were a
   mailing list.  A DSN will be issued, if appropriate, upon "delivery"
   to the recipient address specified by the sender.  When the message
   is forwarded it will have a new envelope return address. Any DSNs
   which result from delivery failure of the forwarded message will not
   be returned to the original sender of the message and thus not expose
   the recipient's forwarding address.





Moore                       Standards Track                    [Page 16]

RFC 1891           SMTP Delivery Status Notifications       January 1996


6.2.8 DSNs describing delivery to multiple recipients

   A single DSN may describe attempts to deliver a message to multiple
   recipients of that message.  If a DSN is issued for some recipients
   in an SMTP transaction and not for others according to the rules
   above, the DSN SHOULD NOT contain information for recipients for whom
   DSNs would not otherwise have been issued.

6.3 Handling of messages from other sources

   For messages which originated from "local" users (whatever that
   means), the specifications under which DSNs should be generated can
   be communicated to the MTA via any protocol agreed on between the
   sender's mail composer (user agent) and the MTA.  The local MTA can
   then either relay the message, or issue appropriate delivery status
   notifications.  However, if such requests are transmitted within the
   message itself (for example in the message headers), the requests
   MUST be removed from the message before it is transmitted via SMTP.

   For messages gatewayed from non-SMTP sources and further relayed by
   SMTP, the gateway SHOULD, using the SMTP extensions described here,
   attempt to provide the delivery reporting conditions expected by the
   source mail environment.  If appropriate, any DSNs returned to the
   source environment SHOULD be translated into the format expected in
   that environment.

6.4  Implementation limits

   A conforming MTA MUST accept ESMTP parameters of at least the
   following sizes:

   (a) ENVID parameter: 100 characters.

   (b) NOTIFY parameter: 28 characters.

   (c) ORCPT parameter: 500 characters.

   (d) RET parameter: 8 characters.

   The maximum sizes for the ENVID and ORCPT parameters are intended to
   be adequate for the transmission of "foreign" envelope identifier and
   original recipient addresses.  However, user agents which use SMTP as
   a message submission protocol SHOULD NOT generate ENVID parameters
   which are longer than 38 characters in length.

   A conforming MTA MUST be able to accept SMTP command-lines which are
   at least 1036 characters long (530 characters for the ORCPT and
   NOTIFY parameters of the RCPT command, in addition to the 512



Moore                       Standards Track                    [Page 17]

RFC 1891           SMTP Delivery Status Notifications       January 1996


   characters required by [1]).  If other SMTP extensions are supported
   by the MTA, the MTA MUST be able to accept a command-line large
   enough for each SMTP command and any combination of ESMTP parameters
   which may be used with that command.

7.  Format of delivery notifications

   The format of delivery status notifications is defined in [5], which
   uses the framework defined in [8].  Delivery status notifications are
   to be returned to the sender of the original message as outlined
   below.

7.1 SMTP Envelope to be used with delivery status notifications

   The DSN sender address (in the SMTP MAIL command) MUST be a null
   reverse-path ("<>"), as required by section 5.3.3 of [9].  The DSN
   recipient address (in the RCPT command) is copied from the MAIL
   command which accompanied the message for which the DSN is being
   issued.  When transmitting a DSN via SMTP, the RET parameter MUST NOT
   be used.  The NOTIFY parameter MAY be used, but its value MUST be
   NEVER.  The ENVID parameter (with a newly generated envelope-id)
   and/or ORCPT parameter MAY be used.

7.2 Contents of the DSN

   A DSN is transmitted as a MIME message with a top-level content-type
   of multipart/report (as defined in [5]).

   The multipart/report content-type may be used for any of several
   kinds of reports generated by the mail system.  When multipart/report
   is used to convey a DSN, the report-type parameter of the
   multipart/report content-type is "delivery-status".

   As described in [8], the first component of a multipart/report
   content-type is a human readable explanation of the report.  For a
   DSN, the second component of the multipart/report is of content-type
   message/delivery-status (defined in [5]).  The third component of the
   multipart/report consists of the original message or some portion
   thereof.  When the value of the RET parameter is FULL, the full
   message SHOULD be returned for any DSN which conveys notification of
   delivery failure.  (However, if the length of the message is greater
   than some implementation-specified length, the MTA MAY return only
   the headers even if the RET parameter specified FULL.)  If a DSN
   contains no notifications of delivery failure, the MTA SHOULD return
   only the headers.

   The third component must have an appropriate content-type label.
   Issues concerning selection of the content-type are discussed in [8].



Moore                       Standards Track                    [Page 18]

RFC 1891           SMTP Delivery Status Notifications       January 1996


7.3 Message/delivery-status fields

   The message/delivery-status content-type defines a number of fields,
   with general specifications for their contents.  The following
   requirements for any DSNs generated in response to a message received
   by the SMTP protocol by a conforming SMTP server, are in addition to
   the requirements defined in [5] for the message/delivery-status type.

   When generating a DSN for a message which was received via the SMTP
   protocol, a conforming MTA will generate the following fields of the
   message/delivery-status body part:

(a) if an ENVID parameter was present on the MAIL command, an Original-
    Envelope-ID field MUST be supplied, and the value associated with
    the ENVID parameter must appear in that field.  If the message was
    received via SMTP with no ENVID parameter, the Original-Envelope-ID
    field MUST NOT be supplied.

    Since the ENVID parameter is encoded as xtext, but the Original-
    Envelope-ID header is NOT encoded as xtext, the MTA must decode the
    xtext encoding when copying the ENVID value to the Original-
    Envelope-ID field.

(b) The Reporting-MTA field MUST be supplied.  If Reporting MTA can
    determine its fully-qualified Internet domain name, the MTA-name-
    type subfield MUST be "dns", and the field MUST contain the fully-
    qualified domain name of the Reporting MTA. If the fully-qualified
    Internet domain name of the Reporting MTA is not known (for example,
    for an SMTP server which is not directly connected to the Internet),
    the Reporting-MTA field may contain any string identifying the MTA,