Support: 1-800-961-4454
1-800-961-2888

MIME Encoding of Email Attachments

1

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.

About the Author

This is a post written and contributed by Pat Matthews.

Pat Matthews is the Senior Vice President of Corporate Development at Rackspace. Prior to Rackspace, Pat founded Webmail.us, a business email hosting company that made Inc. magazine's list of the fastest-growing private companies in America. In 2007 Rackspace acquired Webmail.us and the two businesses joined forces. From 2007 to 2009, Pat led the Rackspace mail business and helped grow it to more than two million paid mailboxes worldwide.

In January 2010, Pat was promoted to Vice President and General Manager of all Rackspace cloud businesses. In this role he led Rackspace to become one of the most important companies in the cloud computing industry. He was promoted to Senior Vice President of Cloud at Rackspace in August of 2010.

Today, Pat oversees corporate development, which includes M&A, investment projects, new business initiatives and strategic partnerships.

Pat is a graduate of Virginia Tech. He is an angel investor and advisor in several startup companies. Pat and his family live in San Antonio, TX.


More
  • http://www.pecorfamily.com Sean Pecor

    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.

    Sean

Racker Powered
©2014 Rackspace, US Inc.