rfc1891.txt

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

   The "addr-type" portion MUST be an IANA-registered electronic mail
   address-type (as defined in [5]), while the "xtext" portion contains
   an encoded representation of the original recipient address using the
   rules in section 5 of this document.  The entire ORCPT parameter MAY
   be up to 500 characters in length.

   When initially submitting a message via SMTP, if the ORCPT parameter
   is used, it MUST contain the same address as the RCPT TO address
   (unlike the RCPT TO address, the ORCPT parameter will be encoded as
   xtext).  Likewise, when a mailing list submits a message via SMTP to
   be distributed to the list subscribers, if ORCPT is used, the ORCPT
   parameter MUST match the new RCPT TO address of each recipient, not
   the address specified by the original sender of the message.)

   The "addr-type" portion of the original-recipient-address is used to
   indicate the "type" of the address which appears in the ORCPT
   parameter value.  However, the address associated with the ORCPT
   keyword is NOT constrained to conform to the syntax rules for that
   "addr-type".

   Ideally, the "xtext" portion of the original-recipient-address should
   contain, in encoded form, the same sequence of characters that the
   sender used to specify the recipient.  However, for a message
   gatewayed from an environment (such as X.400) in which a recipient
   address is not a simple string of printable characters, the
   representation of recipient address must be defined by a
   specification for gatewaying between DSNs and that environment.

5.3 The RET parameter of the ESMTP MAIL command

   The RET esmtp-keyword on the extended MAIL command specifies whether
   or not the message should be included in any failed DSN issued for
   this message transmission.  If the RET esmtp-keyword is used, it MUST
   have an associated esmtp-value, which is one of the following
   keywords:

   FULL  requests that the entire message be returned in any "failed"
         delivery status notification issued for this recipient.

   HDRS  requests that only the headers of the message be returned.





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


   The FULL and HDRS keywords may be spelled in any combination of upper
   and lower case letters.

   If no RET parameter is supplied, the MTA MAY return either the
   headers of the message or the entire message for any DSN containing
   indication of failed deliveries.

   Note that the RET parameter only applies to DSNs that indicate
   delivery failure for at least one recipient.  If a DSN contains no
   indications of delivery failure, only the headers of the message
   should be returned.

5.4  The ENVID parameter to the ESMTP MAIL command

   The ENVID esmtp-keyword of the SMTP MAIL command is used to specify
   an "envelope identifier" to be transmitted along with the message and
   included in any DSNs issued for any of the recipients named in this
   SMTP transaction.  The purpose of the envelope identifier is to allow
   the sender of a message to identify the transaction for which the DSN
   was issued.

   The ABNF for the ENVID parameter is:

     envid-parameter = "ENVID=" xtext

   The ENVID esmtp-keyword MUST have an associated esmtp-value.  No
   meaning is assigned by the mail system to the presence or absence of
   this parameter or to any esmtp-value associated with this parameter;
   the information is used only by the sender or his user agent.  The
   ENVID parameter MAY be up to 100 characters in length.

5.5 Restrictions on the use of Delivery Status Notification parameters

   The RET and ENVID parameters MUST NOT appear more than once each in
   any single MAIL command.  If more than one of either of these
   parameters appears in a MAIL command, the ESMTP server SHOULD respond
   with "501 syntax error in parameters or arguments".

   The NOTIFY and ORCPT parameters MUST NOT appear more than once in any
   RCPT command.  If more than one of either of these parameters appears
   in a RCPT command, the ESMTP server SHOULD respond with "501 syntax
   error in parameters or arguments".

6. Conformance requirements

   The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer
   Agents (MTAs) when accepting, relaying, or gatewaying mail, as well
   as User Agents (UAs) when submitting mail to the mail transport



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


   system.  The DSN extension to SMTP may be used to allow UAs to convey
   the sender's requests as to when DSNs should be issued.  A UA which
   claims to conform to this specification must meet certain
   requirements as described below.

   Typically, a message transfer agent (MTA) which supports SMTP will
   assume, at different times, both the role of a SMTP client and an
   SMTP server, and may also provide local delivery, gatewaying to
   foreign environments, forwarding, and mailing list expansion.  An MTA
   which, when acting as an SMTP server, issues the DSN keyword in
   response to the EHLO command, MUST obey the rules below for a
   "conforming SMTP client" when acting as a client, and a "conforming
   SMTP server" when acting as a server.  The term "conforming MTA"
   refers to an MTA which conforms to this specification, independent of
   its role of client or server.

