[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 4865

INTERNET-DRAFT                                                  G. White
draft-vaudreuil-futuredelivery-04.txt                        Independent
Updates: RFC 3463, 3464                                     G. Vaudreuil
Expires: February 10, 2006                           Lucent Technologies
                                                         August 10, 2006


      SMTP Submission Service Extension for Future Message Release


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 as "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 a
   client to indicate a future time for the message to be released for
   delivery.  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 November 05, 2006           [Page 1]

INTERNET-DRAFT        SMTP Future Message Release       August 10, 2006


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, when submitting a message, to indicate a future time for the
   message to be released for delivery.

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 Message Release 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 Message
   Release".

   1) The EHLO keyword associated with this service extension is
      "FUTURERELEASE".

   2) Two required parameters, the max-future-release-interval and the
      max-future-release-date-time, are combined with the EHLO keyword
      in the manner specified in [n4].

      The max-future-release-interval is a positive integer indicating
      the maximum amount of time for which the message submission server
      (MSA) will hold messages for future release.

      Using ABNF [n2], the syntax of this parameter is as follows:

         future-release-integer = %x31-39 *8DIGIT
                                  ; integer in the range 1-999999999
                                  ; measured in seconds

         max-future-release-interval = future-release-integer

      The max-future-release-date-time is a timestamp, normalized to
      Universal Coordinated Time (UTC), indicating the most remote date
      and time in the future until which the MSA will hold messages for
      future release.



White & Vaudreuil          Expires November 05, 2006            [Page 2]

INTERNET-DRAFT        SMTP Future Message Release        August 10, 2006


      Using ABNF [n2], the syntax of this parameter is as follows:

         max-future-release-date-time = date-time

      where the format of date-time is defined in [n10].

   3) When forming the portion of the EHLO reply containing the
      FUTURERELEASE keyword, the keyword is followed by the
      max-future-release-interval, and then the
      max-future-release-date-time.  The keyword and two values are
      delimited by spaces.

      For example, the ABNF for a continuation line in the EHLO response
      that contains the FUTURERELEASE keyword is:

         line = "250-FUTURERELEASE" SP max-future-delivery-interval
                                    SP max-future-delivery-date-time

   4) One required parameter, the hold-param, is added to the MAIL
      command using either the keyword "HOLDFOR" or the keyword
      "HOLDUNTIL".

      The HOLDFOR parameter value is a future-release-interval,
      which is a positive integer indicating the amount of time the
      message is to be held by the MSA before release.

      The HOLDUNTIL parameter value is a future-release-date-time,
      which is a timestamp, normalized to UTC, indicating the future
      date and time until which the message is to be held by the MSA
      before release.

      Using ABNF [n2], the syntax of this parameter is as follows:

         future-release-interval = future-release-integer

         future-release-date-time = Internet-style-date-time-UTC

         hold-for-param = "HOLDFOR=" future-release-interval

         hold-until-param = "HOLDUNTIL=" future-release-date-time

         hold-param = hold-for-param / hold-until-param

      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 34 characters
      by the possible addition of the hold-param.

   6) No additional SMTP verbs are defined by this extension.




White & Vaudreuil          Expires November 05, 2006            [Page 3]

INTERNET-DRAFT        SMTP Future Message Release        August 10, 2006


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

   It is unfortunate to define two seemingly identical ways to indicate
   a future delivery time.  When the client has both accurate time and
   accurate time zone information, either interval or date-time can be
   trivally calculated from the other.  However, in the current world of
   clients, there are clients with accurate local time but no indication
   of their time zone, and client without a suitably accurate clock.
   Based on the limited facilities available to these time-challenged
   clients, it is likely that only one or the other of these mechanisms
   will be useful.

   It is believed that servers will have accurate time, and can trivally
   convert between these mechanisms.  It is also accepted that the
   protocol and implementation overhead of offering these two mechanisms
   is low, and that few interoperability challenges are anticipated.

