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?
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
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
- 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
Do you offer "less-skilled" employees an easy tool to upload large files to a web site and assign an individual password for that file (perhaps even with a form to indicate the email address to send the file info to)?
-- http://www.MarkWelch.com/ Pleasanton California
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.
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
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.
Think 100MB PowerPoint files: the sales team slings these around like mashed potatoes.
:D), etc. Put a link to the file on the network in the email and don't choke the mail server by attaching anything over 5MB.
This can be fixed by using shared network drives per department. Give marketing their own directory. Give QA their own directory (give IT their own UT2003 server
Better yet, cap it at 5MB and force them to use the other resources.
While I've never personally worked at a place so draconain that they monitor email to ensure its all business-related, every employer has the right to monitor email and network resources to ensure they're not abused.
The point being, teach the employees an alternate method to transfer large files and enforce it. From CEO on down.
Cruising the internet on my TI-99/4A @ a whopping 300 baud!
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.
- 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?Also, there are cases in which only an e-mail will have the desired functionality.
Consider the following scenario: you are sending an e-mail with an attachment to a salesperson for your company. They leave their laptop connected to their docking station until they are ready to go, and Outlook auto-checks for new mail every five minutes. They get your e-mail, along with 50 others right as they are heading for a plane. They don't read the e-mails, assuming they can read them on the plane. If the 7 meg powerpoint file with vital revisions is attached, they have it to go over on the plane. If you linked to an ftp site, perhaps they can attempt to download it using those phones on the airplane.
Large e-mail attachments occasionally have usefulness besides being easier for Luddites to use. Occasionally, they are the appropriate tool for the job. Review the e-mails with large attachments being sent. Educate users that send large e-mails when inappropriate. For your job's sake, double the e-mail size limits for your boss on up.