Red Hat Linux uses Sendmail as its MTA to deliver messages, whether they are intended for users on the same system or for remote destinations. Other MTAs do exist (and can be used well with Red Hat Linux), but most administrators elect to use Sendmail as their MTA due to its power, scalability, and compliance to important Internet standards, such as SMTP.

Sendmail's core duty, like other MTAs, is to safely move email between hosts, usually utilizing the SMTP protocol. However, Sendmail is highly configurable, allowing you to control almost every aspect of how email is handled, including the protocol used.


Sendmail's roots can be traced to the birth of email, occurring in the decade before the birth of ARPANET, the precursor to the Internet. In those days, every user's mailbox was a file that only they had rights to read, and mail applications simply added text to that file. Every user had to wade through their mail file to find any old mail, and reading new mail was a equally difficult. The first actual transfer of a mail message file from one host to another did not take place until 1972, when email began to be moved by FTP over the NCP network protocol. This easier method of communication quickly became popular, even to the point where it made up most of ARPANET's traffic in less than a year.

However, a lack of standardization between competing protocols made email much harder to send from some systems. This continued until the ARPANET standardized on TCP/IP in 1982. Soon after, a new protocol, SMTP, materialized for transporting email messages. These developments, combined with HOSTS files being replaced with DNS, allowed full-featured MTAs to materialize. Sendmail, which grew out of an earlier email delivery system called Delivermail, quickly became the standard as the email began to expand and become widely used.

Purpose and Limitations

It is important to be aware of what Sendmail is and what it can do for you as opposed to what it is not. In these days of monolithic applications that fulfill multiple roles, you might initially think that Sendmail is the only application you need to run an email server within your organization. Technically, this is true, as Sendmail can spool mail to your users' directories and accepts new email via the command line. But, most users actually require much more than simple email delivery. They usually want to interact with their email using an MUA that uses POP or IMAP to download their messages to their local machine. Or, they may prefer a Web interface to gain access to their mailbox. These other applications can work in conjunction with Sendmail and SMTP, but they actually exist for different reasons and can operate separately from one another.

It is beyond the scope of this section to go into all that Sendmail should or could be configured to do. With literally hundreds of different options and rule sets, entire volumes are dedicated to helping explain everything that can be done and how to fix things that go wrong. You should consult the many excellent resources on Sendmail in order to shape it to fit your exact specifications.

However, you should understand what files are installed with Sendmail by default on your system and know how to make basic configuration changes. You should also be aware of how to stop unwanted email (spam) and how to extend Sendmail with the Lightweight Directory Access Protocol (LDAP).

The Default Sendmail Installation

While you can download the source code for Sendmail and build your own copy, many users prefer to use the version of Sendmail installed by default with their Red Hat Linux system. You can also use the Red Hat Linux CD-ROMs to reinstall the sendmail RPM at a later point. Be aware that you must alter the default configuration file for Sendmail to use it as a mail server for more than one host. See the Section called Common Sendmail Configuration Changes for details.

After installation, the sendmail executable is placed in the /usr/sbin/ directory.

Sendmail's lengthy and detailed configuration file,, is installed in the /etc/ directory. You should avoid editing the file directly. Instead, to make configuration changes to Sendmail, edit the /etc/mail/ file and use the included m4 macro processor to create a new /etc/ (after backing up the original /etc/, of course). More information on configuring Sendmail can be found in the Section called Common Sendmail Configuration Changes.

Various Sendmail configuration files are installed in the /etc/mail/ directory including:

Several of the configuration files in /etc/mail/, such as access, domaintable, mailertable and virtusertable, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes you make to these configurations in their database files, you must run the makemap hash /etc/mail/<name> < /etc/mail/<name> command, where <name> is the name of the configuration file to convert.

For example, if you want all email addressed to any account to be delivered to , you need to add a line to the virtusertable file:

Figure 16-1. virtusertable example

Then, to add this new information to the virtusertable.db file, execute makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable as root. This will create a new virtusertable.db that contains the new configuration.

Common Sendmail Configuration Changes

Although a default file is installed in /etc/ during the Red Hat Linux installation process, you will need to alter it to utilize some of the program's more advanced features.

When altering the Sendmail configuration file, it is best generate a entirely new /etc/ file instead of editing an existing one.


Before changing the file, it is a good idea to backup the default version.

To add the desired functionality Sendmail edit the /etc/mail/ file. When you are finished, use the m4 macro processor to generate a new by executing the m4 /etc/mail/ > /etc/ command. After creating a new /etc/, you must restart Sendmail to make it take effect. The easiest way to do this is to type the /sbin/service sendmail restart command as root.

By default, the m4 macro processor is installed with Sendmail. The m4 macro processor is included with the sendmail-cf package.


