The Attachment Craze
As soon as email became an indispensable part of daily communications, it also became a ubiquitous means of file dispersal. Beyond personal photo sharing, inspirational and spiritual PowerPoint presentations, business Word proposals, and vcards, however, lurked phishing scams and virus-laden Trojan horses. As email traffic increased, so too did the burden of mail servers and networks. The potential sinister nature of attachments and infrastructure load has made email attachments a deliverability liability.
Email attachments have become a main source of computer infections. When virus carrying emails first appeared, unsuscepting recipients would open files, even executables, without thought. As the public became aware, people stopped opening files from senders they did not know. However, viral attachments still were received from friends and colleagues who did not know their files were infected. Emails sent from hacked or spoofed email accounts further enticed recipients to open attachments as the sender was supposedly trusted. To mitigate the impact, many corporate email infrastructures scan and destroy attachments or reject the email if infected. Given the load of some email systems, however, the virus scanning became burdensome to the servers. Many have simply opted to deleting all received email attachments.
Not only does virus scanning burden destination mail servers, the sending of an attachment, infected or not, is taxing on the sending server, receiving server, and the networks in between. A typical email is a file about 5K in size. An HTML email newsletter is on the order of around 30K. This excludes images as they are not sent with the email. The size of an email with an attachment is the basic email size plus the size of the file. If the file is not text, it must be UUencoded in order to be placed in the email. UUencoding is a process that converts binary data to a series of text characters. This process typically increases file size 35%.
If you wanted to send a 750K PDF file, in the email it would be about 1MB. Now let’s say you want to send this to 1,000 people in separate emails. You are making your sending email server send 1000MB = 1G of data (we’ll ignore the size of the email without the attachment for this example). This is in addition to its normal load. Now say 100 of those recipients are under the same email domain. That destination server now has to accept 100MB of additional data. Those files end up in the users’ mailboxes which they access over POP or IMAP (or HTTP in some cases). This data now must be housed on the incoming mail server and sent over the network to the user’s desktop. The big issue here is this onslaught of traffic was pushed. It was not requested by the recipients. To manage server and network load, companies’ mail infrastructures will defer delivery or increase spam scores to emails with attachments. Abusive senders will be added to blacklists.
A person needing to disseminate files to many people should post the file on a web server and email the link to that file. This will alleviate the barriers to delivery as described above. It also designates a single source for that file. This is helpful in managing file versioning. If an update is needed, simply replace the file on the server and ask the recipients to download the file again. No longer do the recipients have to search through their inbox wondering which email has the correct version.
Deliverability is the foremost endeavor of any email marketer. Attachments are a liability to delivering emails.