RE: Email messages: How large is too large?

["Linscheid, Sven" <Sven.Linscheid at dresdner-bank.com>]

Sorry, girls and boys. I could not understand what this
discussion should keep here.

You're discussion a point which everyone should decide 
in there own world.

I think Mails from 1 k - 1000 MB are OK. Because with
a 10GB Connection is that really something like should
I drive a Porsche or an Lamborgini!

This is not the place to discuss such a stuff!

Use a newsgroup for it, that like nonsene.internet.org!

Cya

.:MCM:. Sven Linscheid

BTW: /dev/null (I love procmail rules ;-) )

> 
> Tim's suggestion has real merit.  It's an embodiment of what 
> I suggested in
> an earlier post - without being the inventor - that something 
> as easy as
> email and as flexible as ftp might be a really good idea - if we agree
> there's a real problem.  How does one proceed with this in IETF?
> 
> To summarize much of what's been said and to wholeheartedly throw my
> (crrent) bias into it:
> 
> I continue to reject the notions:
> 1) People who are clueless are pathetic examples of internet 
> humanity.  At
> least training should be required.
> 2) We need to have rules or guidelines for email.
> 
> I continue to support the ideas:
> 1) Users are the public now - they don't understand all the underlying
> technical details.  Accept it and deal with the reality.  
> They will send
> files that somebody (with good reason) will deem are "too big".
> 2) Focus on the real issues - not the things that happen at 3 
> sigma.  Are
> download rejections and other disruptions at 1 sigma, 3 
> sigma, 6 sigma?
> What's an acceptable rate?
> 3) Users and providers alike will respond to real problems - 
> either with
> larger capabilities or smaller message content.
> 4)  Hard drives are quite cheap.  Populations are rising 
> rapidly.  File
> sizes have reason to be going up as well.  Pipes are getting 
> fatter.  Right
> now storage spaces are limiting and pipes/access (therefore 
> transport times)
> are limiting.
> 
> So, if we need to do something, let's support at least the 
> spirit of Tim's
> idea and make something happen.  First thing on the agenda 
> should be to
> decide if we need to do something - which will include at 
> what cost?  to
> what benefit?  for how long (i.e. will the need disappear before the
> solution appears)?  I'm not suggesting a flurry of emails to 
> address these
> questions right here and now.  I'm suggesting a bit more 
> deliberate process
> to deal with it.
> 
> Fred Marshall
> Mission Systems, Inc.
> http://fcmarshall.home.mindspring.com
> http://expert-market.com/pengroup/missionsystems/index.html
> 
> 
> ----- Original Message -----
> From: Tim Dierks <tdierks at certicom.com>
> To: <ietf at ietf.org>
> Sent: Thursday, December 16, 1999 4:21 PM
> Subject: RE: Email messages: How large is too large?
> 
> 
> > 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
> > tdierks at certicom.com
> > 510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]
> >
> > > -----Original Message-----
> > > From: Mason, Shane [mailto:smason at BLOCKADE.COM]
> > > Sent: Thursday, December 16, 1999 3:40 PM
> > > To: ietf at ietf.org
> > > 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:iacovou at ancept.com]
> > > Sent: Thursday, December 16, 1999 5:57 PM
> > > To: J. Noel Chiappa; ietf at ietf.org
> > > Subject: RE: Email messages: How large is too large?
> > >
> > >
> > > > -----Original Message-----
> > > > From: J. Noel Chiappa [mailto:jnc at ginger.lcs.mit.edu]
> > > > Sent: Thursday, December 16, 1999 3:30 PM
> > > > To: ietf at ietf.org
> > > > Cc: jnc at ginger.lcs.mit.edu
> > > > Subject: Re: Email messages: How large is too large?
> > > >
> > > >
> > > >     > From: Jon Knight <J.P.Knight at lboro.ac.uk>
> > > >
> > > >     > 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.
> > > iacovou at ancept.com
> > > 400 First Ave
> > > N.
> > > www.ancept.com                                            
>      Suite 450
> > >
> >
>