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

12.4. Creating a sendmail Configuration

Using the
sendmail.mc and sendmail.cf
information covered so far in this chapter you should be able to read
or create a basic sendmail configuration. Let's get
started by looking at a sample sendmail.mc file.

The sendmail
distribution comes with a large number of sample macro configuration
files located in the cf/cf directory. Many are
generic configuration files for different operating systems,
including the generic-linux.mc file for Linux.
Example 12-2 shows the contents of this file.

Example 12-2. The generic-linux.mc file

divert(-1)
#
# Copyright (c) 1998, 1999 Sendmail, Inc. and its suppliers.
#       All rights reserved.
# Copyright (c) 1983 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988, 1993
#       The Regents of the University of California.  All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#
#
#  This is a generic configuration file for Linux.
#  It has support for local and SMTP mail only.  If you want to
#  customize it, copy it to a name appropriate for your environment
#  and do the modifications there.
#
divert(0)dnl
VERSIONID(`$Id: ch12.xml,v 1.2 2005/03/03 21:11:44 ellie Exp ellie $') 
OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl

A few things are obvious about this
configuration file without knowing anything about the file syntax.
First, the name sendmail.mc is obviously not
sacrosanct. generic-linux.mc works just as well
and is clearly a more descriptive name. Second, the configuration
file is very short. The bulk of the lines in Example 12-1 are comments; only the last five lines are
really sendmail configuration commands. Third, the sendmail
configuration commands are short with a relatively simple syntax.

The
five active lines in the generic-linux.mc file
are composed of four different macros. The
VERSIONID macro from the
generic-linux.mc file is:

VERSIONID(`$Id: ch12.xml,v 1.2 2005/03/03 21:11:44 ellie Exp ellie $')

From this we
know that the generic-linux.mc file was last
updated in September 1999 by Greg Shapiro, one of the Linux
developers.

The
OSTYPE(`linux')
command in the generic-linux.mc file loads the
cf/ostype/linux.m4 file, which we will look at
shortly. The
DOMAIN(`generic')
macro processes the cf/domain/generic.m4 file,
which is also discussed shortly.

Finally, the
MAILER(`local')
and
MAILER(`smtp')
macros are used to add the local,
prog, smtp,
esmtp, smtp8,
dsmtp, and relay mailers to the
sendmail.cf configuration.

These five macro lines create the entire generic Linux sendmail
configuration. There are, however, additional details to be found in
the linux.m4 and generic.m4
file.

12.4.1. The linux.m4 OSTYPE File

The cf/ostype/linux.m4
file is shown in Example 12-3.

Example 12-3. The linux.m4 OSTYPE file

divert(-1)
#
# Copyright (c) 1998, 1999 Sendmail, Inc. and its suppliers.
#       All rights reserved.
# Copyright (c) 1983 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988, 1993
#       The Regents of the University of California.  All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#
divert(0)
VERSIONID(`$Id: ch12.xml,v 1.2 2005/03/03 21:11:44 ellie Exp ellie $')
define(`confEBINDIR', `/usr/sbin')
ifdef(`PROCMAIL_MAILER_PATH',,
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail'))
FEATURE(local_procmail)

The file begins with a block of comments
and a VERSIONID macro. It then defines the path to
the directory that holds executable binaries. The path is stored in
the m4 variable confEBINDIR. The
linux.m4 file sets that path value to
/usr/sbin. Next, if the path to
procmail has not yet been defined, it is set to
/usr/bin/procmail. The last line in the file is
a FEATURE macro that loads the
local_procmail feature, which cause sendmail to
use procmail as the local
mailer. m4 uses the path defined for
PROCMAIL_MAILER_PATH when constructing the
local_procmail feature. This is an excellent
example of how a value is first defined and then used in building a
configuration. The linux.m4 file is also a good
example of the type of configuration commands normally found in an
OSTYPE file.

12.4.2. The generic.m4 DOMAIN File

The
cf/domain/generic.m4 file is a sample
DOMAIN file provided by the sendmail developers.
It is used by the generic-linux.mc file shown in
Example 12-1. The generic.m4
file is shown in Example 12-4.

Example 12-4. The generic.m4 DOMAIN file

divert(-1)
#
# Copyright (c) 1998, 1999 Sendmail, Inc. and its suppliers.
#       All rights reserved.
# Copyright (c) 1983 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988, 1993
#       The Regents of the University of California.  All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#
#
#  The following is a generic domain file.  You should be able to
#  use it anywhere.  If you want to customize it, copy it to a file
#  named with your domain and make the edits; then, copy the appropriate
#  .mc files and change `DOMAIN(generic)' to reference your updated domain
#  files.
#
divert(0)
VERSIONID(`$Id: ch12.xml,v 1.2 2005/03/03 21:11:44 ellie Exp ellie $')
define(`confFORWARD_PATH', `$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/
.forward')dnl
define(`confMAX_HEADERS_LENGTH', `32768')dnl
FEATURE(`redirect')dnl
FEATURE(`use_cw_file')dnl
EXPOSED_USER(`root')

Again the file begins with
a large block of comments and a VERSIONID macro.
This is followed by a define that sets the search
path sendmail will use when looking for a user's
.forward file. This command sets the
ForwardPath option in the
sendmail.cf file. $z,
$w, and $h are internal
sendmail.cf macros.[4]

[4] See the
cf/README file for more information about these
sendmail.cf macros and the Sendmail
Installation and Operations Guide, found in file
doc/op.ps, for a full list of all
sendmail.cf macros.

The second
define sets the maximum length for all headers in
a single piece of mail to 32,768 bytes. It does this by setting the
MaxHeadersLength option in the
sendmail.cf file.

The next two lines add features to the
sendmail configuration. The
FEATURE(`redirect')
macro adds support for the .REDIRECT
pseudo-domain. A pseudo-domain is a domain-style extension internally
added to an email address by sendmail to define special handling for
the address. The .REDIRECT pseudo-domain works
together with the aliases database to handle
mail for people who no longer read mail at your site but who still
get mail sent to an old address.[5] After enabling this feature, add an alias
for each obsolete mailing address in the form:

[5] The
aliases database is covered later in this
chapter.

old-address
new-address.REDIRECT

This returns the following error to the sender telling them to try a
new address for the recipient:

551 User not local; please try <new-address>

The
FEATURE(`use_cw_file')
command reads /etc/mail/local-host-names and
adds the hostnames listed there to sendmail.cf
class $=w. Class $=w contains
the names of hosts for which the local computer will accept local
mail. Normally, when a system running sendmail receives mail from the
network that is addressed to another hostname, it assumes that the
mail belongs to that host and forwards the mail to that host if the
local host is configured as a relay, or discards the mail if the
local host is not configured as a relay. If the system should accept,
as local mail, mail that is addressed to another host, the name of
the other host is added to class $=w. Any hostname
listed in the local-host-names file is added to
class $=w when the use_cw_file
feature is used.

The last line in the
generic.m4 file is the
EXPOSED_USER macro. The
EXPOSED_USER macro adds usernames to class
$=E. The users listed in class
$=E are not masqueraded, even when masquerading is
enabled. (Masquerading hides the real hostname in outbound mail and
replaces it with the hostname you wish to advertise to the outside
world.) Some usernames, such as root, occur on
many systems and are therefore not unique across a domain. For those
usernames, converting the host portion of the address makes it
difficult to sort out where the message really came from and makes
replies impossible. The EXPOSED_USER command in
the generic.m4 file prevents that from happening
by ensuring that root is not masqueraded.

Given the commands contained in the
generic-linux.mc file, the
linux.m4 file and the
generic.m4 file, the generic Linux configuration
does the following:

• Sets /usr/sbin as the path to executable binaries

• Sets the procmail path to
  /usr/bin/procmail

• Uses procmail as the local
  mailer

• Defines the search path for .forward files

• Adds support for the .REDIRECT pseudo-domain to
  the configuration

• Loads class $=w from the
  /etc/local-host-names file

• Adds root to class $=E

• Adds the local, prog,
  smtp, esmtp,
  smtp8, dsmtp, and
  relay mailers to the configuration

You can
configure sendmail by modifying the configuration provided in your
Linux distribution or create a custom configuration by modifying the
generic-linux.mc file provided with the sendmail
distribution. In the next section we build a sendmail configuration
based on the generic-linux.mc file.

12.4.3. Creating a Sample Linux sendmail Configuration

We begin building our custom configuration by changing to the
configuration directory and copying the
generic-linux.mc configuration file to a working
file. Because we are creating the configuration for vstout.vbrew.com, we call the working file
vstout.mc.

$ cd sendmail-8.12.11/cf/cf
$ cp generic-linux.mc vstout.mc

We are configuring vstout to be a mail server
for our group. We want it to:

• Accept inbound mail for various clients
  that plan to store mail on the server. No modifications to the m4
  configuration are needed to support this because the
  domain/generic.m4 file used in the Linux
  configuration already includes the
  FEATURE(`use_cw_file')
  command.

• Relay
  mail for clients in the vbrew.com
  domain. Implementing this requires no changes to the m4
  configuration. By default, sendmail configurations support relaying
  for any domain defined in the relay-domains
  file. We will see how to configure the
  relay-domains file later in the chapter when we
  discuss sendmail databases.

• Rewrite the sender address on outbound
  mail to a generic format used by everyone at vbrew.com. We will add support for the
  genericstable database to do this. The contents
  of the genericstable database is covered in the
  sendmail databases section of this chapter.

• Provide some
  anti-spam support. We will use the access
  database for this task.

• Be easy to configure with additional
  security measures. The access database added for
  its anti-spam capabilities has many other easily configured features.
  We will see more about the access database in
  sendmail databases section later in this chapter.

To configure sendmail to do the tasks listed above, we edit the
vstout.mc file and add the following features:

FEATURE(`genericstable')
GENERICS_DOMAIN(`vbrew.com')
FEATURE(`generics_entire_domain')
FEATURE(`access_db')

This first line adds support for the
genericstable. The second line defines vbrew.com as the domain to which the
genericstable will be applied. The third line
tells sendmail to apply the genericstable to
every host in the vbrew.com domain.
The final line adds support for the access
database.

After
removing unneeded comments, updating the VERSIONID
and adding the new lines, the vstout.mc
configuration file is as shown below in Example 12-5:

Example 12-5. Sample custom configuration

VERSIONID(`Sample vstout configuration by Craig Hunt')
OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
dnl Add support for the genericstable
FEATURE(`genericstable')
dnl Apply the genericstable to the vbrew.com domain
GENERICS_DOMAIN(`vbrew.com')
dnl Apply the genericstable to every host in the domain
FEATURE(`generics_entire_domain')
dnl Add support for the versatile access database
FEATURE(`access_db')
MAILER(`local')dnl
MAILER(`smtp')dnl

We now need to build a sendmail.cf file from our
master configuration file, install the new
sendmail.cf file, and ensure that sendmail reads
it.

12.4.4. Building the sendmail.cf File

The
sendmail.cf file is normally built in the same
cf/cf directory where the master configuration
file is created. If you're not currently in that
directory, change to the cf/cf directory before
attempting the build.

Run Build to create the
sendmail.cf file from the m4 master
configuration file. The Build script is easy to
use. Provide the name of the output file you want to create as an
argument on the Build command line. The script
replaces the .cf extension of the output file
with the extension .mc and uses the macro
configuration file with that name to create the output file. Thus,
putting vstout.cf on the
Build command line means that
vstout.mc is used to create
vstout.cf. Here is an example:

$ ./Build vstout.cf
Using M4=/usr/bin/m4
rm -f vstout.cf
/usr/bin/m4 /m4/cf.m4 vstout.mc > vstout.cf || ( rm -f vstout.cf && exit 1 )
chmod 444 vstout.cf

Despite the simplicity of the Build command, many
administrators never use it to build a sendmail configuration because
the m4 command line used to build a sendmail configuration is also
very simple. The m4 command line that would build the
vstout.cf file from the
vstout.mc file is:

$ m4 ../m4/cf.m4 vstout.mc > vstout.cf

For the average sendmail administrator,
the Build script doesn't offer
any critical advantages. For most of us, deciding to use the
Build script or the m4 command is primarily a
matter of personal preference. It is even possible to invoke the
Makefile directly with a basic
make command. Use whatever method you prefer.

After building the new .cf file, test it
thoroughly as described later in this chapter before copying that
file to the location where sendmail expects to find the
sendmail.cf configuration file, which is usually
/etc/mail/sendmail.cf. In most cases this is
simply done with a cp
command

# cp vstout.cf /etc/mail/sendmail.cf

However, it can also be done with the Build
command, as follows:

# mv vstout.cf sendmail.cf
# ./Build install-cf
Using M4=/usr/bin/m4
../../devtools/bin/install.sh -c -o root -g bin -m 0444 sendmail.cf /etc/mail/sendmail.cf
../../devtools/bin/install.sh -c -o root -g bin -m 0444 submit.cf /etc/mail/submit.cf

The Build
install-cf command used above installs two configuration
files: the sendmail.cf file, and a second file
named submit.cf.
sendmail.cf doesn't exist unless you
create it. (In this case we created it as
vstout.cf and renamed that file
sendmail.cf.) But a full
submit.cf file is delivered with the sendmail
distribution, and does not normally need to be created or modified by
you. The submit.cf file is the special
configuration used by sendmail when it acts as a mail submission
program, while sendmail.cf is the configuration
file used by the sendmail daemon. The Build
install-cf command is generally used when a new
sendmail distribution is first installed to ensure that both the
sendmail.cf and submit.cf
files are installed. Other than the initial installation, however,
there is generally no need to copy both files at the same time
because it is not usually necessary to create a new
submit.cf file when you create a new
sendmail.cf file.

Once the configuration is installed, restart sendmail to force it to
read the new configuration by sending it a HUP
signal. This method of restarting sendmail uses standard sendmail
signal processing that is available on any Linux system:

# kill -HUP `head -1 /var/run/sendmail.pid`

Some Linux systems provide their own tools for managing daemons. For
example, some systems can start sendmail with the
service command:

# service sendmail start
Starting sendmail: [  OK  ]

Regardless of how sendmail is restarted, when the daemon starts it
reads in the configuration file
/etc/mail/sendmail.cf, which now contains the
new configuration.