doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc2852.txt b/doc/rfc/rfc2852.txt
new file mode 100644
index 0000000..5e491b6
--- /dev/null
+++ b/doc/rfc/rfc2852.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                           D. Newman
+Request for Comments: 2852                               Sun Microsystems
+Updates: 1894                                                   June 2000
+Category: Standards Track
+
+
+                   Deliver By SMTP Service Extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo defines a mechanism whereby a SMTP client can request, when
+   transmitting a message to a SMTP server, that the server deliver the
+   message within a prescribed period of time.  A client making such a
+   request also specifies the message handling which is to occur if the
+   message cannot be delivered within the specified time period: either
+   the message is to be returned as undeliverable with no further
+   processing, or a "delayed" delivery status notification (DSN) [6] is
+   to be issued.
+
+   This extension should not be viewed as a vehicle for requesting
+   "priority" processing.  A receiving SMTP server may assign whatever
+   processing priority it wishes to a message transmitted with a Deliver
+   By request.  A Deliver By request serves to express a message's
+   urgency and to provide an additional degree of determinancy in its
+   processing.  An indication of an urgent message's status within a
+   given time period may be requested and will be honored.  Moreover,
+   the message may be withdrawn if not delivered within that time
+   period.
+
+   A typical usage of this mechanism is to prevent delivery of a message
+   beyond some future time of significance to the sender or recipient
+   but not known by the MTAs handling the message.  For instance, the
+   sender may know that the message will be delivered as a page but does
+   not consider the message to be sufficiently important as to warrant
+   paging the recipient after business hours. In that case, the message
+   could be marked such that delivery attempts are not made beyond
+
+
+
+Newman                      Standards Track                     [Page 1]
+
+RFC 2852           Deliver By SMTP Service Extension           June 2000
+
+
+   17:00.  Another common usage arises when a sender wishes to be
+   alerted to delivery delays.  In this case, the sender can mark a
+   message such that if it is not delivered within, say, 30 minutes, a
+   "delayed" DSN is generated but delivery attempts are nonetheless
+   continued.  In this case the sender has been allowed to express a
+   preference for when they would like to learn of delivery problems.
+
+1.  Definitions
+
+   Throughout this document, the term "deliver" is taken to mean the act
+   of transmitting a message to its "final" destination by a message
+   transport agent (MTA).  Usually, but not always, this means storing
+   or otherwise handing off the message to the recipient's mailbox.
+   Thus, an MTA which accepts a message to be delivered within a
+   specified time period is agreeing to store or handoff the message to
+   the recipient's mailbox within the specified time period.  Outside
+   the scope of the term "deliver" are any user-specified actions which
+   might take place after the MTA stores or hands off the message; e.g.,
+   user-programmed filters which, often unbeknownst to the MTA, resend
+   the message to some other location.
+
+   The key words "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in this
+   document are to be interpreted as described in RFC 2119 [7].
+
+2.  Framework for the Deliver By SMTP service extension
+
+   The Deliver By SMTP service extension uses the SMTP service extension
+   mechanism described in [4].  The following SMTP service extension is
+   therefore defined:
+
+   (1)  The name of the SMTP service extension is "Deliver By".
+
+   (2)  The EHLO keyword value associated with this service extension is
+        "DELIVERBY".
+
+   (3)  One optional parameter is allowed with this EHLO keyword value.
+        The optional parameter, when supplied, is a comma separated list
+        of options.  Only one option, a min-by-time, is specified in
+        this document.  Future documents may extend this specification
+        by specifying additional options.  The min-by-time is a fixed
+        integer indicating the fixed minimum by-time that the server
+        will accept when a by-mode of "R" is specified as per Section 4.
+
+        The syntax of the optional parameter is as follows, using the
+        augmented BNF notation of RFC 2234 [2]:
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 2]
+
+RFC 2852           Deliver By SMTP Service Extension           June 2000
+
+
+      deliverby-param = min-by-time *( ',' extension-token )
+      min-by-time     = [1*9DIGIT]
+      extension-token = 1*<any CHAR excluding SP, COMMA and all control
+                           characters (US ASCII 0-31 inclusive)>
+      SP               = <the space character (ASCII decimal code 32)>
+      COMMA            = <the comma character (ASCII decimal code 44)>
+
+        If the parameter is omitted, no information is conveyed about
+        the server's fixed minimum by-time.
+
+   (4)  One optional parameter using the keyword "BY" is added to the
+        MAIL FROM command.
+
+   (5)  The maximum length of a MAIL FROM command line is increased by
+        17 characters by the possible addition of the BY keyword and
+        value.
+
+   (6)  No additional SMTP verbs are defined by this extension.
+
+3.  The Deliver By SMTP service extension
+
+   A SMTP client wishing to use the Deliver By SMTP service extension
+   may issue the EHLO command to start a SMTP session and to determine
+   if the SMTP server supports the service extension.  If the server
+   responds with code 250 to the EHLO command, and the response includes
+   the EHLO keyword DELIVERBY, then the Deliver By SMTP service
+   extension is supported by the server.
+
+   If a numeric parameter follows the DELIVERBY keyword value of the
+   EHLO response then that parameter indicates the minimum value allowed
+   for the by-time when a by-mode of "R" is specified with the extended
+   MAIL FROM command as described in Section 4.  Any attempt by a client
+   to specify a by-mode of "R" and a by-time strictly less than this
+   limit, min-by-time, will be rejected with a permanent failure (55z)
+   reply code.
+
+   A SMTP server that supports the Deliver By SMTP service extension
+   will accept the extended version of the MAIL FROM command described
+   in Section 4.  When supported by the server, a SMTP client may use
+   the extended MAIL FROM command (instead of the MAIL FROM command
+   described in [1]) to request that the message be delivered within the
+   specified time period.  The server may then return an appropriate
+   error code if it determines that the request cannot be honored.  Note
+   that this may not be apparent to the server until either presentation
+   of the recipient addresses with RCPT TO commands or completion of the
+   transfer of the message data with the dot (.) command.  As such, the
+
+
+
+
+
+Newman                      Standards Track                     [Page 3]
+
+RFC 2852           Deliver By SMTP Service Extension           June 2000
+
+
+   server may send to the client a success response to the MAIL FROM
+   command only to later return an error response to the RCPT TO, DATA,
+   or dot command.
+
+4.  The extended MAIL FROM command
+
+   The extended MAIL FROM command is issued by a SMTP client when it
+   wishes to inform a SMTP server that a message is to be delivered
+   within a specified period of time and further what action to take
+   should the message prove undeliverable within that time period.  The
+   extended MAIL FROM command is identical to the MAIL FROM command as
+   defined in RFC 821 [1], except that a BY parameter appears after the
+   address.
+
+   The complete syntax of this extended command is defined in [4].  The
+   esmtp-keyword is "BY" and the syntax for the esmtp-value is given by
+   the syntax for by-value shown below.  In the augmented BNF of RFC
+   2234 [2], the syntax for the BY esmtp-parameter is
+
+   by-parameter = "BY="by-value
+   by-value     = by-time";"by-mode[by-trace]
+   by-time      = ["-" / "+"]1*9digit ; a negative or zero value is not
+                                      ; allowed with a by-mode of "R"
+   by-mode      = "N" / "R"           ; "Notify" or "Return"
+   by-trace     = "T"                 ; "Trace"
+
+   Note that the BY esmtp-keyword MUST have an associated esmtp-value.
+   The by-time is a decimal representation of the number of seconds
+   within which the message should be delivered and has the range
+
+     -999,999,999 seconds <= by-time <= +999,999,999 seconds
+
+   and is thus sufficient to represent a time anywhere from
+   approximately 31.6 years in the past to 31.6 years in the future.
+
+   As described in Section 4.1, the by-mode indicates the action the
+   SMTP server must take should it not be possible to transmit the
+   message within by-time seconds.
+
+   Note that by-time is a delta time: the number of seconds within which
+   to deliver the message.  This delta time does not extend an MTA's
+   normal retention period for undeliverable messages nor is it a
+   "deliver after" time.
+
+   A delta time is used so as to prevent problems associated with
+   differences in system clocks between clients and servers.  Servers in
+   receipt of a valid by-parameter are expected to convert the by-time
+   into a locale-specific absolute time called the deliver-by-time.
+
+
+
+Newman                      Standards Track                     [Page 4]
+
+RFC 2852           Deliver By SMTP Service Extension           June 2000
+
+
+   This is done by adding the by-time upon receipt to the current
+   locale-specific time and thereby arriving at a locale-specific
+   absolute time which is by-time seconds in the future or past,
+   depending upon the arithmetic sign of by-time.  The message is then
+   to be delivered by the deliver-by-time.  The sending client and
+   receiving server should assume the transmission time of the MAIL FROM
+   command to be instantaneous.  Clearly, it will not be and network
+   latency will introduce an error, the nature of which will be to
+   extend slightly the effective by-time. The more hops the message
+   takes, the more pronounced the effect will be owing to the cumulative
+   nature of this latency-induced error.
+
+   In the case of a by-mode of "N", it is possible that by-time may be
+   zero or negative.  This is not an error and should not be rejected as
+   such.  It indicates a message for which the deliver-by-time occurred
+   -(by-time) seconds in the past.  [Here, "-(by-time)" represents the
+   arithmetic negation of the by-time value.]  Zero and negative values
+   are allowed so as to preserve information about any requested
+   delivery time information -- information which the delivering MTA may
+   wish to include with the delivered message for the benefit of the
+   recipient or to show in a DSN or NDN (non delivery notification).
+
+   In the case of a by-mode of "R", a zero or negative by-time is a
+   syntax error. In such a case, the SMTP server SHOULD return a
+   permanent failure (501) SMTP reply code in response to the extended
+   MAIL FROM command.  If the SMTP server also supports enhanced error
+   codes [8], then an enhanced error code of 5.5.4 SHOULD also be
+   returned.
+
+   If the by-time is a valid by-time specification but the SMTP server
+   cannot honor or accept it for a server-specific reason, then SMTP
+   server SHOULD respond with either a 455 SMTP response if the
+   condition is transient or a 555 SMTP response if the condition is
+   permanent. In addition, if the SMTP server also supports [8], a
+   suitable 4.X.X or 5.X.X enhanced error code SHOULD also be returned.
+
+4.1.  Server behavior upon receipt of the extended MAIL FROM command
+
+   Upon receipt of an extended MAIL FROM command containing a valid BY
+   parameter, a SMTP server and associated MTA must handle the message
+   in accord with the following subsections, Sections 4.1.1-4.1.5.
+   Delivery status notifications generated in response to processing a
+   message with a Deliver By request should include both the optional
+   Arrival-Date DSN field as well as the new Deliver-By-Date DSN field
+   described in Section 5 of this memo.
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 5]
+
+RFC 2852           Deliver By SMTP Service Extension           June 2000
+
+
+   A by-time Note that a message's by-time does not extend the MTA's
+   normal message retention period: an MTA MAY return a message as
+   undeliverable before the deliver-by-time has been reached.
+
+4.1.1.  Successful delivery
+
+   If the message is delivered before deliver-by-time, no special action
+   need be taken.  If the SMTP server or MTA also supports the Delivery
+   Status Notification SMTP service extension [5] and a NOTIFY parameter
+   including "SUCCESS" was specified, a "delivered" DSN with appropriate
+   status must be returned as per [5].
+
+4.1.2.  Unsuccessful delivery; deliver-by-time not yet reached
+
+   If deliver-by-time has not yet passed and the message has proved
+   undeliverable for temporary reasons, then the SMTP server or MTA
+   should continue delivery or relay attempts as per the site's message
+   handling policy.  If the MTA's message retention period is less than
+   by-time, the MTA MAY return the message as undeliverable before
+   deliver-by-time has been reached.  However, the message MUST still be
+   handled in accord with Sections 4.1.1-4.1.5.
+
+   If deliver-by-time has not yet passed and the message cannot be
+   delivered for permanent reasons, then the SMTP server or MTA MUST
+   return a "failed" DSN with an appropriate status for each recipient
+   address with either no NOTIFY parameter specified or for which the
+   NOTIFY parameter includes "FAILURE".
+
+4.1.3.  Time has expired; deliver-by-time reached or passed
+
+   If the message is not delivered or relayed before deliver-by-time and
+   a by-mode of "R" was specified, no further delivery attempts may be
+   made for the message.  The server or MTA MUST issue a "failed" DSN
+   with status 5.4.7, "delivery time expired", for each recipient
+   address with either no NOTIFY parameter specified or for which the
+   NOTIFY parameter includes "FAILURE".
+
+   If the message is not delivered or relayed before deliver-by-time and
+   a by-mode of "N" was specified, the server or MTA should continue
+   attempts to deliver or relay the message using the site's message
+   handling policy.  In addition, the server or MTA MUST issue a
+   "delayed" DSN with status 4.4.7, "delivery time expired", for each
+   recipient address with either no NOTIFY parameter specified or for
+   which the NOTIFY parameter includes "DELAY".
+
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 6]
+
+RFC 2852           Deliver By SMTP Service Extension           June 2000
+
+
+4.1.4.  Relaying to another SMTP server
+
+   Sections 4.1.4.1 and 4.1.4.2 below describe when a message with a
+   Deliver By request may be relayed to another SMTP server and what
+   additional actions, if any, should or must be taken.  In addition to
+   that discussed in those sections, the following must also be observed
+   when relaying is permitted.
+
+   If the message is relayed to a SMTP server that supports the Deliver
+   By extension, a new BY parameter MUST be relayed specifying a by-time
+   value indicating the number of seconds remaining until deliver-by-
+   time.  The new by-time value should be computed as close to the time
+   the MAIL FROM command is transmitted by the relaying SMTP client as
+   is reasonably possible. Note that if deliver-by-time has passed, the
+   relayed by-time will be a negative value indicating how may seconds
+   has elapsed since delivery-by-time.  Such a case -- relay of a
+   message for which deliver-by-time has just arrived or passed -- may
+   only happen with a message that has a by-mode of "N".
+
+   When a message with a by-trace field with value "T" is relayed, a
+   "relayed" DSN SHOULD be generated by the relaying SMTP client for
+   each recipient which either did not specify a NOTIFY parameter or the
+   NOTIFY parameter does not have the value "NEVER".
+
+   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 <eljefe@bigbiz.com> be delivered to
+   <topbanana@other.com> 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:<eljefe@bigbiz.com> BY=120;R
+     S: 250 <eljefe@bigbiz.com> sender ok
+     C: RCPT TO:<topbanana@other.com>
+     S: 250 <topbanana@wherever.com> 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:<eljefe@bigbiz.com> BY=98;R
+     S: 250 <eljefe@bigbiz.com> Sender okay
+     C: RCPT TO:<topbanana@other.com>
+     S: 250 <topbanana@wherever.com> 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: +1 626 919 3600
+   Fax:   +1 626 919 3614
+   EMail:  dan.newman@sun.com
+
+
+
+
+
+
+
+
+
+
+
+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]
+