Sendmail is frequently employed as a mail relay server for a network. That is, you configure mail clients to send all outgoing mail via the Linux sendmail server. Out of the box, though, recent versions of sendmail refuse such relay attempts as an antispam precaution. You can loosen this configuration using any of several options, specified within a FEATURE specification:

As an example, suppose you want to use the access_db method. You might then include a line like the following in your sendmail .mc file:

FEATURE(`access_db')

Some configurations add more options within the parentheses—say, to specify the method of encoding data and the access database filename (normally /etc/mail/access.db). The access_db and relay_hosts_only options are the safest ways to configure mail relays, and they both use the same access.db configuration file. This file is a binary database file that’s built from a text-mode file, typically called access. This text-mode file consists of lines that take the following format:

                     host.specification  CODE

In addition to these lines, the file may contain additional modifiers, as well as comments that begin with hash marks (#). The host.specification takes the form of IP addresses, IP address groups (specified by incomplete IP addresses, as in 192.168.24 for the 192.168.24.0/24 network), hostnames, domain names, or email addresses. If you use relay_hosts_only, though, specifications must match individual computers, not groups of computers. The CODE tells sendmail what to do with mail from the specified computers:

As an example of an access file, consider the following:

localhost.localdomain  RELAY
localhost              RELAY
127.0.0.1              RELAY
spammer@abigisp.net    DISCARD
iamspam.biz            REJECT
192.168.24             RELAY

The first three lines tell sendmail to relay mail that’s generated locally (on the localhost address, using any of three common names for that system). Such lines are common in default sendmail configurations. The next line tells the system to quietly discard mail from spammer@abigisp.net; but this rule has no effect on mail from other users of http://abigisp.net. The fifth line rejects (refuses with a bounce message) mail from the iamspam.biz domain. The last line authorizes sendmail to relay mail that originates from the 192.168.24.0/24 address range, which is presumably the server’s own local network.

Once you’ve created an access file, you must convert that file to binary form using the makemap command:

# makemap hash /etc/mail/access.db < /etc/mail/access

Many distributions include an appropriate command as part of their sendmail startup scripts, so you may not need to explicitly enter this command.

Mail relaying involves at least three systems: the source, the destination, and the relay. The destination requires no special configuration, and the last section described the relay itself. On the source side, though, sendmail can require special configuration. Sometimes, the source computer doesn’t run sendmail at all; a source might be a desktop system running a mail client. You can, though, use sendmail as a mail source. For instance, the source system might be a Linux computer that runs programs that assume the local computer is running sendmail and that therefore try to send mail using the server. Another configuration is to have a Linux computer serve as both a relay and a source for another relay. For instance, you might want a Linux server to handle mail for your local network but to relay it through an ISP’s mail server. In either case, you must configure sendmail to use another computer as a relay.

Most distributions’ default sendmail configurations don’t use a relay. You can add one to the mix by adding one or more lines to your .mc configuration file:

define(`LOCAL_RELAY', `outgoing.mail.relay')
define(`MAIL_HUB', `outgoing.mail.relay')
define(`SMART_HOST', `outgoing.mail.relay')

The first line applies to outgoing mail that lacks a domain or machine name (for instance, mail addressed to ben); the second applies to mail addressed to users on the computer on which sendmail is running (for instance, ben@armonica.pangaea.edu, where sendmail is running on http://armonica.pangaea.edu); and the third applies to mail addressed to all other systems.

A somewhat simpler way to implement relaying is to use another line:

FEATURE(`nullclient', `outgoing.mail.relay')

This line, however, is intended for use in otherwise nearly empty configuration files. Only the FEATURE(`nocanonify') option should be used with it.

In all these cases, you must adjust the outgoing.mail.relay to point to the server you want to use as a relay.

Particularly when your domain has multiple mail servers or is connected to multiple networks, you may need to configure the system to forward mail in different ways depending on its source or destination. For instance, consider the “gatekeeper” Linux mail server in Figure 13-2. The intent of a configuration like this is to use Linux to provide useful preliminary processing on incoming mail, such as spam filtering and directing email to the correct internal mail server. This server can also pass mail between the two internal servers and filter outgoing mail.

Figure 13-2. Linux can serve as a gatekeeper for one or more other mail servers

Typically, the Linux SMTP server is listed as the domain’s MX server, so external systems will deliver mail to it. Likewise, the internal mail servers, and perhaps individual client systems, can deliver outgoing mail to the Linux server. The trick is to configure the Linux server to deliver mail correctly, without getting into an infinite loop. For instance, you don’t want the server to attempt to deliver mail for your domain back to itself, because this creates an infinite loop. One solution is to use a feature known as a mailer table. This can be activated with a line like this in the sendmail .mc file:

FEATURE(`mailertable')

This entry may include additional options, such as a pointer to the mailer table database file (typically /etc/mail/mailertable.db). Check your .mc file for the default entry, if it exists. As with many other sendmail files, this one relies on a text-mode file that’s converted into a binary database file. The text-mode mailertable file contains entries like this:

.subnet1.pangaea.edu  smtp:exchange1.pangaea.edu
.subnet2.pangaea.edu  procmail:/etc/procmailrcs/exchange2

This configuration tells the server to deliver mail addressed to any computer in the http://subnet1.pangaea.edu subdomain to http://exchange1.pangaea.edu using SMTP and to deliver mail addressed to any computer in the http://subnet2.pangaea.edu subdomain using Procmail and the /etc/procmailrcs/exchange2 Procmail rule set. The first line results in a simple forwarding and so may not be extremely useful; you can just set up your DNS MX record to point directly to that computer. The second line, though, enables you to employ Procmail, which can be used as an interface to spam filters and other tools, on mail passed through the server. Procmail is described in more detail later in this chapter, in Section 13.5.4.