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."
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 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.
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.
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.
- 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?
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.
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).
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.
Huh. Sounds like a dumb ISP. Should at LEAST give your users the option of paying more for a larger quota. For every 10M more, another $5 / month or so. This pays for itself quite quickly.
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!
There is also a cost associated with getting this setup and being able to administer it with billing etc. For some it may be to much of a hassle given the expected return. Am I going to invest 5-6k for people to focus on this and get it worked out so that 5 people can pay me maybe an extra 30-60 bucks a month. I wouldn't, maybe you would?
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.
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.
if your mail server is set up right, all you have to do is edit the unix filesystem quota, and bam, they can recieve larger files (of course sending them is still a problem)
Need a Catering Connection
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.
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.
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...
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.
BD Phone Home!
Shameless plug. Like you weren't expecting it.
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.
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.
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
If you are an ISP, the users are your customers, and they are right (as customers always should be).
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.
If you use OGG Vorbis to encode your music? ;-)
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."
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!"
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 don't know of any sysadmin who's setup can be brought down by a large email attachment
Read the rest of the comments to this article. You will see plenty of cases of sysadmins discussing problems with servers going down due to large file attachments.
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?
I think most people already have a web browser installed. No additional client software is needed. They don't need individual passwords for an upload only web page, either.
disk is cheap, bandwidth is a utility
And email does not work as a reliable file transfer mechanism for large files.
So, you simply find a way to satisfy the customers in a manner that will make you more than it costs you if they leave.
One of the characteristics of the losing customer is that they refuse to pay for the services they are demanding.
Obviosuly, if a customer wants 300Gb of webspace, and unlimited bandwidth for $1 a month, then they are not right, (unless you can supply that for 99c a month) but if they want to send a 6Mb email, then they are.
Your opinion only.
I consider 6MB of email over a dial-up link to be unreasonable.
We have a 4MB limit for emails - one of our customers called us up and demanded that it be raised, because she couldn't send a 3MB file to her sister's work email...
Turns out that her sister's work email had a 2MB limit.
So, according to you, is this still 'reasonale'? (Remember, YOU set the "reasonable" limit to 6MB)
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 :)
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.
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
What, your network can't handle N bits at once? Your 100MHz PII is the problem, not SMTP. Since when does an Internet protocol technology have arbitrary limits?
"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
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
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
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.