INTERNET-DRAFT                                                  G. White
draft-ietf-lemonade-futuredelivery-01.txt                    Independent
Updates: RFC 3464                                           G. Vaudreuil
Expires: July 20, 2005                               Lucent Technologies
                                                       February 20, 2005


         SMTP Submission Service Extension for Future Delivery


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   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 July 20, 2005             [Page 1]


INTERNET-DRAFT          SMTP Future Delivery           February 20, 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 July 20, 2005             [Page 2]


INTERNET-DRAFT          SMTP Future Delivery           February 20, 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 include a
      future-delivery-interval-param with the MAIL command.

   2) An SMTP client MUST NOT send a MAIL command containing a
      future-delivery-interval-param whose value is strictly
      larger than the value of the max-future-delivery-interval
      advertised with the FUTUREDELIVERY keyword in the MSA's reply to
      the EHLO command.

   3) An SMTP client MUST NOT send a MAIL command containing a
      future-delivery-interval-param when the MSA's reply to the EHLO
      command does not contain the FUTUREDELIVERY keyword.

4.1.2 MSA behavior

   1) An MSA that supports Future Delivery MUST comply with the SMTP
      submission protocol as described in [n3].

   2) An MSA that supports Future Delivery MUST comply with the SMTP
      service extension mechanism as described in [n4].

   3) An MSA that supports Future Delivery MUST advertise support for
      same by including the FUTUREDELIVERY keyword, and associated
      max-future-delivery-interval parameter, in its reply to the
      EHLO command.

   4) An MSA that supports 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 July 20, 2005             [Page 3]


INTERNET-DRAFT          SMTP Future Delivery           February 20, 2005


   5) An MSA that supports 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.

   6) 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.

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) 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 [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].

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.



White & Vaudreuil             Expires July 20, 2005             [Page 4]


INTERNET-DRAFT          SMTP Future Delivery           February 20, 2005


   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.

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:

   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.  It is highly
      RECOMMENDED that the future-delivery storage be subject to a
      per-user quota.

   3) 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,


White & Vaudreuil             Expires July 20, 2005             [Page 5]


INTERNET-DRAFT          SMTP Future Delivery           February 20, 2005


      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.  Apparently, there is no
   registration procedure for SMTP extensions.

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

   There are no informative references.




White & Vaudreuil             Expires July 20, 2005             [Page 6]


INTERNET-DRAFT          SMTP Future Delivery           February 20, 2005


10. Authors' Addresses

   Gregory A. White
   6519 Camille Ave.
   Dallas, TX
   USA
   E-Mail: g.a.white@comcast.com

   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 online 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.

   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.

White & Vaudreuil             Expires July 20, 2005             [Page 7]


INTERNET-DRAFT          SMTP Future Delivery           February 20, 2005


13. Change Log (to be removed upon RFC Publication)

13.1 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.

   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.2 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 July 20, 2005             [Page 8]