Section 36.1. Objective 2: Using Sendmail

36.1. Objective 2: Using Sendmail

First, it's important to understand Sendmail's function in regard to email. To do this, it is necessary to learn some terminology. Sendmail is a Message Transfer Agent (MTA)the oldest one in existence. The MTA has two jobs: to ensure that mail messages are transferred between entities and to place those messages in a destination directory. The MTA can also authenticate parties, but this is just part of its function of transferring messages between users or hosts.

In contrast, a POP or IMAP server is called a Message Delivery Agent (MDA). The MDA's job is responsible for providing mechanisms that allow users to retrieve their messages. Both the MTA and MDA are usually server-based functions. The tool that you use to send and receive email is called a Message User Agent (MUA). The MUA is most often a client-side tool, though with web-based mail, the MUA's function becomes complicated to some extent, because the ability to send and receive email is more evenly split between the web browser and a server.

Sendmail is an old MTA; it has has been in constant use for decades. It is the subject of one of the largest O'Reilly books, the well-known "bat book," so called because it has a bat on its cover. This section in no way is meant to replace that remarkable achievement. However, this section will help you get a handle on how much you need to learn about Sendmail in order to pass the LPI Level 2 Exam. But before we move on with the specifics of Sendmail configuration , it is important to understand that other MTAs also exist. Table 36-1 lists the most popular MTAs used with Linux servers.

Table 36-1. Common MTAs
MTA	Available at	Description
Sendmail	http://www.sendmail.org	The traditional MTA. This chapter's examples are based on Sendmail from the Sendmail Consortium.
Postfix	http://www.postfix.org	A common Sendmail replacement, considered more lightweight.
Qmail	http://www.qmail.org	Often used to replace Sendmail as the network MTA.
Exim	http://www.exim.org	A relatively new replacement, the default MTA in the Debian distribution.

Not only is the configuration of MTAs an important skill to enable mail service, but many other services also demand an MTA and interact with it. For example, mailing list servers such as Majordomo (discussed later in this chapter) use an MTA.

36.1.1. Sendmail Configuration

A properly configured email server doesn't need constant attention. When everything's configured properly, few things can go wrong. And when something does go wrong, the protocol used by Sendmail and other Internet MTAs, the Simple Mail Transfer Protocol (SMTP), tends to keep messages buffered until the systems are up again.

In this chapter you will be guided through the configuration and securing of your Sendmail server. The examples are based on a fairly new version of Sendmail, 8.12.10. As Sendmail has had its share of security issues, you are strongly encouraged to upgrade your Sendmail software to a recent version. If your Linux distribution is not very new, check your distribution's web site for erratas and upgrades. Also, antispam features are better supported in recent versions of Sendmail.

The Continuing Importance of Sendmail

Some controversy exists in LPI circles concerning the Sendmail Objective. "Why cover Sendmail when so many have gone over to Qmail or Postfix?" people often ask. The answer is relatively simple: tradition.

Yes, Sendmail has a long, storied history of buffer overflows and security problems. Its longevity has helped contribute to code bloat and needless difficulty in configuration. Yes, other daemons have been written "from scratch" with security in mind, whereas Sendmail was put together in ragtag fashion for years. But again, Sendmail is used by most of the corporations and organizations hiring people. Sendmail also underwent a complete rewrite some years ago. Even though configuring Sendmail often requires the administrator to know its history and a good many other associated protocols (e.g., DNS), it remains the de facto standard.

Nearly 75% of all email worldwide is still handled by Sendmail. This means that regardless of your preference or passion, you are likely to come across a Sendmail installation in your career as a Linux professional.

Increasingly, Sendmail is being replaced by other MTAs by major Linux distributions. One day, LPI will find in its review of small and medium enterprises that the balance has tipped toward newer MTAs. When it does, you can rest assured that the Objective will change, too.

Also, even though most Linux distributions offer other default MTAs, they still require you to know the same concepts and principles. Many of the practices are the same, too. So, if you know Sendmail, you'll be able to quickly learn other MTAs as well.

36.1.1.1. Building and editing configuration files: the m4 utility

The Sendmail configuration file, usually stored in /etc/mail/sendmail.cf, is designed to be easily understood by the mail server software. Unfortunately, email servers don't read files as humans do, and Sendmail has achieved a well-deserved reputation for being difficult to configure.

To remedy this, the creators of Sendmail decided to create a more human-readable set of macros to help configure the daemon. If you learn the basics of the Unix m4 macro language for which the macros are written and adapt the macros to your needs in a plain text file, you can use the m4 utility to convert your macro file into a valid sendmail.cf file.

Tip: The m4 utility is often not installed, even if Sendmail is the MTA used on the server. Use your package management utility (such as apt-get, rpm, or YaST) to install it.

Sendmail often ships with sample m4-based macro files. The default file is usually called sendmail.mc, but you may come across .mc files with different names as well. Some distributions ship with many sample .mc files, each designed to suit different purposes. All you have to do customize these .mc files to meet your own needs.

