doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4865.txt b/doc/rfc/rfc4865.txt
new file mode 100644
index 0000000..6423322
--- /dev/null
+++ b/doc/rfc/rfc4865.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                           G. White
+Request for Comments: 4865                                   Independent
+Updates: 3463, 3464                                         G. Vaudreuil
+Category: Standards Track                                 Alcatel-Lucent
+                                                                May 2007
+
+
+      SMTP Submission Service Extension for Future Message Release
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+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.
+
+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.
+
+
+
+
+
+
+
+
+
+White & Vaudreuil           Standards Track                     [Page 1]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+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 Extended Hello (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.
+
+      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].
+
+
+
+
+
+
+White & Vaudreuil           Standards Track                     [Page 2]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+   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-release-interval
+                                    SP max-future-release-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.
+
+   7) This service extension is appropriate only for the SMTP submission
+      protocol [n3].  This service extension is not appropriate for
+      standard SMTP [n4].
+
+
+
+
+White & Vaudreuil           Standards Track                     [Page 3]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+4.  Behavior
+
+   It is unfortunate to define two seemingly identical ways to indicate
+   a future message release time.  When the client has both accurate
+   time and accurate time zone information, either interval or date-time
+   can be trivially 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 clients 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
+   trivially 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.  SMTP Client
+
+   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.
+
+   3) 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.2.  MSA
+
+   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.
+
+
+
+
+
+
+
+White & Vaudreuil           Standards Track                     [Page 4]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+   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.
+
+   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 items 7, 8, or 9, above, 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 items 7, 8, or 9, above, SHOULD supply the Enhanced
+      Mail System Status Code 5.5.4 (invalid command arguments [i1]) in
+      the reply.
+
+
+
+
+
+
+
+
+
+
+
+White & Vaudreuil           Standards Track                     [Page 5]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+5.  Protocol Interactions
+
+5.1.  Interaction with the DSN SMTP Service Extensions
+
+   The Delivery Status Notification (DSN) service extension is described
+   in [n7], and DSN message format is described in [n8].
+
+5.1.1.  SMTP Client Interaction with DSN
+
+   1) An SMTP client MUST NOT request Future Message Release when
+      sending a DSN to the MSA.
+
+5.1.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.
+
+   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 param from
+                            ; the MAIL command of the original message
+
+         future-release-request-field = "Future-Release-Request:"
+                                        orig-hold-param-value
+
+5.2.  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].
+
+
+
+White & Vaudreuil           Standards Track                     [Page 6]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+5.2.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.
+
+5.2.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 item 1, above, 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 item 1, above, it
+      SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid
+      command arguments [i1]) in the reply.
+
+5.3.  Interaction with the MDN Function
+
+   The Message Disposition Notification (MDN) function is described in
+   [n9].
+
+5.3.1.  SMTP Client Interaction with MDN
+
+   1) An SMTP client MUST NOT request Future Message Release when
+      sending an MDN to the MSA.
+
+6.  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.
+
+
+
+
+White & Vaudreuil           Standards Track                     [Page 7]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+   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.16   Future release per-user message quota exceeded
+
+         There is insufficient 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.
+
+      X.7.17   Future release system message quota exceeded
+
+         There is insufficient 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 [n5] 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.
+
+
+
+
+
+
+
+
+
+White & Vaudreuil           Standards Track                     [Page 8]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+7.  IANA Considerations
+
+   This extension has been added to the list of SMTP Service Extensions
+   on the Mail Parameters Web page.
+
+8.  Acknowledgments
+
+   Much of the credit for this document 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.
+
+9.  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 for Mail", RFC
+         4409, April 2006.
+
+   [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
+
+
+
+
+
+White & Vaudreuil           Standards Track                     [Page 9]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+10.  Informative References
+
+   [i1]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
+         January 2003.
+
+Authors' Addresses
+
+   Gregory A. White
+   6519 Camille Ave.
+   Dallas, TX  75252
+   USA
+   EMail: g.a.white@tx.rr.com
+
+   Gregory M. Vaudreuil
+   Alcatel-Lucent
+   9489 Bartgis Ct
+   Frederick, MD 21702
+   USA
+   EMail: GregV@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+White & Vaudreuil           Standards Track                    [Page 10]
+
+RFC 4865              SMTP Future Message Release               May 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+White & Vaudreuil           Standards Track                    [Page 11]
+