Linux Network Administratoramp;#039;s Guide (3rd Edition) [Electronic resources] نسخه متنی

12.5. sendmail Databases

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.

12.5.1. The aliases Database

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.

Example 12-6. Sample aliases file

#
# 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/newaliases

This
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.

12.5.2. The local-host-names File

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.

12.5.2.1 The bestmx_is_local feature

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.

12.5.3. The relay-domains File

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:

promiscuous_relay

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.

12.5.4. The genericstable Database

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.

12.5.5. The access Database

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 host identified by its hostname or its
  IP address.

• A domain identified by a domain name.

• 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.

12.5.6. Other Databases

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.

12.5.6.1 The mailertable

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.

12.5.6.2 The virtusertable

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,