Subject: [lemonade] future delivery <draft-vaudreuil-UM-issues-00.txt>

From: "Jonathan T. Hawkins" <[email-masked]>
Date: Thu, 01 May 2003 18:31:38 -0700

Hi,

I just joined this work group.  This is my first time to particpate in
IETF, so please accept my apologies ahead of time if I miss something.

    3.3 Future Delivery

       Traditionally messages sent with "future delivery" are held in
the
       recipients client "outbox" or equivalent until the appointed
submission
       time.  Think clients used for WEB or TUI do not have such
       persistent storage and must rely upon server-based outbox queues.

       Such support requires extensions to message submission protocols
to
       identify a message as requiring queuing for future delivery.
Extensions
       to IMAP4 or conventions are required to view and manipulate the
outbound
       queue, for such purposes as cancelling a future message.  Server
support
       for managing such a queue is required such that message are sent
when
       they are intended.

My thoughts after reading this is are the following:
IMHO, thin mail clients would submit messages via a transport protocol
(i.e. SMTP),  rather than IMAP (which is an access protocol).  I do
realize some clients submit messages via IMAP for things like archival
(the ever present "sent folder").

Robustness of the above might be in question.  Typically, IMAP
implementations do not include "store and forward" and "alternative
path" capabilities of protocols such as SMTP.

Would the deferred delivery marker (date of delivery) be designated by
the submission protocol (i.e. SMTP option) or part of the message
encapsulation (i.e. a particular message header)?

One concept I think you stepped over is that by having an IMAP folder
for outbound mail, the user can selectively remove (or cancel) messages
to be future delivered.  This would promote compatability with regular
IMAP clients.