6.1 SMTP protocol interactions

   The following rules apply to SMTP transactions in which any of the
   ENVID, NOTIFY, RET, or ORCPT keywords are used:

(a) If an SMTP client issues a MAIL command containing a valid ENVID
    parameter and associated esmtp-value and/or a valid RET parameter
    and associated esmtp-value, a conforming SMTP server MUST return
    the same reply-code as it would to the same MAIL command without
    the ENVID and/or RET parameters.  A conforming SMTP server MUST
    NOT refuse a MAIL command based on the absence or presence of
    valid ENVID or RET parameters, or on their associated
    esmtp-values.

    However, if the associated esmtp-value is not valid (i.e. contains
    illegal characters), or if there is more than one ENVID or RET
    parameter in a particular MAIL command, the server MUST issue the
    reply-code 501 with an appropriate message (e.g.  "syntax error in
    parameter").

(b) If an SMTP client issues a RCPT command containing any valid
    NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST
    return the same response as it would to the same RCPT command
    without those NOTIFY and/or ORCPT parameters.  A conforming SMTP
    server MUST NOT refuse a RCPT command based on the presence or
    absence of any of these parameters.

    However, if any of the associated esmtp-values are not valid, or
    if there is more than one of any of these parameters in a
    particular RCPT command, the server SHOULD issue the response "501
    syntax error in parameter".




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


6.2 Handling of messages received via SMTP

   This section describes how a conforming MTA should handle any
   messages received via SMTP.

   NOTE: A DSN MUST NOT be returned to the sender for any message for
   which the return address from the SMTP MAIL command was NULL ("<>"),
   even if the sender's address is available from other sources (e.g.
   the message header).  However, the MTA which would otherwise issue a
   DSN SHOULD inform the local postmaster of delivery failures through
   some appropriate mechanism that will not itself result in the
   generation of DSNs.

   DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to
   be sent with a NULL return address ("reverse-path").  This creates an
   interesting situation when a message arrives with one or more
   nonfunctional recipient addresses in addition to a nonfunctional
   return address.  When delivery to one of the recipient addresses
   fails, the MTA will attempt to send a nondelivery notification to the
   return address, setting the return address on the notification to
   NULL.  When the delivery of this notification fails, the MTA
   attempting delivery of that notification sees a NULL return address.
   If that MTA were not to inform anyone of the situation, the original
   message would be silently lost.  Furthermore, a nonfunctional return
   address is often indicative of a configuration problem in the
   sender's MTA.  Reporting the condition to the local postmaster may
   help to speed correction of such errors.

6.2.1 Relay of messages to other conforming SMTP servers

   The following rules govern the behavior of a conforming MTA, when
   relaying a message which was received via the SMTP protocol, to an
   SMTP server that supports the Delivery Status Notification service
   extension:

(a) Any ENVID parameter included in the MAIL command when a message was
    received, MUST also appear on the MAIL command with which the
    message is relayed, with the same associated esmtp-value.  If no
    ENVID parameter was included in the MAIL command when the message
    was received, the ENVID parameter MUST NOT be supplied when the
    message is relayed.

(b) Any RET parameter included in the MAIL command when a message was
    received, MUST also appear on the MAIL command with which the
    message is relayed, with the same associated esmtp-value.  If no RET
    parameter was included in the MAIL command when the message was
    received, the RET parameter MUST NOT supplied when the message is
    relayed.



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


(c) If the NOTIFY parameter was supplied for a recipient when the
    message was received, the RCPT command issued when the message is
    relayed MUST also contain the NOTIFY parameter along with its
    associated esmtp-value.  If the NOTIFY parameter was not supplied
    for a recipient when the message was received, the NOTIFY parameter
    MUST NOT be supplied for that recipient when the message is relayed.

