Message-Id: <1.5.4.32.19970620023116.006b3aac@pop3.holonet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Jun 1997 19:31:16 -0700
To: John C Klensin <klensin@mci.net>,
        "Jeff Stephenson (Exchange)" <jeffstep@Exchange.Microsoft.com>
From: Carl-Uno Manros <carl@manros.com>
Subject: Re: RE: RE: Deferred Mail Delivery
Cc: John Samanick <samanicj@ftm.disa.mil>,
        "'Chris Newman'" <Chris.Newman@innosoft.com>, drums@cs.utk.edu

At 09:24 PM 6/19/97 -0400, John C Klensin wrote:
>
>On Thu, 19 Jun 1997 08:35:37 -0700 "Jeff Stephenson 
>(Exchange)" <jeffstep@Exchange.Microsoft.com> wrote:
>
>> 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,
>
>No real disagreement, except...
>
> * the facility you have just posited isn't analogous to 
>the X.400 facility any more.  That one, unless my memory 
>has failed me, does anticipate the possibility of moving 
>the message to the next-to-last hop and holding it there.  
>On the other hand, X.400 assumes trusted mail systems in a 
>number of ways.
>

John,

I think that your memory does fail you in this case.
This was a subject that was discussed by a number of people 
over a long period of time during my time as the X.400 
Rapporteur.  I cannot recall the exact text in the document
off hand, but I am pretty sure that it strongly recommends
that you should let the first MTA (which presumably is in
your own domain) should hold the message until submission
time, both due to security considerations and for ease of
deleting it, if you so choose.


---rest deleted---

Carl-Uno Manros