Why do we still have such small email attachment filesize restrictions? [closed]

Solution 1:

The problem is this: e-mail (SMTP/POP3/IMAP/what-have-you) is an ancient, simple protocol originally intended for sending plaintext messages in a trusted network. Using it for sending or receiving large amounts of binary data across today's Internet is a bolted-on hack, completely different from the original use case, and it performs rather miserably in this role.

When you attach a file to the e-mail, it gets base64-encoded, which increases its size by 1/3. Thus, your 1 GB file becomes another 300 MB larger; also, there is no built-in compression to the download protocol, thus no way to speed up the transfer (and in some cases (SMTP for sending,POP3 for receiving), even no way to resume a broken transfer - connection broke at 1.2 GB? Sorry, you need to re-transmit it all again). Moreover, SMTP is a store-and-forward protocol. Guess what? Yup, that 1.3 GB file needs to be copied across multiple servers; cue unbounded happiness from the mail server admins.

This was a problem in the 1990s, when there was no useful alternative (FTP? HTTP/1.0? Puh-leeze); but in the glorious year 2011, with various ways of seamlessly up/downloading data to/from the cloud (e.g. Dropbox, Ubuntu One, Amazon S3, to name the most known), the excuse of "there's no other useful way to do this" is not true any more.

Note also that not everyone is on a 100 Mbit link to the Internet - e.g. mobile and smartphone; not every mail client is capable of downloading only the headers (e.g. POP3 is still in much use), and not every user is willing to download the 20 inevitable "look at this funneh 1 GB video" e-mails per week that will appear (people will send as large files as the system will let them; and yes, there is something like FUP with most ISPs).

TL;DR: while it would be technically possible to do such things as e-mailing a 1GB file, it would also be technically possible to pound in a nail using a screwdriver - it's just not a good way to do it, as there are tools that are more suitable for such tasks.

Solution 2:

The same but from a slightly different view:

Email is electronic mail. You know mail as this ancient paper thingy in another little paper envelope. You could write a lot of text on it but not very more than 5 or 6 pages. And email is the same but electronic. It is designed for text (plain text like on a typewriter). Then there was a MIME extension where you could send these fancy red-blinking HTML mails.

No one in the world would complain and say "Oh mail stuck in the way it was at 1322 AD. Why can't I send an elephant in a paper envelope?" It is how it is. For this kind of stuff people invented something like a packet or a transport container. This is how to send goods and elephants. And the Internet guys invented FTP (file transfer protocol), got the name?

In the real world there are many alternatives to FTP because FTP is also an ancient protocol with big disadvantages (mostly in security and not in transferring files). But HTTP is not an alternative as it was developed for centralized document storage with meta data. That you can download and upload files is a brutal extension to it.

So use a letter to send text and a packet to send goods; use email to send information and file transport protocols to send files.

To stay in the picture I have to add: Even if you convince your local post office to accept elephants in paper envelops (and pay the additional fee) there are more parties involved delivering the elephant. There is the mailman who has to carry it to the next post office and probably he has not the right bag for the elephant to fit in. But maybe he has and wants to deliver it to the next post office which in turn says: "No we don't accept elephants".

What to do then? The good mailman in the real world would carry the elephant back to the first post office -- back to sender afterwards. (In the electronic world this would be a bad mailman because he should have shot the elephant and only deliver the certificate of death back to the sender).

So even if you could convince all links in the chain of post delivery to accept elephants you are faced with the recipient. He could say that he wants the elephant but the letterbox is too small for an elephant to fit in. Leading to a return-to-sender elephant delivery. (Not to mention what happens if the elephant doesn't fit in the sender's letterbox...)

Solution 3:

Having been in a situation with Exchange 2007 where management subscribed to the "no limit on email size" philosophy:

An internal user sent a message to their hotmail address with an .iso of a music CD. Jammed the queue on one transport server while processing the message, lit up back pressure, stopping message submission. The user's outlook then dutifully re-submitted the message to the other transport server that was functioning; back pressure, no message submission.

With both transport servers choking on the message, all outbound email halted for about 90 seconds. Hotmail, of course, rejected the message. There was a size limit in place very soon after.