rfc2852.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 732 行 · 第 1/2 页

   Note that these "relayed" DSNs are generated regardless of whether
   success notifications were explicitly requested with a NOTIFY=SUCCESS
   parameter.  Note further that the "relayed" DSNs discussed here are
   not terminal notifications:  downstream SMTP servers and MTAs may
   still support [5] and as such additional notifications may still
   result.

4.1.4.1.  Relaying a message with a by-mode of "R"

   A message for which a by-mode of "R" was specified MUST NOT be
   relayed to a SMTP server which does not support the Deliver By SMTP
   service extension.  Moreover, the server to which it is relayed MUST
   NOT have a fixed minimum by-time which is greater than the time
   remaining in which the message is to be delivered.  The fixed minimum
   by-time is expressed by the optional deliverby-param discussed in
   Section 2.

   If the message requires relaying in order to be delivered yet cannot
   be relayed, then the message is deemed to be undeliverable for
   permanent reasons and Section 4.1.2 should be applied.







Newman                      Standards Track                     [Page 7]

RFC 2852           Deliver By SMTP Service Extension           June 2000


4.1.4.2.  Relaying a message with a by-mode of "N"

   A message with a by-mode of "N" may be relayed to another server
   regardless of whether or not the SMTP server to which it is relayed
   supports the Deliver By extension.

   If the message is relayed before deliver-by-time to a SMTP server
   that does not support the Deliver By extension, then the relaying
   SMTP client MUST issue a "relayed" DSN for each recipient which
   either did not specify a NOTIFY parameter or the NOTIFY parameter
   does not have the value "NEVER". Further, if the SMTP server being
   relayed to supports the Delivery Status Notification SMTP service
   extension [5] then for each recipient: if no NOTIFY parameter was
   supplied, "NOTIFY=FAILURE,DELAY" SHOULD be requested; if a NOTIFY
   parameter was specified and does not have the value "NEVER", "DELAY"
   SHOULD be added to the list of notify-list-element values if not
   already present.  Note that this explicitly overrides the "MUST NOT"
   wording of Section 6.2.1(c) of [5].

4.1.5.  Relaying to a foreign mail system

   If the foreign mail system supports semantics similar to the Deliver
   By SMTP service extension described in this memo, then convey the
   Deliver By request to that system.  Otherwise, relay the message as
   if relaying to a SMTP server which does not support the Deliver By
   extension.

5.  Delivery status notifications and extension

   The format of delivery status notifications (DSNs) is specified in
   [6].  DSNs generated in response to a Deliver By request should
   include an Arrival-Date DSN field.  This memo also extends the per-
   message-fields of [6] to include a new DSN field, Deliver-By-Date,
   indicating the deliver-by-time as computed by the MTA or SMTP server
   generating the DSN.  In the augmented BNF of RFC 822 [2], per-
   message-fields is therefore extended as follows:

     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 ]
         [ deliver-by-date-field CRLF ]
         *( extension-field CRLF )
     deliver-by-date-field = "Deliver-by-date" ":" date-time





Newman                      Standards Track                     [Page 8]

RFC 2852           Deliver By SMTP Service Extension           June 2000


   where date-time is a RFC 822 [2] date-time field as ammended by RFC
   1123 [3].

6.  Examples

   In the following sample SMTP dialog, the SMTP client requests that a
   message from <[e-mail]> be delivered to
   <[e-mail]> within 2 minutes (120 seconds) and returned
   otherwise.  This request takes the form of a BY parameter on the MAIL
   FROM line of "BY=120;R" as shown below:

     S: 220 acme.net SMTP server here
     C: EHLO bigbiz.com
     S: 250-acme.net
     S: 250 DELIVERBY
     C: MAIL FROM:<[e-mail]> BY=120;R
     S: 250 <[e-mail]> sender ok
     C: RCPT TO:<[e-mail]>
     S: 250 <[e-mail]> recipient ok

   Suppose now that the receiving SMTP server in the above example needs
   to relay the message to another SMTP server, mail.other.com.  Owing
   to the original by-mode of "R", the message may only be relayed to
   another SMTP server which supports the Deliver By extension (Section
   4.1.4).  Further, when relaying the message, the Deliver By request
   must be relayed.  With this in mind, consider the following SMTP
   dialog:

     S: 220 mail.other.com ESMTP server at your service
     C: EHLO acme.net
     S: 250-mail.other.com
     S: 250 DELIVERBY 240
     C: QUIT

   In the above dialog, the relaying SMTP server, acme.net, connects to
   mail.other.com and issues an EHLO command.  It then learns that the
   Deliver By extension is supported but that the minimum by-time for a
   by-mode of "R" is 4 minutes (240 seconds).  This value exceeds the
   message's original by-time and therefore necessarily exceeds the
   remaining by-time.  The relaying SMTP server thus ends the SMTP
   session after which it must either attempt to follow any other MX
   records or, if there are no more MX records to follow, must return
   the message as undeliverable.  Similar behavior would result if the
   EHLO command was met with an error or did not include the DELIVERBY
   keyword.

   Consider instead, the relaying SMTP session:




