The sample configuration created above uses several sendmail databases. (Here we use the term "database" loosely to include both real databases and flat files.) sendmail databases are an often overlooked component of sendmail configuration. Yet sendmail databases play an important role in sendmail configuration. It is in these databases, not in the m4 files or the sendmail.cf file, that day-to-day configuration changes are made. The sendmail databases used in our sample configuration are as follows:
aliases
The aliases database is included in the configuration by default. This database is an essential component in local mail delivery and in mail forwarding. Nothing needs to be added to the configuration to use the aliases database.
local-host-names
The local-host-names file is added to a configuration by the use_cw_file feature. This file is used to define which mail is accepted for local delivery.
relay-domains
The relay-domains file is included in the configuration by default. Therefore, no changes are needed in the sendmail configuration to use this file. The relay-domains file can authorize relaying, which, by default, is disabled.
genericstable
The genericstable feature adds support for this database. The genericstable is used to rewrite the email addresses an organization uses internally into the format it wishes to present to the outside world.
access
The access_db feature adds support for this database. The access database is useful in a wide variety of ways.
Each of these databases, and others not used in the sample configuration, are described in the following sections.
Mail aliases are a powerful feature for routing mail on a destination host. For example, it is common practice to direct feedback or comments relating to a World Wide Web server to "webmaster." Often there isn't a user known as "webmaster" on the target machine; instead, it is an alias for another user. Another common use of mail aliases is to create mailing lists by directing a single alias to many recipients or to use an alias to direct incoming messages to the list server program. Aliases can:
Provide a shorthand or well-known name for mail to be addressed to in order to go to one or more persons. For example, all systems require aliases for the well-known names Postmaster and MAILER-DAEMON in order to be RFC compliant.
Invoke a program with the mail message as the input to the program. Always be extremely aware of security when defining aliases that invoke programs or write to programs, since sendmail sometimes runs with root permissions.
Deliver mail to a file.
Details concerning mail aliases may be found in the aliases(5) manpage. A sample aliases file is shown in Example 12-6.
# # The following two aliases must be present to be RFC-compliant. # It is important to resolve them to 'a person' who reads mail routinely. # postmaster: root # required entry MAILER-DAEMON: postmaster # required entry # # # demonstrate the common types of aliases # usenet: janet # alias for a person admin: joe,janet # alias for several people newspak-users: :include:/usr/lib/lists/newspak # read recipients from file changefeed: |/usr/local/lib/gup # alias that invokes program complaints: /var/log/complaints # alias writes mail to file #
Whenever you update the /etc/aliases text file, be sure to run the command:
# /usr/bin/newaliasesThis command rebuilds the database that sendmail uses internally. The newaliases command is a symbolic link to the sendmail executable, which behaves exactly as if sendmail was invoked with the -bt command line argument.
The sendmail program consults the aliases database to determine how to handle an incoming mail message that has been accepted for local delivery. If the user portion of the delivery address in the mail message matches an entry in the aliases database, sendmail redirects the message as described by the entry. But this happens only if sendmail accepts the mail message for local delivery. The local-host-names file helps sendmail decide which messages should be accepted for local delivery.
Inbound mail is either delivered directly to the addressee or relayed to another mail host for delivery. sendmail accepts only mail for local delivery that is addressed to the local host. All other mail is relayed. The system checks class $=w to decide whether or not it should accept inbound mail for local delivery. Class $=w is an array that contains all of the names that sendmail considers valid for local mail delivery.
The use_cw_file feature directs sendmail to load the /etc/mail/local-host-names file into class $=w. It does this by placing the following F command in the sendmail.cf file:
Fw/etc/mail/local-host-names
Once the use_cw_file feature is added to the configuration, sendmail expects to find the local-host-names file and displays a non-fatal error message when it doesn't. If you're not ready to add hostnames to the file, simply create an empty file.
To configure the sendmail server to accept inbound mail for other hosts, simply add the hostnames of those hosts to the local-host-names file. The local-host-names file is just a list of hostnamesone hostname to a line. Here is a sample local-host-names file for the vbrew.com domain:
vbrew.com vporter.vbrew.com vale.vbrew.com vlager.vbrew.com vpils.vbrew.com vipa.vbrew.com
The values stored in the local-host-names file are added to the other values in class $=w. The other values stored in $=w are all of the hostnames, hostname aliases, and IP addresses assigned to this host that sendmail was able to determine by probing the various network interfaces. It is possible to limit the interface probing done by sendmail by adding the following define to the sendmail configuration:
define(`confDONT_PROBE_INTERFACES', `true')
The confDONT_PROBE_INTERFACES define is generally only used when probing the interfaces gives sendmail erroneous information, or when a large number of virtual interfaces are used.
It is also possible to add hostnames to class $=w inside the sendmail configuration file using the LOCAL_DOMAIN macro:
LOCAL_DOMAIN(`vbrew.com') LOCAL_DOMAIN(`vipa.vbrew.com')
However, every time a LOCAL_DOMAIN macro is added to the configuration the sendmail.cf file must be rebuilt, tested, and moved to the /etc/mail directory. When the local-host-names file is used, there is no need to rebuild sendmail.cf just because the local-host-names file has been edited.
The bestmx_is_local feature is another way to accept mail for local delivery that is addressed to another hostname. It works well if the only reason why hostnames are being added to the local-host-names file is because the local host is the preferred mail exchanger for those hosts. Mail addressed to any system that lists the local host as its preferred mail exchanger is accepted as local mail when the bestmx_is_local feature is used. To use this approach, put the following line in the configuration:
FEATURE(`bestmx_is_local', `vbrew.com')
The great advantage of the bestmx_is_local feature is that it is easythe hostnames of MX clients do not need to be added to the local-host-names file. However, a potential problem with the bestmx_is_local solution is that it increases the processing overhead for each piece of mail. This is not a problem for a small system, but it could be a problem if the system deals with a high volume of mail. Another limitation is that bestmx_is_local depends completely on MX records, but it is possible to have other reasons to accept mail as local mail. The local-host-names file can store any hostnames that you wish; it is not limited to hosts that define your system as their mail exchanger.
Mail that is not addressed to the local host is relayed. The relay-domains file is one way to configure relaying.
By default, sendmail does not permit relayingeven relaying from other hosts within the local domain. Attempts to relay through a system using the default configuration returns the "Relaying denied" error to the sender. sendmail will, however, relay mail for any domain listed in class $=R, and anything listed in the relay-domains file is added to class $=R. For example, the following commands extend the relay-domains file to enable relaying for the vbrew.com domain:
# cat >> /etc/mail/relay-domains vbrew.com Ctrl-D
Restart sendmail to ensure that it reads the relay-domains file:
# kill -HUP `head -1 /var/run/sendmail.pid`
Now, hosts within the local domain are allowed to relay through vstout.vbrew.comall without any changes to the m4 configuration or any need to rebuild the sendmail.cf file. Mail from or to hosts in the vbrew.com domain is relayed. Mail that is neither from nor to a host in the vbrew.com domain is still blocked from relaying mail.
There are other ways to enable relaying. However, none is as easy as adding the local domain to the relay-domains file, and some are potential security risks. A good alternative is to add the local domain name to class $=R by using the RELAY_DOMAIN macro. The following lines added to the macro configuration would have the same effect as the relay-domains file defined above:
dnl RELAY_DOMAIN adds a domain name to class R RELAY_DOMAIN(`vbrew.com')
However, the RELAY_DOMAIN command requires modifying the m4 configuration, and rebuilding and reinstalling the sendmail.cf file. Using the relay-domains file does not, which makes the relay-domains file simpler to use.
Another good alternative is the relay_entire_domain feature. The following command added to a macro configuration would enable relaying for hosts in the local domain:
dnl A feature that relays mail for the local domain FEATURE(`relay_entire_domain')
The relay_entire_domain feature relays mail from any host in a domain listed in class $=m. By default, class $=m contains the domain name of the server system, which is vbrew.com on a server named vstout.vbrew.com. This alternative solution works, but is slightly more complex than using the relay-domains file. Additionally, the relay-domains file is very flexible. It is not limited to the local domain. Any domain can be listed in the relay-domains file and mail from or to any host in that domain will be relayed.
There are some techniques for enabling relaying that should be avoided for security reasons. Two such alternatives are:
This feature turns on relaying for all hosts. Of course, this includes the local domain so this feature would work. However, it would create an open relay for spammers. Avoid the promiscuous_relay feature even if your host is protected by a firewall.
relay_local_from
This feature enables relaying for mail if the email address in the envelope sender address of the mail contains the name of a host in the local domain. Because the envelope sender address can be faked, spammers can possibly trick your server into relaying spam.
Once the relay-domains file is configured to relay mail to and from the local domain, clients on the local network can start sending mail through the server to the outside world. The genericstable, discussed next, allows you to rewrite the sender address on the mail as it passes through the server.
To provide support for the genericstable, we added the genericstable feature, the GENERICS_DOMAIN macro, and the generics_entire_domain feature to our sample sendmail configuration. The following commands were added:
FEATURE(`genericstable') GENERICS_DOMAIN(`vbrew.com') FEATURE(`generics_entire_domain')
The genericstable feature adds the code sendmail needs to make use of the genericstable. The GENERICS_DOMAIN macro adds the value specified on the macro command line to sendmail class $=G. Normally, the values listed in class $=G are interpreted as hostnames, and only exact matches enable genericstable processing. The generics_entire_domain feature causes sendmail to interpret the values in class $=G as domain names, and any host within one of those domains is processed through the genericstable. Thus the hostname vipa.vbrew.com, because it contains the domain name vbrew.com, will be processed through the genericstable with this configuration.
Each entry in the genericstable contains two fields: the key and the value returned for that key. The key field can be either a full email address or a username. The value returned is normally a full email address containing both a username and a hostname. To create the genericstable, first create a text file that contains the database entries and then run that text file through the makemap command to build the genericstable database. For the vstout.vbrew.com server, we created the following genericstable:
# cd /etc/mail # cat > genericstable kathy kathy.mccafferty@vbrew.com win winslow.smiley@vbrew.com sara sara.henson@vbrew.com dave david.craig@vbrew.com becky rebecca.fro@vbrew.com jay jay.james@vbrew.com alana@vpils.vbrew.com alana.darling@vbrew.com alana@vale.vbrew.com alana.henson@vbrew.com alana alana.sweet@vbrew.com Ctrl-D # makemap hash genericstable < genericstable
Given this genericstable, the header sender address win@vipa.vbrew.com is rewritten to winslow.smiley@vbrew.com, which is the value returned by the genericstable for the key win. In this example, every win account in the entire vbrew.com domain belongs to Winslow Smiley. No matter what host in that domain he sends mail from, when the mail passes through this system it is rewritten into winslow.smiley@vbrew.com. For replies to the rewritten address to work correctly, the rewritten hostname must resolve to a host that will accept the mail and that host must have an alias for winslow.smiley that delivers the mail to the real win account.
The genericstable mapping can be anything you wish. In this example, we map login names to the user's real name and the local domain name formatted as firstname.lastname@domain.[6] Of course, if mail arrives at the server addressed to firstname.lastname@domain, aliases are needed to deliver the mail to the users' real address. Aliases based on the genericstable entries shown above could be appended to the aliases database in the following manner:
[6] The firstname.lastname@domain format is not universally endorsed. See the sendmail FAQ for some reasons why you might not want to use this address format.
# cd /etc/mail # cat > aliases kathy.mccafferty: kathy win.strong: craig sara.henson: sara david.craig: dave rebecca.fro: becky alana.smiley: alana alana.darling: alana@vpils.vbrew.com alana.henson: alana@vale.vbrew.com jay.james: jay Ctrl-D # newaliases
The aliases that map to a username store the mail on the server, where it is read by the user or retrieved by the client using POP or IMAP. The aliases that map to full addresses forward the mail to the host defined in the full address.
Most of the entries in the sample genericstable (kathy, sara, dave, becky, and jay) are any-to-one mappings that work just like the win entry described above. A more interesting case is the mapping of the username alana. Three people in the vbrew.com domain have this username: Alana Henson, Alana Darling, and Alana Sweet. The complete addresses used in the genericstable keys for Alana Darling and Alana Henson make it possible for sendmail to do one-to-one mappings for those addresses. The key used for Alana Sweet's entry, however, is just a username. That key matches any input address that contains the username alana, except for the input addresses alana@vpils.vbrew.com and alana@vale.vbrew.com. When a system handles mail that originates from several hosts, it is possible to have duplicate login names. The fact that the key in the genericstable can contain a full email address allows you to map these overlapping usernames.
The last database used in the sample Linux sendmail configuration is the access database. This database is so versatile that it should probably be included in the configuration of every mail server.
The access database offers great flexibility and control for configuring from which hosts or users mail is accepted and for which hosts and users mail is relayed. The access database is a powerful configuration tool for mail relay servers that provides some protection against spam and that provides much finer control over the relay process than is provided by the relay_domains file. Unlike the relay_domains file, the access database is not a default part of the sendmail configuration. To use the access database, we added the access_db feature to our sample Linux sendmail configuration:
FEATURE(`access_db')dnl
The general idea of the access database is simple. When an SMTP connection is made, sendmail compares information from the envelope header to the information in the access database to see how it should handle the message.
The access database is a collection of rules that describe what action should be taken for messages from or to specific users or hosts. The database has a simple format. Each line in the table contains an access rule. The left side of each rule is a pattern matched against the envelope header information of the mail message. The right side is the action to take if the envelope information matches the pattern.
The left pattern can match:
An individual defined by either a full email address (user@host.domain) or a username written as username@.
A network identified by the network portion of an IP address.
By default, the pattern is matched against the envelope sender address, and thus the action is taken only if the mail comes from the specified address. Adding the blacklist_recipient feature to the sendmail configuration applies the pattern match to both source and destination envelope addresses. However, an optional tag field that can be prepended to the left side to provide finer control over when the pattern match is applied. Beginning the pattern with an optional tag tells sendmail to limit pattern matching to certain conditions. The three basic tags are:
To:
The action is taken only when mail is being sent to the specified address.
From:
The action is taken only when mail is received from the specified address.
Connect:
The action is taken only when the specified address is the address of the system at the remote end of the SMTP connection.
There are five basic actions that may be defined on the right side of an access rule. These are:
OK
Accept the mail message.
RELAY
Accept the mail messages for relaying.
REJECT
Reject the mail with a generic message.
DISCARD
Discard the message using the $#discard mailer.
ERROR :dsn:code text
Return an error message using the specified DSN code, the specified SMTP error code, and the specified text as the message.
An example /etc/mail/access might look like this:
friends@cybermail.com REJECT aol.com REJECT 207.46.131.30 REJECT postmaster@aol.com OK linux.org.au RELAY example.com ERROR:5.7.1:550 Relaying denied to spammers
This example would reject any email received from
The access database can do much more than shown here. Note that we explicitly said "basic" tags and "basic" actions because there are several more values that can be used in advanced configurations. If you plan to tackle an advanced configuration, see the "More Information" section later in the chapter.
The access database is the last database we used in our sample configuration. There are several other databases that are not used in our sample Linux sendmail configuration. These are described in the following section.
Some of the available sendmail databases were not used in our sample configuration either because their use is discouraged or because they focus on outdated technologies. These databases are:
define( `confUSERDB_SPEC' , `path')
The confUSERDB_SPEC option tells sendmail to apply the user database to local addresses after the aliases database is applied and before the .forward file is applied. The path argument tells sendmail where the database is found. The user database is not widely used because the sendmail developers discourage its use in their responses to questions 3.3 and 3.4 of the FAQ.
FEATURE( `use_ct_file' , `path')
The use_ct_file feature tells sendmail to add trusted usernames from the specified file to the class $=t. Because users listed in $=t are allowed to send mail using someone else's username, they present a security risk. There are fewer files to secure against tampering if trusted users are defined in the macro configuration file using confTRUSTED_USERS, and because so few users should be trusted, defining them in the macro configuration file is no burden.
FEATURE( `domaintable' , `specification')
The domaintable feature tells sendmail to use the domain table to map one domain name to another. An optional database specification can be provided to define the database type and pathname, which, by default, are hash type and /etc/mail/domaintable. The domaintable eases the transition from an old domain name to a new domain name by translating the old name to the new name on all mail. Because you are rarely in this situation, this database is rarely used.
FEATURE( `uucpdomain' , `specification')
The uucpdomain feature tells sendmail to use the uucpdomain database to map UUCP site names to Internet domain names. The optional database specification overrides the default database type of hash and the default database path of /etc/mail/uucpdomain. The uucpdomain database converts email addresses from the .UUCP pseudo-domain into old-fashioned UUCP bang addresses. The key to the database is the hostname from the .UUCP pseudo-domain. The value returned for the key is the bang address. It is very unlikely that you will use this database because even sites that still use UUCP don't often use bang addresses because current UUCP mailers handle email addresses that look just like Internet addresses.
FEATURE('bitdomain', 'specification')
The bitdomain feature tells sendmail to use the bitdomain database to map BITNET hostnames to Internet domain names. BITNET is an outdated IBM mainframe network that you won't use, and therefore you won't use this database.
There are two other databases, mailertable and virtusertable, that, although not included in the sample configuration, are quite useful.
The mailertable feature adds support to the sendmail configuration for the mailertable. The syntax of the mailertable feature is:
FEATURE(`mailertable', `specification')
The optional database specification is used to override the default database type of hash and the default database path is /etc/mail/mailertable.
The mailertable maps domain names to the internal mailer that should handle mail bound for that domain. Some mailers are used only if they are referenced in the mailertable. For example, the MAILER(`smtp') command adds the esmtp, relay, smtp, smtp8, and dsmtp mailers to the configuration. By default, sendmail uses only two of these mailers. The esmtp mailer is used to send standard SMTP mail, and the relay mailer is used when mail is relayed through an external server. The other three mailers are unused unless they are reference in a mailertable entry or in a custom rewrite rule. (Using the mailertable is much easier than writing your own rewrite rules!)
Let's use the smtp8 mailer as an example. The smtp8 mailer is designed to send 8-bit MIME data to outdated mail servers that support MIME but cannot understand Extended SMTP. If the domain example.edu used such a mail server, you could put the following entry in the mailertable to handle the mail:
.example.edu smtp8:oldserver.example.edu
A mailertable entry contains two fields. The first field is a key containing the host portion of the delivery address. It can either be a fully qualified hostnameemma.example.eduor just a domain name. To specify a domain name, start the name with a dot, as in the example above. If a domain name is used, it matches every host in the domain.
The second field is the return value. It normally contains the name of the mailer that should handle the mail and the name of the server to which the mail should be sent. Optionally, a username can be specified with the server address in the form user@server. Also, the selected mailer can be the internal error mailer. If the error mailer is used, the value following the mailer name is an error message instead of a server name. Here is an example of each of these alternative entries:
.example.edu smtp8:oldserver.example.edu vlite.vbrew.com esmtp:postmaster@vstout.vbrew.com vmead.vbrew.com error:nohost This host is unavailable
Normally, mail passing through the mailertable is sent to the user to which it is addressed. For example, mail to jane@emma.example.edu is sent through the smtp8 mailer to the server oldserver.example.edu addressed to the user jane@emma.example.edu. Adding a username to the second field, however, changes this normal behavior and routes the mail to an individual instead of a mail server. For example, mail sent to any user at vlite.vbrew.com is sent instead to postmaster@vstout.vbrew.com. There, presumably, the mail is handled manually. Finally, mail handled by the mailertable does not have to be delivered at all. Instead, an error message can be returned to the sender. Any mail sent to vmead.vbrew.com returns the error message "This host is unavailable" to the sender.
The sendmail virtusertable feature adds support for the virtual user table, where virtual email hosting is configured. Virtual email hosting allows the mail server to accept and deliver mail on behalf of a number of different domains as though it were a number of separate mail hosts. The virtual user table maps incoming mail destined for some user@host to some otheruser@otherhost. You can think of this as an advanced mail alias featureone that operates using not just the destination user, but also the destination domain.
To configure the virtusertable feature, add the feature to your m4 macro configuration as shown:
FEATURE(`virtusertable')
By default, the virtusertable source file is /etc/mail/virtusertable. You can override this by supplying an argument to the macro definition; consult a detailed sendmail reference to learn about what options are available.
The format of the virtual user table is very simple. The left side of each line contains a pattern representing the original destination mail address; the right side has a pattern representing the mail address that the virtual hosted address will be mapped to. The following example shows three possible types of entries:
samiam@bovine.net colin sunny@bovine.net darkhorse@mystery.net @dairy.org mail@jhm.org @artist.org $1@red.firefly.com
In this example, we are virtual hosting three domains: bovine.net, dairy.org, and artist.org.
The first entry redirects mail sent to a user in the bovine.net virtual domain to a local user on the machine. The second entry redirects mail to a user in the same virtual domain to a user in another domain. The third example redirects all mail addressed to any user in the dairly.org virtual domain to a single remote mail address. Finally, the last entry redirects any mail to a user in the artist.org virtual domain to the same user in another domain; for example,