The default does not allow sendmail to accept network connections from any host other than the local computer. If you want to configure sendmail as a server for other clients, please edit /etc/mail/ and change DAEMON_OPTIONS to also listen on network devices or comment out this option all together. Then regenerate /etc/ by running:

This configuration should work for most SMTP-only sites. It will not work for UUCP (UNIX to UNIX Copy) sites; you will need to generate a new if you must use UUCP mail transfers.

You should consult the /usr/share/sendmail-cf/README file before you edit any of the files in the directories under the /usr/share/sendmail-cf directory, as they can affect how future /etc/ files are configured.


One common Sendmail configuration is to have a single machine act as a mail gateway for all the machines on the network. For instance, a company may want to have a machine called that does all their mail. On that machine, add the names of machines for which will handle mail to /etc/mail/local-host-names. Here is an example:

# - include all aliases for your machine
# here.

Figure 16-2. Example settings for local-host-names

On the other machines, torgo, poodle, and devel, edit /etc/ to "masquerade" as when sending mail and to forward any local mail processing to Find the DH and DM lines in /etc/ and edit them as such:

# who I send unqualified names to
# (null means deliver locally)
# who gets all local email traffic
# who I masquerade as (null for no masquerading)

Figure 16-3. Example settings for

With this type of configuration, all mail sent will appear as if it were sent from, and any mail sent to or the other hosts will be delivered to

Stopping Spam with Sendmail

Email spam can be defined as unnecessary and unwanted email received by a user who never requested the communication. It is a disruptive, costly, and widespread abuse of Internet communication standards.

Sendmail has made it relatively easy to block new spamming techniques being employed to send junk email using your system. It even blocks many of the more usual spamming methods by default. You would need to consciously activate them by changing your /etc/mail/ file in a particular way to make your system susceptible.

For example, forwarding of SMTP messages, also referred to as SMTP relaying, has been disabled by default since Sendmail version 8.9. Before this change occurred, Sendmail would direct your mail host ( to accept messages from one party ( and send them to a different party ( Now, however, you have to specifically tell Sendmail to permit a domain to relay mail through your domain. Simply edit the /etc/mail/relay-domains file and restart Sendmail by typing the service sendmail restart command as root to activate the changes.

However, many times, your users may be bombarded with spam from other servers throughout the Internet that are beyond your control. In these instances, you can use Sendmail's access control features available through the /etc/mail/access file. As root, add the domains that you would like to block or specifically allow access, such as:       550 Go away and do not spam us anymore   OK
10.0                 RELAY

Figure 16-4. Example settings for access

Because /etc/mail/access.db is a database, you need to use makemap to activate your changes by recreating the database map. This is easily done by running the makemap hash /etc/mail/access < /etc/mail/access command as root.

This example shows that any email sent from would be blocked with a 550 RFC-821 compliant error code and message back to the spammer, except for email sent from the sub-domain, which would be accepted. The last line shows that any email sent from the 10.0.*.* network can be relayed through your mail server.

As you might expect, this example only scratches the surface of what Sendmail can do in terms of allowing or blocking access. See the /usr/share/doc/sendmail/ for more detailed information and examples.

Using Sendmail with LDAP

Using the Lightweight Directory Access Protocol (LDAP) is a very quick and powerful way to find specific information about a particular user from a much larger group. For example, you could use an LDAP server to look up a particular email address from a common corporate directory by a user's last name. In this kind of implementation, LDAP is largely separate from Sendmail, with LDAP storing the hierarchical user information and Sendmail only being given the result of LDAP queries in pre-addressed email messages.

However, Sendmail supports a much greater integration with LDAP, where it uses LDAP to replace separately maintained files, such as aliases and virtusertables, on different mail servers that work together to support a medium- to enterprise-level organization. In short, you can use LDAP to abstract the mail routing level from Sendmail and its separate configuration files to a powerful LDAP cluster that is being leveraged by many different applications.

The current version of Sendmail contains support for LDAP. To extend your Sendmail server using LDAP, first get an LDAP server, such as OpenLDAP, running and properly configured. Then, you need to edit your /etc/mail/ to include:


Figure 16-5. Example settings for LDAP in


This is only for a very basic configuration of Sendmail with LDAP. Your configuration should differ greatly from this depending on your implementation of LDAP, especially if you wish to configure several Sendmail machines to use a common LDAP server.

Consult /usr/share/doc/sendmail/ for detailed LDAP routing configuration instructions and examples.

Next, recreate your /etc/ file by running m4 and restarting Sendmail. See the Section called Common Sendmail Configuration Changes for instructions on doing this.

For more information on LDAP, see Chapter 19.