WDIFF

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

Internet Draft GregINTERNET-DRAFT G. White
Expires in six months Lucent Technologies
draft-vaudreuil-futuredelivery-02.txt Comnet Messaging
Updates: RFC 1894bis Greg 3464 G. Vaudreuil
Expires: August 2004 Lucent Technologies
April 29, 2002
February 2004

SMTP Submission Service Extension for Future Delivery
<draft-vaudreuil-futuredelivery-00.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.

This document is an Internet Draft. 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 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 a "work in progress".

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts 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).

This Internet-Draft is in conformance with Section 10 of RFC 2026.

Internet Draft Future Delivery April 29, 2002

ABSTRACT

Abstract

This memo defines an extension to the SMTP submission protocol for
client indication of a future-delivery time. This extension permits
a client to use server-based storage for a message that should be
held in queue until an appointed time in the future. This is useful
for clients which do not have local storage or are otherwise unable
to release a message for delivery at an appointed time.

Working Group Summary

None Yet

White & Vaudreuil Expires 10/29/02 August 2004 [Page 2]

Internet Draft 1]

INTERNET-DRAFT SMTP Future Delivery April 29, 2002 February 2004

Table of Contents

1. INTRODUCTION ........................................................4 Introduction .................................................. 3
2. FRAMEWORK FOR THE FUTURE DELIVERY SMTP SUBMISSION SERVICE EXTENSION .4 Framework ..................................................... 3
3. THE FUTURE DELIVERY 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 SUBMISSION SERVICE EXTENSION MECHANISM .....5 service extension ..... 7
4. IMAP4 CONSIDERATIONS ................................................9 Security Considerations ....................................... 7
5. SECURITY CONSIDERATIONS .............................................9 Acknowledgments ............................................... 8
6. ACKNOWLEDGMENTS ....................................................10 References .................................................... 9
7. REFERENCES .........................................................11 Copyright Notice .............................................. 10
8. COPYRIGHT NOTICE ...................................................12 Authors' Addresses ............................................ 10
9. AUTHORS' ADDRESSES .................................................12 Change Log .................................................... 10

White & Vaudreuil Expires 10/29/02 August 2004 [Page 3]

Internet Draft 2]

INTERNET-DRAFT SMTP Future Delivery April 29, 2002 February 2004

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] to allow an
authenticated client to submit, to a Message Submission Agent (MSA),
a message for future delivery.

This extension is created with the understanding that an end-user
desire is to be able to review future-delivery messages via their mail
client, and if necessary, to dequeue or delete them using the Internet
Message Access Protocol v4 (IMAP4) []. This specification introduces
a specific IMAP4 folder convention for an "outbox," a folder that
contains future-delivery messages.

2. Framework for the Future Delivery SMTP submission service extension

The Future Delivery service extension for SMTP submission uses the
SMTP service extension mechanism [3] [5] to extend the SMTP submission
protocol [1]. [3]. The following SMTP submission service extension is
hereby defined:

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

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

2) One optional parameter, the max-future-delivery-interval, is
allowed with this EHLO keyword value.

This value is a fixed, non-negative 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.

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

futuredelivery-param = max-future-delivery-interval
max-future-delivery-interval = [1*9DIGIT]

3) One required parameter, the future-delivery-interval, is added to
the MAIL command using the keyword "AFTER".

This value is a fixed, positive integer indicating the amount of

White & Vaudreuil Expires 10/29/02 [Page 4]

Internet Draft Future Delivery April 29, 2002
time (in seconds) the message is to be held by the MSA before
relay.

future-delivery-interval-param = "AFTER="[1*9DIGIT]

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

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

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

8) [4].

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

3. The Future Delivery SMTP submission service extension mechanism Mechanism

