Mail servers

A mail server, or mail hub, is a central server to handle all email traffic to and from a local network. Workstations on the network route all mail through the hub rather than routing it directly to the recipient. The hub rewrites the header of all of the outgoing messages so that they appear to come directly from the hub. Received mail is automatically routed to the hub and spooled there; none of the client workstations receive mail directly. There are a number of advantages to this system:

Addressing is simplified. All mail is addressed to one machine, so that outside users do not have to be concerned about multiple email addresses for a given site.
All mail is spooled centrally, making management easier.
Client machines are insulated from the outside world; there is no need for the name of a client machine to be known outside of the local network. This adds an extra level of security.
There is no need to configure mail on each client machine; a simple sendmail.cf that can be copied to each machine will suffice. Any changes in the mail configuration need only be done on the hub.
Client machines do not have to be aware of changes in network routing and do not have to queue messages; they simply send mail to the hub for routing, which takes care of everything.

There are, however, some disadvantages as well:

The hub needs to know about all of the users on the network. This is fine if accounts are already centralized using NIS or some other data sharing system; otherwise, accounts or aliases for all users must be set up on the hub. This complicates account administration.
There can be performance problems. The use of the hub incurs extra delays in transport. Also, if there are a lot of users or a lot of mail exchanged, the hub can become overloaded.

Configuring a mail hub

Several things must be done to configure a mail hub:

A client sendmail.cf must be created. This will tell sendmail to route all mail through the hub, and to rewrite addresses so that outgoing mail appears to have come from the hub rather than the client machine.
A DNS MX record must be created for each client machine, directing all mail addressed to the client to the hub.
The sendmail configuration on the hub must be changed so that mail addressed to a client machine is re-written to be addressed to the hub.
If users are going to read mail on the client machines, the system must be set up to NFS mount the hub's mail spool on all of the clients.

Client configuration

To configure a client machine on a network using a mail hub, there are two basic things that must be done:

Configure delivery agents to direct mail to hub
Configure rulesets to rewrite sender address to appear to be from the hub

This is accomplished by making a special client sendmail.cf. How this is done will vary between versions of sendmail. Generating this file by hand can be complex, and varies between versions of sendmail. However, it is also possible to generate this file using M4, as outlined in the section on Configuring sendmail. Here is the M4 code that would be used to generate a client sendmail.cf:

	include(`../m4/cf.m4')
	VERSIONID(`$Id: servers.html,v 1.4 1996/09/03 22:45:17 uthuppur Exp $')
	OSTYPE(unknown)
 
	MASQUERADE_AS(indiana.edu)
	FEATURE(always_add_domain)
 
	EXPOSED_USER(root)
	EXPOSED_USER(postmaster)
	EXPOSED_USER(MAILER_DAEMON)
 
	FEATURE(nullclient, mail-relay.indiana.edu)

Here, indiana.edu would be replaced with the name of the mail hub.

DNS configuration

In order to have mail addressed to client machines automatically delivered to the hub, MX records must be created for each client machine. The MX record for each client machine should point to the mail hub. If name service is administered off-site, you will have to ask your DNS administrator to make these changes.

The primary file for your DNS zone should contain entries for each client machine. They will look something like this:

client_hostname		IN	A	123.45.6.7
			IN	HINFO	SPARC 10 Solaris

A new MX record should be added immediately after the A record, pointing to the mail hub:

client_hostname		IN	A	123.45.6.7
			IN	MX	10 mail_hub
			IN	HINFO	SPARC 10 Solaris

The "10" in the MX record specifies the priority of the mail exchanger; this only comes into play if there is more than one MX record. Because only the hub will be handling mail, each client machine will have only one MX record, pointing to the hub.

After the file has been reconfigured, the SOA record must be updated and the nameserver must be told to reload the file. For more details, see your DNS documentation.

Hub configuration

Although MX entries allow mail addressed to a client to be redirected to the hub, this is not sufficient by itself; since the mail is still addressed to the client, the hub will attempt to deliver the message to the client and fail. There are two ways to solve this problem:

Change the address re-writing rules in the hub's sendmail.cf so that mail addressed to a client machine gets re-addressed to the hub. This method is beyond the scope of this document.
Add the hostnames of client machines to the class macro w in sendmail.cf. Class macro w is a list of names that the hub can go by. If the client machines are on this list, then the hub will receive mail addressed to a client machine as if it were addressed to the hub. For example, if a hub had three clients, with hostnames foo, bar, and baz, the following line would be added to the hub's sendmail.cf:
```
          Cw foo bar baz
    
```
These need not be on the same line; there may be multiple Cw entries in sendmail.cf to make formatting more readable.

Mail spool configuration

If the mail spool is to be accessed on multiple machines, it must be exported to each of the client machines, and the fstab or vfstab on each client machine must be modified to automatically mount the mail spool. For details on how to do this, see the sections on NFS in Integrating Your Machine with the Network

Terms used: mail server, mail hub, sendmail, sendmail.cf, DNS, MX record, NFS, m4.