Internet Draft Greg White Expires in six months Lucent Technologies Updates: RFC 1894bis Greg Vaudreuil Lucent Technologies April 29, 2002 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. This Internet-Draft is in conformance with Section 10 of RFC 2026. Internet Draft Future Delivery April 29, 2002 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. Working Group Summary None Yet White & Vaudreuil Expires 10/29/02 [Page 2] Internet Draft Future Delivery April 29, 2002 Table of Contents 1. INTRODUCTION ........................................................4 2. FRAMEWORK FOR THE FUTURE DELIVERY SMTP SUBMISSION SERVICE EXTENSION .4 3. THE FUTURE DELIVERY SMTP SUBMISSION SERVICE EXTENSION MECHANISM .....5 4. IMAP4 CONSIDERATIONS ................................................9 5. SECURITY CONSIDERATIONS .............................................9 6. ACKNOWLEDGMENTS ....................................................10 7. REFERENCES .........................................................11 8. COPYRIGHT NOTICE ...................................................12 9. AUTHORS' ADDRESSES .................................................12 White & Vaudreuil Expires 10/29/02 [Page 3] Internet Draft Future Delivery April 29, 2002 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 [] to allow an authenticated client to submit, to a Message Submission Agent (MSA), a message for future delivery. This extension is created with the understanding that an end-user desire is to be able to review future-delivery messages via their mail client, and if necessary, to dequeue or delete them using the Internet Message Access Protocol v4 (IMAP4) []. This specification introduces a specific IMAP4 folder convention for an "outbox," a folder that contains future-delivery messages. 2. Framework for the Future Delivery SMTP submission service extension The Future Delivery service extension for SMTP submission uses the SMTP service extension mechanism [3] to extend the SMTP submission protocol [1]. The following SMTP submission service extension is hereby defined: 1) The name of the SMTP submission service extension is "Future Delivery". 2) The EHLO keyword value associated with this service extension is "FUTUREDELIVERY". 3) 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 [4], the syntax of this parameter is as follows: futuredelivery-param = max-future-delivery-interval max-future-delivery-interval = [1*9DIGIT] 4) 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 White & Vaudreuil Expires 10/29/02 [Page 4] Internet Draft Future Delivery April 29, 2002 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. 5) The maximum length of a MAIL command is increased by 16 characters by the possible addition of the AFTER keyword and value. 6) No additional SMTP verbs are defined by this extension. 7) The FUTUREDELIVERY service extension can only be used in conjunction with the AUTH service extension []. 8) This service extension is appropriate only for the SMTP submission protocol [1]. This service extension is not appropriate for standard SMTP [3]. 3. The Future Delivery SMTP submission service extension mechanism An MSA that supports Future Delivery must also support the Authorization service extension [5]. 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. White & Vaudreuil Expires 10/29/02 [Page 5] Internet Draft Future Delivery April 29, 2002 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 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 Future Delivery 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 []. 2) An MSA that supports Future Delivery MUST comply with the SMTP service extension mechanism as described in []. 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). White & Vaudreuil Expires 10/29/02 [Page 6] Internet Draft Future Delivery April 29, 2002 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 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 []. 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 []. 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 [], then the MSA MUST reject the MAIL command for security reasons as described in []. 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 []. 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 [], and DSN format is described in []. White & Vaudreuil Expires 10/29/02 [Page 7] Internet Draft Future Delivery April 29, 2002 3.3.1 SMTP client interaction with DSN 1) An SMTP client MUST NOT request Future Delivery when sending a DSN to the MSA. 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 []. Using Augmented BNF [], 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 [AUTH]. 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 []. 3.4.1 SMTP client interaction with DELIVERBY 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 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. White & Vaudreuil Expires 10/29/02 [Page 8] Internet Draft Future Delivery April 29, 2002 4. IMAP4 considerations Future delivery message may be stored in the message store associated with the subscriber. If so, the message store should make the contents of that queue available via IMAP4 []. 4.1 IMAP4 "Outbox" definition A new standard folder "Outbox" is defined to provide access to the future delivery queue. This queue is of the form of a mailbox, but must contain the full SMTP envelope such that when delivery commences, the full recipient list and any and all SMTP extensions are provided. Open Issue: Should a batch SMTP format be specified for storage in an outbox? 4.2 IMAP4 behavior A message that is dequeued using an IMAP (or other) client is not considered a delivery failure. No DSN shall be sent to the originator of that message. When messages queued within the message store for future delivery What happens if you move a message to the outbox and it does not have an envelope? Does it just sit there? Presumably copying a message to the outbox does not enqueue a delivery event. Any protocol implications here? 5. Security Considerations The Future Delivery service extension presents a number of security considerations: 1) Unauthenticated future delivery messages provide a means to 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. In implementations where the future-delivery storage is accessible via IMAP, it is suggested that this quota be shared with the mailbox 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- White & Vaudreuil Expires 10/29/02 [Page 9] Internet Draft Future Delivery April 29, 2002 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. 6. Acknowledgments This document was written with the deliver-by extension, RFC 2852 by Dan Newman as a template. The document structure and many of the words have been recycled as appropriate. White & Vaudreuil Expires 10/29/02 [Page 10] Internet Draft Future Delivery April 29, 2002 7. References [] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. [] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996. [] Moore, K. and G. Vaudreuil, " An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [] Crispin, M., " INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 2060, December 1996. [] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000. White & Vaudreuil Expires 10/29/02 [Page 11] Internet Draft Future Delivery April 29, 2002 8. Copyright Notice "Copyright (C) The Internet Society (2002). 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." 9. Authors' Addresses Gregory M. Vaudreuil Lucent Technologies 17080 Dallas Parkway Dallas, TX 75248-1905 USA Voice: +1-972-733-2722 E-Mail: GregV@ieee.org Greg A. White Lucent Technologies 17080 Dallas Parkway Dallas, TX 75248-1905 USA Voice: +1-972-733-2714 E-Mail: GregWhite@lucent.com White & Vaudreuil Expires 10/29/02 [Page 12]