OK, I'll make a suggestion.
When the sending user injects the message into the mail system, the SMTP
server could detect large e-mail attachments and replace them with reference
pointers; it would then cache the attachment someplace; possibly in local
storage, but an ISP or an enterprise with multiple SMTP servers could have a
seperate set of file storage servers. The reference pointer would refer to
the storage location of the attachment and would be obscurely chosen in a
manner to make it difficult to index and/or retrieve attachments without
access to the e-mail message containing the reference link.
When the receiving user's mail agent sees such a reference, it can directly
contact the caching server and download the attachment. This retrieval can
happen immediately or it can wait until the user explicitly requests it. The
retrieval protocol should support interruption and restart of the download
process.
In addition, SMTP servers which handle the e-mail message between the
initial server and the end user could choose to fetch the attachment on
behalf of the user and reassemble the e-mail message into a monolithic
whole. They would presumably do this based on some local policy.
The attachment would be deleted from the SMTP server's cache based on some
set of criteria, which could include:
- After some period of time
- After being completely fetched by the intended recipient[s]
- Some combination of the above.
If the initial SMTP server doesn't have enough caching space, the user agent
could automatically upload the attachment to some other caching server
(possibly just using the user's local machine, if it has appropriate access
to the Internet and sufficient availability) and edit the outgoing message
to include a reference rather than the inline attachment.
Regardless, compression should be added to MIME and integrated into user
agents to automatically compress and decompress large attachments.
While it's non-trivial to implement and deploy this proposal, it would seem
to offer a more flexible mechanism for large message delivery without
forcing users to unduly conform their usage to the limitations of
implementations.
- Tim
Tim Dierks
Chief Technology Officer, Certicom
[EMAIL PROTECTED]
510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]
> -----Original Message-----
> From: Mason, Shane [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 16, 1999 3:40 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Email messages: How large is too large?
>
>
> What's the SOLUTION??? Watching this thread is like watching a dog chase
> it's tail. The distinguished left hand keeps saying that "E-mail wasn't
> designed to do this." The down and dirty right hand keeps
> asserting "User's
> will keep using it if there is no good alternative."
>
> Well I have news for all of you. You are all correct!
>
> Quit arguing and let's come up with a solution.
>
> Shall a new WG be created to deal with this issue??
>
> ICMan
>
> -----Original Message-----
> From: Danny Iacovou [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 16, 1999 5:57 PM
> To: J. Noel Chiappa; [EMAIL PROTECTED]
> Subject: RE: Email messages: How large is too large?
>
>
> > -----Original Message-----
> > From: J. Noel Chiappa [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, December 16, 1999 3:30 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Email messages: How large is too large?
> >
> >
> > > From: Jon Knight <[EMAIL PROTECTED]>
> >
> > > sending an email with a large Word attachment to all
> > 15000 users on
> > > campus isn't a good idea as our mail servers will melt.
> > ... especially
> > > from non-academic departments who are used to doing
> > paper based mass
> > > mailings to students. ... depite us offering to put the
> > Word document
> > > on a web page and then send a small email pointing at it
> >
> >
> > The caveat about using the email system to transfer things
> > from one user to
> > another is that it is, after all, an *email* system, and
> > engineered for that,
> > not a generic bulk-data-transfer system. To use a real-world
> > analogy, the
> > post-office may take parcels, but above a certain size, you
> > have to switch to
> > a shipping company, which is set up to deal with larger
> > items. In a similar
> > vein, the email system was designed for certain
> > characteristic payloads,
> > particularly size - i.e. *email*.
>
> Speaking of University campuses:
>
> The University of Minnesota has a great looking mall. They spend a
> lot of time and money maintaining the trees, shrubs, and grass. The
> sidewalks running between buildings were a great idea. A lot of people
> used them and stayed off the grass. But you know, a lot of other people
> did the math and the shortest distance between 2 points is a straight
> line. Too bad the sidewalks weren't designed to run along that line.
> So a lot of nice pretty grass turned to ugly mud as more and
> more people
> stomped over the grass to get were they needed to be in the
> most "optimal"
> way.
>
> This practice continued for a long time. Sure, eventually signs went up
> telling people not to step on the grass. But that didn't work.
>
> Eventually the University put chain fences on every corner of the mall.
> The chain fences look nice. The grass is well maintained now. I
> guess they
>
> decided not to add sidewalks.
>
> E-mail should either be able to handle a message of any size or
> the user
> should be told right away that the message can't be sent. People have
> already mentioned the GUI aspect of this problem. I agree to a large
> extent
> with them.
>
> So the problem essentially comes down to money. When are message sizes
> causing too many problems for admins to cost justify their
> efforts on? At
> that point we either decide to put up nice fences or we build sidewalks.
>
> The post-office has a nice fence in place. They didn't want to build a
> sidewalk. I think eventually we are going to opt for the sidewalk.
>
> ------------------------------------------------------------------
> ----------
> ----
> Neophytos Iacovou Ancept Inc.
> [EMAIL PROTECTED]
> 400 First Ave
> N.
> www.ancept.com Suite 450
>