Newman                      Standards Track                     [Page 9]

RFC 2852           Deliver By SMTP Service Extension           June 2000


     S: 220 mail.other.com ESMTP server at your service
     C: EHLO acme.net
     S: 250-mail.other.com
     S: 250 DELIVERBY 30
     C: MAIL FROM:<[e-mail]> BY=98;R
     S: 250 <[e-mail]> Sender okay
     C: RCPT TO:<[e-mail]>
     S: 250 <[e-mail]> Recipient okay

   In the above, the relaying SMTP client relays the BY parameter with
   the by-mode preserved and the by-time computed to be the remaining
   number of seconds at the approximate time that the MAIL FROM command
   was transmitted from the relaying SMTP client (acme.net) to the
   receiving SMTP server (mail.other.com).  In this example, 22 seconds
   have elapsed since acme.net received the MAIL FROM line from the
   original sending client and relayed the Deliver By request to
   mail.other.com.

7.  MX based relaying considerations

   Sites which wish to use the Deliver By SMTP service extension and
   which direct their mail via MX records [9] need to ensure that all of
   their MX hosts -- hosts to which their mail is directed by MX records
   -- support the Deliver By extension. SMTP clients which support
   Deliver By SHOULD NOT attempt multiple MX hosts looking for one which
   supports Deliver By.

   MX hosts should pay careful attention to the min-by-time value they
   present in response to EHLO commands.  It is not practical for an MX
   host to present a value which either (1) is substantially different
   from that which can be handled by the destination host to which it
   relays, or (2) doesn't recognize normal delivery latencies introduced
   when the MX host relays mail to the destination host.

8.  Security Considerations

   Implemention of Deliver By allows tracing of a mail transport system.
   The by-trace field "T" explicitly requests that a trace be generated.
   Moreover, even when the by-trace field is not used, a crude trace may
   be generated by entering a series of messages into the transport
   system, each with successively increasing by-time values; e.g.,
   "BY=0;R", "BY=1;R", "BY=2;R". Probing, and in some cases tracing, can
   be accomplished through other means: querying the visible SMTP
   servers, investigating Received: header lines in bounced messages,
   and using utilities such as "traceroute".






Newman                      Standards Track                    [Page 10]

RFC 2852           Deliver By SMTP Service Extension           June 2000


9.  Other Considerations

   SMTP servers which support the Deliver By SMTP service extension as
   well as their associated MTAs are not required to assign any special
   processing priority to messages with Deliver By requests.  Of course,
   some SMTP servers and MTAs may do so if they desire.  Moreover,
   delivery status notifications generated in response to messages with
   Deliver By requests are not required to receive any special
   processing.  Consequently, users of this service should not, in
   general, expect expedited processing of their messages.  Moreover,
   just because a message is sent with a "BY=60;R" parameter does not
   guarantee that the sender will learn of a delivery failure within any
   specified time period as the DSN will not necessarily be expedited
   back to sender.

10.  Acknowledgments

   The author wishes to thank Keith Moore for providing much of the
   initial impetus for this document as well as the basic ideas embodied
   within it.  Further thanks are due to Ned Freed and Chris Newman for
   their reviews of this document and suggestions for improvement.






























Newman                      Standards Track                    [Page 11]

RFC 2852           Deliver By SMTP Service Extension           June 2000


11.  References

   [1]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
        August 1982.

   [2]  Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [3]  Braden, R., Editor, "Requirements for Internet Hosts --
        Application and Support", STD 3, RFC 1123, October 1989.

   [4]  Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed,
        "SMTP Service Extensions", STD 10, RFC 1869, November 1995.

   [5]  Moore, K., "SMTP Service Extension for Delivery Status
        Notifications", RFC 1891, January 1996.

   [6]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
        Delivery Status Notifications", RFC 1894, January 1996.

   [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [8]  Freed, N., "SMTP Service Extension for Returning Enhanced Error
        Codes", RFC 2034, October 1996.

   [9]  Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
        974, January 1986.

12.  Author's Address

   Dan Newman
   Sun Microsystems, Inc.
   1050 Lakes Drive, Suite 250
   West Covina, CA  91790
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail:  [e-mail]











Newman                      Standards Track                    [Page 12]

RFC 2852           Deliver By SMTP Service Extension           June 2000


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Newman                      Standards Track                    [Page 13]