You have been redirected here, which houses content from our former website; this content may or may not be current. Our official website may have more up-to-date information.
UBC Mathematics: MathNet FAQ [Big Attachments]

UBC Mathematics: MathNet FAQ [Big Attachments]

Question: Why is the practice of Emailing large attachments to many recipients discouraged?
Author: Joseph Tam
Date: Sept. 2, 2004

Sending large attachments via Email is an inefficient and wasteful way of disseminating information to a large group of people, as one copy is made for each recipient. It taxes the network, mail servers, disk storage of both the sender and especially the recipients, and sometimes the recipient's patience if they use a dial-up modem for their internet connection.

The typical scenario is that someone will broadcast information (and sometimes committing the double sin of formatting it in a proprietary format) to a mailing list that may contain hundreds, or even thousands, of recipients. A copy is then made for each individual recipient. So, for example, if 4 megabyte attachment is sent to a department mailing list with 250 people, an aggregate of 1 gigabyte of mail storage is used by this one message.

Some Email accounts (e.g. Hotmail, Yahoo) have size quotas, and sending large attachments to them will either fill up or severely reduce the available space for new mail.

It is also typical that not all of the recipients need or want the attachment, yet these recipients have already expended the considerable computing overhead to receive, scan or filter for spam and viruses, and store the large attachment.

A far better strategy is to post the information or file onto a web site (or FTP site if you have access to one), then Email out a short message that describes the contents and refers interested parties to the URL. This will allow people who want the data to pull the data off the web site at their leisure, and those who don't can delete the message without having incurred the overhead of receiving all the data in the first place.

Using this method with the above scenario, a 1K blurb instead of a 4Mb attachment will mean a three-orders of magnitude (1/4000th) reduction in computing resources.