4.1.1 SMTP client behavior

   1) An SMTP client preparing to use Future Message Release MUST first
      verify that the MSA supports this extension.

   2) An SMTP client using Future Message Release MUST include one, and
      only one, hold-param with the MAIL command.

   4) An SMTP client using Future Message Release with the "for"
      option of the hold-param MUST ensure that the
      future-release-interval is less than or equal to the
      max-future-release-interval advertised by the MSA.

   4) An SMTP client using Future Message Release with the "until"
      option of the hold-param MUST ensure that the
      future-release-date-time is earlier than or equal to the
      max-future-release-date-time advertised by the MSA.

4.1.2 MSA behavior

   1) An MSA supporting Future Message Release MUST comply with the SMTP
      submission protocol as described in [n3].

   2) An MSA supporting Future Message Release MUST NOT advertise this
      support (i.e. include the FUTURERELEASE keyword in its EHLO reply)
      on any port other than the submission port.

   3) An MSA supporting Future Message Release MUST include the
      FUTURERELEASE keyword, and associated max-future-release-interval
      and max-future-release-date-time parameters, in its reply to the
      EHLO command.


White & Vaudreuil         Expires November 05, 2006            [Page 4]

INTERNET-DRAFT        SMTP Future Message Release       August 10, 2006


   4) An MSA supporting Future Message Release MUST accept a MAIL
      command containing a valid hold-param, given that the MAIL command
      contains no other errors.

   5) An MSA that accepts a message with a request for Future Message
      Release indicating the "for" option MUST NOT release the message
      until the amount of time specified in the future-release-interval
      elapses.

   6) An MSA that accepts a message with a request for Future Message
      Release indicating the "until" option MUST NOT release the message
      until the date and time indicated by the future-release-date-time
      occurs.

   7) An MSA supporting Future Message Release MUST reject a MAIL
      command containing the "for" option specifying a value that is
      greater than the advertised max-future-release-interval, or
      otherwise invalid.

   8) An MSA supporting Future Message Release MUST reject a MAIL
      command containing the "until" option specifying a value that
      is later than the advertised max-future-release-date-time, or
      otherwise invalid.

   9) An MSA supporting Future Message Release MUST reject a MAIL
      command containing more than one hold-param.

  10) An MSA supporting Future Message Release, when rejecting a MAIL
      command per 4.1.2.7, 4.1.2.8 or 4.1.2.9, SHOULD supply the reply
      code 501 (syntax error in parameters or arguments [n4]) in
      the reply.

  11) An MSA supporting Future Message Release, when rejecting a MAIL
      command per 4.1.2.7, 4.1.2.8 or 4.1.2.9, 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 Message Release 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
      Message Release request, the MSA MUST include an Arrival-Date:
      field in the machine-readable body part of the DSN.


White & Vaudreuil          Expires November 05, 2006            [Page 5]

INTERNET-DRAFT        SMTP Future Message Release        August 10, 2006


   2) If an MSA generates a DSN for a message that includes a Future
      Message Release request, the MSA MUST include a
      Future-Release-Request: field in the machine-readable body
      part of the DSN.  The value of this field is the value of the HOLD
      parameter contained in the MAIL command of the original message.

      The Future-Release-Request: 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:

         orig-hold-param-value = ("for;" future-release-interval) /
                                 ("until;" future-release-date-time)
                            ; this is the value of the HOLD parm from
                            ; the MAIL command of the original message

         future-release-request-field = "Future-Release-Request:"
                                        orig-hold-param-value

4.3 Interaction with the DELIVERBY SMTP service extension

   If an MSA supports the Future Message release and Deliver By service
   extensions, it is possible for an SMTP client to make simultaneous
   requests for future message release and deliver-by times when
   submitting a message.  A problem will occur if the future message
   release time is farther in the future than the deliver-by time.  In
   order to honor the deliver-by request, the future message release
   request has to be ignored.  In order to honor the future message
   release 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 Message Release and
      Deliver By extensions with the same message, the client MUST
      ensure that the specified deliver-by time is farther in the
      future than the specified ("until" option) or implied ("for"
      option) future message release time.

