6. The Mail Hub and Delivery Agents

Instead of having each individual workstation in a network handle its own mail, it can be advantageous to have a powerful central machine that handles all mail. Such a machine is called a mail hub and is analogous to the way Federal Express originally handled package delivery. In the old days, when you sent a package via Federal Express from, say, San Francisco to Paris, or even from San Francisco to Los Angeles, that package was first sent to Memphis, Tennessee (see Figure 6.1). The Memphis location was the Federal Express hub. All packages, no matter what their origin or destination, were sent to the hub first and then were transported outward from there.

Figure 6.1: The Federal Express hub approach

The advantage to this approach is that the Memphis hub was the only Federal Express office that needed the special knowledge of how to deliver packages anywhere in the world. [1] Local offices needed to know only how to deliver to the hub.

[1] Federal Express now has several regional hubs.

In a similar way, your workstations can be thought of as the outlying offices (client machines) and your central mail-handling machine as the hub. For mail, the hub performs the following functions for the entire site:

• All incoming mail is sent to the hub, meaning that no mail is sent directly to a client machine. This hub approach has several advantages. No client needs to run a sendmail daemon to listen for mail. No client's name needs to be known to the outside world, thus insulating client machines for easier security.

• Rather than having each client send its mail directly to the outside world, all outgoing mail from clients is sent to the hub, and the hub then forwards that mail to its ultimate destination. The advantages are that clients do not need to be continually aware of changes in the Internet; deferred mail queues on the hub, not on the client machine, making management simpler; and a single, simple sendmail.cf file may be shared by, or distributed to, all the clients.

• All outgoing mail is modified so that it appears to have originated on the hub. The alternative is to have reply mail returned directly to each client. The advantages of the hub approach are that all mail appears to come from a single, giant machine (making replying to mail easier).

• All mail to local users is delivered to, and spooled on, the hub. The alternative is to have one or more separate mail spool directories on separate client machines. The advantages of the hub approach are that all local delivery is handled by one machine, that no client needs to accept mail for local delivery, and that management is easier with a single spool.

There are disadvantages to the hub approach when a site is composed of differing machine architectures and when machines are spread over many networks:

• At sites where there is a huge amount of mail constantly flowing, the load on the hub can become excessive. This can cause client mail to be queued rather than sent, even when mail is destined for local delivery.

• For the hub to work, it needs to know the login names of all users on the system. Either it must have a master /etc/passwd file that is the union of all systems' passwd files, or it must use NIS to access such a master file. [2] In the absence of universal user passwd knowledge, it must have an aliases file entry for every local user.

  [2] See Managing NFS and NIS by Hal Stern (O'Reilly & Associates, 1992).

• Because all mail passes through the hub, rather than being sent to the recipient directly, there are unavoidable delays. Those delays are negligible at small sites (a couple of hundred or so users) but can become significant at sites with a huge number of users.

• If a client machine has direct UUCP connections or is connected to multiple networks, a more complex configuration file is needed.