Received: from localhost (daemon@localhost) 
        by CS.UTK.EDU with SMTP (cf v2.9s-UTK)
	id LAA07483; Thu, 19 Jun 1997 11:37:11 -0400
Received: by CS.UTK.EDU (bulk_mailer v1.7); Thu, 19 Jun 1997 11:35:59 -0400
Received:  
        by CS.UTK.EDU (cf v2.9s-UTK)
	id LAA07362; Thu, 19 Jun 1997 11:35:58 -0400
Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) 
        by CS.UTK.EDU with SMTP (cf v2.9s-UTK)
	id LAA07296; Thu, 19 Jun 1997 11:35:42 -0400
Received: by DOGGATE with Internet Mail Service (5.0.1613.0)
	id <NGT2YAW3>; Thu, 19 Jun 1997 08:35:42 -0700
Message-ID: <2FBF98FC7852CF11912A000000000001050E827D@DINO>
From: "Jeff Stephenson (Exchange)" <jeffstep@Exchange.Microsoft.com>
To: "'John C Klensin'" <klensin@mci.net>
Cc: drums@cs.utk.edu, "'Chris Newman'" <Chris.Newman@innosoft.com>,
        John Samanick <samanicj@ftm.disa.mil>
Subject: RE: RE: Deferred Mail Delivery
Date: Thu, 19 Jun 1997 08:35:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1613.0)
Content-Type: text/plain

Of _course_ you'd never trust anything outside your own trusted enclave
with a deferred delivery message - I don't think you'd ever want to use
it for anything but submission to an SMTP server which you control.  The
point is that a laptop machine might not be able to connect when you
want the message sent, and many people turn off their desktops when they
go home for the day, so having the client do a deferred submission is
not always a viable solution.  Also note that I was not actually
advocating this in my comments, but just pointing out that we shouldn't
dismiss the notion out-of-hand.

-- jeff

> -----Original Message-----
> From:	John C Klensin [SMTP:klensin@mci.net]
> Sent:	Thursday, June 19, 1997 5:53 AM
> To:	Jeff Stephenson (Exchange)
> Cc:	drums@cs.utk.edu; 'Chris Newman'; John Samanick
> Subject:	Re: RE: Deferred Mail Delivery
> 
> 
> On Mon, 16 Jun 1997 17:25:49 -0700 "Jeff Stephenson 
> (Exchange)" <jeffstep@Exchange.Microsoft.com> wrote:
> 
> > Actually I can see some uses for this, though it would have to be
> pretty
> > tightly controlled due to concerns such as those Chris mentioned.
> Say,
> > for example, that you want to make some major announcement
> concerning
> > your (publicly traded) company after the NYSE closes but you've got
> to
> > be elsewhere when that happens; you'd like to compose the
> announcement,
> > submit it for delivery after the market closes, and leave.
> >...
> 
> Jeff,
> 
> You would never, never, trust the remote (delivery-end) MTA 
> with that sort of announcement.  You might get away with it 
> once, but, after that, the operator of that MTA --over whom 
> you would presumably have no control-- would rapidly 
> discover the advantages of sniffing the deferred delivery 
> queue and leaking it to the press.  And I'd bet you, and 
> not the receiving MTA, would end up in an "interesting"
> discussion with your stockholders or the SEC.   
> 
> On the other hand, we've had client(sender)-side facilities 
> around, in a variety of environments, that do this for 
> years and years, and they don't require protocol changes.  
> Think of them as "deferred submit".
> 
>    john
>