WDIFF

draft-vaudreuil-futuredelivery-02.txt --> draft-vaudreuil-futuredelivery-03.txt

draft-vaudreuil-futuredelivery-02.txt Comnet Messaging
draft-vaudreuil-futuredelivery-03.txt Independent
Updates: RFC 3463, 3464 G. Vaudreuil
Expires: August 2004 November 5, 2006 Lucent Technologies
February 2004
May 05, 2006

SMTP Submission Service Extension for Future Delivery Message Release

Status of this Memo

This document

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is an Internet-Draft
aware have been or will be disclosed, and is any of which he or she
becomes aware will be disclosed, in full conformance accordance with
all provisions of Section 10 6 of RFC 2026.

This document is an Internet Draft. Internet Drafts
BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, areas, and its Working Groups. working groups. Note that
other groups may also distribute working documents as Internet Drafts.

Internet Drafts
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 Internet-Drafts as reference
material or to cite them other than as a "work in progress".

To learn the current status progress."

The list of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This memo defines an extension to the SMTP submission protocol for a
client indication of to indicate a future-delivery time. 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 August 2004 November 05, 2006 [Page 1]
INTERNET-DRAFT SMTP Future Delivery February 2004

Table of Contents

1. Introduction .................................................. 3
2. Framework ..................................................... 3
3. Mechanism ..................................................... 4
3.1 Behavior .................................................. 5
3.2 Interaction with the AUTH SMTP service extension .......... 6
3.3 Interaction with the DSN SMTP service extension ........... 6
3.4 Interaction with the DELIVERBY SMTP service extension ..... 7
4. Security Considerations ....................................... 7
5. Acknowledgments ............................................... 8
6. References .................................................... 9
7. Copyright Notice .............................................. 10
8. Authors' Addresses ............................................ 10
9. Change Log .................................................... 10

White & Vaudreuil Expires August 2004 [Page 2]

INTERNET-DRAFT SMTP Future Delivery February 2004 Message Release May 5, 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 [3] [n3] to allow an
authenticated client to submit, to a Message Submission Agent (MSA),
client, when submitting a message, to indicate a future time for the
message to be released for future 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 Delivery Message Release service extension for SMTP submission uses
the SMTP service extension mechanism [5] [n4] to extend the SMTP
submission protocol [3]. [n3]. The following SMTP submission service
extension is hereby defined:

The name of the SMTP submission service extension is "Future
Delivery". Message
Release".

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

2) One optional parameter, Two required parameters, the max-future-delivery-interval, is
allowed max-future-release-interval and the
max-future-release-date-time, are combined with this the EHLO keyword value.

This value
in the manner specified in [n4].

The max-future-release-interval is a fixed, non-negative positive integer indicating
the maximum amount of time (in seconds) for which the MSA will accept & hold messages
for future delivery. If this value is zero, there is no
MSA-imposed limit to the maximum future delivery interval. If the
parameter is omitted, no information is conveyed about the maximum
future delivery interval. release.

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

futuredelivery-param = max-future-delivery-interval
max-future-delivery-interval

future-release-integer = [1*9DIGIT]

3) One required parameter, %x31-39 *8DIGIT
; integer in the future-delivery-interval, range 1-999999999
; measured in seconds

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

The max-future-release-date-time is added a timestamp, normalized to
Universal Coordinated Time (UTC), indicating the MAIL command using 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 May 5, 2006

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

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

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

3) When forming the portion of the EHLO reply containing the
FUTURERELEASE keyword, the keyword "AFTER".

This 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 fixed, future-release-interval,
which is a positive integer indicating the amount of time (in seconds) the
message is to be held by the MSA before
relay.

future-delivery-interval-param 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 = "AFTER="[1*9DIGIT] 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.

White & Vaudreuil Expires August 2004 [Page 3]

INTERNET-DRAFT SMTP Future Delivery February 2004

5) The maximum length of a MAIL command is increased by 16 34 characters
by the possible addition of the AFTER keyword and value.

5) hold-param.

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

6) The FUTUREDELIVERY service extension can only be used in
conjunction with the AUTH service extension [4].

White & Vaudreuil Expires November 05, 2006 [Page 3]
INTERNET-DRAFT SMTP Future Message Release May 5, 2006

7) This service extension is appropriate only for the SMTP
submission protocol [3]. [n3]. This service extension is not
appropriate for standard SMTP [5].

3. Mechanism

An MSA that supports Future Delivery also supports the Authorization
service extension [4]. An MSA that advertises support for Future
Delivery also advertises support for Authorization in the same EHLO
reply. An MSA that advertises support for Future Delivery without
advertising support for Authorization [n4].