An MSA that supports Future Delivery must also support supports the Authorization
service extension [5]. [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 is error, and SMTP clients will
not use Future Delivery on this MSA.

An SMTP client wishing to use Future Delivery issues the EHLO command
to start an SMTP session and determine if the MSA supports Future
Delivery and Authorization. If the MSA responds with reply code 250
to the EHLO command, and the response includes the EHLO keywords
FUTUREDELIVERY and AUTH, then Future Delivery is supported by the
MSA.

If a numeric value follows the FUTUREDELIVERY keyword, this value
indicates the maximum amount of time (in seconds) the MSA is willing
to hold a message for future delivery. Messages submitted with a
future-delivery-interval greater than this value are rejected by the
MSA.

If the MSA supports Future Delivery and Authorization, the SMTP
client then issues the AUTH command. If this command is rejected by
the MSA, then the client is not allowed to issue a MAIL command
containing a future-delivery-interval parameter. Only after the MSA
accepts an AUTH command is the client allowed to issue a MAIL command
containing a future-delivery-interval parameter.

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

White & Vaudreuil Expires 10/29/02 [Page 5]

Internet Draft Future Delivery April 29, 2002
If the value of the future-delivery-interval parameter is greater
that the MSA's advertised max-future-delivery-interval, or is
otherwise invalid, the MSA rejects the MAIL command. If both
parameters are valid, and there are no other errors on the MAIL
command, 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 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 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 Future Delivery behavior 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 behavior

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

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

3) An MSA that supports Future Delivery MUST advertise support for
same by including the FUTUREDELIVERY keyword in its reply to the
EHLO command.

4) An MSA that supports Future Delivery and wishes to enforce a
maximum amount of time that a message will be held for future
delivery MUST advertise that amount of time by including a max-
future-delivery-interval parameter with the FUTUREDELIVERY keyword
in the reply to the EHLO command.

5) An MSA that supports Future Delivery MUST accept a MAIL command
containing a valid future-delivery-interval (given that the MAIL
command contains no other errors).

White & Vaudreuil Expires 10/29/02 [Page 6]

Internet Draft Future Delivery April 29, 2002

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) An MSA that accepts a message with a request for Future Delivery
MUST NOT attempt to deliver or relay 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
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

1) An SMTP client wishing to use Future Delivery MUST use this
extension only when the MSA advertises support for both
Authentication AND Future Delivery in the same reply to an EHLO
command.

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

3) An SMTP client wishing to use Future Delivery MUST issue a MAIL
command that includes a valid authorization parameter along with
the aforementioned future-delivery-interval parameter.

3.2.2 MSA Interaction with AUTH

1) An MSA that supports Future Delivery MUST also support
Authentication.

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

3) When an MSA receives 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 the
MSA MUST reject the MAIL command for security reasons as described
in []. [5].

4) When an MSA receives a MAIL command containing an invalid
authorization parameter, the MSA MUST reject the command for
security reasons as described in []. [5]. The validity or invalidity
of the associated future-delivery-interval parameter is immaterial
in this case.

3.3 Interaction with the DSN SMTP service extension

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

White & Vaudreuil Expires 10/29/02 [Page 7]

Internet Draft Future Delivery April 29, 2002 [10].

3.3.1 SMTP client interaction with DSN

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

White & Vaudreuil Expires August 2004 [Page 6]

INTERNET-DRAFT SMTP Future Delivery February 2004

3.3.2 MSA interaction with DSN

1) When an MSA generates a DSN for a message that includes a future
delivery request, the MSA MUST include an Arrival-Date: field in
the machine-readable body part of the DSN.

2) When an MSA generates a DSN for a message that includes a future
delivery request, the MSA MUST include a Future-Delivery-Date:
field in the machine-readable body part of the DSN.

The Future-Delivery-Date: field is an extension to the set of DSN
per-message fields described in []. [10]. Using Augmented BNF [], [2],
the syntax of this new field is as follows:

future-delivery-date-field = "Future-Delivery-Date:" date-time

The date-time value is the absolute future-delivery-time the MSA
calculated when the message was received. The date-time format is
described in [AUTH]. [6].

3.4 Interaction with the DELIVERBY SMTP service extension

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

3.4.1 SMTP client interaction with DELIVERBY

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

3.4.2 MSA interaction with DELIVERBY

