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.
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.
The cf/ostype/linux.m4 file is shown in Example 12-3.
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.
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.
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.
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:
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.
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.