4.1 Behavior

It is error, and SMTP clients will
not use Future Delivery on this MSA.

An SMTP client wishing unfortunate to use Future Delivery issues the EHLO command define two seemingly identical ways to start an SMTP session and determine if indicate
a future delivery time. When the MSA supports Future
Delivery and Authorization. If the MSA responds with reply code 250
to the EHLO command, client has both accurate time and
accurate time zone information, either interval or date-time can be
trivally calculated from the response includes other. However, in the EHLO keywords
FUTUREDELIVERY current world of
clients, there are clients with accurate local time but no indication
of their time zone, and AUTH, then Future Delivery is supported by the
MSA.

If client without a numeric value follows suitably accurate clock.
Based on the FUTUREDELIVERY keyword, this value
indicates limited facilities available to these time-challenged
clients, it is likely that only one or the maximum amount other of time (in seconds) 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 MSA
protocol and implementation overhead of offering these two mechanisms
is willing
to hold a message for future delivery. Messages submitted with a
future-delivery-interval greater than this value low, and that few interoperability challenges are rejected by the
MSA.

If 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 Delivery Message Release MUST include one, and Authorization,
only one, hold-param with the MAIL command.

4) An SMTP client then issues using Future Message Release with the AUTH command. If this command is rejected by "for"
option of the MSA, then hold-param MUST ensure that the client
future-release-interval is not allowed less than or equal to issue a MAIL command
containing a future-delivery-interval parameter. Only after the MSA
accepts an AUTH command is
max-future-release-interval advertised by the client allowed to issue a MAIL command
containing a future-delivery-interval parameter.

The MSA.

4) An SMTP client then issues a MAIL command containing a future-
delivery-interval parameter and an authorization parameter. If the
authorization parameter is invalid, the MSA rejects the MAIL command.
If using Future Message Release with the value "until"
option of the future-delivery-interval parameter is greater hold-param MUST ensure that the MSA's advertised max-future-delivery-interval, or
future-release-date-time is
otherwise invalid, the MSA rejects the MAIL command. If both
parameters are valid, and there are no other errors on earlier than or equal to the MAIL
command,
max-future-release-date-time advertised by the MSA accepts that command.

The future-delivery-interval parameter is stated as a time interval
to prevent problems associated with differences in system clocks

White & Vaudreuil Expires August 2004 [Page 4]

INTERNET-DRAFT SMTP Future Delivery February 2004

between SMTP clients and MSAs. MSAs in receipt of a valid future-
delivery-interval parameter are expected to convert the parameter
into a locale-specific absolute time called the future-delivery-time.
This is done by adding the future-delivery-interval to the locale-
specific message receipt time. The MSA is expected to assume that
the transmission time of the MAIL command is instantaneous.

If the MSA accepts a message with a future-delivery request, then the
MSA delivers/relays the message after the MSA's system clock passes
the future-delivery time.

3.1 Behavior

3.1.1 SMTP client behavior

1) An SMTP client wishing to use Future Delivery MUST include a
future-delivery-interval parameter with the MAIL command.

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

3.1.2 MSA.

4.1.2 MSA behavior

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

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

3) An MSA that supports supporting Future Delivery Message Release MUST NOT advertise this
support for
same by including (i.e. include the FUTUREDELIVERY FUTURERELEASE keyword in its reply to the EHLO command.

4) reply)
on any port other than the submission port.

3) An MSA that supports supporting Future Delivery and wishes to enforce a
maximum amount of time that a message will be held for future
delivery Message Release MUST advertise that amount of time by including a max-
future-delivery-interval parameter with include the FUTUREDELIVERY keyword
FUTURERELEASE keyword, and associated max-future-release-interval
and max-future-release-date-time parameters, in the its reply to the
EHLO command.

White & Vaudreuil Expires November 05, 2006 [Page 4]
INTERNET-DRAFT SMTP Future Message Release May 5, 2006

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

6) An MSA that supports Future Delivery MUST reject a MAIL command
containing a future-delivery-interval parameter whose value is
strictly greater than the value of the advertised max-future-
delivery-interval parameter.

7) errors.

5) An MSA that accepts a message with a request for Future Delivery
MUST NOT attempt to deliver or relay Message
Release indicating the "for" option MUST NOT release the message
until the amount

White & Vaudreuil Expires August 2004 [Page 5]

INTERNET-DRAFT SMTP Future Delivery February 2004 of time specified in the future-delivery-interval parameter future-release-interval
elapses.

