1.6 Not So Fast . . .

After performing this sort of analysis, one might conclude that email performance tuning isn't necessary for a particular organization's system(s). However, before dismissing the rest of this book, some other factors might be worth considering. At most organizations, the number of people using email, the number of messages sent and received per person, and the average size of each email message are larger today than the corresponding numbers of a year ago. There's no reason to believe that these numbers won't be even bigger next year. At many sites where the email server(s) can easily handle the load, this situation might be only temporary. It's quite likely that more capacity will be necessary someday.

The rate at which email flows into and out of an organization might be quite modest and easily handled by an untuned system. If a site's connection with the Internet is large, the possibility always exists that demand may increase dramatically in short order. This increase may be due to malevolence, error, transient conditions, or an organization's marketing department suddenly cranking up an email campaign without informing the information technology folks. These things happen. While it's not out of the question that an organization's email loading might increase dramatically overnight, overwhelming whatever resources might currently be in play, a well-tuned system will provide overhead to reduce the chance of a catastrophic outage due to a sudden increase in load. Further, if the system does become overwhelmed, a well-tuned system will handle these situations more gracefully and recover from them more quickly than a naively configured system will.

While a low-bandwidth Internet connection may very well provide a choke restricting the amount of email flowing through a gateway, it doesn't mean that someone won't try to send out more email than can fit in the pipe. An organization with a T1 connection to the Internet may find that it needs to get critical patch information out to a million customers as soon as possible and decide that email is the most efficient way to accomplish this goal. For example, if the informational message is 2KB in size, there are 1 million recipients for the message at 500,000 different email domains, and one-third of the T1 is available for transporting email data, then it could not possibly take less than four hours to get all the email out. This estimate assumes that our email server is arbitrarily fast, no delays occur on the Internet, and everyone else's server is up and ready to go.

Unfortunately, real life is messier than this scenario. It's entirely possible that the folks responsible for sending these messages won't consider how badly their mailing will slam the email gateway, and they may not even be aware of how much (or how little) bandwidth exists between them and the Internet. The email server almost certainly will become overwhelmed with the sudden load. It will take a great deal of time to accept all those messages. This process will consume resources within the machine that will slow its ability to send those messages out to the Internet. If this scenario actually occurred, it's entirely possible that the email server would still be working on sending this email out days after it received the first message.

Even if the list of email addresses is of high quality, a fair percentage of the destination email addresses will not exist, potentially generating hundreds of megabytes of bounced email notifications. These notifications are extra messages that will return to the server, adding to its load. Some email addresses will be for hosts that should exist but don't respond for days. Even if this group represents a small percentage of the total number of recipients, it might entail several or many thousands of messages that can slow down the email server's queues for many days. While considering the sudden processing of 1 million email messages is an extreme example, any email system can experience significant problems handling sudden message volumes several orders of magnitude smaller than this case.

With today's Internet, it would be remiss to ignore the possibility of havoc caused to email servers by self-replicating viruses found in message attachments. Busy email gateways have been shut down because of these attacks [CER99]. In such cases, it is usually better if the shutdown occurs because someone made the decision to take this step, rather than because the gateway couldn't handle the load.

Finally, even a single careless message can cause a great deal of disruption to an email server. With today's drag-and-drop desktop operating systems, some simple-to-perform actions can have serious consequences. On most systems, the actions required to email a 100-word document are the same as those required to send a 100MB presentation or spreadsheet, and often a user is not aware of just how large the documents they're working on might be. On more than one occasion, the sending of a single ill-advised document has caused multihour email disruptions in large organizations.

A well-tuned email server provides not only additional capacity to handle high volumes of email, but also headroom against the occasional incident. Even if mishaps whether accidental, caused by emergency, or due to maliciousness are rare, email has become so important to most organizations that any outage can significantly disrupt business. Even if day-to-day email throughput doesn't require expensive hardware and hours of configuration, some relatively simple and inexpensive modifications to an existing system, if they can prevent even a single noticeable outage caused by transient events, can produce significant returns on investment.