[unisog] Size Limit on E-Mail Attachments
jim.dillon at cusys.edu
Mon Nov 5 19:19:34 GMT 2001
Why use a fire-hydrant to water the lawn?
I don't disagree with you, really. What I was objecting with was the
arbitrary limit at a fairly small size (single digit in MBs was
suggested). While email is absolutely not the best answer for large file
transfers, training 2000 clueless individuals to use FTP is far more costly
and unproductive than letting them attach 6MB files and emailing them IF,
this is a big if, there is enough supporting bandwidth. In otherwords it
is a situational answer based on business requirements, not an arbitrary
I really just wanted to emphasize the bigger picture - people need to move
data, don't cut it off until you can define the bigger picture solution and
the point where it is costing too much.
Training the anonymous hoards to use FTP servers is ineffective. The
researchers with constant needs and big files - sure a lot of good
solutions have been offered including SFTP, SSH, etc. Train them.
At 01:43 PM 11/03/2001 -0600, you wrote:
>While your argument sounds real good, email was never designed nor
>intended to be a file transfer mechanism. There are other methods that
>were specifically designed to do this; web pages are one, sftp is another,
>scp is yet another. Email is merely convenient, but it's not even the
>fastest/best way to move large files.
No real argument here.
>Why should you have to burn a CD and drive 90 miles to deliver it when you
>can move it across the network in a few minutes? We are successfully
>transferring multi-hundred MB files across I2 using SFTP. You just have
>to teach the folks that need that functionality how to do it. - can't
>argue that Sending the same file through email is often a lost cause
>because the email *clients* aren't capable of handling email that size,
>even if the email servers are.
No argument for the BIG case, again, its the arbitrary low limits I'm
concerned with. Most patches and upgrades seem to be in 3 to 12 MB range,
and some of the proposed limits were as low as 2MB if I remember
right. That won't even support your average powerpoint presentation, let
alone a quick and widespread distribution of an OS patch. If we allow
enough bandwidth to surf, there should be enough to support attachments of
a reasonably large size.
The sad truth to the "drive it" scenario is the vast diversity of the
organizations managing the many different systems. It is often impossible
to make contact with a person capable of supporting the end user on one
side or the other of the connection. In fact the only available support
might be a student who only comes in on Mondays and Thursdays. Thus it is
often safer and more expedient to drive, if not a whole lot more
costly. An arbitrarily low limit will increase the amount of this going
on, sad but true due to highly un-integrated systems and account
management. Simplifies a lot if it is the two central IT orgs doing the
work, but even then you might spend some time getting past the help-desk to
someone who can actually set up the accounts, help the end users find a
client for file transfer, and teach them to use it. I truly hope that all
of your institutions are not in this shape, but I'm afraid it is more the
norm than not at large state institutions.
>We have a size limit of 25MB for email *and* we bounce email with
>attachments that have certain extensions (EXE being one of them.) We've
>had no complaints about the process (which doesn't mean there aren't any,
>but we've been praised by many for the extension blocks), but when someone
>needs to move large files, we set them up with SFTP and teach them how to
>Why use a garden hose to do the work of a fire hydrant?
Don't use a fire hydrant to water the lawn, you'll crack your side-walks
and foundation! A hose is sufficient, and much easier to turn on!
>--On Friday, November 02, 2001 7:21 PM -0700 Jim Dillon
><jim.dillon at cusys.edu> wrote:
>>There may be some unnecessary waste, but turning off the spigot because
>>your sprinkler system leaks does not get the lawn watered. Patch the
>>leaks or get a new sprinkler!
>Paul L. Schmehl, pauls at utdallas.edu
>Supervisor, Support Services
>The University of Texas at Dallas
>AVIEN Founding Member
Jim Dillon, CISA
IT Audit Manager
jim.dillon at cusys.edu
Dept. Phone: 303-492-9730
More information about the unisog