Sendmail
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 to be used.
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 chore. The first actual transfer of a mail message file from one host to another didn't take place until 1972, where email began to 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, and this continued until the ARPANET standardized on TCP/IP in 1982. A new protocol, SMTP, materialized for message transporting. 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 Internet began to expand and be widely utilized.
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, that 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 online and offline sources of information 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.
After installation, the sendmail executable is placed in the /usr/sbin directory.
Sendmail's lengthy and detailed configuration file (sendmail.cf) is installed in /etc. You should not edit the sendmail.cf file directly unless you know exactly what you are doing, due to the fact it is very lengthy and complex. Instead, to make configuration changes to Sendmail, edit the /etc/mail/sendmail.mc file and use the included m4 macro processor to create a new /etc/sendmail.cf (after backing up the original /etc/sendmail.cf, 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 /etc/mail 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 to the virtusertable file:
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
A default sendmail.cf file will be installed in /etc. The default 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.
If you need to generate a new /etc/sendmail.cf file to configure Sendmail, you should utilize the m4 macro processor. If you ever edit the /etc/mail/sendmail.mc to add functionality to Sendmail, backup your current /etc/sendmail.cf file, generate a new one by executing the m4 /etc/mail/sendmail.mc > /etc/sendmail.cf command, and add any previous changes from the /etc/sendmail.cf you backed up to the new /etc/sendmail.cf file. After creating a new /etc/sendmail.cf, you must restart Sendmail to make it take effect. The easiest way to do this is to type the 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, which is installed in /usr/share/sendmail-cf.
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/sendmail.cf files are configured.
Masquerading
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 mail.bigcorp.com that does all their mail. On that machine, add the names of machines for which mail.bigcorp.com will handle mail to /etc/mail/local-host-names. Here is an example:
# sendmail.cw - include all aliases for your machine # here. torgo.bigcorp.com poodle.bigcorp.com devel.bigcorp.com |
Figure 16-2. Example settings for local-host-names
On the other machines, torgo, poodle, and devel, edit /etc/sendmail.cf to "masquerade" as mail.bigcorp.com when sending mail and to forward any local mail processing to bigcorp.com. Find the DH and DM lines in /etc/sendmail.cf and edit them as such:
# who I send unqualified names to
# (null means deliver locally)
DRmail.bigcorp.com
# who gets all local email traffic
DHmail.bigcorp.com
# who I masquerade as (null for no masquerading)
DMbigcorp.com |
Figure 16-3. Example settings for sendmail.cf
With this type of configuration, all mail sent will appear as if it were sent from bigcorp.com, and any mail sent to torgo.bigcorp.com or the other hosts will be delivered to mail.bigcorp.com.
Stopping Spam with Sendmail
Email spam can be defined as unnecessary and unwanted email received by a user that probably does not know the sender and never requested the communication. It is a very 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:
badspammer.com 550 Go away and don't spam us anymore tux.badspammer.com OK 10.0 RELAY |
Figure 16-4. Example settings for access
Because /etc/mail/access 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:
LDAPROUTE_DOMAIN('yourdomain.com')dnl
FEATURE('ldap_routing')dnl |
Figure 16-5. Example settings for LDAP in sendmail.mc
 | 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/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 15.