Many might be tempted to simply bypass using m4 and an .mc file and simply edit the sendmail.cf file directly. This is a mistake, because any changes you make directly to this file will be overwritten if you or an application later generates the sendmail.cf file from the macro file. And don't think that you or another person won't do that later on. For this reason, the recommended method is to edit only the macro file.

36.1.1.2. Additional configuration files

The sendmail.cf file is not the only file that is used to configure Sendmail. Various additional files exist in the /etc/mail directory.

Tip: Sendmail maintains much of its configuration information in a binary database format for the sake of efficiency. Therefore, after editing this information in various text files, you must convert them to a database format by running the makemap command and then restart Sendmail. For instance, to convert the /etc/mail/access file to Sendmail's database format, you would change to the /etc/mail directory and issue the following command:

Make sure that you understand the purpose of the following files:

access

Used to allow or deny access to systems and users. Starting with Version 8.9, Sendmail does not relay by default, so you can either use this file to override antirelaying settings in the sendmail.cf file or reconfigure the sendmail.cf file. To create the new access map, enter:

 makemap hash access < access

local-host-names

Allows you to inform Sendmail about the hostname of the computer.

virtusertable

Used to map incoming email to a local account. Using virtusertable, you can make sure that a message sent to one account (e.g., sales@oreilly.com) is actually sent to two users (e.g., james@oreilly.com and sandi@oreilly.com). Or, if you wish to set up a "catchall" email address to route mail with mistyped addresses, you can use the virtusertable file to which to route these messages to a particular user. To create the requisite binary file, issue the following command to read the source file that contains the virtusertable instructions:

 makemap hash /etc/mail/virtusertable < sourcefile

Older Sendmail systems might expect you to use dbm rather than hash in the previous command. You can give the source file any name you wish.

genericstable

Used for outbound mail. Allows you to rewrite local usernames (e.g., james@albion.stangernet.com) so that they appear to have originated from a different host or domain. Mail can even appear to originate from a different username. To create the requisite binary file, run the following command so that the genericstable file is read to create the genericstable.db file:

 makemap -r hash genericstable.db < genericstable

Messages are rewritten only if they originate from your system. Incoming messages are not affected.

genericsdomain

Tells your system which addresses are considered local and which are considered remote. Populate the file by using the following command:

 hostname -long

Place the results of this command into the genericsdomain file.

mailertable

Can route email from remote systems. Seen by some as a better way to route messages than using virtusertable, because it is faster and more capable. Often used to configure a Sendmail system to act as a backup email system, or MX host.

domaintable

Can be used, for example, if a company or organization needs to make a transition from an old domain name to a new one To create the actual binary file, issue the following command:

 makemap hash /etc/mail/domaintable < /etc/mail/domaintable.txt

aliases

Used to redirect mail for local recipients. You can use the file to make sure that mail sent to the root account, for example, is mailed to your standard user account. The syntax for each line of the file is:

 original_account: user

where user is the account that will receive email sent to original_account. The aliases file must be processed into an aliases.db database that Sendmail can read using the following command:

 makemap hash /etc/mail/aliases.db < /etc/mail/aliases

