UNIX System Administration Handbook - Evi Nemeth [339]
Building a configuration file from a sample .mc file
Before we dive into pages and pages of details about the various configuration macros, features, and options, we will put the cart before the horse and create a “no frills” configuration to illustrate the process. Our example is for a leaf node, foo.com, and the master configuration file is called foo.mc.
We’ll put foo.mc in our shiny new cf directory. The translated (by m4) configuration file will be foo.cf in the same directory and we’ll ultimately install it as sendmail.cf in /etc/mail.
Some boilerplate should go in each new .mc file:
divert(-1)
#### basic .mc file for foo.com
divert(0)
VERSIONID('$Id$')
If you want to put comments at the start of your file, the first line has to be a divert statement, which throws away any spurious garbage on the m4 output streams. The #-style comments come next, followed by another divert. A VERSIONID line (here, in RCS format) completes the boilerplate. It is described in detail in the next section.
In many cases, specifying an OSTYPE (see page 574) to bring in operating-system-dependent paths or parameters and also a set of MAILERs (see page 576) will complete the configuration:
OSTYPE('linux')
define('confCOPY_ERRORS_TO', 'postmaster')
MAILER('local')
MAILER('smtp')
Here, we also set an option (confCOPY_ERRORS_TO) that sends a copy of the headers of any bounced mail to the local postmaster. This notification allows the postmaster to intervene when the problem is at the local site.
To build the real configuration file, just run the Build command you copied over to the new cf directory:
# ./Build foo.cf
Finally, install foo.cf in the right spot—normally /etc/mail/sendmail.cf, but some vendors move it. Favorite vendor hiding places are /etc and /usr/lib.
A larger site can create a separate m4 file to hold site-wide defaults in the cf/domain directory; individual hosts can then include the contents of this file. Not every host needs a separate config file, but each group of hosts that are similar (same architecture and same role: server, client, etc.) will probably need its own configuration.
Even with sendmail’s easy new configuration system, you still have to make several configuration decisions for your site. As you read about the features described below, think about how they might fit into your site’s organization. A small site will probably have only a hub node and leaf nodes and thus will need only two versions of the config file. A larger site may need separate hubs for incoming and outgoing mail and, perhaps, a separate POP/IMAP server.
Whatever the complexity of your site and whatever face it shows to the outside world (exposed, behind a firewall, or on a virtual private network, for example), it’s likely that the cf directory contains some appropriate ready-made configuration snippets just waiting to be customized and put to work.
19.7 BASIC SENDMAIL CONFIGURATION PRIMITIVES
sendmail configuration commands are case sensitive. By convention, the names of predefined macros are all caps (e.g., OSTYPE), m4 commands are all lower case (e.g., define), and configurable variable names start with a lowercase conf and end with an all-caps variable name (e.g., confCOPY_ERRORS_TO). Macros usually (all except VERSIONID) refer to an m4 file called ../macroname/arg1.m4. For example, the macro OSTYPE('linux') causes ../ostype/linux.m4 to be included.
In this section we cover the basic configuration commands and leave the fancier features for later.
The VERSIONID macro
You should maintain your config files with CVS, RCS or SCCS, not only so that you can back out to an earlier config version if that should be necessary but also so that you can identify the versions of the m4 files that go