(d) If any ORCPT parameter was present in the RCPT command for a
    recipient when the message was received, an ORCPT parameter with the
    identical original-recipient-address MUST appear in the RCPT command
    issued for that recipient when relaying the message.  (For example,
    the MTA therefore MUST NOT change the case of any alphabetic
    characters in an ORCPT parameter.)

    If no ORCPT parameter was present in the RCPT command when the
    message was received, an ORCPT parameter MAY be added to the RCPT
    command when the message is relayed.  If an ORCPT parameter is added
    by the relaying MTA, it MUST contain the recipient address from the
    RCPT command used when the message was received by that MTA.

6.2.2  Relay of messages to non-conforming SMTP servers

   The following rules govern the behavior of a conforming MTA (in the
   role of client), when relaying a message which was received via the
   SMTP protocol, to an SMTP server that does not support the Delivery
   Status Notification service extension:

(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when
    relaying the message.

(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp-
    value containing the keyword SUCCESS, and the SMTP server returns a
    success (2xx) reply-code in response to the RCPT command, the client
    MUST issue a "relayed" DSN for that recipient.

(c) If the NOTIFY parameter was supplied for a recipient with an esmtp-
    value containing the keyword FAILURE, and the SMTP server returns a
    permanent failure (5xx) reply-code in response to the RCPT command,
    the client MUST issue a "failed" DSN for that recipient.

(d) If the NOTIFY parameter was supplied for a recipient with an esmtp-
    value of NEVER, the client MUST NOT issue a DSN for that recipient,
    regardless of the reply-code returned by the SMTP server.  However,
    if the server returned a failure (5xx) reply-code, the client MAY
    inform the local postmaster of the delivery failure via an
    appropriate mechanism that will not itself result in the generation
    of DSNs.




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


    When attempting to relay a message to an SMTP server that does not
    support this extension, and if NOTIFY=NEVER was specified for some
    recipients of that message, a conforming SMTP client MAY relay the
    message for those recipients in a separate SMTP transaction, using
    an empty reverse-path in the MAIL command.  This will prevent DSNs
    from being issued for those recipients by MTAs that conform to [1].

(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP
    server returns a success (2xx) reply-code in response to a RCPT
    command, the client MUST NOT issue any DSN for that recipient.

(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP
    server returns a permanent failure (5xx) reply-code in response to a
    RCPT command, the client MUST issue a "failed" DSN for that
    recipient.

6.2.3  Local delivery of messages

   The following rules govern the behavior of a conforming MTA upon
   successful delivery of a message that was received via the SMTP
   protocol, to a local recipient's mailbox:

   "Delivery" means that the message has been placed in the recipient's
   mailbox.  For messages which are transmitted to a mailbox for later
   retrieval via IMAP [6], POP [7] or a similar message access protocol,
   "delivery" occurs when the message is made available to the IMAP
   (POP, etc.) service, rather than when the message is retrieved by the
   recipient's user agent.

   Similarly, for a recipient address which corresponds to a mailing
   list exploder, "delivery" occurs when the message is made available
   to that list exploder, even though the list exploder might refuse to
   deliver that message to the list recipients.

(a) If the NOTIFY parameter was supplied for that recipient, with an
    esmtp-value containing the SUCCESS keyword, the MTA MUST issue a
    "delivered" DSN for that recipient.

(b) If the NOTIFY parameter was supplied for that recipient which did
    not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for
    that recipient.

(c) If the NOTIFY parameter was not supplied for that recipient, the MTA
    MUST NOT issue a DSN.







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


6.2.4  Gatewaying a message into a foreign environment

   The following rules govern the behavior of a conforming MTA, when
   gatewaying a message that was received via the SMTP protocol, into a
   foreign (non-SMTP) environment:

(a) If the the foreign environment is capable of issuing appropriate
    notifications under the conditions requested by the NOTIFY
    parameter, and the conforming MTA can ensure that any notification
    thus issued will be translated into a DSN and delivered to the
    original sender, then the MTA SHOULD gateway the message into the
    foreign environment, requesting notification under the desired
    conditions, without itself issuing a DSN.

(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the
    destination environment cannot return an appropriate notification on
    successful delivery, the MTA SHOULD issue a "relayed" DSN for that
    recipient.