The aliases file works only for mail sent to local accounts (email addresses whose domains are local to your MTA's system). It is not used to change address information for outbound user accounts.

The /etc/mail directory does not have to contain all of the preceding files. The aliases file, for example, is usually found right off of the /etc directory. The other files need to be present only if the sendmail.cf file is configured to use these features. You will have to create these files yourself and use the m4 configuration files to configure the sendmail.cf file to refer to the files. You will learn more about the files relevant to the LPI Exam in later sections.

36.1.1.2.1. Restarting Sendmail

If you change any of the preceding files, you need to restart Sendmail. You can restart it in various ways, including any of the following:

 kill -HUP 'cat /var/run/sendmail.pid' killall -HUP sendmail /etc/rc.d/init.d/sendmail restart /etc/init.d/sendmail restart

or the following two-step procedure, using the PID of the sendmail process found through the ps command:

 ps aux | grep sendmail kill pid

The most universal method is to use the kill or killall command.

36.1.2. Securing Sendmail

One of the first steps you can take to secure Sendmail is to disable it altogether on hosts that don't need it. For example, you likely do not need Sendmail to process mail from other hosts if you are going to use it for internal mail (i.e., mail sent between users on the same system).

In an environment in which only a few MTAs handle email routing, the MTA daemon should be disabled on all the other hosts. Disabling the daemon still lets the system send email, but not receive it from remote hosts. When installing, most distributions specifically ask if you want to enable the Sendmail daemon. Fedora and RedHat, however, have traditionally enabled the Sendmail daemon automatically after installation without consulting the administrator. On those distributions and versions, unless the host is an email-routing MTA, disable the listening Sendmail daemon by entering:

 root@james mail# chkconfig --level 123456 sendmail off

Then verify that the service is disabled:

 root@james mail# chkconfig --list sendmail sendmail        0:off   1:off   2:off   3:off   4:off   5:off   6:off

On a more general level, MTA software needs to be given two pieces of information to be considered secure:

Which IP addresses or IP networks/subnetworks may use the mail server as a relaythat is, use the server to send email to anyone chosen by the originator. Without this restriction, your mail server will be used for unauthorized mail relaying. In other words, your Sendmail server can become a spam factory.
Which domains your mail server should accept email for. This simply means whom you're serving with your email server.

36.1.2.1. Defining a trusted network

No one wants to receive spam. Furthermore, you don't want to be an unwitting party that promotes spam. If you fail to configure Sendmail correctly, your mail server may very well be a so-called "open relay" that can be abused by spammers. Several public lists of open relays exist on the Internet, and most MTA software can easily be configured to reject incoming email if the originating mail server is blacklisted. If your mail server gets into one of these lists, you may face a difficult process getting off the list again. You may even have to pay to be removed from some of these lists. Table 36-2 describes a few of the open relay blacklists at the time of writing.

Table 36-2. Popular relay blacklists (RBLs)
Blacklist	URL
Open Relay Database	http://www.ordb.org
Spamhaus	http://www.spamhaus.org
Blitzed	http://www.blitzed.org
Composite Blocking List	http://cbl.abuseat.org
Distributed Server Blocking List	http://www.dsbl.org

36.1.2.2. The /etc/mail/access file

As discussed earlier, newer versions of Sendmail do not relay by default. Also, newer versions of Sendmail default to allowing only the local host to send email. If you want to allow your users to send email from their desktop computers via your Sendmail server, you will need to add the IP addresses of those computers to Sendmail's list of allowed senders. At the same time, this file is used when someone from the outside tries to send to you and therefore can be useful to stop spammers from reaching your users.

Earlier you learned that you can use the /etc/mail/access file to list the IP addresses, domains, and email addresses that can use the server. The input file that you write lists IP addresses, domains, and email addresses on the left side and the action to take on the right side. Table 36-3 describes the actions and results described in the input to the access file.

Table 36-3. Actions in access database
Action	Result
`OK`	Unconditionally accept the email for local delivery. Sendmail's default behavior is to OK all mail destined for the host. The explicit OK action is often used when other Sendmail rules would reject the email because of spam control or if the domain does not resolve.
`RELAY`	Accept the email for relaying through this Sendmail server. RELAY is also an OK to bypass other checks (spam control, etc).
`REJECT`	Reject the incoming email with a generic rejection message.
`DISCARD`	Silently discard the message. Only sender addresses or domains may be discarded, not IP addresses or networks.

The codes in Table 36-3 are all case-sensitive. Following is an example of what you can put in the input file:

 # This guy is a known spammer. nasty.spammer@random-mail.com    DISCARD # Drop all mail from this DNS domain. If the host trying to send mail # resolves into a host within the DNS domain, the mail is rejected. spam-r-us.net                    DISCARD # A friend of ours has an IP address that resolves to the # spam-r-us.net domain but we'd still like to receive his email. 10.45.34.203                     OK # Our local network is 1.2.3.0 - 1.2.3.255. Sendmail does not accept # CIDR notation (1.2.3.0/24) so you need to operate on the traditional # network boundaries. 1.2.3                            RELAY # Another known mail server may use your mail server for relaying: 172.20.45.23

Remember, once you make changes to the access file, you need to use the makemap command to re-create the access binary file.

36.1.2.3. Testing Sendmail configuration

If you'd like to check that your Sendmail server actually does what you configured it to do, you may run Sendmail in test mode. This starts Sendmail with a special interactive session, much like a terminal session. To enter test mode, first become root, as Sendmail sometimes requires this privilege. You can then use the -b and -t options to the sendmail command. A test mode session might look something like the following:

 root@james # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset>; <address>

You would then enter the following to look up relay settings:

 /map access 1.2.3 map_lookup: access (1.2.3) returns RELAY (0)

Notice in the preceding command that you precede everything you type with a forward slash. Now, issue a command that determines what happens when mail comes from the random-mail.com domain:

 /map access nasty.spammer@random-mail.com map_lookup: access (nasty.spammer@random-mail.com) returns DISCARD (0)

Notice that the email is discarded.

Using this testing mode is much easier than configuring an email client and sending email messagess to the SMTP server. To quit the session, enter the following:

 /quit

36.1.2.4. Defining accepted email domains: local-host-names and sendmail.cw

When setting up an email server, you probably know which domains it is supposed to handle. If the hostname of your server does not happen to be the exact name of the email domain, you need to add the domain to the file /etc/mail/local-host-names. This file defines local mail addresses for the host. If you run an old version of Sendmail, the filename is /etc/mail/sendmail.cw. The format of this file is easy: one domain per line:

 somedomain.com someotherdomain.com differentdomain.com

The /etc/mail/local-host-names file is a plain text file and does not need to be turned into a hash by makemap. However, you must force Sendmail to reread the file in order for the changes to apply. You can do this either by restarting Sendmail or, less disruptively, by sending it a SIGHUP signal as with many other daemons. You may then want to check that Sendmail has read and accepted the virtual domains. Enter test mode and check its configuration as follows:

 root @james mail# sendmail -bt ADDRESS TEST MODE (ruleset 3 is NOT automatically invoked) Enter <ruleset> <address>

Then enter:

$=w

You should see:

 [192.168.1.18] system localhost.localdomain localhost someotherdomain.com [127.0.0.1] somedomain.com differentdomain.com

Then quit the session:

 /quit

You can see in the sample output that some other domains appear in this list besides those in /etc/mail/local-host-names. This is because Sendmail, in accordance with the RFCs governing email, accepts mail for the host itself. It thus includes the host's IP addresses (in square brackets) and the hostnames that are associated with these IP addresses either in the /etc/hosts file or by DNS lookup.

When your mail server accepts multiple domains, be aware that you cannot have users with the same name in the different domains. For example, email to tom@somedomain.com and tom@someotherdomain.com will actually end up in the same person's inbox. If these two addresses happen to be read by the same person, this is OK. Otherwise, you need to configure your Sendmail server to understand and properly process virtual user accounts. This will be explained in detail later.

36.1.3. Delivering Email

A mail server works differently when it delivers mail to a remote server (SMTP delivery) and when it delivers mail to users on its own system (local delivery). SMTP delivery relies on either DNS information (the usual behavior) or on local transport mechanisms (normally used in company networks using the smart host facility). Local delivery happens when either a local user (found in the /etc/passwd file) or a virtual user exists on the system. In these cases, the MTA leaves mail in an inbox file or set of files located on the local system.

Tip: When users check their email from separate computers, this last part is not actually regarded as delivery, but retrieval, as it is the user's initiative to actively fetch the email. The MTA's job was done when it delivered the mail to a local mailbox. Retrieving the email does not involve the MTA at all; it is taken care of by other software, normally POP or IMAP server software that reads from the local mailbox when the user logs in.

36.1.3.1. SMTP delivery based on DNS lookup

You must know on the exam exactly how Sendmail uses DNS. An example will help you learn more about the process. Suppose you send an email to john.smith@somedomain.com. The email address consists of two parts: the local user part and the domain part. The local user part is what comes before the @ at sign, and the domain part is what comes after. Notice that no server name is given, just the domain name. This would seem to be incomplete information, but thanks to DNS, Sendmail can get the job done.

When delivering based on DNS, Sendmail (or any MTA, for that matter) asks a nearby DNS server for the server responsible for receiving the messages that it wants to deliver. In our case, it asks, "Which mail server should accept messages for somedomain.com?" Sendmail really does not care much at this point about the destination directory or even the user. Right now, it's interested in finding the server responsible for receiving messages for the whole domain. Usually, other MTAs don't know the answer. DNS does know, as long as a valid MX (standing for Mail eXchange) record exists in the DNS zone of the destination domain.

More technically, when the MTA wants to know where to send email for a domain, it does the equivalent of the following command:

 dig MX somedomain.com

From a DNS zone, an MX record returned for the zone looks something like this:

 somedomain.com.     1800    IN      MX      10 mail1.somedomain.com. somedomain.com.     1800    IN      MX      20 mail2.somedomain.com.

This output shows that somedomain.com has two MTAs running, mail1.somedomain.com and mail2.somedomain.com. These might be running Sendmail, or they might not. But they must be MTAs.

The numbers immediately in front of the mail server names (e.g., 10 for mail1.somedomain.com) indicate priorities. Lower numbers mean higher priorities, so mail1.somedomain.com has a higher priority than mail2.somedomain.com. As a result, if mail1.somedomain.com is unreachable for the moment, email messages will be sent to mail2.somedomain.com.

Tip: The first number given in the example (e.g., 1800) is the Time To Live (TTL) value associated with the IN entry. Many zones will list the TTL entry at the start of the output, rather than inline with the actual DNS entries.

In the preceding scenario, mail1 is called the primary server, and mail2 (along with any other nonprimary servers) is called a secondary server or secondary MX. Secondary mail servers check the DNS MX information when trying to deliver mail, so that if your mail server has suffered a major failure and will be permanently down, you could establish a new primary mail server, change the DNS information, and be up and running again.

When you send an email message, your outgoing mail server will know what to do with the priority numbers. If a primary mail server is unavailable, it automatically tries the second best mail server, the third, and so on. If no mail servers are available at all (which is quite possible in the case of a major power failure or other disaster), the company may have made arrangements so that another company or its ISP will be listed as one of the servers. If not, the sender MTA will just wait for some time and then try to send the email again, working its way through the MX priority list. The RFCs recommend that an MTA wait four days before giving up. Most MTAs send a warning to the original sender after about five hours, saying that the email is not yet delivered but that the MTA will continue to try for a given time.

It is perfectly acceptable to have more than one server with the same priority level. Thanks to the retry mechanisms of SMTP, the sender MTA will try again if one of the same-priority MXs is down, and this time perhaps it will reach one of the running servers.

Let's take a look at the MXs currently set up for the cisco.com domain:

 cisco.com.          86400   IN      MX      20 sj-inbound-1.cisco.com. cisco.com.          86400   IN      MX      20 sj-inbound-2.cisco.com. cisco.com.          86400   IN      MX      20 sj-inbound-3.cisco.com. cisco.com.          86400   IN      MX      20 sj-inbound-4.cisco.com. cisco.com.          86400   IN      MX      30 proxy9.cisco.com. cisco.com.          86400   IN      MX      50 proxy6.cisco.com. cisco.com.          86400   IN      MX      10 sj-inbound-0.cisco.com. cisco.com.          86400   IN      MX      20 proxy5.cisco.com.

As the output shows, there is only one primary MX (with a priority of 10) but no fewer than five MXs with the next-level priority of 20. If the primary MX is unavailable, the sender MTA will attempt delivery to one of the priority-20 mail servers, chosen at random.

SMTP delivery using DNS lookups is the default behavior of all MTAs. The default configuration in /etc/mail/sendmail.cf, which defines DNS delivery, is usually quite sufficient.

Tip: An MX record cannot point to a CNAME entry. It usually points to an A entry (for IPv4) or a AAAA entry for IPv6. You will not need to know in-depth IPv6 concepts for the LPIC 2 Exam, however.

36.1.3.1.1. SMTP delivery via a smart host

A smart host is another mail server to which your MTA may forward all messages for further processing. Sending through a smart host uses most of the same mechanisms as with DNS. We may compare smart host delivery to what happens when a secondary MX tries to deliver a message to the primary MX: if the primary MX is up, the server sends the mail; if not, it just waits. The previously mentioned maximum wait period also applies to smart host configurations.

The principal difference between DNS-based and smart host-based delivery is that in a smart host configuration, the email's final destination mail server (at least as far as your MTA is concernedit could be a gateway to other systems, but that's not important here) is statically coded into the mail server's configuration, not dynamically determined through DNS mechanisms.

