A long time ago, email was designed for one purpose: Delivering text messages from one place to another.  Since it was developed in the States, the primary language of email was set to be English.  And since the English language uses exactly 26 letters (52, if you consider capitals and lower case letters different) and a few assorted characters, ASCII was chosen to be the de-facto character set for email.


Since that time, many things have changed.  We now have the ability to specify the character set to use in email.  Most commonly, that's either ASCII or UTF-8.  We also have put email to use for a lot more than just sending short text messages from place to place.  At some point, someone decided that an email message would be a great way to send a file to someone else.  The difficulty they encountered, however, is that a file exists in binary format on the source computer and they wanted to transfer it to another computer, for delivery in binary format, over an ASCII connection medium.  Obviously, this requires re-encoding the message through some means.  It was at this point that UUEncode and UUDecode appeared.  UUencode would encode a file in ASCII format for transmission over electronic mail.  UUDecode would take that file and decode it again.  The problem with these tools was that they were inefficient and difficult to use; encoding and decoding had to be done outside of the email window. Over time, Quoted-Printable (Q-P) and Base 64 came about, and pretty much took over the binary attachment handling world.


But even these tools have some inefficiencies.  Specifically, a file encoded using Q-P or Base64 is going to necessarily expand in size.  A file containing only ASCII text can be easily converted with almost no size increase, whereas an executable or other binary file is going to tend to get quite a bit larger.  Worse, smaller files grow by a larger percentage than do bigger ones.  This is due to the fact that smaller files tend to have fewer repeatable patterns than larger ones, as well as more expansion due to administrative overhead.  Overall, as file size grows, it approaches a growth rate of 33% (depending on the encoding mechanism), although small files can be as much as 50-75% larger when encoded for email transmission. 


So what sort of size limits should admins set?  Generally, it is a good idea to think of the largest file attachment size you want your users to be able to receive via email.  Once you have that size, multiply it by 4/3 or 133%.  That is approximately the size of file attachments you need to allow through the appliance.  It's also worth noting that transmission of large attachments is *MUCH* more efficient over FTP or some other binary file transmission mechanism. 


Either way, it is recommended that customers set their file attachment size filtering feature to filter for files about 33% larger than the actual maximum file size.



Notable links:


http://ask-leo.com/why_are_emailed_attachments_larger_than_the_original_file.htm l




http://googlesystem.blogspot.com/2009/11/why-its-bad-idea-to-send-huge-files-by. html