Re: Handling large attachments

RANDY@mpa15ab.mv.unisys.com Mon, 20 May 1996 21:05 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25857; 20 May 96 17:05 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25853; 20 May 96 17:05 EDT
Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa13403; 20 May 96 17:05 EDT
Received: by mx2.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA04146; Mon, 20 May 96 13:17:32 -0700
Errors-To: owner-imap@cac.washington.edu
X-Orig-Sender: owner-imap@cac.washington.edu
Received: from eamail1.unisys.com by mx2.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA04139; Mon, 20 May 96 13:17:29 -0700
Received: from mvdns1.mv.unisys.com (mvdns1.mv.unisys.com [192.59.253.100]) by eamail1.unisys.com (8.7.3/8.6.12) with SMTP id UAA25102; Mon, 20 May 1996 20:17:31 GMT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: RANDY@mpa15ab.mv.unisys.com
Received: from eamail1.unisys.com by mvdns1.mv.unisys.com (4.1/SMI-4.1-1.8) id AB27931; Mon, 20 May 96 20:28:25 GMT
Date: Mon, 20 May 1996 13:16:00 -0000
To: imap%cac.washington.edu@mvdns1.mv.unisys.com, treister%Beadle.Stanford.EDU@mvdns1.mv.unisys.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: Handling large attachments
In-Reply-To: Your message of "20 May 96 10:37:47 -0700"
References: <Mailstrom.1.05.64507.1101.treister@networking.stanford.edu>
Message-Id: <EGWP15112B024D@MPA15AB>

On 20 May 96 10:37:47 -0700, Adam Treister <treister@Beadle.Stanford.
EDU> wrote:

> Is there any mechanism to forward or reply to messages with
> attachments without downloading the data just to munge them into a new
> wrapper and send them back up the wire?
>
> I can see 2 possible solutions:
>
> 1) A server-based "delegate agent" that can be invoked from the remote
> client which opens the mailbox extracts the desired pieces and sends
> off the new message.
>
> 2) A "Save Part As" function on the server that will write the
> requested attachment to some accessible space, so that the MUA can
> send off the reply / forward as a MIME external part aot the
> attachment itself.  This has some security issues, and the part may
> need to be encrypted in the process, but it does seem to be the most
>
> Anyone else have a solution that can be implemented within the
> existing protocol and doesn't require needless download to the client.

I don't think this can be done using the existing protocol.  Personally,
I would be very interested in a way to extend the IMAP/IMSP model to
allow a client to access files on the server.  Not only for replying to
mail without the need to ship the data to the client and back, but also
to allow arbitrary server files to be attached to outbound messages, and
so incoming messages (or their attachments) could be saved as server files.
This could be done with FTP, but it would still require shipping the
data round-trip.

The problem, as I see it, is how such functionality could be gotten
without bloating the protocol or extending it where people don't want it
to go.  Since IMSP is for configuration information, IMAP is for
message access, and SMTP is for message submission, there isn't any
cross-over (except in a client that understands them all).

Perhaps if IMAP had a "save as" ability to extract a message or body
part into a server file (assuming the user was authorized to do this),
and the CHUNKING extension to SMTP was itself extended to allow a chunk
to be specified as a server file, it could all be done.  The client
would issue an IMAP command to save parts of messages in server files,
then compose a reply, and send the data in chunks.  One or more of the
chunks would be references to the previously-saved server files.  I
imagine that this would require the authentication extension to SMTP as
well, so the server could know if the user was permitted to access the
requested files.

--
|Randall Gellens             |                    randy@mv.unisys.com|
|(714) 380-6350              | fax (714)597-8053 can add ,,,,,,,,6350|
|Opinions are personal;  facts are suspect;   I speak only for myself|