Smart host configurations are usually found within larger networks where different servers should use only one server for further processing. All your other servers should be configured to use your main MTA. In this case, you do not need to set up MX records on your internal DNS servers (if you even have any).

In another scenario, on which the following example is based, you tighten your firewall so that only your properly configured mail server may handle outgoing email by forwarding it to an external MTA on a so-called "bastion host." Configuring Sendmail on a bastion host will be discussed later.

On your internal Sendmail server, you need to change only one configuration directive. In your sendmail.mc file, find or create a line specifying your smart host as either an IP address or a server name, as shown in the following examples:

 define('SMART_HOST','[172.20.45.23]') define('SMART_HOST',' external-mailserver.company.com')

IP addresses are distinguished by being enclosed in square brackets. You can choose whichever line you prefer; they have the same effect.

Tip: Both of the SMART_HOST directives in the sendmail.mc file illustrate an important element of the file's syntax: you must use a backquote (') to start a value and an apostrophe (') to end it. This syntax is required by the m4 processor used to transform sendmail.mc to sendmail.cf.

After changing and saving the sendmail.mc file, run the m4 processor to apply the changes to the sendmail.cf file. As explained earlier, most distributions supply a Makefile that runs m4 to convert sendmail.mc to sendmail.cf, so typing a make command in the /etc/mail directory will generate the sendmail.cf file correctly.

36.1.4. Manual Entries

If you want to get your hands dirty by editing in the sendmail.cf file, the directive you must find (or set) is DS. An example is:

 DS[172.20.45.23]

You can also add the following entry to achieve the same effect:

 DS external-mailserver.company.com

Once you have made either of the preceding changes, you need to restart the Sendmail daemon (and all the daemon's children, if any). As described earlier, there are many ways to restart Sendmail, but make sure that you understand both of the following commands:

 /etc/init.d/sendmail reload killall -HUP sendmail

To confirm that you have made a change, check your message log. Following are sanitized examples from an Ubuntu and Red Hat system, respectively:

 Apr 24 12:45:18 foo sm-mta[7679]: restarting /usr/sbin/sendmail due to signal Apr 24 12:45:18 foo sm-mta[7692]: starting daemon (8.12.11): SMTP+queueing@00:10:00

These lines show that the Sendmail daemon has started and is now ready to queue processes. The following example shows Sendmail restarting in a Red Hat system:

 Apr 24 12:52:28 foo sendmail: sendmail -HUP succeeded

After restarting, Sendmail delivers every email message not destined for a local user account through your external mail server and out onto the LAN, WAN, or Internet.

Tip: On Red Hat/Fedora systems, the /etc/init.d/sendmail script understands the reload argument even though it is not documented.

36.1.5. Local Delivery

An email address has two parts: the local user part and the domain part. Local delivery is defined as an instance when your mail server receives an email in which the domain part matches its own domain or list of domains. As mentioned earlier, the accepted domains are listed in the /etc/mail/local-host-names file, for newer systems. In older systems, this information is listed in /etc/mail/sendmail.cw.

This file is one of the first checkpoints on an email's path to final delivery, so if you want Sendmail to accept mail for your domain, you will need to edit this file so that it contains the appropriate domain names. Because the file may contain more than one domain, your mail server may even accept mail for your company and for your privately owned email domain at the same time.

Traditionally, a match between an email address and a user account is found by reading the MTA server system's /etc/passwd file. As a result, john.smith@somedomain.com will be delivered to the user account named john.

By using an aliases file, you can have mail to the address customer-support@ispcompany.com simultaneously distributed to the accounts tom, dick, and harry. You will learn more about the aliases file later.

When running more than one email domain on the same server, you will most likely run into the following problem: an account named tom is found in more than one of your domains. The result could be chaos, because the MTA would try to deliver the email messages to multiple people.

The solution to this problem is the concept of virtual users, described in the following section.

36.1.6. Using virtusertable

In Sendmail, the concept of the virtual user allows you to configure Sendmail so that nonlocal email can be properly routed. You create virtual users with the file named /etc/mail/virtusertable. Here are some examples of the format used:

 # Tom, Dick and Harry all have local user accounts. # Tom's system user account is tjohnson, Dick's is dsmith, # and Harry's is hflynn. tom@somedomain.com              tjohnson dick@somedomain.com             dsmith harry@somedomain.com            hflynn # Harry is the guy that gets all wrongly addressed email # within the @somedomain.com address space @somedomain.com                 hflynn # Here is the other Tom; he has a different user account. tom@someotherdomain.com         tgoldman @someotherdomain.com            tgoldman # Now, a third guy named Tom -- but he's reading his mail somewhere else. tom@differentdomain.com         tom@acme-company.com @differentdomain.com            error:nouser Sorry, no such user.

Beginning at the top, you see three email addresses all belonging to @somedomain.com. Below those, you see a so-called catchall rule: if someone mistypes an email address to @somedomain.com, the email is forwarded to Harry (hflynn) instead of being returned to sender with a "no such user" error message.

Then you see the second Tom who has an email account on your server. The second Tom and the previous Tom have different local user accounts, so this does not introduce a problem. The email domain someotherdomain.com has a catch-all rule as well.

Then a third Tom enters the scene. Even though your mail server handles his email address, tom@differentdomain.com, he also has another email account at work, (@acme-company.com) and he likes to read all his mail there. After his entry is a @differentcompany.com catchall resulting in an error message. If someone misspells the local part of the email address, the email message is returned and the sender is notified.

Once you have created a virtusertable entry such as this one, you need to use the makemap command as follows to create a database file that Sendmail can read:

 makemap hash virtusertable < virtusertable

Catchall Rules

When operating with virtual domains, you should have a catchall rule for each domain. If not, Sendmail will try to find a local user that will match the local part of the (wrong) email address. If someotherdomain.com did not have a catchall rule, an email sent to the nonexistent virtual address mick@someotherdomain.com could end up at a local user named mick even though he has nothing to do with someotherdomain.com.

36.1.7. Checking Virtual Users

Once you have created virtual users, check them by by entering Sendmail's test mode. Test mode is an interactive shell run by Sendmail that allows you confirm your settings. If you have the following /etc/mail/local-host-names file:

 somedomain.com someotherdomain.com differentdomain.com

the following example of an interactive session confirms your virtual users and virtual user mappings:

 # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> /map virtuser tom@somedomain.com map_lookup: virtuser (tom@somedomain.com) returns tjohnson (0) /map virtuser tom@someotherdomain.com map_lookup: virtuser (tom@someotherdomain.com) returns tgoldman (0) /map virtuser tom@differentdomain.com map_lookup: virtuser (tom@differentdomain.com) returns tom@acme-company.com (0) /quit

36.1.8. Email Aliases

Aliasing is different from using and mapping virtual users. On your mail server, a file named /etc/mail/aliases (or simply /etc/aliases) exists. On each line you will see the alias and the real address, separated by a colon and a tab. What is called the real address may be a new alias or an email address somewhere else. Consider this /etc/mail/aliases file:

 MAILER-DAEMON:  postmaster postmaster:     root john.smith:     jsmith jack.smith:     jack@acme-company.com custsupp:       tom,dick,harry

Whenever changes are made to the aliases file, you must run the newaliases command to convert the contents of the text file into a database format that Sendmail will recognize. Once you do this, Sendmail will recognize your changes.

36.1.8.1. The contents of the aliases file

The MAILER-DAEMON address shown in the preceding example is used as a sender address whenever the mail server needs to communicate with someone, such as when receiving an email message to a nonexistent user. Quite a few people actually respond to this automated message asking what to do.

The postmaster address is an address required by the email RFCs. All email domains must have a postmaster account, which should be processed regularly.

The entry of john.smith is an alias for the person using the user account jsmith. John's brother, Jack, also has an email account here, but he reads his email at work, so his entry forwards jack.smith's email to jack@acme-company.com.

The fourth entry is somewhat more complex. The alias custsupp is translated into three different local user accounts, separated by commas. It is important to note that forwarding to more than one address is allowed only in the aliases file, not the virtusertable file. If you want all your customers to contact your team (Tom, Dick, and Harry) via the common email account customer-support@isp.com, you need to include one entry in the virtusertable file:

 # /etc/mail/virtusertable customer-support@isp.com        custsupp

and one in the aliases file:

 # /etc/mail/aliases custsupp:                       tom,dick,harry

To verify that Sendmail got your aliases correct, enter test mode again:

 # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> /map aliases postmaster map_lookup: aliases (postmaster) returns root (0) /quit

36.1.8.2. Reversing virtual user accounts

If you or your users run scheduled jobs that report results by sending an email message or if someone uses an email client installed on the mail server (e.g., Pine, Mutt, or Gnus), the email will show the local username as the sender address. Suppose John Smith, with jsmith as his user account name, doesn't want jsmith@somedomain.com to be exposed. Rather, he wants his aliased address john.smith@somedomain.com to appear to recipients instead.

This request is actually quite easy to fulfill with Sendmail, as long as you have a relatively new version (e.g., Sendmail 8.10). However, this feature may not be enabled in your configuration. To enable it, use the m4 utility. As long as you have a fairly new version of the software, it is a simple task involving the creation of a genericstable file.

If you have the following lines in your sendmail.mc file, reverse aliasing is already enabled. If not, you need to add them. Remember the backtick and apostrophe (''). Otherwise, your entry will result in an error when m4 runs.

 FEATURE('genericstable', 'hash -o /etc/mail/genericstable.db')dnl GENERICS_DOMAIN_FILE('/etc/mail/generics-domains')dnl

After adding these lines, you need to build the sendmail.cf file again. It's a good idea to back up your existing sendmail.cf file and perhaps build the new one in a different directory:

 m4 sendmail.mc > sendmail.cf

Then copy the new file to the appropriate directory (e.g., /etc/mail) and reload Sendmail.

36.1.8.3. The genericstable file

For the genericstable file, you need to include the domains that you will map from; under normal circumstances this is the fully qualified name of the host. The /etc/mail/genericstable file will be a mirror of the virtusertable file, so that the local account is on the left side and the alias is on the right side. Following is a genericstable file that matches the virtusertable we created earlier:

 # Tom, Dick, and Harry all have local user accounts tjohnson                       tom@somedomain.com dsmith                         dick@somedomain.com hflynn                         harry@somedomain.com # the other tom tgoldman                       tom@someotherdomain.com

The genericstable file must be converted to a database file so that Sendmail can read it. To do this, as usual, enter a makemap command:

 # makemap hash genericstable < genericstable

The Sendmail test mode command for verifying the reverse virtual user mapping is:

 /map generic [username]

used as follows:

 # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> /map generics tjohnson map_lookup: generics (tjohnson) returns tom@somedomain.com (0) /quit

On the Exam

You are expected to know the difference between the virtusertable and the genericstable files. Be able to explain each file's function. Make sure that you know how each file is formatted as well.

36.1.9. Bastion Host Sendmail Server

A bastion host is a system that can be accessed from a public network, such as the Internet. It is often advisable to offer such an external server to handle all incoming email. Sometimes, this server will also process outgoing mail, if you are concerned about forwarding viruses, worms, and other problems. Your bastion host Sendmail server may also perform spam filtering and/or virus control to help keep viruses outside of your network.

A bastion host must be configured with the following concerns in mind: First, it must provide provide necessary email services, exactly as defined by the organization you are working for. This seems like an obvious concern, but always make sure that your solution provides all necessary services, as long as the requested service does not cause a security problem in and of itself. Second, your Sendmail bastion server must be configured so that it can withstand attacks. As soon as it goes live, your system will be a target of all kinds of attacks and exploit attempts. While it is not possible to anticipate all attacks, it is best to research ways to "lock down" your system as much as possible.

36.1.9.1. Locking down the server

First, the bastion host should be protected behind some kind of firewall. Preferably, this firewall should be a separate unit. Using a local solution, such as iptables, is also a good idea, but it is no substitute for a separate firewall. When configuring your firewall solutions, consider the following rules:

Two firewall stances exist: open by default, and closed by default. Firewalls that are open by default allow any traffic. You must then create rules that block the ports, IP addresses, and traffic types that you wish to block. Firewalls that are closed by default will not allow any traffic at all, unless you explicitly allow the port, IP address, and traffic type. Generally, closed by default is preferable, though there is no hard and fast rule.
Find the most secure way to allow incoming and outgoing email. By definition, a Sendmail bastion host should be running Sendmail (e.g., port 25). However, many administrators also enable POP-3 (port 110) and IMAP (port 143). Remember, also, that SMTP, POP-3, and IMAP servers all open up ports above 1024 to communicate with clients and other servers. Create rules accordingly.
Also available are SSL-enabled SMTP (port 25, but some firewalls may reject encrypted packets), POP-3 (995), and IMAP (993). Enable these ports only if you are using them.

Next, "harden" the operating system itself. The topic of operating system hardening is the subject of entire books. Following is a brief list of hardening steps that will help you not only pass the LPI Exam, but also protect your live servers:

Disable all unnecessary services.: If you are creating a Sendmail bastion host, this server should be offering only the SMTP service or an SSL-enabled SMTP service. Still, many people need to administer their servers remotely, so they use SSH on their systems. Additional services, such as a web server andaccording to puristsPOP and IMAP servers should be disabled.
Configure all running services for security.: If you must provide additional services on your bastion host, secure them as much as possible. If you plan on using SSH or VNC to administer the systems remotely, use firewall rules and internal configuration files (e.g., /etc/ssh/sshd_config) to allow connections only from certain IP addresses, for example. Although it is possible to spoof IP addresses, such steps will help reduce the likelihood of successful attacks. Additional configuration options exist for almost any service. Use them. If you are using SSH, for example, use public-key encryption for authentication. This sounds like a basic idea, but you will be surprised at how few people actually do.

In this brief discussion, you have learned about how important it is to lock down the operating system. The Sendmail daemon needs special attention as well.

36.1.9.2. Configuring Sendmail for a bastion host

First, the Sendmail server needs to be secured from unauthorized relaying. Second, if you have internal mail servers, this server must act as a smart host for them. Under normal circumstances, only one or two IP addresses should be allowed to use this server as a smart host relay.

Third, you need to tell the external MTA where it should forward your company's email and which domains your server handles. This is done in the file /etc/mail/mailertable. The format should be familiar; what to look for is on the left side and what to do with it is on the right side. If we continue using our three domains from before, the file will appear as follows:

 somedomain.com           smtp:[192.168.200.3] someotherdomain.com      smtp:[192.168.200.3] differentdomain.com      smtp:[192.168.200.3]

In this example, your internal mail server has, as you probably guessed, the IP address 192.168.200.3.

Remember to convert the file to the Sendmail-readable database format with the following command:

 makemap hash mailertable < mailertable

Or you can use the update scripts supplied in the /etc/mail directory.

You may want to check the mailertable configuration as well:

 # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> /map mailertable somedomain.com map_lookup: mailertable (somedomain.com) returns smtp:[192.168.200.3] (0) /quit

36.1.10. Managing Mail Traffic

You have already learned about how to verify Sendmail's configuration through the -bt options, a key skill in managing mail traffic . Additional considerations include:

Monitoring mail: It is not enough to know how Sendmail works to pass the LPI exam. You also need to know how to review incoming and outgoing mail by reading log files.
Filtering and sorting mail: You must know how to identify content in email messages and then filter and sort mail accordingly. You will need to know how to identify the content of the Subject, From, and To fields, as well as the content of the message body, and then configure your system to process the messages accordingly. There are many ways to filter and sort mail. This chapter focuses on Procmail.

A brief discussion follows on each of these topics.

36.1.11. Monitoring Mail

The most common ways to monitor Sendmail messages are:

Checking the Sendmail log: The /var/log/maillog file, on many systems that use Sendmail, contains messages specific to Sendmail, as determined by the sendmail.cf file. Sendmail uses the syslog facility to generate messages. Specifically, the mail syslog level is often used to send messages to the maillog file.
Reviewing the /var/log/messages file: Depending upon the system, some or all Sendmail messages are sent to the /var/log/messages file.

Each Sendmail log entry has the following format:

 date, host, sendmail_function[pid]: <qid>: occurrence=message

Table 36-4 contains a brief discussion of each field in the mail log.

Table 36-4. Sendmail log
Entry	Description
date	The month, day, and time (according to system time) of the event. No year is given.
host	The host that generated the message. Useful for remote logging. If it is a local message, the host is often given as the hostname or as `localhost.localdomain` if the hostname has not been configured.
sendmail_function	The particular Sendmail process that generated the message.
pid	The process ID that generated the message.
qid	The ID number of the message in the queue or process assigned by Sendmail.
occurrence=message	The occurrence and associated message.

Various occurrences exist. Following are some of the more common:

Relay: Shows the system that received and sent the relayed message, in username@domainname format and with a domainname of localhost when the messages is relayed by the local system.
Delay: The total amount of time the message was delayed. Specifically, the difference between when the message was received and when it was delivered. The format for messages delayed less than a day is HH:MM:SS. For messages longer than a day, the format is days+HH:MM:SS.
Nrcpts: The number of recipients, after aliasing.
From: The sender of the message, in the format from=address. The sender value can be a user-based email address, a message from the postmaster, or a Sendmail-specific value if the message has bounced.
Pri: The priority of the message assigned by Sendmail. The message priority decreases after each resend, but the priority value given in this message is the initial one.
Size: The size of the message, in bytes.

Additional entries exist, but these are the most important ones for the LPI Exam. For example, the following entry shows that a relay has occurred for the root account on the local system:

 jacob sendmail[15232]: jBK0llQK015232: from=root, size=0, class=0, nrcpts=0, relay=root@localhost

36.1.12. Log Configuration

Try opening /etc/syslog.conf and review the settings. You do not have to use the default settings on your system. You can, for example, set syslog to send all mail messages to a remote system, which is particularly useful if you have a Sendmail bastion host or if you want a backup log for security reasons. This syslog.conf entry sends all mail messages to the system jacob.stangernet.com:

 mail.*   @jacob.stangernet.com

In many cases, you may want the mail.alert syslog level of logging, which will relate all alert-level Sendmail information. These messages include when Sendmail starts or restarts, as well as conditions that are considered fatal including failed processes and messages that are not sent due to a system failure:

 mail.alert       @jacob.stangernet.com