E-Mail Size Limits? 268
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?
Email size (Score:5, Interesting)
Sounds pretty good (Score:5, Interesting)
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.
Re:Sounds pretty good (Score:5, Interesting)
Re:Sounds pretty good (Score:5, Insightful)
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)?
Re:Sounds pretty good (Score:5, Funny)
The problem with saying "put larger files on a web site or ftp site" is that most people can't figure out how to do that properly, or if they do it, they make the file visible to ANYONE (including search engines) so that confidential data might be lost.
Right! Luckily, e-mail is highly secure.
Re:Sounds pretty good (Score:2, Funny)
Re:Sounds pretty good (Score:5, Interesting)
I'd also like to note that Microsoft is planning to possibly remove access to attachments in Outlook altogether [microsoft.com], quite probably due to all the bad press about their piss-poor handling of insecure (or "Level 1") attachments.
So what we have is not only a problem where many mail servers will continue to refuse messages greater than 5MB in size, we also have issues with many e-mail providers (HotMail, Yahoo, Softhome, etc.) restricting people to 5MB TOTAL mailbox size, with dial-up users cursing you out for sending them a 45 minute download (they COULD use something that previews the messages on the server and prune the big ones before downloading, but hey ... ), and with umpteen tens of thousands of viruses/worms/trojans that are perpetually mis-handled by retarded mail clients, and more and more companies, ISPs, etc. either virus scanning, removing potentially harmful, or flat-out removing access to all attachments on incoming and/or outgoing mail (for virus and security / confidentiality reasons).
It's very rare that I send an attachment that can't be embedded in the e-mail itself (a .DOC file that could be copy/pasted) or linked to from a webserver (even GeoCities or something would be easy enough - that's point and shoot, and many free web hosting companies virus scan uploads for you anyways).
Re:Sounds pretty good (Score:2)
Now take the next step and encrypt the e-mail and you've got an approach that can really be used for moderately important data.
Re:Sounds pretty good (Score:3, Interesting)
Don't forget the concept of "training" and online help.
Even the most clueless can handle this concept.
There are MANY methods to prevent search engines from indexing
drop boxes including password access to the dropbox directory / ssl, etc. Again, a bogus argument. Search the net for more info.
Re:Sounds pretty good (Score:2)
I've tried to get access to my corporate computer (winNT.. not by choice) and have failed miserably. I've tried the company ftp sites and they don't accept my username/password despite following the sysadmin's instructions completely... I get locked out after 3 attempts.
Attaching my files to an email and then saving that email as a draft is the only way I have found I can get my work files to my remote/home site. If the ftp worked for me, I'd certainly be using it.
Re:Sounds pretty good (Score:2)
It might be easier (for the sender) to provide a link to a page on the corporations web site so a sender can upload a file over http.
Re:Sounds pretty good (Score:2)
Size limits ARE needed (Score:5, Interesting)
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.
education is the only way (Score:5, Insightful)
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.
Re:education is the only way (Score:3, Interesting)
At my work, nobody explained to the users why they shouldn't send large e-mails, and a limit wasn't set. Of course, there was they day when a chain letter involving a fairly large image file showed up, and everybody sent it to everybody else. The amount of space the individual copies of this chain letter took up on our server's hard drive grew exponentially until the partition the mail was stored on filled up, and mail services shut down because there was no room to fit incoming mail.
Explain to users this danger and show them some method of breaking files up or transferring them in other ways. In my experience, you have to either by extremely prodigious or extremely unprofessional to create a standard office document that exceeds 5meg.
Re:Size limits ARE needed (Score:3, Interesting)
In exchange, if one person sends everybody in the company on the exchange server a 20 meg email, the usage of the store is only 20 megs. The feature of being able to access the same account at the same time w/o locks and use the different connections (outlook, imap via moz, webmail) to maniuplate the mailbox at the same time is VERY sweet.
Re:Size limits ARE needed (Score:2)
Your usage may be fixed by checking your IMC Settings and running an offline defrag of the private store. It is well documented that in Exchange 5.5, a 1 meg email receieved by the IMC can cause the private store to jump to 1 gig. The DB Archetecture Sucks, but what the software does with the db blows just about everything else out of the water.... for now.
Re:"a good email storage/access system such as ex. (Score:2)
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?
Re:"a good email storage/access system such as ex. (Score:2)
Re:Size limits ARE needed (Score:3, Funny)
A couple of years ago, email in my wife's department ground to a halt when a departing administrator sent out this (paraphrased) message:
And he attaches a 7 meg MP3 and sends the message to 300 people....
Re:Size limits ARE needed (Score:2)
Ian
Re:Size limits ARE needed (Score:3, Interesting)
Re:Size limits ARE needed (Score:3, Informative)
In most sane email servers, a 10MB attachment sent to 200 people would take up ... 10MB plus pointers. What are you using?
$size_of_mail_disk / $number_of_users (Score:2, Insightful)
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.
Re:$size_of_mail_disk / $number_of_users (Score:2)
That is a number that would be unique to your business needs and resources (money, equipment, software, bandwidth, etc.)
I can help for $some_large_number / hour consulting...
It really depends on the industry.. (Score:2)
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.
Education instead of cushioning. (Score:4, Insightful)
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.
Re:Education instead of cushioning. (Score:2)
I've mostly thought of Emails as an electronic equivalent to a post-it note rather than a more formal publication, the goal is communicating, not publishing
Re:Education instead of cushioning. (Score:2)
Possible symptoms;
Re:Education instead of cushioning. (Score:2)
Re:Education instead of cushioning. (Score:2)
From a user perspective, FTP, SMTP, POP/IMAP are all basically the same: how to pass a message from one person to another. FTP deals with messages called "files" between machines. Email deals with messages call "mail" between users.
Who's to say this can't be generalized into a generic message queue architecture over which both email and file transfers can occur? All you need is some generic headers a binary chunk. After that, who the hell cares if it is email or a file or anything else. Come to think of it, a generic message passing architecture like this could help distribute load, because just like email, where your message is really handed down through several servers, the ftp file could be "handed down" instead of passing in a direct client-server manner, hammering the FTP source.
Re:Education instead of cushioning. (Score:3, Interesting)
I work for a small ISP (mostly dialup, a few ADSL). Incoming limit for email is, I believe, 8MB, which I think works out to 5MB for a binary file when encoded. (Feel free to correct me, people.) We have more than a few business customers on dialup, and every now and then we'll get a secretary calling up asking why the quarterly report got rejected by our mail server. The answer, of course, is that it's a 10MB Excel spreadsheet, it's too big, and our mail server refused it.
Email Is Not How You Transfer Large Files, Especially Over Dialup: It takes forever, people use crappy modems (I *hate* hearing the words "ess emm fifty-six") that get disconnected in the middle of a download, and there's no way for them to start where they left off. *Plus*, inna meantime their other email, which is inevitably of the highest importance, is sitting behind said quarterly report, and they can't get at it.
FTP or HTTP, by contrast, combined w/a download manager of some description, would be great. (I was going to moan about how I'd love a Windows version of the insanely great wget, but hey! turns out there is one [interlog.com]...sweet!) It would be The Right Thing, it wouldn't hold up their email, and you'd be able to resume if you were disconnected.
I agree that teaching the user is also The Right Thing, and I try to do so when I can. But -- I'm thinking about one customer in particular; I haven't had to talk to her in a while, but she's a good example -- how do I explain this to someone who just wants the frigging report, and to whom it's obvious that her ISP is only standing in her way, and is pissed off as a result?
Part of the problem, I'll admit, is that we don't have a ready alternative right now to hand her: we don't offer FTP space at the moment for our users. I'd love it if we had the intranet-/internet-facing FTP + Samba space mentioned in a post above, but that's not going to happen anytime soon. (Though now that I think of it, it would be easy to set up some space and just tell people about it when they need it; give them access for, say, 24 hours, then kill the account. Hm...)
I'm asking for help on this, not throwing up my hands and giving up. I've figured out the Right (quickest) way to talk people through setting up a dialup connection, or changing their modem settings, or getting the information from them I need to figure out what's wrong. But I haven't been able to figure out how to explain Email + Multi-Megabyte Attachments + Dialup == Bad yet. How do you guys do it?
Re:Education instead of cushioning. (Score:3, Insightful)
You have the misconception that email is for small transfers, while FTP/HTTP is for large transfers. That is like saying that post is for small letters and shopping malls are for parcels.
The fact is, these protocols fulfil distinctly different roles; they don't just cater for different sizes. Email is for unidirectional interpersonal communication, period. IM (ICQ, AIM, IRC) is for one-on-one or group bidirectional interpersonal communication. FTP is for distribution and receipt of arbitrary data of a non-personal nature. HTTP is primarily intended for distribution of data in a content-sensitive fashion.
FTP is a lousy way to send a spreadsheet to someone. First I have to put it on an FTP site, set the permissions to allow access to the correct people (only), and then mail them with the address/path/document name and login/password. I can't do this unless I have a FTP server which I can configure AND is only 24/7 (i.e. not possible from a normal dial-up account).
SMTP is, in fact, meant to assist in dealing with transfers of this nature. I send the mail to my ISP's SMTP server, a transfer which can proceed at the full bandwidth of my dial-up line. That SMTP server transfers the data to the recipient's SMTP server as load and bandwidth allows. The recipient can then download the information, again at his/her full bandwidth. As opposed to a bandwidth constrained intercontinental transfer of a 10Mb file at 1k/sec. Which is a bitch.
The real problem here is not the users, but the infrastructure. Quite simply we need a parcel service to augment the postal service, which can't handle large parcels really well. In Internet terms that means some facility to add connection retraining / resume between clients and servers, and between servers and servers, in the SMTP network. It would also be beneficial to allocate a "small" and "large" mailbox to every user (and parcels cause a collection note in the small mail box).
yEnc: The Answer (Score:3, Interesting)
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?
Re:Education instead of cushioning. (Score:2)
People don't want to know how a technology works. They want to use it, in as painless a way as possible, to get a job done. The reason you as an IS person exist is to help them do that. Technology for its own sake is IMHO the biggest sin we IS types commit in our daily jobs.
Regardless of how well the Internet was thought out in advance (and, there is contrary evidence on this point, witness the ICANN board upheavals) the target audience has changed and if the old way (separate services, FTP, Telnet, etc.) doesn't meet the new audience's needs, it's the system (not the audience) that must change.
Computers were invented for people, not the other way around. Get over your bad self.
Re:Education instead of cushioning. (Score:2)
You can't run IT like that. You need to have a clear set of policies and proceedures. Get these blessed by senior managment. As long as you have justification, this is a no-brainer. People who violate those need to be delt with via the normal disciplinary proceedures your company has which may even eventually lead to termination of employment for the violator.
IT personel do NOT need to put up with verbal abuse on the phone. Hang up. Call HR to report the asshole.
That's how I run MY IT department. Moral increased greatly in the rank and file of IT, and end users (and management) are happy because systems are more reliable / responsive due to proper use / end of abuse.
Re:Education instead of cushioning. (Score:2)
Something that people seem to always forget is that the short term ease is rarely ever worth the long-term headaches. Drag'n'dropping a file onto an FTP server and typing the name into the e-mail takes all of five seconds. Let it transfer in the background while you compose the message. That way, too, you can send a 5KB e-mail to 1000 people, and the QoS on the FTP server (and the nature of people getting around to downloading the file as they see fit, which means staggered downloading) eases the strain on servers and end-users and networks all along the way.
Remember that your saving ten seconds per e-mail could displace a thousand people for several hours (or days).
E-mail wasn't designed for file transfers. FTP was. Leave the square pegs where they belong. :)
Why have per e-mail limit? (Score:2)
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....
Re:Why have per e-mail limit? (Score:2)
Software Delivery (Score:5, Interesting)
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.
Re:Software Delivery (Score:2)
Other filters "defang" mail by nuking image references in html mail, javascript, etc.
More and more filtering is being done in the corporate space to the point where email has become an unreliable way to send files. Again, as long as MS (and others) contine to ignore the virus problem and intentionally design their products to be prone to viruses, filtering will only get more pervasive. As a side note, Anti-virus software generally fails due to the fact that virus definitions are created AFTER the virus is discovered, and is only effective AFTER users install upgraded definitions. This creates a time-lag where users are basically unprotected. File-type based rejection / defanging is therefore a much more effective tool against email borne viruses / worms (which doesn't mean that you shouldn't use anti-virus software of course.)
Back to the main topic, while the reality is that more and more people are sending huge files around, it is still a bad idea as mail servers and the mail protocols (smtp & pop mainly) are not designed to handle large messages. There is no "resume transfer" for example. Large files mailed to mailing lists can explode out to many gigabytes: a concept many users don't understand. MUA's don't generally offer the option of skipping a message that they are having a problem downloading. IMAP of course is a better solution to this but many ISP's don't offer IMAP access.
As for your specific problem, you are letting someone elses problem be your problem, and causing other problems as a result, which is very problematic when you think about it
Re:Software Delivery (Score:2)
If they could wait til tomorrow, they could someone from IT to figure out this infernal weird wide web thingy for them.
like naming
First of all, the only people who want files emailed to them are the ones who can't figure out to download it. Ever try explaining something as highly technical as renaming a file to an end user who can't drive a web browser?
Personally, I prefer to change EXE to EX1, so there's only one letter to change back.
Re:Software Delivery (Score:2)
Renaming works fine, but its a PITA that wouldn't be neccessary if it weren't for *certain* email clients with huge security holes. And emailing large files wouldn't even be neccessary if everyone used standard methods to access standard type of information.
"And if yer grandma had wheels, ya could use her for luggage" as the saying goes.
The problem with not having a limit... (Score:2)
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.
Don't use EMAIL for files. (Score:4, Informative)
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.
DO use email for files (Score:3, Interesting)
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.
Re:Don't use EMAIL for files. (Score:3, Informative)
Size Limits Depend on Industry, Tasks, and Purpose (Score:3, Insightful)
- 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.)
IMAP and Modem (Score:2, Interesting)
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.
Re:IMAP and Modem (Score:2, Interesting)
I think the point to this was that personal items (baby pictures, grandma goes to the disco for her 95th birthday.mov, etc) (sent or recieved during work time) would be put on personal servers rather than work servers, moving the responsibility to keep lots of free disk space from the work admins to whoever is sending the pictures/their home computer/their ISP.
I think 25MB is a good number. (Score:2)
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.
Personally very sick of the e-mail size snobs (Score:3, Insightful)
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
Re:Personally very sick of the e-mail size snobs (Score:2)
There are several great ways of creating "easy to use" drop boxes for internal / external users. It's the IT department's JOB is to create and maintain these resources. Instead of whining how it's hard, just DO it. Sheesh. This is NOT HARD people!
Email is wasteful.... (Score:2)
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).
remove size limitations (Score:3, Insightful)
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.
Re:remove size limitations (Score:2, Insightful)
The problem gets worse if you're running a mail server for several thousand people (like I used to at a small college). It's absolutely critical that file size limits are enforced or else the next Star Wars trailer that gets passed around to all the students via email swamps the server in a hurry.
Re:remove size limitations (Score:2)
At my university, we're provided with e-mail addresses that can be used as webmail, IMAP, POP3, or can be forwarded, and the size limit on the account is 25 megs, but it's a soft limit.
My geology prof sent me, recently, a powerpoint presentation, her entire lecture for the whole year, including images, text, and embedded movies. The e-mail came to 63 megs (suffice to say, I was not expecting this). It came through fine, but any other mail was responded to with a temporary 'mailbox is full' message until I removed it from my account. This resulted, the second time she sent it (there was a problem with the first), in my saving to my attachments folder and then deleting the message, which in turn deleted it from my attachments folder, so she had to re-re-send it. Now she has discovered she left a lecture out, so she may have to send it again.
Through all this, I've blasted past my quota three times so far, and likely will again, and no one has complained. Why? Because disk space is supercheap (and most students don't get large e-mails anyway, and the people who do are justified), bandwidth is cheap (my prof sends her e-mail from a large research lab outside of town, I download it at home on DSL, and the university is, well, the university), and proper administration and training goes a long way.
--Dan
Limits (Score:3, Interesting)
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.
Re:Limits (Score:3, Informative)
With modern mail stores, mail box limits of 100M / user is fairly realistic, although you can KILL your mail server if you use POP with frequent checks and "leave mail on the server" options.
5M is a resonable max to expect someone to get over a modem, although that's pretty bad too.
Just Say No (Score:4, Insightful)
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.
5 megs should be more than enough (Score:3, Insightful)
The biggest problem with e-mail is that it's really not designed to be a file transport mechanism. Delivery is subject to delay because it's not always point-to-point transfer. Intermediate servers can easily go down, delaying or preventing transmissions, and there's no universal way to get an acknowledgment of delivery once it leaves your network.
Not to mention the inefficiency of forcing banary file transfer through an system that really wasn't designed with that in mind. And the resource drain on your e-mail server.
The best way to handle large file transfer is to establish a means by which files can be FTP'd or perhaps even transferred via WebDAV shares - but protect them accordingly.
Misread writeup body... (Score:2)
that is just a flash in the pan
as
that is just Flash in the Spam
?????
Offer a better way. (Score:5, Interesting)
What you must do is develop an easier method for the users to transfer those files. You must take into consideration that file access must be available internally or externally and not require extra steps for the user to make it happen.
The best way in my opinion would be to setup an FTP site and a script to purge older files from the site automatically. Say for instance a 7 day directory and a 2 week directory. You will loikely want to provide some form of security restriction to the FTP site either by using separate subdirectories and controlling access with file permissions. Links to the file could then include a userid and password to access the file. However, keep in mind that the securoty of an attachment in email is non-existant anyway so don't fret security too much.
Train your users to place their files in the appropriate directory and then send a link to the file, rather than the file itself. But, be aware that this requires the users to perform extra steps and they will be reluctant. To force them to use this new scheme you will have to limit the size of mail that they can send but, you should not limit the size that they can receive, as they will need to receive mails from outside sources over which, you have no control.
Ideally, you should modify their mail client software so that simply clicking the attachment button automatically places the file on the ftp server and creates the link in the message. This does require some programming. If you use open source clients it should be trivial to do or hire someone to do it for you. If, more likely, you use Outlook then you will need to develop a VBA module to do it for you and replace the user's attachment button with a button to the VBA module.
It can be done but, are you willing to do the work required to make it happen. Because, your users are not!
Re:Offer a better way. (Score:3, Interesting)
Modifying each mail client would be hell unless you have a mandate to use a particular client; where I work, Outlook is a thankful minority. Easier to do the convert-to-URL on the server side of things, sometimes. For instance, MIMEDefang [roaringpenguin.com] has a nifty action_replace_with_url function.
Nothing like Faculty trying to fling bloated Office documents at student email accounts on free mail servers with tiny quotas...
Alternate Method (Score:2)
A friend of my recently wrote a web-based application to upload, and later retreive files. A user, vendor, or client goes to their website, enters in their email address, the recipients address, and selects a file to upload. After the upload, an email is sent to the recipient to retrieve the file. It almost works like a greeting card system.
They have an 800MB file size limit (good enough for ISO images of CDs), and files are automatically removed after 30 days.
I believe ABCUpload [websupergoo.com] was the component used in this project. Yes, it's made for ASP/IIS, but I'm sure there's alternatives for Apache.
15 Megs (Score:5, Interesting)
By mistake, a colleague sent a 50MB mail to 20 recipients worldwide.
Looking at the log from the mail server we saw that the delivery failed big time, because most sites limits the mail size to 6-10MB. If you set the limit to 15 MB, you will be able to handle larger mails that most sites. Your users won't benefit from a larger limit.
Back in the day... (Score:2)
I worked for a subsidiary of [insert large company here]. We had a 56k line connecting us to the corporate cloud, and by extension the Internet.
One day a user decided to send 80 MB of mp3's to a friend at AOL. Hilarity ensued:
By the time I caught it, there were something like 7 copies of the bounce in the queue, and of course it was still trying to resend... When I finally got someone from corporate on the phone, and they told me it was a timeout issue, they then asked what our link speed was. After they stopped laughing, they upped the timeouts on their end...
User got a visit.
We limit to 2MB (Score:5, Funny)
Thus spake our mail server, "I have no swap, and I must page! I have no disk, and I must spool! I hazzzzzzzzzzzzzzzttt!"
And the Network Administrator pointed out that this was predicted. And the size limit was reinstated.
direct users to better methods (Score:2)
Unknown to many newbies, they have many methods at their disposal these days. Direct them to file transfers via AOL's Instant Messenger or the other IM programs, point them to free homepage servers like yahoo.com/geocities, tell them to explore IRC if they're daring.
There are lots of easy alternatives to transferring large files to people via email, and email, while it happens to be the easiest method, is simply the worst. Why clog up x number of people's mailboxes by pushing a huge file on them (it sucks for the recipient if they're on a modem) instead of allowing them to grab the files themselves.
Sysadmins should help the world by politely teaching their clients/users 'net etiquette. Many people that came onto the internet in the last few years simply don't understand why it's a "bad thing", so teach them, and point them to better alternatives. They'll love you for it.
Email infrastructure unsatisfactory? (Score:2, Interesting)
The way people decide to send an attachment rather than sharing the file and sending a pointer to it indicates that this is the easier way for users. This is important. So possibly what should be done is improving the email infrastructure to be able to handle such uses efficiently.
I'm thinking that maybe, when a file is being attached to a message, the default could be that the file is stored at the mailserver and only a pointer is included in the message. The thing is, most people reading email are connected to the net at the time, and a mail user agent could easily handle referenced attachments the same way as included attachments.
The necessary steps (all I can think of right now) would be
I believe it would be relatively simple on the implementation side and it could further simplify internet use.
What do you think?
Web based 'ftp' (Score:2, Interesting)
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.
email is the new UPS or Fedex (Score:4, Insightful)
Re:email is the new UPS or Fedex (Score:2)
That's nice. Unfortunately the email protocol IS NOT DESIGNED AS A FILE TRANSFER PROTOCOL. As an email admin I have seen users try to send multiple CD-ROM images as file attachements on one email message. This will cause most email servers to fail, denying all users access to their mail. It is my job as a sysadmin to make sure that some former employee can't bring down business critical services by sending an arbitrarily large email.
File attachment size limits are REQUIRED on email servers to insure some user who needs a bit of training doesn't bring down the entire system.
There is a basic engineering principle here - YOU CAN'T GET 10 lbs of crap into a 5 lb bag. Email cannot serve as a general purpose file transfer mechanism.
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
BALONEY. ftp over ssh is perfectly secure. As is HTTP over SSL. The fact is that if a sysadmin sets a file size limit in order to prevent loss of service, he is doing his job.
Replacing FedEx with email saves us $300k+/year (Score:5, Informative)
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.
Wouldn't be an issue... (Score:2)
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)
Education and alternatives (Score:2, Interesting)
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 [web-ftp.org]) 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...)
I am (Score:4, Interesting)
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
secure corporate website with file upload area (Score:2)
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*
AOL doing something well for consumers? (Score:2, Interesting)
I come across this question every day (Score:2)
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
Shouldn't 5 megs per message be enough? (Score:2)
11MB mail box, 20MB for attachments, for a reason! (Score:2, Interesting)
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.
Size Matters (Score:2)
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.]So many arguments, so little grasp (Score:5, Insightful)
- 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?Re:This is a business.. (Score:2)
This is a common policy, but not a universal one and not necessarily a good one. My employer is doing quite well with the policy that happy employees do good work, so we don't spy on them or try to force them to maintain an exact separation between work and home.
The poster used family portraits as an example of how big things are these days, but I'd be surprised if that were really the driving factor here. Think 100MB PowerPoint files: the sales team slings these around like mashed potatoes. But that's OK; our mail server, a cheap PC running Debian+Exim, doesn't even blink, and they understand that it's rarely a good idea to let such things leave our fast network.
Re:This is a business.. (Score:2, Insightful)
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.
Re:This is a business.. (Score:2)
A 100MB email to ten people doesn't come anywhere near choking my mail server, despite the fact that it's made from cheap commodity parts a few years old.
The point being, teach the employees an alternate method to transfer large files and enforce it. From CEO on down.Perhaps I can do this; but why should I? In terms of user interface, email is exactly the right thing for them to use. One of them has a file, and wants the others to end up with it on their own machines. In a single operation, he sends it to the others, and in a single operation, they have it. Putting it on our server is an invitation to leave it there, sucking up server disk space when everyone forgets about it (as opposed to getting caught when they sweep their own machines for bloat) and being inaccessible when they're on the road.
This is not one of those rare occasions when it is necessary to be a BOFH. Just because I personally think email is for text and people who use it for other things are wankers does not mean it makes business sense to enforce this policy in my workplace.
Re:This is a business.. (Score:2)
I continue to contend that the time to stop them is when you anticipate performance problems. They know how to put files on the server, and I let them make their own decisions on when to do it, advising them when requested or when the need becomes obvious to me. Forcing them to exchange files in some other way will make their lives harder, not easier, causing them to bring in less money, which does not Enhance Shareholder Value. In addition, seemingly arbitrary restrictions (after all, It Worked Before, It Works Elsewhere, and so on) diminish their trust in me and make it harder to get cooperation when I actually need it.
Re:This is a business.. (Score:2)
Why? How is 5MB special? My mail server's job, like the jobs of the other servers, is (to the greatest extent possible) to let the users do what they think they need to do. It's sometimes my job to convince them that they don't need to do it, but I don't have especially good arguments against huge emails, nor do I see a need for them. Sure, it's aesthetically un-pleasing to me (base64? Ugh. PowerPoint? Double ugh), but that's not what we call a business case.
My mail server can handle mail up to 2GB. (Beyond that, I suspect I'll run into a 32-bit barrier in at least one of Exim, UW IMAP, and the libraries they use.) As long as they don't do something really stupid like trying to send something that huge over our little T1, it's not a problem.
And these are the clients... (Score:2)
(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.)
Re:And these are the clients... (Score:2)
I am a sysadmin for an agency. I have never seen a client who could not download a file from a web page.
Re:Companies like this needs alternative file-send (Score:2, Informative)
Re:Who are the users? (Score:2, Funny)
Me:Good afternoon, welcome to CustomerIsAlwaysRightNet, how can I help you?
Them:yOUR BLOODY SERVER IS BROKEN AGAIN, FIX IT now!!! i'M RUNNING A BUSINESS HERE, YOU'RE COSTING ME MONEY, i WANT A MONTH'S CREDIT ON MY ACCOUNT BECAUSE i HAVEN'T BEEN ABLE TO CHECK MY EMAIL FOR THREE MINUTES NOW!!!
Me: Of course sir. Here at CustomerIsAlwaysRightNet, the customer is always right, so it's perfectly obvious that I need to go and fix our broken password file. The customer is always right, so you couldn't possibly...ooo, I don't know, left your CAPS LOCK key on or anything ludicrously stupid like that.
Your month's credit for the three minutes of lost time because of our terribly broken mail server? I'll put that on your account straight away. In fact, I'd better make it two months, seeing that our monumental stuff-up has inconvenienced you so greatly...
Listen, moosh - if I had a dollar for every half-witted maroon who's given me an ear-bashing because they KNOW that it's OUR system that's stopping them from getting online because we've been really mean and nasty and made their modem turn itself off, or even gone round to their houses, broken in in the middle of the night, and actually UNPLUGGED the phone line from the back of the computer (At least, I guess that must be how it got to be unplugged, none of our Always Right customers would do that so they could make a phone call and then forget to plug it back in again, would they?), I wouldn't be sitting here listening to this pompous TIT rant at me that his WinXP heap of parrot droppings that he paid six grand for from Myers is the most advanced computer money can buy and he's not going to be paying this $200 overage because it's our accounting system that is, quote, "up the shit", and (not only, but also) we've given his username and password to someone else and let them connect to the internet with it (and somehow convinced Telstra to give them his PHONE NUMBER to do it with as well - callerID, anyone?), run up this huge overage with it - the Imesh in his startup folder, of course, has nothing to do with it, neither do the six different ad servers, DNS hijackers and spyware toolbars running on his system, and the fact that the 'Connect To' window is popping up every thirty seconds or so is entirely something OUR COMPUTERS are doing to him...
Go on, ask me if I'm going to let you send a 50 MB email to everyone in your address book. Ask me, go on..I WANT you to ask me...
Need...beer...urge...to kill...rising...
Re:Who are the users? (Score:3, Interesting)
When you explain to some of these poeple that hey, you just can't put 200GB on a 120GB disk along with your operating environment and other company file storage, they blink.
Customers are not always right - customers in many cases need to be educated so that they may understand how "this e-mail stuff" works.
Re:Who are the users? (Score:2)
Yah. You won't be in business long. Any business person knows that there are customers that you cannot afford to have. They are so demanding that servicing them will be a financial loser for you. Better for you that they should be your competitor's customers.
Re:Who are the users? (Score:2)
Re:Who are the users? (Score:2)
Re:Who are the users? (Score:2)
Password (Score:3, Insightful)
The other method that I frequently use is to zip the file and then replace the extension. MyFile.zip becomes MyFile.txt. No problem.
Re:What about overly aggressive virus scans? (Score:2)
When viruses impede your ability -- and everyone else's -- to do work.
Seriously: you're using a tool for file transfer that was great, once, but is now vulnerable to exploitation by viruses and other nogoodniks. I say your problem is not with antivirus software, but with viruses ruining a particular tool. Either, as someone above suggested, password protect your .zip files, or (easy for me to say, I know) look for another solution like web or web or ftp space.