From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2852.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc2852.txt (limited to 'doc/rfc/rfc2852.txt') 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* + SP = + COMMA = + + 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 be delivered to + 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: BY=120;R + S: 250 sender ok + C: RCPT TO: + S: 250 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: BY=98;R + S: 250 Sender okay + C: RCPT TO: + S: 250 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] + -- cgit v1.2.3