INTERNET-DRAFT G. White draft-vaudreuil-futuredelivery-02.txt Comnet Messaging Updates: RFC 3464 G. Vaudreuil Expires: August 2004 Lucent Technologies February 2004 SMTP Submission Service Extension for Future Delivery Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines an extension to the SMTP submission protocol for client indication of a future-delivery time. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. White & Vaudreuil Expires August 2004 [Page 1]
INTERNET-DRAFT SMTP Future Delivery February 2004 Table of Contents 1. Introduction .................................................. 3 2. Framework ..................................................... 3 3. Mechanism ..................................................... 4 3.1 Behavior .................................................. 5 3.2 Interaction with the AUTH SMTP service extension .......... 6 3.3 Interaction with the DSN SMTP service extension ........... 6 3.4 Interaction with the DELIVERBY SMTP service extension ..... 7 4. Security Considerations ....................................... 7 5. Acknowledgments ............................................... 8 6. References .................................................... 9 7. Copyright Notice .............................................. 10 8. Authors' Addresses ............................................ 10 9. Change Log .................................................... 10 White & Vaudreuil Expires August 2004 [Page 2]
INTERNET-DRAFT SMTP Future Delivery February 2004 1. Introduction There is a widely-used feature within the voice messaging community to compose and send a message for delivery in the future. This is useful for sending announcements to be heard at the beginning of a work day, to send birthday greetings a day or so ahead, or to use as a lightweight facility to build a personal reminder service. This extension uses the SMTP submission protocol [3] to allow an authenticated client to submit, to a Message Submission Agent (MSA), a message for future delivery. 2. Framework The Future Delivery service extension for SMTP submission uses the SMTP service extension mechanism [5] to extend the SMTP submission protocol [3]. The following SMTP submission service extension is hereby defined: The name of the SMTP submission service extension is "Future Delivery". 1) The EHLO keyword value associated with this service extension is "FUTUREDELIVERY". 2) One optional parameter, the max-future-delivery-interval, is allowed with this EHLO keyword value. This value is a fixed, non-negative integer indicating the maximum amount of time (in seconds) for which the MSA will accept & hold messages for future delivery. If this value is zero, there is no MSA-imposed limit to the maximum future delivery interval. If the parameter is omitted, no information is conveyed about the maximum future delivery interval. Using Augmented BNF [2], the syntax of this parameter is as follows: futuredelivery-param = max-future-delivery-interval max-future-delivery-interval = [1*9DIGIT] 3) One required parameter, the future-delivery-interval, is added to the MAIL command using the keyword "AFTER". This value is a fixed, positive integer indicating the amount of time (in seconds) the message is to be held by the MSA before relay. future-delivery-interval-param = "AFTER="[1*9DIGIT] The absence of this parameter on the MAIL command does not imply a default value for this parameter. White & Vaudreuil Expires August 2004 [Page 3]
INTERNET-DRAFT SMTP Future Delivery February 2004 4) The maximum length of a MAIL command is increased by 16 characters by the possible addition of the AFTER keyword and value. 5) No additional SMTP verbs are defined by this extension. 6) The FUTUREDELIVERY service extension can only be used in conjunction with the AUTH service extension [4]. 7) This service extension is appropriate only for the SMTP submission protocol [3]. This service extension is not appropriate for standard SMTP [5]. 3. Mechanism An MSA that supports Future Delivery also supports the Authorization service extension [4]. An MSA that advertises support for Future Delivery also advertises support for Authorization in the same EHLO reply. An MSA that advertises support for Future Delivery without advertising support for Authorization is error, and SMTP clients will not use Future Delivery on this MSA. An SMTP client wishing to use Future Delivery issues the EHLO command to start an SMTP session and determine if the MSA supports Future Delivery and Authorization. If the MSA responds with reply code 250 to the EHLO command, and the response includes the EHLO keywords FUTUREDELIVERY and AUTH, then Future Delivery is supported by the MSA. If a numeric value follows the FUTUREDELIVERY keyword, this value indicates the maximum amount of time (in seconds) the MSA is willing to hold a message for future delivery. Messages submitted with a future-delivery-interval greater than this value are rejected by the MSA. If the MSA supports Future Delivery and Authorization, the SMTP client then issues the AUTH command. If this command is rejected by the MSA, then the client is not allowed to issue a MAIL command containing a future-delivery-interval parameter. Only after the MSA accepts an AUTH command is the client allowed to issue a MAIL command containing a future-delivery-interval parameter. The SMTP client then issues a MAIL command containing a future- delivery-interval parameter and an authorization parameter. If the authorization parameter is invalid, the MSA rejects the MAIL command. If the value of the future-delivery-interval parameter is greater that the MSA's advertised max-future-delivery-interval, or is otherwise invalid, the MSA rejects the MAIL command. If both parameters are valid, and there are no other errors on the MAIL command, the MSA accepts that command. The future-delivery-interval parameter is stated as a time interval to prevent problems associated with differences in system clocks White & Vaudreuil Expires August 2004 [Page 4]
INTERNET-DRAFT SMTP Future Delivery February 2004 between SMTP clients and MSAs. MSAs in receipt of a valid future- delivery-interval parameter are expected to convert the parameter into a locale-specific absolute time called the future-delivery-time. This is done by adding the future-delivery-interval to the locale- specific message receipt time. The MSA is expected to assume that the transmission time of the MAIL command is instantaneous. If the MSA accepts a message with a future-delivery request, then the MSA delivers/relays the message after the MSA's system clock passes the future-delivery time. 3.1 Behavior 3.1.1 SMTP client behavior 1) An SMTP client wishing to use Future Delivery MUST include a future-delivery-interval parameter with the MAIL command. 2) An SMTP client MUST NOT send a MAIL command containing a future- delivery-interval parameter whose value is strictly larger than the value of the max-future-delivery-interval parameter advertised in the MSA's reply to the EHLO command. 3.1.2 MSA behavior 1) An MSA that supports Future Delivery MUST comply with the SMTP submission protocol as described in [3]. 2) An MSA that supports Future Delivery MUST comply with the SMTP service extension mechanism as described in [5]. 3) An MSA that supports Future Delivery MUST advertise support for same by including the FUTUREDELIVERY keyword in its reply to the EHLO command. 4) An MSA that supports Future Delivery and wishes to enforce a maximum amount of time that a message will be held for future delivery MUST advertise that amount of time by including a max- future-delivery-interval parameter with the FUTUREDELIVERY keyword in the reply to the EHLO command. 5) An MSA that supports Future Delivery MUST accept a MAIL command containing a valid future-delivery-interval (given that the MAIL command contains no other errors). 6) An MSA that supports Future Delivery MUST reject a MAIL command containing a future-delivery-interval parameter whose value is strictly greater than the value of the advertised max-future- delivery-interval parameter. 7) An MSA that accepts a message with a request for Future Delivery MUST NOT attempt to deliver or relay the message until the amount White & Vaudreuil Expires August 2004 [Page 5]
INTERNET-DRAFT SMTP Future Delivery February 2004 of time specified in the future-delivery-interval parameter elapses. 3.2 Interaction with the AUTH SMTP service extension The Authentication service extension is described in [4]. 3.2.1 SMTP client interaction with AUTH 1) An SMTP client wishing to use Future Delivery MUST use this extension only when the MSA advertises support for both Authentication AND Future Delivery in the same reply to an EHLO command. 2) An SMTP client wishing to use Future Delivery MUST first become authenticated via the AUTH command mechanism described in [4]. 3) An SMTP client wishing to use Future Delivery MUST issue a MAIL command that includes a valid authorization parameter along with the aforementioned future-delivery-interval parameter. 3.2.2 MSA Interaction with AUTH 1) An MSA that supports Future Delivery MUST also support Authentication. 2) An MSA that advertises support for Future Delivery in the reply to an EHLO command MUST also advertise support for Authentication in the same reply. 3) When an MSA receives a MAIL command containing a future-delivery- interval parameter, and the MSA has not yet authenticated the client via the AUTH command mechanism described in [4], then the MSA MUST reject the MAIL command for security reasons as described in [5]. 4) When an MSA receives a MAIL command containing an invalid authorization parameter, the MSA MUST reject the command for security reasons as described in [5]. The validity or invalidity of the associated future-delivery-interval parameter is immaterial in this case. 3.3 Interaction with the DSN SMTP service extension The Delivery Status Notification (DSN) service extension is described in [8], and DSN message format is described in [10]. 3.3.1 SMTP client interaction with DSN 1) An SMTP client MUST NOT request Future Delivery when sending a DSN to the MSA. White & Vaudreuil Expires August 2004 [Page 6]
INTERNET-DRAFT SMTP Future Delivery February 2004 3.3.2 MSA interaction with DSN 1) When an MSA generates a DSN for a message that includes a future delivery request, the MSA MUST include an Arrival-Date: field in the machine-readable body part of the DSN. 2) When an MSA generates a DSN for a message that includes a future delivery request, the MSA MUST include a Future-Delivery-Date: field in the machine-readable body part of the DSN. The Future-Delivery-Date: field is an extension to the set of DSN per-message fields described in [10]. Using Augmented BNF [2], the syntax of this new field is as follows: future-delivery-date-field = "Future-Delivery-Date:" date-time The date-time value is the absolute future-delivery-time the MSA calculated when the message was received. The date-time format is described in [6]. 3.4 Interaction with the DELIVERBY SMTP service extension If an MSA supports the Future Delivery and Deliver By service extensions, it is possible for an SMTP client to make simultaneous requests for future delivery and deliver-by times when submitting a message. A problem will occur if the future-delivery-date is farther in the future than the deliver-by-date. In order to honor the deliver-by request, the future-delivery request has to be ignored. In order to honor the future-delivery request, the deliver-by request has to be ignored. This section addresses that problem. The Deliver By extension is described in [7]. 3.4.1 SMTP client interaction with DELIVERBY 1) When an SMTP client wishes to use the Future Delivery and Deliver By extensions with the same message, the value of the future- delivery-interval parameter MUST be strictly less than the value of the accompanying by-time parameter. 3.4.2 MSA interaction with DELIVERBY 1) If an MSA supports Future Delivery and Deliver By, and receives a MAIL command containing a future-delivery-interval parameter whose value is greater than or equal to the value of the by-time parameter, the MSA MUST reject that MAIL command. 4. Security Considerations The Future Delivery service extension presents a number of security considerations: 1) Unauthenticated future delivery messages provide a means to White & Vaudreuil Expires August 2004 [Page 7]
INTERNET-DRAFT SMTP Future Delivery February 2004 overwhelm the storage of an MSA. The Future Delivery service extension must always be used in conjunction with the Authentication service extension. 2) Authenticated future delivery without a per-user quota may also provide a way to overwhelm an MSA's storage. It is highly recommended that the future-delivery storage be subject to a per- user quota. 3) Some element of deception is inherent the future delivery concept. The message arrival time is intentionally delayed past the time it would otherwise be received. This extension provides no mechanism for hiding this from the message recipient. The RFC2822 message header, including the sent timestamp remain the same as they were submitted. While a sending client may elect to place the future- delivery-time as the date in the RFC2822 Date: field, there is no requirement or expectation that the Received: fields and other trace information be modified by the transport system to further this deception. 5. Acknowledgments This document was written using [7], written by Dan Newman, as a template. The document structure and many of the words have been recycled as appropriate. White & Vaudreuil Expires August 2004 [Page 8]
INTERNET-DRAFT SMTP Future Delivery February 2004 6. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [4] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [5] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [6] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [7] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000. [8] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [9] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. [10] Moore, K. and G. Vaudreuil, " An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. White & Vaudreuil Expires August 2004 [Page 9]
INTERNET-DRAFT SMTP Future Delivery February 2004 7. Copyright Notice "Copyright (C) The Internet Society (2003). 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." 8. Authors' Addresses Gregory A. White Comnet Messaging Richardson, TX USA Voice: +1-972-201-0193 E-Mail: gregwhite@lucent.com Gregory M. Vaudreuil Lucent Technologies Dallas, TX USA Voice: +1-972-733-2722 E-Mail: gregv@ieee.org 9. Change Log Changes from -01,txt to -02,txt 1) No changes. Draft had expired, so it was re-submitted. Changes from -00.txt to -01.txt: 1) Removed all of the IMAP4 references. 2) Filled in all of the reference numbers. White & Vaudreuil Expires August 2004 [Page 10]
