Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-02.t xt

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Thu, 25 Aug 2005 08:32:13 -0500

Thank you Arnt for contributing the vocabulary that lets us move on.  I see several things that needs to be addressed an a revision.

1) The draft text needs to be consistent that this is a "release at" feature, not "deliver at".  

2) The examples in the introduction should be refined or alternates suggested to make this clearer.

I don't think a name-change is necessary, but will of course do what consensus requires.

By way of further explanation, 

The draft clearly states that this is used only for SMTP-Submission, not general SMTP. (section 3, #6) Therefore there is no way this can be used for accurate delivery time.   The limitation to submission was two-fold, only one of which remains standing

	a) Keep messages in a queue in the administrative domain of the sender where per-user 
	    quota can be enforced.  This is important to keep a sender from overwhelming *your*
          MTA with barrels of messages.  This is a crucial design element for workable security
          and is called out in depth in the security considerations section. 

	b) Support revocation, that is, keep messages local so they can be revolked with 
	    the now-dropped IMAP extension to manage the outbox.  The last disposition was
	    to consider such a mechanism in the future based on MSGTRAK rather than IMAP.

Support of deliver-at requires that every SMTP server in the path be upgraded to support future delivery, and by implication, be capable of storing messages for an indefinitate amount of time in the event the next hop does not support this extension.  If the storage interval is finite at any hop beyond the submission server, the service will appear random to the sender since the allowed intervals will depend upon the path the message takes to the recipient.

I have considered a note allowing this extension to be use hop-by-hop within a single administrative domain, but now believe that to be a private matter.  The intent is to forward all release-after messages to a deep-freezer that is backed-up or otherwise administered for this purpose.  So long as there is a consistent policy between the deep-freeer and the associated  submission server, this will work fine with no more protocol specified.

Greg V.

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]]
Sent: Thursday, August 25, 2005 6:24 AM
To: [email-masked]
Cc: [email-masked]; Antony Bowesman; Mark Crispin
Subject: Re: [lemonade] I-D
ACTION:draft-ietf-lemonade-futuredelivery-02.t xt

Hm, I see the disconnect now. I always read the draft as solving the 
simple issue that might be described as "deferuntil", the one that 
gives 80% result for 20% effort, and didn't really understand that 
people might read the draft differently.

The draft enables me to send mail in three hours or tomorrow morning, at 
a time when I know I won't be at the keyboard. Useful, say I. 
Personally I've wanted that often.

I don't think the draft enables me to send mail at 2006-03-14 14:00, 
because it demands a fixed list of recipients, content and delivery 
date right now. If a meeting is planned at 2006-03-15 14:00, there's 
every chance that the agenda, list of attendees, venue, date or time is 
changed before 2006-03-14, and the draft doesn't give me any way to 
recall or change the meeting announcement. Possible time skew seems 
tiny compared to that.

I'm not sure whether a change of name is necessary. A change of emphasis 
and/or examples sounds good.

(I also had a think about timezone, and IMNSHO it's not reasonable that 
SMTP server administrators should have to keep updated time zone 
information for all over the world. People just aren't that diligent. 
Wasn't there some US change this autumn? A lot of administrators 
outside the US won't even hear about that change, far less regard it as 
a valid reason to upgrade their production mail servers.)

Arnt

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade