Sendmail

History

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 the localhost. 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, sendmail.cf, is installed in the /etc/mail/ directory. You should avoid editing the sendmail.cf file directly. Instead, to make configuration changes to Sendmail, edit the /etc/mail/sendmail.mc file, back up the original /etc/mail/sendmail.cf, and then use the included m4 macro processor to create a new /etc/mail/sendmail.cf. 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:

• access — Specifies which systems can use Sendmail for relaying email.

• domaintable — Allows you to provide domain name mapping.

• local-host-names — The place where you include all aliases for your machine.

• mailertable — Specifies instructions that override routing for particular domains.

• virtusertable — Permits you to do a domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine.

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 domain.com account to be delivered to <bob@otherdomain.com>, you need to add a line similar to the one below to the virtusertable file:

@domain.com       bob@otherdomain.com

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 containing the new configuration.

Common Sendmail Configuration Changes

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

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

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

To add the desired functionality Sendmail edit the /etc/mail/sendmail.mc file. When you are finished, use the m4 macro processor to generate a new sendmail.cf by executing the m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf command. After creating a new /etc/mail/sendmail.cf, 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 but is part of the m4 package.

Important

The default sendmail.cf 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/sendmail.mc and change DAEMON_OPTIONS to also listen on network devices or comment out this option all together. Then regenerate /etc/mail/sendmail.cf by running: m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

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 sendmail.cf 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/mail/sendmail.cf files are configured.

FEATURE(always_add_domain)dnl
FEATURE(`masquerade_entire_domain')
FEATURE(`masquerade_envelope')
FEATURE(`allmasquerade')
MASQUERADE_AS(`bigcorp.com.')
MASQUERADE_DOMAIN(`bigcorp.com.')
MASQUERADE_AS(bigcorp.com)

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/sendmail.mc 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 (x.org) to accept messages from one party (y.com) and send them to a different party (z.net). 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 in this example:

badspammer.com       ERROR:550 "Go away and do not spam us anymore"
tux.badspammer.com   OK
10.0                 RELAY

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 badspammer.com would be blocked with a 550 RFC-821 compliant error code and message back to the spammer, except for email sent from the tux.badspammer.com 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/README.cf 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/sendmail.mc to include the following:

LDAPROUTE_DOMAIN('yourdomain.com')dnl
FEATURE('ldap_routing')dnl

	Note
	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/README.cf for detailed LDAP routing configuration instructions and examples.

Next, recreate your /etc/mail/sendmail.cf 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.