MIME Encoding of Email Attachments

I spoke to one of our customers on the phone today that wasn’t very happy with our services for an interesting reason. It turns out that his employees are communicating with a number of people via email that have an inbound attachment limit of 10MB set by their ISP—and many of the emails they send out are getting close to that 10MB limit. The problem is, when attachments leave our system they are MIME encoded and thus grow in size by about 33%. For this customer, the MIME encoding is pushing his company’s attachments over the 10MB limit set by the ISPs or email hosting providers on the receiving end of the emails.
This is one of those weird technical issues that can confuse a lot of people (me included). We try to get around the confusion on our end by offering higher attachment size limits to make up for the MIME encoding. As we state on our website:
Incoming and outgoing message size limits are set to 35 MB. This allows a 25 MB file to be attached because MIME encoding adds 33% to size.
Unfortunately, we cannot control what other companies are doing. As an FYI, just about every email system in the world MIME encodes email attachments.
Some email clients will hide this 33% increase, even though it still occurs. For example Outlook displays the un-encoded size (at least in my version of Outlook 2000), but when the email is sent from mail server to mail server, the size is actually 33% larger than what Outlook displays. So the number that really matters is the number we display.

Rack Blogger is our catchall blog byline, subbed in when a Racker author moves on, or used when we publish a guest post. You can email Rack Blogger at blog@rackspace.com.


  1. This may not be an ideal solution, but you might get to thinking about how you can create a component that would separate the attachment from the email and store it on an ‘attachment server’. Inside the email would be some form of password along with a web link to the file to be downloaded. The reader would click on a link, and after supplying the password would be able to download the file via http. Then the file could be made available for a certain period of time before being destroyed. You could even host the files on an SSL server. Personally I think too many confidential files get tossed around the internet and people aren’t aware of how long those files may be sitting around on mail servers as bounces and so on.



Please enter your comment!
Please enter your name here