Frequently, unexperienced customers or prospects ask us about the possibility of sending mailing containing big attachments.
This is the kind of task that seems trivial when sending just a couple of e-mails, but that immediately reveals as a not-such-a-sensible-idea when viewed from the point of view of someone that sends thousands of e-mails.
First of all let's consider how long it will take to send out such a campaign. For example, we need to send 5,000 e-mails with a 5 MB attached .doc file. Let's do the numbers.
Attachments are encoded using Base64 (for sending binaries as text). This in average leads to an increase of 37% in the size of the attachment, so considering a total size of 5 MB (we consider content size as irrelevant here), the size when the email is sent will be:
5 x 1.37 = 6.85 MB
Now, we have 5,000 e-mails to send, so the total size of the information we need to transfer is:
5,000 x 6.85 MB = 34,250 MB --> 34.25 GB
This is equivalent to transferring 49 CD-ROMs through the wire!! (and we're not considering some extra synchronization traffic that is needed for the sake of simplicity).
If our server is placed in an advanced datacenter and has, for example, a 6 Mbps symmetric connection to the Internet (which is very good and is quite expensive), which is equivalent to 750 KB/sec (or 0,75 MB/sec), this implies a sending time of:
34,250 MB / 0.75 MB/sec = 45,666.67 seconds --> 12 hours, 41 minutes, 7 seconds
A regular 5.000 e-mailing will take around 4 minutes or less. Bufff!
Other important thing to consider is deliverability to the destination servers. If you send an e-mail with a big attachment to, let's say, a couple of accounts at hotmail.com, you probably will not have any problems. But, how many recipients can you have in your list with a hotmail e-mail account? 20%, 30%?. Probably more. Say hotmail, say yahoo, say one of your big customers in a B2B list. The point is that when a server sees a lot of big e-mails coming from the same IP, they usually block the sender because she is eating up a lot of their bandwidth. A lot of ISPs don’t have bandwidth enough to support getting a large number of emails with big attachments. So you probably will get a lot of deliverability problems if you do this.
Some recipients will have limited account storage, even in these times of almost unlimited account space. A lot of corporate servers limit the size of the incoming e-mails for their employees, so you get a chance or not getting them delivered and receive a lot of soft bounces (with more bandwidth usage in your server, by the way).
Even if you get to your recipient's inbox, if they don't know you well, you probably will get a lot of spam complaints or very low open rates for fear of getting a computer virus. Besides this, nobody likes to receive big e-mail attachments without being warned in advance.
There is an added benefit or not sending attachments: you can put files in your web server and add a direct link in your email to these files. This way you avoid the problems stated above and, as a plus, you get detailed information about which recipients clicked on it, getting very useful data that you cannot obtain from attached files.
We can allow you to send attached files in MAILCast, but we don't recommend it. Drop us a line to get a quote if you need this kind of service :-)