3.2 Interaction with the AUTH SMTP service extension

The Authentication service extension is described in [4].

3.2.1 SMTP client interaction with AUTH

6) An SMTP client wishing to use Future Delivery MUST use this
extension only when the MSA advertises support that accepts a message with a request for both
Authentication AND Future Delivery in Message
Release indicating the same reply to an EHLO
command.

2) An SMTP client wishing to use Future Delivery "until" option MUST first become
authenticated via NOT release the AUTH command mechanism described in [4].

3) message
until the date and time indicated by the future-release-date-time
occurs.

7) An SMTP client wishing to use MSA supporting Future Delivery Message Release MUST issue reject a MAIL
command that includes a valid authorization parameter along with containing the aforementioned future-delivery-interval parameter.

3.2.2 MSA Interaction with AUTH

1) An MSA "for" option specifying a value that supports Future Delivery MUST also support
Authentication.

2) is
greater than the advertised max-future-release-interval, or
otherwise invalid.

8) An MSA that advertises support for supporting Future Delivery in the reply
to an EHLO command Message Release MUST also advertise support for Authentication
in the same reply.

3) When an MSA receives reject a MAIL
command containing a future-delivery-
interval parameter, and the MSA has not yet authenticated the
client via the AUTH command mechanism described in [4], then "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 the a MAIL
command for security reasons as described
in [5].

4) When an containing more than one hold-param.

10) An MSA receives supporting Future Message Release, when rejecting a MAIL
command containing an invalid
authorization parameter, per 4.1.2.7, 4.1.2.8 or 4.1.2.9, SHOULD supply the MSA MUST reject 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 for
security reasons as described in [5]. The validity per 4.1.2.7, 4.1.2.8 or invalidity
of 4.1.2.9, SHOULD supply the associated future-delivery-interval parameter is immaterial
Enhanced Mail System Status Code 5.5.4 (invalid command
arguments [i1]) in this case.

3.3 the reply.

4.2 Interaction with the DSN SMTP service extension

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

3.3.1 [n8].

4.2.1 SMTP client interaction with DSN

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

White & Vaudreuil Expires August 2004 [Page 6]

INTERNET-DRAFT SMTP Future Delivery February 2004

3.3.2

4.2.2 MSA interaction with DSN

1) When If an MSA generates a DSN for a message that includes a future
delivery 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 May 5, 2006

2) When If an MSA generates a DSN for a message that includes a future
delivery Future
Message Release request, the MSA MUST include a Future-Delivery-Date:
Future-Release-Request: field in the machine-readable body
part of the DSN. The Future-Delivery-Date: 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 [10]. [n8]. Using Augmented BNF [2], ABNF [n2],
the syntax of this new field is as follows:

future-delivery-date-field

orig-hold-param-value = "Future-Delivery-Date:" date-time

The date-time value ("for;" future-release-interval) /
("until;" future-release-date-time)
; this is the absolute future-delivery-time value of the MSA
calculated when HOLD parm from
; the MAIL command of the original message was received. The date-time format is
described in [6].

3.4

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 Delivery Message release and Deliver By service
extensions, it is possible for an SMTP client to make simultaneous
requests for future delivery message release and deliver-by times when
submitting a message. A problem will occur if the future-delivery-date future message
release time is farther in the future than the deliver-by-date. deliver-by time. In
order to honor the deliver-by request, the future-delivery future message release
request has to be ignored. In order to honor the future-delivery future message
release request, the deliver-by request has to be ignored. This
section addresses that problem. The Deliver By extension is
described in [7].

3.4.1 [n6].

4.3.1 SMTP client interaction with DELIVERBY

1) When an SMTP client wishes to use the Future Delivery Message Release and
Deliver By extensions with the same message, the value of the future-
delivery-interval parameter client MUST be strictly less than
ensure that the value
of specified deliver-by time is farther in the accompanying by-time parameter.

3.4.2
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 Delivery Message Release and Deliver By, By
extensions, and receives a message requesting the use of both
extensions, the MSA MUST reject the MAIL command containing a future-delivery-interval parameter
whose value if it determines
that the future message release time is greater farther in the future than or equal to
the value of deliver-by time.

2) When an MSA is rejecting a MAIL command per 4.3.2.1, it SHOULD
supply the by-time
parameter, 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 May 5, 2006

3) When an MSA MUST reject that is rejecting a MAIL command.

4. 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 Delivery Message Release service extension presents a number of
security considerations:

1) Unauthenticated future delivery Unauthorized future-release messages provide a means to

