Slashdot Mirror
E-Mail Size Limits?
Technoman asks: "I work for a company that for the past four years has restricted individual e-mail messages to 5 meg each. We now have users suggesting that this limit is to small and hinders them in performing their job. I would like to know how others are using size limits, and if not how they deal with large e-mails." As human communication over the net becomes more and more complex, the "acceptable size" of an email message will increase. 10 years ago, if you got an email over 10k, something was seriously amiss; but these days, that is just a flash in the pan. Many people rely on email, not FTP to transfer files, and things like a few family portraits can easily exceed several megs in size, so drawing the line for all users may not be as easy as you think, depending on your users and your network. Put simply, if you were the administrator of an e-mail server, what would you set the maximum size of an incoming email message to be, and what would be the reasoning behind said limit?
Our company restricts emails to 2meg, and we rarely have any problems with that. On the few occasions that a large email needs to be sent, the IT department will temporarily raise the quota. Personally I hate receiving emails over 1 meg in size!
http://www.22balmoralroad.net/ http://www.tinynetworks.co.uk/
Five meg sounds like a pretty good limit to me. In fact it may be a little high. There are still many people on dialup to whom 5 meg is a 35 or so minute download.
My own personal opinion is that if a message is over one meg I put it up on an web site and place the url in the message. If its over 100 megs then I'll choose some format that is easily resumable (DCC, FTP, etc.) .
If people get in the habit of sending massive emails you will start to get mysterious complaints about mail getting rejected. After finally getting your users to give you the returned mail message you'll discover that not all mail servers even accept large mail. Some will reject it as being too big.
At the company I presently work for, almost EVERY email has an attachment (an excel spreadsheet and a word document). On occassion, those too lazy to type have sent in their scanned TIFF files. I recieved a 48 page TIFF file the other day that 140MB. I deleted it without opening it and told them to re-send in a smaller format. However, everyone else in my office is completely oblivious to the fact of the size of an email and replication. a 10MB attachment sent to 200 people occupies a lot of space REALLY quick. Especially since by default Save sent items and forwards contain the attachments. Everyone else in my office chalks up large attachments to "Outlook being broke" and asks me to come fix it. I then explain to them that they're trying to d/l a large file and just wait (stupid 2B channel ISDN). I recently convinced the Home Office that a size limit of 5MB was needed and exceptions could be made as needed. So far, nobody has needed one. :)
A little education goes a long way. People need to be taught some of what goes on in order to understand why doing XYZ is a bad idea.
"...we dont care about the economics; we just want to be able to hack great stuff."
If you are an ISP, the users are your customers, and they are right (as customers always should be).
What sort of data do they need to send? Is it complete documents with formatting? Video files? Software? And who are they sending files to?
Put simply, if you were the administrator of an e-mail server, what would you set the maximum size of an incoming email message to be, and what would be the reasoning behind said limit?
I would say $size_of_mail_disk divided by $number_of_users applied with a quotum. This would probably amount to something round and about 100MB.
My users would probably have a hell of a time actually getting this e-mail from the server, but I don't see the technical solution would help here. Users will simply use e-mail to transfer files simply because they can.
sig not found
The quota size depends on the industry/department. People who are IT people should not be held to a email quota because most likey they are getting a few hundred emails a day, some large, some small... lots of mailing list traffic, and the rejects for everybody else. Now, this normally wont blow the cap, but it would be nice to forward joe blow's 10 failed emails of 1 meg each to him at one time.
The last two companies I worked at we more or less had no limit on the email size.... I asked employees to keep their mailbox size usage (exchange) to a reasonable amount... unreasonable would be storing porn in your exchange store... which I have had people do.... I'm nice about it though.... At one point Management decided we needed a limit on imcomming email size just to limit the sizes of the emails customers were sending in. We limited it at that point to 50 megs.... but we kept a email address w/o a incomming quota so customers could send very very very large things to us.
Okay, I'm sure I'll sound like a elitist prick to some people, but I really don't care. What you should do, is to _educate_ people in what the Internet consists of, and what medium you should do to do what.
Explain to people that sending large emails really isn't very nice, that you'll most likely increase the overhead due to the way the files are encoded, and so forth.
Explain to people, the difference between ftp, smtp, http, pop3, nntp, imap and so forth. If you're daring, even explain them how to use telnet. Don't go into the very _details_ of the protocols unless they ask, of course. Just explain how things should be done.
If people use instant messenging, explain the difference between IM, ICQ, IRC, and whatever they want to use.
Explain things instead of just choosing the easy way out and adapting to them - except if their way really _is_ better.
That's my opinion. Now flame me for beeing an elitist bastard.
"Rune Kristian Viken" - http://www.nwo.no - arca
A little education goes a long way.
To my opinion education is the only way your users will know what to do.
Putting a size limit on your e-mail server doesn't learn them anything exept that their e-mail administrator is a complete *ss (in their view).
E-mail size limits only help if you explain to your uses why they shouldn't send files by e-mail if there is another way and, how they should share documents. For example by providing a common storage place by http or ftp somewhere. These sharing tools however have to be just as simple as sending e-mail for people to use them.
sig not found
I've seen some posts suggesting this isn't a good thing, but it's just so much easier to do... especially if you don't have a remote server with a web panel interface. If a user ftp's a file, and then gets to a computer without an ftp program, what can they do? nothing much... unless the ftp is visible on the web. Using webmail (which everyone at my university uses now) makes this process much simpler. Even I, who know quite a bit about computers, find sending files over email much easier because when I get to work or home, I don't have to download anything... the file is already sitting on my computer (unless my mail program has crashed for some reason).
Anywho, that's off topic a bit. I personally don't see a problem with configurable limits. Is this possible on a per-account basis? Set the limit at 5mb (that seems high to me!) and then increase it for users who request it. Really, if people want to send huge files over email, they should break them up over several emails rather than uploadding a 100mb email.
I'm currently developing a web-page, and I am thinking of making a http-send page (easy in PHP) where people can upload files like when u attach files for mails on hotmail/yahoo mail. Then the file will be transferred to the users home-dir.
It's really a problem that some files seem to exist only on mailsystems, and no longer in filesystems. If this trend keeps ruling our company, I think we have to buy bigger disks for the mailserver, and just accept this fact, unless a better economical solution comes on the market.
I don't think that a per-e-mail limit is useful. At the place I work there is a 20 mb limit on e-mail boxes (you can overflow it to 30 mb but the admins don't like it and you get a lot of nasty e-mails).
All e-mails that I get are instantly downloaded from the exchange server onto my local machine as soon as I connect to the network. Of course, when someone sends an 11mb file it is a little annoying downloading that files over a slow VPN connection but even that inconvience doesn't outway the convience of being able to send a document when I want.
The public drive is broken up into groups. It would be difficult to share a file with someone in another group if we could not use the mail system for that due to permission issues. (An external ftp server would be unacceptable)
If the file is any larger than 20mb than the best approach in my opinion is to burn the data to a cd and mail it to them (internal mail system is quite good for this).
In the past 12 months my local mail file is at 600mb. That's 600mb of important info that's kept organised. I'd estimate that only %3-%5 of any e-mail I've recieved have been larger 5mb.
That's just my opinion....
My organization delivers software installers and updates to users primarily via web downloads. And pretty regularly, there is someone who can't get to the download area of the web site for whatever reason (web proxy is down, don't have/dog ate the password, the regular guy isn't here today) who wants us to "just email" him the files. Our main install is just a tad over 5 MB, which straddles the line for some people. Also, there is the occaisional need to get a particular file to an individual user, and email is the prefered method in this case.
.EXE file directly (which all of our installers are), and our own incoming filter will delete .EXE files from *inside* a zip file! To send me an .EXE, you have to not only zip it, but password the zip file!
Lately, the biggest obstacle is not file size, but attachment filters. Almost nobody can recieve an
Thank you, MS Outlook, for these innovations in the use of email.
I am not your blowing wind, I am the lightning.
... as such, no one should be using their email for personal correspondance.
Getting large family portraits at work? All the more reason to keep the limit at 5MB.
Me, I set up an FTP server on my cable connection for just such occasions.
If users are complaining that 5MB isn't enough, do the following:
1) Remind them this is a business network and as such you have the right to limit the amount of file size attachments
2) Get them WinZIP and teach them how to use it
3) Set up an FTP server
Cruising the internet on my TI-99/4A @ a whopping 300 baud!
Samsung Contact (was HP OpenMail), anyone?
r.
I remember a few years ago, I sent a large (7mb... which at the time was about 6.5mb larger than the next biggest I'd ever sent). It crashed our mail server.
What had happened was that the mail server only had 1.5mb of disk space left. Normally that wouldn't have been a problem, because it was only temporary storage for the messages as they left the building, but the size of my message meant that it got permenantly stuck, it caused all other emails behind it in the queue to back up for five hours, before the server finally died.
Lessons learned:
1. Limits are sometimes a good thing.
2. Server admins should keep adequate disk space free.
3. Mail servers are not immortal.
(Spudley Strikes Again!)
I have to agree with previous posts. Email is not a file transfer protocol, it's a mail protocol. It's designed for text. If you want to send files, use a protocol that was designed for it like FTP, HTTP, or DCC file transfer.
If your company is smart they use an instant messenger. If not, I suggest you use one. Using an instant messenger users can send files between each other without going through servers.
- Inventory information
- Competitive Analyses
- Employee Phone Directory
- Customer Lists
- Financial Data (budgets)
One problem, of course, is that many companies want to actually PREVENT easy transfer of some of this data (for example, worried that employees may email confidential data to themselves at home, to use when going to work for another competitor).It is actually pretty rare that regular documents, including source code, exceed a limit like 5MB. However, when documents are created with one tool and saved with another (for example, when a web page containing a table is edited using Microsoft Word), the file size quickly bloats.
My experience has always been that a 5MB limit will need to be "worked around" several times per month by certain employees. For some things, this is easy: instead of sending a single ZIP file containing 20 huge images, break it into 5 files containing 4 each, or send each one individually. If perfect quality isn't an issue (e.g. vacation or baby pictures), run the images through a JPEG reducer.
I actually don't recall EVER sending a file larger than 10MB, and usually I encounter problems with files that are 3-5MB before encoding. I have to consider two issues for larger data transfers: my own bandwidth and the recipient's bandwidth (if the mail would be routed through a non-ISP company mailserver, they might also have bandwidth issues). When sending large batches of images or mega-spreadsheets, it usually makes more sense to send a CD-ROM. (And using CD-ROM also helps because it's harder for most folks to delete or lose than an email attachment.)
Note that all this discussion is about individual email size limits, not mail account limits or quotas. That's a whole other issue. Usually when folks encounter the mailbox quota, it's because their email client is not configured to delete email after downloading it to a PC (a practice that can make sense if you read email from multiple locations, but the art is then setting the right delay before deleting).
I suspect the real issue here is that casual and unnecessary transfer of large files can quickly tie up bandwidth -- especially for branch offices sharing a 128K DSL line, or emails that are sent to 20 or more different recipients. (Recall the Dancing Baby, and this week the various Halloween flashies.)
-- http://www.MarkWelch.com/ Pleasanton California
As a modem user (*sigh*), I find that using IMAP is a great solution for people that attach massive files to e-mails they send to me. I only end up downloading the headers, and I can see the filesize before deciding whether to download it or not.
I've seen a few posts that state that people should use another method like HTTP or FTP, but that doesn't save space on the server any better than sending through e-mail. The obvious best solution is to find a way to send through something that doesn't require a server, like an instant messenger or DCC on IRC, but even then, it should be possible to send huge attachments through e-mail for when no other solution is viable such as users behind firewalls.
(1) There are often very legitimate reasons for needing to send someone a file over 5MB; not everyone's trafficing in hi-res pictures of Aunt Sally eating rhubarb pie. In advertising, for instance, legitimate presentation documents bound for a client can bloat up in size very quickly. Which leads us into the next (and more important) issue...
(2) You not only have to educate your users in the fine art of using FTP, but the clients to whom those users are sending files in the first place. Trust me, if Company X just spent $10 million to have an agency develop an ad campaign for them, the last thing they'd want to get back for their money is a long lecture on the proper use of various file transfer techniques from the local techie.
It's a service economy out there, and if you don't provide in a manner that's convenient for the client, you get serviced (in the most painful Oz sense of the word.)
Right now all the servers I administer are at 25MB. I find this is more than large enough for anyone who is actually working. File sharing needs to happen over a file server that is what a file server is for. Mail servers are for communicating and there are safeguards like limiting file size that need to be in place to prevent someone from being an id10t and bringing the entire server down because he thought it would be funny to send some video of a monkey scratching his ass to everyone in the company.
I used to have all internal mail unlimited in size until the sales team at one company decided it would be a good medium for sending files back and forth and they began sending and broadcasting a 100MB+ Powerpoint presentation back and forth. Get about 5 revisions going and have them all be broadcasted to 30 people and watch a small mail server go down.
I was under the impression hp openmail/samsung contact was a dead product. It was posted on slashdot like two years ago that samsung was discontinuing development right after they finished buying it from HP.
Damn, I just checked the pricing, for 5 mail boxes, 5 user cals, its like 500 bucks... I'd get Backoffice Server instead........ It only costs what, 550?
> "I work for a company that for the past four years has restricted
> individual e-mail messages to 5 meg each.
To me this should be more that enough room. A user could attach a
large document etc and still have room for their message.
> We now have users suggesting that this limit is to small and hinders
> them in performing their job.
They likely have a legitimate need that they currently resolve through
email. Provide them with an alternate means to address this same
need. Explain that email is a tool designed for written
communication not a tool for graphic design, or file transfer.
>I would like to know how others are using size limits, and if not how
> they deal with large e-mails." As human communication over the net
> becomes more and more complex, the "acceptable size" of an
> email message will increase. 10 years ago, if you got an email over
> 10k, something was seriously amiss; but these days, that is just a
> flash in the pan.
This is not because users need larger size limits it is because there
are more users, and many of those users are using email improperly.
There may be many different reasons why users are using email
improperly. In your company you may find that users are sending
large emails because they need a file server, or web server, or some
other collaboration tool.
>Many people rely on email, not FTP to transfer files, and things like
> a few family portraits can easily exceed several megs in size, so
> drawing the line for all users may not be as easy as you think,
> depending on your users and your network.
People do this using their ISP accounts because this is often the only
way available to them to share files. In a business, you should be
able to provide your users with a file server, and or web server or
some other mechanism to share files. Sharing files over email is
simple but an unfair burden to your network and DASD.
>Put simply, if you were the administrator of an e-mail server, what
> would you set the maximum size of an incoming email message to be,
> and what would be the reasoning behind said limit?
I would consider setting it to 100k, but would set it to 3MB knowing
that people will still want to send spreadsheets and other
documents.
I would provide a file server, web server, or some other collaboration
tool to allow users to share documents in a far more efficient way.
I would also train users that attaching a word processor document to
an email provides no advantages to their message, it only burns disk
space and network bandwidth. I would also explain that by sending
this document to many people they have burdened every recipient of
the email with unnecessary disk use, and in some cases an unnecessary
requirement for a software package license just to read the document.
I would further explain that sending files in email can cause an
unreasonable burden on the email administration to ensure that the
files are free of viruses and that it can cause and exponential
increase in both the processing time of each email, and email server
disk space requirements. (Some of this depends on your email
implementation. You did not describe that in your question.)
Good luck.
Don't duplicate work, check out the horde project. They have an excellent file manager for web use, coded in php.
Read my plan to save the Bengals
It is very easy for those of us who own / run servers to say "Just put it on a FTP server." It is a lot harder to explain to the average user how to run a server, what servers they have access to (most people don't), what FTP programs are available, and how to explain to their recipients how to download the file.
In short, it is quite the pain in the ass for a 30% file size savings.
Short of an efficient method for transferring files directly between computers (which could be a major security issue when a connection can be initiated while the other person is away from the computer), the file has to reside somewhere to be transferred. If it sits on your FTP server, it takes up 10 megs. If it sits on your e-mail server, it takes up 13 megs. Either way, I'm not particularly impressed. Those with dial-up connections shouldn't be downloading those files, but a halfway decent connection shouldn't have a major problem.
Yes, many clients don't like downloads above a certain size. This is a shortcoming of the clients that should be overcome by their programmers, not by a rejection of those mails system wide.
Really, the hassle of putting files / documents up on an FTP server to the average user is quite, quite large compared to the simplicity of clicking the "Attach" button. Perhaps this can lead to abuses, with forwards and mails going to 20 people. These abuses should be met with auto-responding messages encouraging them to watch company resources, rather than outright rejection.
Sometimes you just need to send a 20 meg file. Who is this network working for again?
-Chris
This Sig is a mnemonic device designed to allow you to recognize this author in the future.
The size of the email limit is dependant on the job role of the person of the email account.
For example, a developer who primarily communicates with his peers in-house, and typically no one else, would only require a 5M account.
A sales/marketing person will need a much larger account because of the clients/customers they deal with. They usually have word docs/presentations coming from many resources. They are sending excel sheets and other files. Overall a sales/marketing erson will need an account the size of 25M.
I do agree with the idea that they might want to consider using a FTP account. Unforunately, those who are not techno savvy, might not like the idea, because it's something else they have to learn, and there's also te security issue involved; some individuals receive files that are not meant for others to see.
I would say look at the role of the person. Evaluate what their role is, and who they deal with often. Employees who deal with lots of clients need large email accounts, there's no way around it.
Email relies on encoding methods that can double or triple the size of an attachment, so it really isn't he best method for sending large files.
As for what other companies do, most have limits around 2 meg (some less, some a little more). If people need to transfer files within the company setup some sort of fileserver for sharing, geared toward the expertise level of your users (FTP if they have some sense, Windows/Mac shares if they don't).
If someone tries to pressure you to give them larger email size limits explain the above issues, state that it would cost the company more money and unless they have really good reason to need to send 10 meg attachments they aren't gonna get it (since it could hose your mail server in the hands of an idiot).
I guess what it is going to boil down to is the nature of your buissness, if I was System Admin for a company that used email for communications I think 1 or 2 meg would be fine with a couple exceptions for people (family portraits are a personal thing, not buissness). This is really more of a situtational judgement thing, Slasdot users can tell you what they are doing, but it could be vastly differnt from your scenerio (and using wrong advice without enough pesonal knowledge could screw ya).
My old Company didn't have a limit, one day some non-tech person from a branch accross the country sent everyone in the office a 40 meg powerpoint. It didn't really contain any information that couldn't have been put in a secure intranet.
Even on a T1 it took as all some time to download it (there were about 15 people all getting it at the same time).
In retrospect, I think 5 meg would have been a good limit (but that should depend on what your bandwidth is) if nothing else, just to protect the servers. If someone needs to send/receive a larger file, then speccial arrangements can be made.
-TheDawgLives suckitdown
At my old job, we were screwed.
We had offices with IT and web staff in New York, Ontario, California, Michigan and Florida.
Everything was firewalled.
Email attachments was limited to 1.5MB
FTP was blocked.
At the time that I left, security policies forced us to use ICQ and AOL Instant messenger to xfer files. (Real secure, huh)
Conformity is the jailer of freedom and enemy of growth. -JFK
If your infrastructure can't handle the occasional 40MB mail, fix it. Disk space is dirt cheap, so is network infrastructure. If you use imap (which is a pretty good idea), modem users do not have to download larger messages. If your mailserver is clever enough to not replicate attachments for each addressee, performance will be acceptable.
Users will just get annoyed if they can't send their powerpoint docs to other users. Most employees cost more per day then they'll use in storage space per year so don't impose restrictions with respect to file storage. 5MB is nothing today.
Jilles
We have about 180 users and our standard Exchange mailbox size limit is 90MB (soft) and 100MB (hard). Some higher ups get double that, and some really high ups and people that have jobs where they need to keep a lot of old email have none.
I couldn't imagine a 5MB limit. That's fine in a world of text only email, but not today. Too many Word/Excel/Project docs floating around. I do not limit mail attachment sizes because it has not been abused, yet.
Call me old-fashioned, but I consider 5MB to be plenty for a single e-mail message size. While there are good exceptions to this rule, I'll list the arguments in favor of a "small" max message size:
Again, some of these points means that you need to make a public webserver available for users to post things on. I would recommend a CGI that posts content and returns a key to that content (MD5 hash, perhaps). Only with the key can the user get the content. That way, your staff can upload anything of any size, and then e-mail the MD5 key to other people to let them download it. Reasonable security and relative ease. You could even have users include an expiration date so you can auto-delete stale uploads.
I always set up the "size" field, in real numbers (do you really expect a user to know what 10MB is?) so that they eventually learn about email size.
I have no quotas on email, except for the fact that we only have 2,678,837,248 bytes free on our server at this point in time.
--Mike--
Computers - Tools to let people get their jobs done.
Bit of a mixup: HP discontinued development about 18 months ago. Samsung picked it up shortly after, and announced the new Contact project a few months later.
;-)
Not sure where you get $500 from. 5 users would be about HALF that price
r.
Our solution was to create a web based file sharing system that supplements your existing email service. This system is available for internal employees as well as external employees. Its simple. If you need to send a file, you login in to the service (LDAP enabled so one password for all systems) and fill out a form with the recipients email address and then attach the file(s) you want to send. The recipient receives an email from the user and the location to pickup the file. This is all done via HTTP but we recently added support for a client side java application that will download the file via FTP transparently. Its all *extremely* user friendly.
An interesting aside is that to correctly implement 'view attachment' in a browser window and 'download attachment' to your harddrive functionality, we have to send a bogus MIME Type for the file so that IE will actually download the attachment instead of opening it in the window. (Word doc, PDF, etc.)
Another option that we explored was to use WebDAV. The issue we ran into there was that WebDAV is not supported natively under Mac OS 9 or Win 9x.
Also, was this written with .NET? Hell, no. J2EE all the way.
1;
I work in construction. Email is essential to transfer in a way the users already know how to use files, drawings, and other documents. Disk is cheap. Bandwidth is a utility cost. ftp has lost the widespread adoption battle because it's got some security issues, and frankly it's a technology that just gets in the way. The function of IT is to provide a service that people need. If you want to impose limits on what users can do, expect to be replaced sometime by a sysadmin that doesn't have those urges.
This topic is already stuffed to the gills with comments, but I like the prospect of Redundant mods.
E-mail was never intended to be a file transfer system. People need to be educated on using something like a file transfer protocol for transferring files. Makes sense, no?
I suppose I can deal with one image every so often, but I'd much rather receive a URL where I can view the picture. My university sets a quota on my Inbox. I don't need it filling up with data that is handled far better with some other application.
"I'll say it again for the logic-impaired." -- Larry Wall.
User education is a bit hard when you have 17,000 users to deal with and less then 10 staff to do it (it's a college)
The hardest part of using FTP as a solution is that it requires the recipient to have a FTP client on there machine, but that isn't the case. There are several web based FTP clients (such as web-ftp) to make it simpler for everyone to place files on a FTP server.
I think even 5MB limit is too large, especially if you are on dial-up (I hate it when someone sends me a 2MB movie...)
What, me worry?
I am the administrator of an e-mail server. Our limit is 5Mb. I found that to be a reasonable elbow in the curve between most of our trafic by message count (e.g. Things like "I'm running late...could you hold off processing xxxx for me?" and "No.") and the majority by size (e.g. "Here's a copy of that set of porn CDs I stole"). It only affects legitimate bussiness trafic about once a year (we don't use MS Office, etc.) and it cuts our total storage volume by about 80%.
-- MarkusQ
Goto their website and punch in the numbers.
Hang on. It's actually THREE times the price.
MS Small Business Server with the standard 5 CALs costs $1500 (or $1200 if you're nice to MS), with no rights to upgrades and only two support "incidents".
If I "punch in the numbers", Samsung Contact with 5 mailboxes costs $416.51, including one year's 24x7 support and upgrade rights ("maintenance"). (It's $520.64 if you also want to buy the optional Samsung Clients.)
r.
Comment removed based on user account deletion
Very simple to do - all modern browsers I can think of support file upload now. Then when someone logs in, they tag who the file is for, upload the file(s), and the system can then automatically send an email notification to the recipient. With a download link, even. Gosh. How high-tech is that?
Why is this so fucking hard, people? Jesus!
And if you want a really _cool_ geeky solution, go with 'sendfile' (an implementation of the SAFT protocol) - the file transfer solution that should've taken off like a rocket but didn't. *sigh*
Correct me if I'm wrong on this one, but isn't AOL is the only e-mail service used predominantly by consumers that doesn't have a low space limit.
No TiVo and no caffeine make me something something...
It's nice for all of us as geeks to say "make the users use FTP" (though frankly, I'd prefer scp or nothing), but it isn't practical.
I work in a not-for-profit that publishes a weekly journal, so we are both "an academic environment" (we operate somewhat like a unversity), and a good-size for-profit company. To that end, the requirements of our user community are very different.
We used to traffic a lot of paper and film via FedEx and couriers, and moving all that processing to electronic mediums saves us over $300k/year. I should know, I had a big hand in implementing our digital workflow (why do you think they bought me an Aibo?). Our technology spending isn't any more than it was when everything was paper based, but our saving have been huge.
We use Groupwise for corporate email, and the post offices live on a SAN virtual disk. Our SAN has over 2TB in storage, Netware lets you concat volume segments dynamically, and Groupwise only stores a message once in the database and passes pointers to each internal recipient. So storing large attachments is very efficient, and enlarging the post offices is trivial. Our SAN is only 33% populated, and smaller drives (75GB) can be replaced on the fly with larger drives (180GB) and the array will resize and rebuild itself hot.
So we have no inbound or outbound attachment limit, though we do keep an eye on things to make sure people don't go nuts. We just upgraded our servers last weekend after 2 1/2 years in service, despite our post offices growing by a factor of 10. Having administered Exchange, Notes, and Groupwise, I think we've got the best of the three groupware packages, and our users are happy enough (they would be happy, but who is every happy at the phone company because they have a dial tone?)
In three years, we did turn up our bandwidth from (2) T-1s to a 6mbt fractional DS-3, but email only accounts for a small portion of that traffic (we host half a dozen more websites than we used to).
The largest attachment I ever emailed was probably 100MB, and I honestly find 5MB limits to be draconian. We have an FTP drop, but our vendors won't use it. Last month, I had to email a vendor a dat tape with 13MB of data because they have a 5MB attachment limit. Sick.
"All I ever wanted was to see Larry Wall give Bill Gates a Perl necklace."
http://www.eisenschmidt.org/jweisen
I work at an ISP and we have a limit of 5 Megs.
The problem is, other isps in our area have a limit of 2, 5, and 20 Megs. I too personally hate receiving anything over 1Mb, yet some of our dialup customers consistantly receive files 3-5Mbs and it takes some time for them to receive them. I am a purist, so whenever I get a call regarding email, my first response is to tell the customer to go into their Webmail which we offer as a supplement to pop & imap and DELETE the offending message. We also have a 20Mb limit on the server per account. ARGHH!! just mod me as underrated because this topic causes me grief. Why don't people just use FTP? It STANDS for file transfer protocol! USE IT!! I say everybody goes back to shell accounts over dialup. Broadband pisses me off.
end of bitching. thanks for listening.
ignore this nonsense rant
HURD - Hurd's Under Research & Development
We've got a 10MB limit on attachments at our corporation, which seldom is the real hassle -- it's the 50MB TOTAL e-mail space on the server. So if you get several big attachments over the weekend, and you haven't emptied the Recycle and Sent folders lately, you may find that you can't reply to messages until you clean out some of the trash.
It gets worse -- at 100MB, you can not receive mail at all. Many has been the time I've wanted to send 100 1MB files to the twelfth bozo who forgot not to "Reply to All" when telling some other bozo not to "Reply to All" on a mass mailing.
Design for Use, not Construction!
If it's intranet email, this won't be a consideration, but for internet email, you have to consider that many of the mail routers that the mail hops through are still running sendmail or something similar, and can't handle files larger than 10 mb. If it's an intranet, and you're using IIS/Exchange, it's not a problem.
i am comfortable with my ability to handle any administration problems that might arise from implementing a very large mail limit. anything larger than a CD-ROM in size is too large though. i won't go past that.
-- Betting on the survival of the media industry is a serious risk. I advise investing elsewhere.
Bad worker, no cookie.
Phredd.
Phredd - "I have found people tend to take you far less seriously once you start waving your genitals at them..."
Do you realize how easy it is to take down a Mail server with no message size limits.... You can fill up even the largest of Raid array's in minutes, 50Mb messages times number of users! People are worried about DDOS, Well can you imagine if someone with a spam mailing list attached 100MB files to each out going email. Oh boy! And the poor admin in he has made the mistake of having the mail spool on the same mount point as the /var/log most boxes will drop quickly 1)Mail can't write, 2)Box complains and trys to log it, then goes right nut's until a kernel panic because it can't write log's...
If you use OGG Vorbis to encode your music? ;-)
That's strange - it seems to work just fine as that! I don't know of any sysadmin who's setup can be brought down by a large email attachment - maybe it's the sysadmin who needs the training? Of course ftp/ssh and http/ssl are secure - but are you really advocating setting up a username and password for everyone who ever needs to send you a file? Or that they need to install additional client software to do it? Here's the tech support results: email - 0, ftp/ssh 1.disk is cheap, bandwidth is a utility
I set up an 11MB quota for each of our 4000 users. But I allow a larger attachment and you have a 5day grace period to delete mail. So each user can receive up to a 20 MB attachment and as long and they download and delete it off the server they will still receive their email.
Before I set up the enforcement of the attachment size I had a teacher try to email an audio recording of her class to her supervisor. It was a 44.1KHz stereo AIFF file and it was an hour long, so it was around 640MB. Who needs napster when you have email! Most users are pretty good, but we have around 1% that are constantly over quota.
-- Chris Martin, System Administrator
You know, I was just thinking how much useless email gets generated when you mix together average Joe corporate users and applications such as Outlook.
and other egregious examples.If only Outlook could be retro-fitted with a stupidity governor that would nudge users towards making efficient use of their IT infrastructure, rather than just blundering along doing ugly things just because
I'd like to see Outbound Outlook filters that would solve these problems close to the source.
[Sorry for the Dilbertesque rant. Too much sugar, I guess.]"Provided by the management for your protection."
Someone should write a plugin that intercepts the user's click on Attach File or gives another button for it then lets the user select the file, etc. Behind the scenes the plugin uploads the file to the company intranet or ftp site and slips a link to it in the email. At the far end when the user clicks Download Attachment or whatever the plugin grabs the file off the ftp server. Make it easy for a sysadmin to configure and distribute remotely or with a self-installing file he can send to users. No more huge email attachments.
Stop the Slashdot Effect! Don't read the articles!
ftp may be insecure but so is email. also, email goes across so many channels that it's more likely to be intercepted.
i am a happy linux user, but... as your users most likely demand windows (or at least use it at home) turn off "web-based ftp" in internet explorer and your users will be very happy; the only difference from normal usage is that they'll have to right-click and press "copy to folder" because copy-paste doesn't work right.
It's about bandwidth and time. If you have a dodgy connection, then downloading a file of size N may screw up with a probability P of *approximately* 1 - exp(-Nl) where l measures the dodginess of the connection. As POP has no resume, the number of times the file has to be downloaded on average is 1/(1-P), and so the time spent downloading it is: O(N/(1-(1-exp(-Nl)))) = O(N/exp(-Nl))=O(N exp(Nl)), ie it is *exponential* in the size of the file. Even for people on reasonably stable connections, very large files mean trouble unless they know how to delete them without downloading. Don't do it!
Free Java games for your phone: Tontie, Sokoban
Take the concept of "bursting" bandwidth to the email box. Allow your email box to have a 20 meg limit, but only for 20 minutes while your granny sends you that video of her vacation to Hawaii, and then you drop back down to the 5 meg limit.
"Your superior intellect is no match for our puny weapons!"
For my servers I imposed a 10MB limit. Which came
out to around 7.7MB of data before encoding. There
were some points where people wanted to send large
attachments. I would point them to my MRTG graphs and say: "You realize you want to send 1 message that is larger in size, then the REST OF THE COMPANY AS A WHOLE SENDS IN EMAIL IN a 24 HOUR PERIOD?". I mean that is excessive, if you have 50 employees and one of them sends a single message that generates more traffic then everyone else combined for the full day. I imposed a 200MB quota on them(hard quota). There was never any real complaints, it was easy to explain to them what the problem was. If they didn't understand I just said "just forget it, you can try to send files all day long and they won't go through, don't like it? tough". But that only happened once or twice. Was I an asshole? probably.
I also setup a restrictive FTP server, where customers could login anonymously, upload files, then the employees would login using the 'ftpadmin' account, and download the files(the FTP server restricted directory listings at the server level, so every directory showed as having no files or directories, also the incoming directory prevented downloads as anonymous and the outgoing directory prevented uploads as anonymous). If the employee wanted to post a file for a customer, they would use the ftpadmin account, and upload the file to the outgoing directory, then email a link ftp://ftpserver2.company.com/outgoing/file,
no special authentication, all anonymous. It was real easy. and unless you knew the EXACT path and EXACT name of the file nobody else could get to it. It worked extremely well.
my main issue was with backups though. the IT group was more then happy to make 150GB of space available for people to store their porn, their mp3s, their whatever. But it was not going to be on an expensive raid array that is backedup everynight. it would be on a few IDE disks on a server and they were made aware if this goes down, then its gone. they didn't care, they just wanted temporary storage, and they got it. for the longest time some of the backup tapes were backing up really stupid things like mp3s and games and stuff which didn't need backing up, took away from the things that DID need backing up.
and as others have pointed out, computers are there to help people get their work done. That includes the IT group, who should not have to be called upon because some dipshit decided to email a ton of data which then clogs the WAN pipes and slows the network down for EVERYONE.
If they really wanted to they can always split the file up, but nobody ever did that enough for us to notice. even my home network, which I have unlimited bandwidth I restrict to 10mb emails, I rarely get an email larger then 80kb.
I work as a corporate researcher in an advertising agency. For the work I do, it is simply unacceptable to have a 5Mb limit. Putting together reference documentation for a major project, project materials and so forth often have many files that are all above this size. Often these all need commentary as to what they are, what page/file you need to go to and so forth.
Asking me to waste my time going back and forth between loading it up on a server, writing commentary on where you need to go in which file to get the key info in an email, making sure that whoever is recieving the mail can get access the server, etc., is simply not a good use of my time. It would also be confusing to the people recieving my research - they often have a hard enough time with simple attachments.
You can go on about what is the "right" way to do things but in terms of my company's bottom line, it is cheaper to use email and deal with the bandwidth issue than for me and the people I do research for to waste our time.
We don't live in an ideal world, and human factor efficienies are often more important than machine efficiencies. Enough said.
Hi,
If you insist on limiting the mail-size you should set up a ftp dropbox for every user and provide them with a URL to that they can include into their standard signature.
They can tell their mail contacts just to click on that URL and put their stuff there.
Works on most plattforms with most browsers for most of the poeple. However, they know email, they are used to it and it doesn't impose any additional harm. So give them email.
k2r
Now accordingly, there are still people using dialup connections - in fact, the real problem that's causing broadband to have a hard time catching on is the affordability. As such, if you email J. Random Home User a 3 MB file, and he's on a 28.8 modem, it's going to take him 15-20 minutes of download time. That ties up what little bandwith he has, while the broadband/T1/OC3/whatever user pushes a button and watches it go out almost instantaneously. In short, it's just plain inconsiderate, but it could be owing to an error in judgement.
So what to do? Like another user suggested, make an FTP site available. It's old fashioned, but the net still uses FTP very heavily - it's a great way to move files around. It's not as "easy" as attaching a file to a message and letting it go, but it's a lot more efficient, and hasn't that what this has always been about?
This sig no verb.
- email wasn't designed for files So why was UUENCODE and UUDECODE, then later MIME created? It wasn't invented by Microsoft for use in Outlook!
- It's too much disk usage, it'll bring your mail server down So size your mail server according to your projected users needs. You did do a needs analysis before submitting your budget, didn't you?
- It hurts people on dial up Why would you treat every user the same? Remember the needs analysis you did?
- Too much bandwidth usage! if you can't afford it, put limits
- use ftp instead do you really think the sales managers and Project managers want to get You to set up an account for every person they deal with who needs to send them documents? No matter when they need them?
- ftp is secure over ssh so you're going to produce documentation for each user on how to use this new software they have to download? "I need to send you a 2Mb file!" "No can do, let me contact our sysadmin on monday so he can set up an account and tell you what software to download to accomplish this". Please.
- no compromise can be reached! plenty of folks here set 650Mb attachment limits. Know how they can do that? They know their systems, and did capacity planning, they've come up with limits they can handle that work for the users. Often they have different limits for different users
email attachments are here to stay, they replace physical media, and get us closer to the paperless office. The inventors of MIME didn't consider it a gross abuse of the medium, why should you?I tried to explain to my business unit manager-boss what the problem was, why, and that the FTP-like file service we had for just that reason was the way to send files
He agreed with every point I made, that I was technically correct. He then pointed out that it didn't matter. The users were going to damn well use their email the way they wanted to, they had sound business reasons _for_ sending/keeping large files. He also implied that IT was there to serve the users and we'd better keep up.
I miss that job, sometimes.
(Go to Menu: Tools>Options>Incoming Mail: [x] Skip Messages over [80] K in size)
If something bigger, or with a bigger attachment, comes in, I just get a synthesized message with the headers and front part, giving me a choice whether to retrieve the whole thing.
This way, normal small stuff comes in quickly and your line is not tied up by some idiot spam movie attachment making normal messages wait until that is downloaded (or worse: when the line drops due to time limits and you can't get past it by trying again).
I saw people sending out their whole mp3 collections in 30 meg-sized mails, I saw others suffer from 5 megs holiday pics in their mailboxes accessed by humble 56k modems and having to give them a POP3 primer on the phone to have them delete that stuff ... Yes, mail isn't ment for big files, and besides this orthodox opinion, it still isn't very practical to send huge files per mail.
I would go for the send-links-in-mails-to-files-on-{web,file}servers idea, maybe protected through SSL, temporary passwords and having the files auto-deleted after three days or when having been fullydownloaded one or two times or whatever... (Proposing some minor access security for the files being made available, I wonder how many of these suits 'needing' unlimited mail sizes protect their files when sent by mail? I have never seen a single member of this demandish breed (being subject to this publication) being able to handle PGP/GnuPG/whatever, they often consider that as another evil trick by notorious sysadmins, since security measures hinder them in doing their work properly, just as mail size limits do... So much for ranting :)
>It would be nice if the SMTP server simply
>forwarded the text of the message and replaced
>the attachment(s) with a list of
>filenames/sizes and URL(s) that the receiver
>could download the files from.
This is a silly suggestion - such a thing must already exist? (I just can't find it with google)
s.
it is an insane mess.
For those sites that have incoming e-mail size limits (which usually seem to be 2MB or 10MB) we recommend users compress and/or split up their large attachment files - some mail servers will automatically re-combine the split messages when they are received (otherwise the recipients of the e-mail would need access to the utilities to do this). There are numerous free and shareware utilities to do this for just about any OS. This is a lot less hassle than using FTP or even a web server to distribute/receive such files.
50 Megs should work.
Its big enough not to hinder productivity, and 50MB isnt too much that will break the server.
I figure, anyone transferring files above 50M will not complain when it comes back to them. They will realize they need a different way to move the files.
Most people don't know how, or why, to turn it on. When it is turned on, most people don't know what the size unites represent - b, K, M.
A bit more education is required.
Yay me!
There should be no limit. Or maybe something safe like 1Gbytes.
Computers are supposed to make our lives easier.
I routinely move large books (10s of Mbytes) and movies (100s of Mbytes) around, both for work and for entertainment. Email is much friendlier for us humans than ftp or scp.
Yes, that's a lot of bytes. Some things will break (like slow dialup lines).
Fix the computers, not the humans.
yEnc has shown widespread acceptance in Usenet, I'd like to see it used as the de-facto format for SMTP mail. Electronic mail's "push" nature makes it extremely useful where FTP/HTTP is not (although IRC DCC is) and I'd enjoy having the pleasure of subscribing to mailing lists which send out multimedia or other forms of large content and having it delivered, just like postal mail, right to my desktop or a nearby ISP mail server. Who is with me?
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
This eventually lead to spammers sending viruses--and several groups, Owners Protection, Anti-Spam, etc. where created to blacklist spammers those users. A guy I worked with registered a new Audiogalaxy account every couple months in order to map user ID numbers (which where numerically sequential) into a ballpark figure of the date in which the user registered, and you had to be an Audiogalaxy member for a few months to get into certain groups. This was all to prevent spammers sending unsoliciated music to the entire group, but all-in-all the "group" philosophy of Audiogalaxy was one-of-a-kind. It was wonderful.
(Michael--the owner of AG--was working on limiting which members could send files to the groups, but he never got around to it before the demise from the RIAA. Of course, AG group's analogy in this case--mailing lists--,which I'm sure you are aware, can have sending restricted to certain users, thus avoiding spam. Spam is now irrelevant, I only mention it as a footnote in Audiogalaxy history.)
Not only could you join groups to have the owners share their favorite albums (often, sometimes compilations) with you, you could join so-called "free-send" groups where anyone could send anyone any file. That was kinda neat, if you had a nice song you could send it to the group and see what others thunk, especially if you're the one that recorded it. I learned about plenty of independent musicians this way.
And the perhaps most important thing that came out of Audiogalaxy's groups is: you got 0-day. Before The Eminem Show came out, I vividly remember hundreds, even thousands of fellow fans joining, eagarly waiting for the album to come out. When it dropped, members of our sending group got it first. I left my satellite on 24/7, and it starting downloaded immediately within hours of its release. I was amazed. Audiogalaxy has beaten IRC. No other P2P technology has shined so well in this regard, in fact, P2P is often now looked upon as a place to get old stuff, not 0-day.
That's not to say there is no room for improvements. On the contrary, there are plenty of improvements which could be made on the old SMTP protocol. Audiogalaxy, being peer-to-peer, was smart enough to download from other peers once they picked up the file, alleviating uploading from the original sender. This meant someone with connections but a 56K modem could leak The Eminem Show to an AG group, and it would be sent to a couple people. Those people would then be sharing it for others. Eventually, the entire group had it! And this is what was intended; if you didn't want the CD you didn't join that group. (Joining and leaving groups was easy).
Didn't mean to write a book there, but I hope I proved my point. Push technology is kick-ass. Forget your silly pull FTP and HTTP! Its good, but I want to subscribe to a warez mailing list, and get warez when it comes out. I have a fast enough connection, I laugh at all those sysadmins who say their servers can't handle >5MB attachments. Mine can, and the warez community will be able to, without a trace of a doubt.
As aside, the NNTP protocol behind Usenet seems to be similar to Audiogalaxy groups, but not similar enough. The peers are not individual users but individual dedicated servers. Usenet is also way too uncontrolled, even with moderators. I'd prefer SMTP mailing lists. Now we just need to find a way to make SMTP attachments be distributed over willing users...hey look! Bit Torrent!.
Warez by mail. You heard it here first. (Note that although warez has a negative connotation, especially legally, it is a big sucker of bandwidth. And once warez pioneers the P2P email, the world of legal uses will follow!)
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
Everywhere I've seen yEnc used, I've also seen vicious flamewars about its use. Many people are of the opinion that yEnc needed more "thinking time" before actually being released into use. (It was the work of one person, and I believe there were problems with the "1.0" version of the "standard"). Also, not all newsreaders / browsers support it yet.
David.
Not all newsreaders or browsers support yEnc yet, but Forte Agent does, and your newsreader should too. There is even a plug-in for Outlook Express. If worst comes to worse, one can always manually yDecode the file using YDEC.EXE.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
I saw a few posts about concerns over using FTP for sharing files. I completely agree with those people. FTP is far too in-secure. I would rather use scp or sftp. But we use a better solution. We have WebDAV server with https:// (secured http) and LDAP authentication. The user just copies the files to a WebDAV location, using WebFolders and send the URL in the email. I also developed a application to keep track of who is accessing files etc. All this using Apache - not a single cent to buy any file sharing application. For more info: http://www.webdav.org or http://www.tldp.org/HOWTO/Apache-WebDAV-LDAP-HOWTO /
BTW all 3 major OSes (Linux, MacOS X, Windows) now support WebDAV natively
Consensus is good, but informed dictatorship is better
my isp set the limit at 10megs, which I think is perfectly acceptable. The only files I receive that approach that size are mp3s of friend's music who for some reason can't send the files in an IM program.
GoatPigSheep, the 3 most important food groups
Its problems are listed here.
Its got all the problems that show up when someone tries to invent something without doing the research 1st.
It's a good thing that you posted as an AC. Get an education and a life, dork.
Check out Efisto if you are interested in providing your users with an easy-to-use solution to sending files. The project is still in its early stages but already quite useful. Basically, you upload a file onto your personal space on a server via a special client and then tell the server to send these files to your recipient. The server will then generate a unique session id and email a link to that session in the server to the recipient. Meanwhile the server readies a .zip-file that the user can download from the server using the link that was sent to him.
We have a 50 Megabyte limit with a corporate
ftp server for larger. The design personel
send lots of files up to that limit.
I know this is crazy, but I see a lot of people giving the excuse that I need a higher limit for emailing files. Are these people asking for the bigger email size and not realizing that if it is sent over the internet most people will not be able receive them? The receiving mail systems or the ISP's mail system does not allow for a hugh email size for an email message.
I think it is really crazy that people use Email to act as a replacement for FTP/SCP/DCC and other file transport protocols. If the excuse is that users can't use those protocols, then maybe a webserver accepting the file should be used in place of email. Post the file to a webserver page and then direct users to the page to download it for their use. Or if the files are to be used for within the intranet then use a shared drive.
Email has work fine for many years without the dumb user forcing a greater size for emails. I think it is time to go back to basics. Remember KISS? How does the attachment in the email follow this? It makes more problems; i.e. I can send Joe User some file with an extension he can't use because he does not have the application.
I can give more examples if you need them. I was an email administrator for a quite naive company.
I think there are two simple questions to ask:
.doc, .xls...) or for fun (.swf, .exe, .jpg...).
(1) What kind of attachments are the complainees sending/receiving (and are they work related);
and also, (2) how many users are we talking about here. I only ask the second question because I have worked at places with as many as 200 employees, and the SysAdmins had no trouble maintaining custom size limits per user (of course, there was a 5MB default) depending on job duties (does the job require the transmission of large attachments?).
But the first question is the most important whether you maintain user limits individually, in in groups, or overall. I would first investigate what the large attachments coming in and going out really are. Are they work-related (.pdf,
I would also make the recommendation that all e-mail be sent in text format only. HTML e-mails are on "needed" by SPAMmers, not by professional business people. As the webmaster at a mid-sized biotech firm, I successfully proposed and wrote the draft for a company-wide e-mail style guide, and text-only format was a requirement. The SysAdmins predicted improvements in bandwidth and the Marketing dept. agreed that text-only was more professional, compatible with all e-mail clients in all countries, and that HTML e-mails were inconsistently "designed" (font size, color, type, etc.) and from some individuals, sometimes tacky!
The other thing to investigate is whether the e-mails w/ large attachments are between members of the LAN? If so, they should utilitze a file-server instead of clogging up the e-mail server. Or, if the majority of the computers have ZIP drives or some other removable storage format, there is no reason one cannot walk that disk across the office.
Companies should not have to spend lots of money and time on e-mail servers. Dealing with SPAM, hack attacks, and wrong e-mail addresses is work enough.
This may only apply to ISPs, but I think that higher levels of service should also allow bigger attachments. 2MB on the low end, 5MB on the high end.
Does anyone know of a situation where the SMTP server has been set up to replace the offending attachment with at link to the files location on a FTP/HTTP server?
An old argument to be sure, but email attachments are bigger than they ought to be because of the MIME band-aid protocol. Perhaps someone (read: not me) should draft a new mail transfer protocol that doesn't require binary files be converted into ASCII at a tremendous use of CPU and bandwidth. my2c
The educational institution where i work has a fairly good system. There is no official limit, but as your mailbox grows, so do the consequences.
) , but the source and specs for the server are freely available, as are the clients.
After 10 megs, you get a message asking you to remove stuff whenever you sign on.
After 50 megs, the message appears whenever you send or receive a message.
After 100 megs, you will continue to receive messages, but you won't be able to send any until you drop below 100 again.
There are approximately 5000 people here, and as of 1998, around 250,000 messages were sent every day. I haven't seen any more recent stats than that, but I'm sure it has increased. It's a homegrown system ( http://www.dartmouth.edu/pages/softdev/blitz.html
Plain text is the simplest format - but it can not handle bolding &c. On the other hand, html handles bolding and cross-reference, but can come with all sorts of nasties.
Even delicate formatting does not chew up a lot of space: TeX is a classic example of delicate formatting + small size.
The problem is that we have bloated formats, that not only preserve the document, but the user's printer and last view of it.
We have all sorts of fun trying to print documents sent to us by users who printed to a bypass tray last! [word preserves that information].
A limit gets people into thinking about small file formats, prehaps. At least not using excessive ransom fonts &c.
But if a megabyte stores only four documents where it used to store 40, then this is going to increase storage. Some storage and pipe issues have been addressed: faster, bigger drives, faster networking. But some remain stuck where it was 10 years ago: dial-up modems and floppy disks.
I suppose that it is as much the fault of the software manufacturers problem, since their bloated formats (with no option to make it smaller), is crushing the infrastructure.
OS/2 - because choice is a terrible thing to waste.
I don't understandy why comments here keep insisting that FTP is "difficult" to use.
Correctly configured under Windows (or even something like KDE), the end-used experience of accessing an FTP site is no different than accessing a local folder. Under Windows, you can even map an FTP site to a drive letter, with everything handled transparently in the background.
It really is incredibly simple once set up. You can drag and drop you can access an FTP site in a way no different than accessing a disk drive or a local network folder. If users can figure out how to copy files to and from a floppy, they can use it.
My suggestion: Keep the 5MB email limit and implement the FTP drop-box solution for those that need it (perhaps with several folders that are purged every 1/5/10/30 days).