1) If an MSA supports Future Delivery and Deliver By, and receives
a MAIL command containing a future-delivery-interval parameter
whose value is greater than or equal to the value of the by-time
parameter, the MSA MUST reject that MAIL command.

White & Vaudreuil Expires 10/29/02 [Page 8]

Internet Draft Future Delivery April 29, 2002

4. IMAP4 considerations

Future delivery message may be stored in the message store associated
with the subscriber. If so, the message store should make the
contents of that queue available via IMAP4 [].

4.1 IMAP4 "Outbox" definition

A new standard folder "Outbox" is defined to provide access to the
future delivery queue. This queue is of the form of a mailbox, but
must contain the full SMTP envelope such that when delivery commences,
the full recipient list and any and all SMTP extensions are provided.

Open Issue: Should a batch SMTP format be specified for storage in an
outbox?

4.2 IMAP4 behavior

A message that is dequeued using an IMAP (or other) client is not
considered a delivery failure. No DSN shall be sent to the originator
of that message.

When messages queued within the message store for future delivery

What happens if you move a message to the outbox and it does not have
an envelope? Does it just sit there? Presumably copying a message to
the outbox does not enqueue a delivery event. Any protocol
implications here?

5. Security Considerations

The Future Delivery service extension presents a number of security
considerations:

1) Unauthenticated future delivery 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 the
Authentication service extension.

2) Authenticated future delivery without a per-user quota may also
provide a way to overwhelm an MSA's storage. It is highly
recommended that the future-delivery storage be subject to a per-
user quota. In implementations where the future-delivery storage
is accessible via IMAP, it is suggested that this quota be shared
with the mailbox quota.

3) Some element of deception is inherent the future delivery concept.
The message arrival time is intentionally delayed past the time it
would otherwise be received. This extension provides no mechanism
for hiding this from the message recipient. The RFC2822 message
header, including the sent timestamp remain the same as they were
submitted. While a sending client may elect to place the future-

White & Vaudreuil Expires 10/29/02 [Page 9]

Internet Draft Future Delivery April 29, 2002
delivery-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

This document was written with the deliver-by extension, RFC 2852 using [7], written by Dan Newman Newman, as a
template. The document structure and many of the words have been
recycled as appropriate.

White & Vaudreuil Expires 10/29/02 August 2004 [Page 10]

Internet Draft 8]

INTERNET-DRAFT SMTP Future Delivery April 29, 2002

7. February 2004

6. References

[] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.

[] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
January 1996.

[] Moore, K. and G. Vaudreuil, " An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.

[] Crispin, M., " INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 2060, December 1996.

[]

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

[]

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

[]

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

[AUTH]

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

[]

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

[]

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

[]

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

[8] 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] Moore, K. and G. Vaudreuil, " An Extensible Message Format for
Delivery Status Notifications", RFC 3464, January 2003.

White & Vaudreuil Expires 10/29/02 August 2004 [Page 11]

Internet Draft 9]

INTERNET-DRAFT SMTP Future Delivery April 29, 2002

8. February 2004

7. Copyright Notice

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process MUST be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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 M. Vaudreuil
Lucent Technologies
17080 Dallas Parkway
Dallas, A. White
Comnet Messaging
Richardson, TX 75248-1905
USA
Voice: +1-972-733-2722 +1-972-201-0193
E-Mail: GregV@ieee.org

Greg A. White gregwhite@lucent.com

Gregory M. Vaudreuil
Lucent Technologies
17080 Dallas Parkway
Dallas, TX 75248-1905
USA
Voice: +1-972-733-2714 +1-972-733-2722
E-Mail: GregWhite@lucent.com gregv@ieee.org

9. Change Log

Changes from -01,txt to -02,txt

1) No changes. Draft had expired, so it was re-submitted.

Changes from -00.txt to -01.txt:

1) Removed all of the IMAP4 references.

2) Filled in all of the reference numbers.

White & Vaudreuil Expires 10/29/02 August 2004 [Page 12] 10]
----