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 <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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
> > [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
> > >
> >
>
