INTERNET-DRAFT G. White draft-ietf-lemonade-futuredelivery-02.txt Independent Updates: RFC 3463, 3464 G. Vaudreuil Expires: January 31, 2006 Lucent Technologies July 31, 2005 SMTP Submission Service Extension for Future Delivery Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 draft documents 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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 January 31, 2006 [Page 1]
INTERNET-DRAFT SMTP Future Delivery July 31, 2005 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 [n3] to allow a client to submit a message for delivery at a future time. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [n1]. 3. Framework The Future Delivery service extension for SMTP submission uses the SMTP service extension mechanism [n4] to extend the SMTP submission protocol [n3]. The following SMTP submission service extension is hereby defined: The name of the SMTP submission service extension is "Future Delivery". 1) The EHLO keyword associated with this service extension is "FUTUREDELIVERY". 2) One required parameter, the max-future-delivery-interval, is paired with the EHLO keyword in the manner specified in [n4]. This value is a fixed, positive integer indicating the maximum amount of time (in seconds) for which the MSA will accept & hold messages for future delivery. Using ABNF [n2], the syntax of this parameter is as follows: future-delivery-integer = %x31-39 *8DIGIT ; integer in the range 1-999999999 max-future-delivery-interval = future-delivery-integer 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 or delivery. White & Vaudreuil Expires January 31, 2006 [Page 2]
INTERNET-DRAFT SMTP Future Delivery July 31, 2005 future-delivery-interval-param = "AFTER=" future-delivery-interval future-delivery-interval = future-delivery-integer The absence of this parameter on the MAIL command does not imply a default value for this parameter. 4) The maximum length of a MAIL command is increased by 16 characters by the possible addition of the future-delivery-interval-param. 5) No additional SMTP verbs are defined by this extension. 6) This service extension is appropriate only for the SMTP submission protocol [n3]. This service extension is not appropriate for standard SMTP [n4]. 4.1 Behavior 4.1.1 SMTP client behavior 1) An SMTP client wishing to use Future Delivery MUST first verify that the MSA supports this extension. 2) An SMTP client wishing to use Future Delivery MUST include a future-delivery-interval-param with the MAIL command. 3) An SMTP client wishing to use Future Delivery MUST ensure that the value of the future-delivery-interval-param is less than or equal to the value of the max-future-delivery-interval advertised by the MSA. 4.1.2 MSA behavior 1) An MSA wishing to support Future Delivery MUST comply with the SMTP submission protocol as described in [n3]. 2) An MSA wishing to support Future Delivery MUST advertise this support ONLY on the SMTP submission port. 3) An MSA wishing to support Future Delivery MUST include the FUTUREDELIVERY keyword, and associated max-future-delivery-interval parameter, in its reply to the EHLO command. 4) An MSA supporting Future Delivery MUST accept a MAIL command containing a valid future-delivery-interval-param (given that the MAIL command contains no other errors). White & Vaudreuil Expires January 31, 2006 [Page 3]
INTERNET-DRAFT SMTP Future Delivery July 31, 2005 5) 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-param elapses. 6) An MSA supporting Future Delivery MUST reject a MAIL command containing a future-delivery-interval-param whose value is either strictly greater than the value of the advertised max-future-delivery-interval parameter or otherwise invalid. 7) An MSA supporting Future Delivery, when rejecting a MAIL command per 4.1.2.6, SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply. 8) An MSA supporting Future Delivery, when rejecting a MAIL command per 4.1.2.6, SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply. 4.2 Interaction with the DSN SMTP service extension The Delivery Status Notification (DSN) service extension is described in [n7], and DSN message format is described in [n8]. 4.2.1 SMTP client interaction with DSN 1) An SMTP client MUST NOT request Future Delivery when sending a DSN to the MSA. 4.2.2 MSA interaction with DSN 1) If 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) If 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 [n8]. Using ABNF [n2], the syntax of this new field is as follows: future-delivery-date-field = "Future-Delivery-Date:" date-time The value of date-time is calculated by adding the value of the future-delivery-interval-param to the locale-specific absolute time at which the MSA received the message. The date-time format is described in [n5]; however, a numeric zone value MUST be used within the date-time in order to align with other date fields defined in [n8]. White & Vaudreuil Expires January 31, 2006 [Page 4]
INTERNET-DRAFT SMTP Future Delivery July 31, 2005 4.3 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 time is farther in the future than the deliver-by time. 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 [n6]. 4.3.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-param MUST be strictly less than the value of the accompanying by-time parameter. 4.3.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-param whose value is greater than or equal to the value of the by-time parameter, the MSA MUST reject that MAIL command. 2) When an MSA is rejecting a MAIL command per 4.3.2.1, it SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply. 3) When an MSA is rejecting a MAIL command per 4.3.2.1, it SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply. 4.4 Interaction with the MDN function The Message Disposition Notification (MDN) function is described in [n9]. 4.4.1 SMTP client interaction with MDN 1) An SMTP client MUST NOT request Future Delivery when sending an MDN to the MSA. 5. Security Considerations The Future Delivery service extension presents a number of security considerations: White & Vaudreuil Expires January 31, 2006 [Page 5]
INTERNET-DRAFT SMTP Future Delivery July 31, 2005 1) Unauthorized future-delivery messages provide a means to overwhelm the storage of an MSA. An MSA that supports Future Delivery MUST also support at least one of the authorization mechanisms enumerated in [n3]. 2) Authorized future-delivery without a per-user quota may also provide a way to overwhelm an MSA's storage. An MSA's future-delivery storage SHOULD be subject to a per-user quota. 3) If an MSA is imposing a per-user quota on future-delivery storage, and detects that an incoming future-delivery message will exceed the user's future-delivery storage quota, the MSA MUST reject the MAIL command. 4) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the reply code 552 (requested mail action aborted: exceeded storage allocation [n4]) in the reply. 5) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the new Enhanced Mail System Status Code defined for this purpose. This new status code updates [i1]. X.7.9 Future delivery quota exceeded There is insuffient per-user quota to queue the message for future delivery. This code suggests the client can submit again only after the per-user queue has drained. 6) Some element of deception is inherent in the future delivery concept. The message delivery time is intentionally delayed past the time it would otherwise be delivered. This extension provides no mechanism for hiding this from the message recipient. The RFC 2822 message header, and specifically the Date: field, remain unchanged after submission. While a sending client MAY elect to place the future-delivery-time as the date in the 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. IANA Considerations According to the IANA website, this extension will be added to the list of SMTP extensions on the Mail Parameters webpage once this draft becomes a Standards Track RFC. This document defines an additional enhanced status code. At this time there is no IANA registry for these extension values beyond publication of this document in the standards-track. White & Vaudreuil Expires January 31, 2006 [Page 6]
INTERNET-DRAFT SMTP Future Delivery July 31, 2005 7. Acknowledgments This document was written using [n6], authored by Dan Newman, as a template. The document structure and many of the words have been recycled as appropriate. 8. Normative References [n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [n2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [n3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [n4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [n5] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [n6] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000. [n7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [n8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [n9] Hansen, T. and G. Vaudreuil, "Message Disposition Notification," RFC 3798, May 2004. 9. Informative References [i1] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, Jauuary 2003. White & Vaudreuil Expires January 31, 2006 [Page 7]
INTERNET-DRAFT SMTP Future Delivery July 31, 2005 10. Authors' Addresses Gregory A. White 6519 Camille Ave. Dallas, TX 75252 USA E-Mail: g.a.white@comcast.net Gregory M. Vaudreuil Lucent Technologies 9489 Bartgis Ct Frederick, MD 21702 USA E-Mail: GregV@ieee.org 11. Intellectual Property Rights Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org." 12. Copyright Notice and Disclaimer Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. White & Vaudreuil Expires January 31, 2006 [Page 8]
INTERNET-DRAFT SMTP Future Delivery July 31, 2005 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 13. Change Log (to be removed upon RFC Publication) 13.1 Changes from -01.txt to -02.txt 1) Clarified requirements in section 4.1.1, SMTP client behaviour. 2) Removed the requirement that the MSA comply with the SMTP service extension mechanism, as the list thought this was redundant text. 3) Added requirement that the MSA MUST only advertise this extension on the submission port. 4) Added requirements stating how to form the reply to a MAIL command when the future delivery time included with the MAIL command is greater than the max-allowable-future-delivery-time advertised by the MSA. 5) Added requirements stating how to form the reply to a MAIL command when the future-delivery-time and the deliver-by time don't align properly. 6) Change the level of the requirement of the per-user quota requirement in Section 5, Security Considerations, from "highly RECOMMENDED" to "SHOULD". 7) Added requirements stating how to form the reply to a MAIL command when the MSA detects that the future delivery message will exceed the user's future delivery quota. This includes the definition of a new Enhanced Mail System Status Code. 13.2 Changes from -00.txt to -01.txt 1) Removed the Mechanism section, as it pretty much duplicated the Behavior section. 2) Removed the requirement that an MSA supporting FUTUREDELIVERY MUST also support the AUTH extension. Removed all of the requirements referencing the AUTH extension. 3) Changed requirement for EHLO FUTUREDELIVERY keyword so that a positive max-future-delivery-interval value MUST be supplied with that keyword. A value of zero, or no value at all, are no longer options. White & Vaudreuil Expires January 31, 2006 [Page 9]
INTERNET-DRAFT SMTP Future Delivery July 31, 2005 4) Changed the ABNF definition of max-future-delivery-interval and future-delivery-interval from [1*9DIGIT] to [%x31-39 *8DIGIT]. This change forces these values to be integers in the range 1-999999999. 5) Added section for FUTUREDELIVERY interaction with MDN. 6) Modified the definition of the Future-Delivery-Date: field to state that the zone in the date-time value MUST be numeric. Since this field goes in the machine-readable portion of a DSN, this change was made so the definition matches the definitions of the other date fields defined in RFC 3464. 7) Rewrote Security Considerations in terms of "authorization" instead of "authentication." 8) Modified paragraph 1) of Security Considerations to state that an MSA supporting FUTUREDELIVERY MUST employ at least one of the authorization mechanisms listed in RFC 2476. 9) Made all (hopefully) of the changes necessary for the draft to be compliant with ID-NITS and ID-GUIDELINES found on the IETF website. Made other wordsmithing changes to improve clarity. 13.1 Discussion of -00.txt As a note, the -00.txt version of this draft was previously published as draft-vaudreuil-futuredelivery-02.txt. The name of the draft was changed after the LEMONADE WG voted to make this document a WG item. White & Vaudreuil Expires January 31, 2006 [Page 10]
