wdiff rfc4865.original rfc4865.txt

INTERNET-DRAFT
Network Working Group G. White
draft-vaudreuil-futuredelivery-04.txt
Request for Comments: 4865 Independent
Updates: RFC 3463, 3464 G. Vaudreuil
Expires: February 10, 2006
Category: Standards Track Lucent Technologies
August 10, 2006
May 2007

SMTP Submission Service Extension for Future Message Release

Status of this 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

This document specifies an Internet standards track protocol for the
Internet Engineering
Task Force (IETF), its areas, community, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Please refer to the current edition of six months the "Internet
Official Protocol Standards" (STD 1) for the standardization state
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 status of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list this protocol. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html this memo is unlimited.

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

3) When forming the portion of the EHLO reply containing the
FUTURERELEASE keyword, the keyword is followed by the
max-future-release-interval, 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 max-future-release-interval
SP max-future-delivery-date-time 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].

4.1

4. Behavior

It is unfortunate to define two seemingly identical ways to indicate
a future delivery message release time. When the client has both accurate
time and accurate time zone information, either interval or date-time
can be
trivally 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 client 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 trivally
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.1

4.1. SMTP client behavior 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 future-release-
date-time is earlier than or equal to the
max-future-release-date-time max-future-release-
date-time advertised by the MSA.

4.1.2

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

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 items 7, 8, or 4.1.2.9, 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 4.1.2.7, 4.1.2.8 items 7, 8, or 4.1.2.9, 9, above, SHOULD supply the Enhanced
Mail System Status Code 5.5.4 (invalid command arguments [i1]) in
the reply.

4.2

5. Protocol Interactions

5.1. Interaction with the DSN SMTP service extension Service Extensions

The Delivery Status Notification (DSN) service extension is described
in [n7], and DSN message format is described in [n8].

4.2.1

5.1.1. SMTP client interaction Client Interaction with DSN

1) An SMTP client MUST NOT request Future Message Release when
sending a DSN to the MSA.

4.2.2

5.1.2. MSA interaction 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: 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: 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: 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 param from
; the MAIL command of the original message

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

4.3

5.2. Interaction with the DELIVERBY SMTP service extension 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

5.2.1. SMTP client interaction 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

5.2.2. MSA interaction 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, 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 4.3.2.1, item 1, above, it
SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid
command arguments [i1]) in the reply.

4.4

5.3. Interaction with the MDN function Function

The Message Disposition Notification (MDN) function is described in
[n9].

4.4.1

5.3.1. SMTP client interaction 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 future message release without a per-user quota may
also provide a way to overwhelm an MSA's storage. An MSA's
future-release 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

X.7.16 Future release per-user message quota exceeded

There is insuffient 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.10 Future-release

X.7.17 Future release system message quota exceeded

There is insuffient 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: 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: Date field, there
is no requirement or expectation that the Received: Received fields and
other trace information be modified by the transport system to
further this deception.

7. IANA Considerations

According to the IANA website, this

This extension will be has been added to the list of SMTP extensions Service Extensions
on the Mail Parameters web Web page.

8. Acknowledgments

Much of the credit for this draft document is due to the LEMONADE working
group. Through many revisions 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", Submission for Mail", RFC 2476,
December 1998.
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,"
Notification", RFC 3798, May 2004.

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

10. 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
EMail: g.a.white@tx.rr.com

Gregory M. Vaudreuil
Lucent
Alcatel-Lucent Technologies
9489 Bartgis Ct
Frederick, MD 21702
USA
E-Mail:
EMail: GregV@ieee.org

11. Intellectual Property Rights Notice

Full Copyright Statement

Copyright (C) The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain Trust (2007).

This document is subject to the implementation or use of the technology described rights, licenses and restrictions
contained in this BCP 78, and except as set forth therein, the authors
retain all their rights.

This document or and the extent to which 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.

12. Copyright Notice and Disclaimer

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

Acknowledgement

Funding for 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.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 Editor function is
greater than the max-allowable-future-delivery-time advertised currently provided 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.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.
Internet Society.