White & Vaudreuil Expires August 2004 [Page 7]

INTERNET-DRAFT SMTP Future Delivery February 2004
overwhelm the storage of an MSA. The Future Delivery service
extension must always be used in conjunction with An MSA that supports Future
Message Release MUST also support at least one of the
Authentication service extension.
authorization mechanisms enumerated in [n3].

2) Authenticated future delivery Authorized future-message-release without a per-user quota may
also provide a way to overwhelm an MSA's storage. It is highly
recommended that the future-delivery An MSA's
future-release message storage SHOULD be subject to a per-
user 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 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 May 5, 2006

6) Some element of deception is inherent in the future delivery message
release concept. The message arrival release time is intentionally
delayed past the time it would otherwise be received. 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 RFC2822 RFC 2822 message
header, including and specifically the sent timestamp Date: field, remain the same as they were
submitted. unchanged after
submission. While a sending client may MAY elect to place the future-
delivery-time
future-message-release-time as the date in the RFC2822 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.

5. Acknowledgments

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 was written using [7], written by Dan Newman, as a
template. The defines an additional enhanced status code. At this
time there is no IANA registry for these extension values beyond
publication of this document structure and in the standards-track.

7. Acknowledgments

Much credit for this draft is due to the LEMONADE working group who
through many revisions resulted in fundamental new understandings
of this protocol and corresponding refinement of the words have been
recycled as appropriate. 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 August 2004 November 05, 2006 [Page 8]
INTERNET-DRAFT SMTP Future Delivery February 2004

6. Message Release May 5, 2006

8. Normative References

[1]

[n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[2]

[n2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[3] 4234, October 2005.

[n3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.

[4] Myers, J., "SMTP Service Extension for Authentication", RFC
2554, March 1999.

[5]

[n4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.

[6]

[n5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[7]

[n6] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June
2000.

[8]

[n7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC 3461,
January 2003.

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

[10]

[n8] Moore, K. and G. Vaudreuil, " An "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,
Jauuary 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 August 2004 November 05, 2006 [Page 9]
INTERNET-DRAFT SMTP Future Delivery February 2004

7. Copyright Message Release May 5, 2006

11. Intellectual Property Rights Notice

"Copyright (C)

This document and translations IETF takes no position regarding the validity or scope of it may any
Intellectual Property Rights or other rights that might be copied and furnished claimed
to
others, and derivative works that comment on or otherwise explain it
or assist in its pertain to the implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction use of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, technology described
in this document itself may or the extent to which any license under such rights
might or might not be modified in available; nor does it represent that it has
made any independent effort to identify any way, such as by removing rights. Information
on the copyright notice or references procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the Internet Society IETF Secretariat and any
assurances of licenses to be made available, or other
Internet organizations, except as needed for the purpose result of
developing Internet standards in which case the procedures an
attempt made to obtain a general license or permission for
copyrights defined in the Internet Standards process MUST be
followed, use
of such proprietary rights by implementers or as required 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 translate it into languages bring to its attention any
copyrights, patents or patent applications, or other than
English.

The limited permissions granted above are perpetual and will not proprietary
rights that may cover technology that may be
revoked by 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 the information contained herein is 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 DISCLAIMS 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."

8. Authors' Addresses

Gregory A. PURPOSE.

White
Comnet Messaging
Richardson, TX
USA
Voice: +1-972-201-0193
E-Mail: gregwhite@lucent.com

Gregory M. & Vaudreuil
Lucent Technologies
Dallas, TX
USA
Voice: +1-972-733-2722
E-Mail: gregv@ieee.org

9. Expires November 05, 2006 [Page 10]
INTERNET-DRAFT SMTP Future Message Release May 5, 2006

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

13.0 Changes from -01,txt draft-ietf-lemonade-futuredelivery-04.txt to -02,txt draft-vaudreuil-futuredelivery-03

1) No changes. Draft had expired, so it Changed filename back to non-WG form to reflect consensus that this be
progressed as an individual contribution.

13.1 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.2 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.3 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 re-submitted. 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.4 Changes from -00.txt to -01.txt: -01.txt

1) Removed the Mechanism section, as it pretty much duplicated the
Behavior section.

White & Vaudreuil Expires November 05, 2006 [Page 11]
INTERNET-DRAFT SMTP Future Message Release May 5, 2006

2) Removed the requirement that an MSA supporting FUTUREDELIVERY MUST
also support the AUTH extension. Removed all of the IMAP4 references.

2) Filled 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 reference numbers. 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.5 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 August 2004 November 05, 2006 [Page 10] 12]
----