Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'll confess this is an area where I'll give it 10-20mb and toss out an "email is not intended for file transfer" whenever a user gripes about having to use FTP.

But a shiny new mail server deserves a rational approach... so what is a non-voodoo method for determining an appropriate limit for attachment size?

(Wavering on whether this is a wiki, or if there's a method that's Just That Good.)

I thought there would be some good guidelines independent of environment, but specifics were called for - so 50 mailboxes, exchange 2007, AD, hardware is TBD. Clients are a 2007/2003 mix, I figured I'd set sent/received to match, just to keep things simple.

share|improve this question
    
Similar to this question: serverfault.com/questions/24426/… –  Ward Jun 17 '09 at 21:46
    
Doh! Thanks for the link. My search skills failed me there. –  Kara Marfia Jun 18 '09 at 13:04
    
Zero seems like a totally reasonable limit to me. –  Tom O'Connor Apr 13 '11 at 15:25

15 Answers 15

up vote 18 down vote accepted

"Email is not intended for file transfer!"

In all seriousness, I set mine at 10MB, any higher and you might get rejections from remote SMTP servers. If your company/client does use a lot of larger files, I might be convinced to set it at 15 or 20MB but no higher than that.

I instruct clients to use a service like Dropbox if sending larger files. [Disclosure, that is my referral link!]

share|improve this answer
    
Good point, I wasn't thinking about the fact that an increased limit increases the bouncebacks they'll be getting from other's mail servers. –  Kara Marfia Jun 17 '09 at 20:24
1  
+1 For "Email is not intended for file transfer!". –  Lankymart Apr 30 at 9:43

This is directly dependent on your business.

I have users who routinely get files in the 40MB range, and sometimes well above that. I essentially set an unlimited size for that reason.

Take a look at your legitimate attachments, take the average size and double it, then look at the largest legitimate attachment you've received. If it's bigger than double the average, then make it 50% bigger than the largest so far.

share|improve this answer
1  
Sure, and I have users who regularly try to get 300MB legitimate attachments. The content is legitimate? But the size is not legitimate for email transfer. –  d-_-b Nov 26 '12 at 6:35

How many users? IMAP? POP3?

I don't bother with anything over 10, as you said, it's not a file transfer service.

share|improve this answer

Sent or received email-attachments? Are your organization using MS Exchange / MS Office Outlook / Active Directory / SharePoint? If so, what version? This is complicated topic.

share|improve this answer

10 MB firm! Except for the executives who are wide open. We got tired of getting cursed at!

share|improve this answer
    
Sad but true! Inbox restrictions go out the window there, as well. –  Kara Marfia Jun 18 '09 at 13:00

I'm in the "10Mb and that's your lot" camp. It isn't just what you can send but also what the people you send to can receive. Unless your business operates in an area where sending very large binaries by email is the norm then why go higher?

Aside from that, you do need to make sure you offer an alternative for people who really do need to send larger files, whether it's something like Dropbox, a good old fashioned FTP server or something else clever (We have the server and bandwidth capacity to offer our own service similar to dropbox to our users, as it happens).

share|improve this answer

I tend to go a little higher, and creep up on 30MB. It's going to vary from business to business. As an alternative to file attachments, try senduit.

share|improve this answer
    
Hey, that interface is so simple, even our customers couldn't screw it up... –  Kara Marfia Jun 18 '09 at 13:02

Whatever the size is, be sure to keep the incoming limit over the outgoing limit. Servers can and will bounce your mail by sending it back (all of it) if there is a non-size-related error (wrong address or so), and even if it will only add a few bytes you don't want to reject that mail based on size.

Also some "email clients" (I use the term cautiously) create replies to emails with attachments by adding just the same attachment. You also don't want to bounce those mails, as dumb as this behaviour may be.

Luckily there are nice MTAs (not Exchange, but for example postfix is one) that allow you to restrict bounces to a much lower size than the original mail. So that first case might be on the decline as this feature gets adopted even by braindead MTAs.

Anyway, the choice of size really depends on who you mostly communicate with and what their limits are. In graphical businesses, maximum sizes of triple-digit megabytes are not unheard of, in other businesses (I want to say academics, but times have changed, sadly) you might even get away with telling people that attachments are bad practice to begin with. I know I did, but that was ten years ago :(

share|improve this answer

10MB here too. It seems to be the accepted standard. I have customers who complain about it (in particular a bunch of architects who consistently use "large CAD drawings" as an excuse for overriding any quota or limit) but all it takes is to point out to them that (1) email is a shared service, and therefore their activities might impact on availability for others, and (2) they have to play nice with the recipient.

For anything over that limit there are plenty of alternative arrangements available, so everyone can be kept happy.

share|improve this answer

We set ours to whatever Gmail's limit is. We are notoriously deaf to the pleas of certain scientists in our midsts who wish to email large data-sets back and forth with fellow researchers. This is why we still have both departmental mail-servers, and Exchange servers supporting 4000-odd users and mail-stores under 1TB.

share|improve this answer

At the individual PC level, all the amazing improvements in hardware speed and capacity have given people a distorted sense of what's reasonable. Fast PCs and laptops with 500GB+ hard drives make dealing with 5MB pics from digital cameras, movies, documents with lots of pictures inserted, etc., no problem.

Then they want to send them out over the wire... Yes, it works lots of the time to send 20MB, 50MB, even bigger attachments. But when something goes wrong, it messes things up in a much bigger way. There's bigger files in the queue, maybe your bandwidth charges go up, something like that.

Anyway, that's all preliminary to what we did: pulled 20MB out of the air and said "that's it." It's big enough that we can relate it to our 100MBPS connection and try to give them a sense of what would happen if 50 people were trying to send the same size file at once.

share|improve this answer

The limit itself is somewhat less important than providing a consistent, secure and easy-to-use alternative to users who need to send and receive larger files.

share|improve this answer

Strict out, loose in. I will accept anything up to 100 MB in, but I deny anything over 15 out.

share|improve this answer

To meet the limit of 5 MB or 10 defined on some servers Private messaging (Exchange, Qmail ...), there is a professional solution that overcomes the size and type of files you want to send. The solution also provides traceability and security strong that do not offer FTP (password and username in clear ...). Also available on mobile environment (iPhone, Windows phone 7/mobile, Blackberry,...)

2 technologies available:

The platform mode solution:

http://www.edipoles.com/index.php?id_page=36&openPanel=1

The solution in Outlook plugin:

http://www.edipoles.com/index.php?id_page=30&openPanel=1

share|improve this answer

As the world progresses so do policies. With our recent upgrade to Exchange 2010 we've upped our send/receive limit to 25 MB (Gmail's limit). With Gmail's hosted email services expanding you are only going to run into problems with a lower limit. If storage space is not a problem (considering disks are smaller, faster, and cheaper) than why not?

share|improve this answer

protected by Community May 31 '13 at 16:41

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.