Red Hat Linux uses Sendmail as its MTA to deliver messages, whether they are
intended for users on the same system or for remote destinations. Other
MTAs do exist (and can be used well with Red Hat Linux), but most administrators
elect to use Sendmail as their MTA due to its power, scalability, and
compliance to important Internet standards, such as SMTP.
Sendmail's core duty, like other MTAs, is to safely move email between
hosts, usually utilizing the SMTP protocol. However, Sendmail is highly
configurable, allowing you to control almost every aspect of how email
is handled, including the protocol to be used.
Sendmail's roots can be traced to the birth of email, occurring in the
decade before the birth of ARPANET, the precursor to the Internet. In
those days, every user's mailbox was a file that only they had rights
to read, and mail applications simply added text to that file. Every
user had to wade through their mail file to find any old mail, and
reading new mail was a chore. The first actual transfer of a mail
message file from one host to another didn't take place until 1972,
where email began to to be moved by FTP over the NCP network
protocol. This easier method of communication quickly became popular,
even to the point where it made up most of ARPANET's traffic in less
than a year.
However, a lack of standardization between competing protocols made
email much harder to send from some systems, and this continued until
the ARPANET standardized on TCP/IP in 1982. A new protocol, SMTP,
materialized for message transporting. These developments, combined
with HOSTS files being replaced with DNS, allowed full-featured MTAs
to materialize. Sendmail, which grew out of an earlier email delivery
system called Delivermail, quickly became the standard as the Internet
began to expand and be widely utilized.
It is important to be aware of what Sendmail is and what it can do for
you as opposed to what it is not. In these days of monolithic
applications that fulfill multiple roles, you might initially think
that Sendmail is the only application you need to run an email server
within your organization. Technically, that is true, as Sendmail can
spool mail to your users' directories and accepts new email via the
command line. But, most users actually require much more than simple
email delivery. They usually want to interact with their email using
an MUA that uses POP or IMAP to download their messages to their local
machine. Or, they may prefer a Web interface to gain access to their
mailbox. These other applications can work in conjunction with
Sendmail and SMTP, but they actually exist for different reasons and
can operate separately from one another.
It is beyond the scope of this section to go into all that Sendmail
should or could be configured to do. With literally hundreds of
different options and rule sets, entire volumes are dedicated to helping
explain everything that can be done and how to fix things that go
wrong. You should consult the many excellent online and offline sources
of information on Sendmail in order to shape it to fit your exact
specifications.
However, you should understand what files are installed with Sendmail
by default on your system and know how to make basic configuration
changes. You should also be aware of how to stop unwanted email (spam)
and how to extend Sendmail with the Lightweight Directory
Access Protocol (LDAP).
While you can download the source code for Sendmail and build your own
copy, many users prefer to use the version of Sendmail installed by
default with their Red Hat Linux system. You can also use the Red Hat Linux CD-ROMs to
reinstall the sendmail RPM at a later point.
After installation, the sendmail executable is
placed in the /usr/sbin directory.
Sendmail's lengthy and detailed configuration file
(sendmail.cf) is installed in
/etc. You should not edit the
sendmail.cf file directly unless you know exactly
what you are doing, due to the fact it is very lengthy and
complex. Instead, to make configuration changes to Sendmail, edit the
/etc/mail/sendmail.mc file and use the included
m4 macro processor to create a new
/etc/sendmail.cf (after backing up the original
/etc/sendmail.cf, of course). More information on
configuring Sendmail can be found in the section called Common Sendmail Configuration Changes.
Various Sendmail configuration files are installed in
/etc/mail including:
access — Specifies which systems can use
Sendmail for relaying email.
domaintable — Allows you to provide
domain name mapping.
local-host-names — The place where you
include all aliases for your machine.
mailertable — Specifies instructions that
override routing for particular domains.
virtusertable — Permits you to do a
domain-specific form of aliasing, allowing multiple virtual
domains to be hosted on one machine.
Several of the configuration files in /etc/mail,
such as access, domaintable,
mailertable and
virtusertable, must actually store their
information in database files before Sendmail can use any
configuration changes. To include any changes you make to these
configurations in their database files, you must run the
makemap hash
/etc/mail/<name> <
/etc/mail/<name> command,
where <name> is the name of the
configuration file to convert.
For example, if you want all email addressed to any
domain.com account to be delivered to
<bob@otherdomain.com>, you need to add a line to the
virtusertable file:
Then, to add this new information to the
virtusertable.db file, execute makemap
hash /etc/mail/virtusertable < /etc/mail/virtusertable as
root. This will create a new virtusertable.db
that contains the new configuration.
A default sendmail.cf file will be installed in
/etc. The default configuration should work for
most SMTP-only sites. It will not work for UUCP
(UNIX to UNIX Copy) sites; you will need to generate a new
sendmail.cf if you must use UUCP mail transfers.
If you need to generate a new /etc/sendmail.cf
file to configure Sendmail, you should utilize the
m4 macro processor. If you ever edit the
/etc/mail/sendmail.mc to add functionality to
Sendmail, backup your current /etc/sendmail.cf
file, generate a new one by executing the m4
/etc/mail/sendmail.mc > /etc/sendmail.cf command, and add
any previous changes from the /etc/sendmail.cf
you backed up to the new /etc/sendmail.cf
file. After creating a new /etc/sendmail.cf, you
must restart Sendmail to make it take effect. The easiest way to do
this is to type the service sendmail restart
command as root.
By default, the m4 macro processor is installed
with Sendmail. The m4 macro processor is included
with the sendmail-cf package, which is installed
in /usr/share/sendmail-cf.
You should consult the
/usr/share/sendmail-cf/README file before you edit
any of the files in the directories under the
/usr/share/sendmail-cf directory, as they can
affect how future /etc/sendmail.cf files are
configured.
One common Sendmail configuration is to have a single machine act as
a mail gateway for all the machines on the network. For instance, a
company may want to have a machine called
mail.bigcorp.com that does all their mail. On
that machine, add the names of machines for which
mail.bigcorp.com will handle mail to
/etc/mail/local-host-names. Here is an example:
On the other machines, torgo,
poodle, and devel, edit
/etc/sendmail.cf to "masquerade" as
mail.bigcorp.com when sending mail and to
forward any local mail processing to
bigcorp.com. Find the DH
and DM lines in
/etc/sendmail.cf and edit them as such:
With this type of configuration, all mail sent will appear as if it
were sent from bigcorp.com, and any mail sent
to torgo.bigcorp.com or the other hosts will be
delivered to mail.bigcorp.com.
Email spam can be defined as unnecessary and
unwanted email received by a user that probably does not know the
sender and never requested the communication. It is a very disruptive,
costly, and widespread abuse of Internet communication standards.
Sendmail has made it (relatively) easy to block new spamming
techniques being employed to send junk email using your system. It
even blocks many of the more usual spamming methods by default. You
would need to consciously activate them by changing your
/etc/mail/sendmail.mc file in a particular way to
make your system susceptible.
For example, forwarding of SMTP messages, also referred to as
SMTP relaying, has been disabled by default
since Sendmail version 8.9. Before this change occurred, Sendmail
would direct your mail host (x.org) to accept
messages from one party (y.com) and send them to
a different party (z.net). Now, however, you have
to specifically tell Sendmail to permit a domain to relay mail through
your domain. Simply edit the
/etc/mail/relay-domains file and restart Sendmail
by typing the service sendmail restart command as
root to activate the changes.
However, many times, your users may be bombarded with spam from other
servers throughout the Internet that are beyond your control. In these
instances, you can use Sendmail's access control features available
through the /etc/mail/access file. As root, add
the domains that you would like to block or specifically allow access,
such as:
Because /etc/mail/access is a database, you need
to use makemap to activate your changes by
recreating the database map. This is easily done by running the
makemap hash /etc/mail/access < /etc/mail/access
command as root.
This example shows that any email sent from
badspammer.com would be blocked with a 550
RFC-821 compliant error code and message back to the spammer, except
for email sent from the tux.badspammer.com
sub-domain, which would be accepted. The last line shows that any
email sent from the 10.0.*.* network can be relayed through your mail
server.
As you might expect, this example only scratches the surface of what
Sendmail can do in terms of allowing or blocking access. See the
/usr/share/doc/sendmail/README.cf for more
detailed information and examples.
Using the Lightweight Directory Access Protocol
(LDAP) is a very quick and powerful way to find specific
information about a particular user from a much larger group. For
example, you could use an LDAP server to look up a particular email
address from a common corporate directory by a user's last name. In
this kind of implementation, LDAP is largely separate from Sendmail,
with LDAP storing the hierarchical user information and Sendmail only
being given the result of LDAP queries in pre-addressed email
messages.
However, Sendmail supports a much greater integration with LDAP, where
it uses LDAP to replace separately maintained files, such as
aliases and virtusertables,
on different mail servers that work together to support a medium- to
enterprise-level organization. In short, you can use LDAP to abstract
the mail routing level from Sendmail and its separate configuration
files to a powerful LDAP cluster that is being leveraged by many
different applications.
The current version of Sendmail contains support for LDAP. To extend
your Sendmail server using LDAP, first get an LDAP server, such as
OpenLDAP, running and properly
configured. Then, you need to edit your
/etc/mail/sendmail.mc to include:
 | Note |
|---|
| | This is only for a very basic configuration of Sendmail with
LDAP. Your configuration should differ greatly from this depending
on your implementation of LDAP, especially if you wish to configure
several Sendmail machines to use a common LDAP server.
Consult /usr/share/doc/sendmail/README.cf for
detailed LDAP routing configuration instructions and examples.
|
Next, recreate your /etc/sendmail.cf file by
running m4 and restarting Sendmail. See the section called Common Sendmail Configuration Changes for instructions on doing this.
For more information on LDAP, see Chapter 15.