4.3.2 MSA interaction with DELIVERBY

   1) If an MSA supports Future Message Release and Deliver By
      extensions, and receives a message requesting the use of both
      extensions, the MSA MUST reject the MAIL command if it determines
      that the future message release time is farther in the future than
      the deliver-by time.

   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.




White & Vaudreuil          Expires November 05, 2006            [Page 6]

INTERNET-DRAFT        SMTP Future Message Release        August 10, 2006


   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 Message Release when
      sending an MDN to the MSA.

5. Security Considerations

   The Future Message Release service extension presents a number of
   security considerations:

   1) Unauthorized future-release messages provide a means to
      overwhelm the storage of an MSA.  The authorization mechanisms
      required for the base mail submission protocol [n3] are expected
      to provide appropriate defense against such attacks.

   2) Authorized future-message-release without a per-user quota may
      also provide a way to overwhelm an MSA's storage.  An MSA's
      future-release message storage SHOULD be subject to a per-user
      quota.

   3) If an MSA is imposing a per-user quota on future-release message
      storage, and detects that an incoming future-release message will
      exceed the user's future-release message 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-release per-user message quota exceeded

         There is insuffient per-user quota to queue the message for
         future release.  This code suggests the client can
         submit again only after the per-user queue has drained.







White & Vaudreuil          Expires November 05, 2006            [Page 7]

INTERNET-DRAFT        SMTP Future Message Release        August 10, 2006

      X.7.10   Future-release system message quota exceeded

         There is insuffient system quota to queue the message for
         future release.  This code suggests the client can
         submit again after the system queue has drained.

   6) Inaccurate time on the MSA may result in premature or delayed release
      of messages.  Both HOLDUNTIL and HOLDFOR request mechanisms are sensitive
      to inaccurate or changing clocks on the MSA.

   7) Some element of deception is inherent in the future message
      release concept.  The message release time is intentionally
      delayed past the time it would otherwise be released;  hence,
      the message delivery time is 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-message-release-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 web page.

7. Acknowledgments

   Much of credit for this draft is due to the LEMONADE working group.
   Through many revisions the discussion resulted in fundamental new
   understandings of this protocol and corresponding refinement of
   the implied requirements and protocol.  Special thanks to those who
   patiently lead the WG to understand that doing both interval and
   date-time was the pragmatically correct approach to the needs of diverse
   clients.


















White & Vaudreuil          Expires November 05, 2006            [Page 8]

INTERNET-DRAFT        SMTP Future Message Release        August 10, 2006


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 4234, October 2005.

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

   [n10] Klyne, G. and C. Newman, "Date and Time on the Internet:
         Timestamps," RFC 3339, July 2002

9. Informative References

   [i1]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
         January 2003.

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



White & Vaudreuil          Expires November 05, 2006            [Page 9]

INTERNET-DRAFT        SMTP Future Message Release        August 10, 2006


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 (2006).

   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 November 05, 2006           [Page 10]

INTERNET-DRAFT        SMTP Future Message Release        August 10, 2006

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

13.0 Changes from -03 to -03.txt

  1) Numerous editorial fixes

  2) New status code for system quota exceeded

  3) Rework to correct BNF for max-future-release-date-time

  4) Augmented security considerations to address server time inaccuracy

13.1 Changes from draft-ietf-lemonade-futuredelivery-04.txt to draft-vaudreuil-futuredelivery-03

   1) Changed filename back to non-WG form to reflect consensus that this be
    progressed as an individual contribution.

13.2 Changes from -03.txt to -04.txt

   1) Changed extension framework to define HOLDFOR and HOLDUNTIL for
      the MAIL command (instead of the HOLD parameter).

   2) Made wording changes to several of the SMTP client and MSA
      behavior requirements

13.3 Changes from -02.txt to -03.txt

   1) Rewrote entire draft in terms of future message release instead of
      future message delivery.  Almost every paragraph of Sections 1
      through 5 have been changed.

13.4 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".

White & Vaudreuil          Expires November 05, 2006           [Page 11]

INTERNET-DRAFT        SMTP Future Message Release        August 10, 2006

   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.5 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.6 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 November 05, 2006           [Page 12]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/