UNIX System Administration Handbook - Evi Nemeth [340]
VERSIONID('$Id$')
and for SCCS it’s
VERSIONID('%W% (ident) %G%')
The actual version information will be filled in by RCS or SCCS as you check in the file. It will appear in the final sendmail.cf file as a comment. This information can also be useful if you forget where you put the sendmail distribution; often, the location of files is dictated by available disk space and not by filesystem design logic.
In the SCCS form, %W% expands to the filename and version, and %G% expands to the last modification time. Replace ident with a string that identifies your site.
The OSTYPE macro
Files in the ostype directory are named for the operating system whose default values they contain. An OSTYPE file packages up a variety of vendor-specific information, such as the expected locations of mail-related files, paths to commands that sendmail needs, flags to mailer programs, etc.
By convention, OS-specific information is interpolated into the config file with the OSTYPE macro.21
Every config file must include an OSTYPE macro near the top, typically just after VERSIONID.
OSTYPE files do their work primarily by defining other m4 variables. For example,
define('ALIAS_FILE', '/usr/lib/aliases')
specifies the location of the system-wide aliases file. You can override the default values for your OS later in the .mc file if you wish, but don’t change the distributed OSTYPE file unless it’s actually wrong, in which case you should submit a bug report too. Some sites want a consistent location for the aliases file across platforms and so redefine its location in their DOMAIN file.
The README file in the cf directory lists all the variables that can be defined in an OSTYPE file. Some of the important ones are shown in Table 19.10, along with several that you may want to configure for spam abatement (but which are undefined by default). The default values are what you get if your OSTYPE file doesn’t specify something else.
Table 19.10 Default values of some variables set in OSTYPE files
sendmail supports the use of multiple alias files and NIS maps, both to allow the simultaneous use of files and NIS and to facilitate the division of aliases between global and local files. For example,
define('ALIAS_FILE', ''/etc/aliases,nis:mail.aliases'')
would search the file /etc/aliases first, and if that failed, would then try the NIS map called mail.aliases.
See Chapter 18 for more information about NIS.
If you install sendmail on a new OS release or architecture, be sure to create a corresponding OSTYPE file and give it to sendmail.org so that it can be included in the next release. Just model your new file after those already there and check it against the table of defaults in the cf/README file. If the value of a variable on your new system is the same as the default value, you don’t need to include an entry for it (but it doesn’t hurt to protect yourself in case the default changes).
Table 19.11 shows the OSTYPE files for our four reference platforms.
Table 19.11 OSTYPE files for common systems
The DOMAIN macro
The DOMAIN directive allows site-wide generic information to be specified in one place (cf/domain/filename.m4) and then referred to in each host’s individual config file with
DOMAIN('filename')
The filename is usually chosen to describe your site. For example, our file for the computer science department is called cs.m4 and appears in our .mc files as:
DOMAIN('cs')
Like OSTYPE, DOMAIN is really just a nice way of doing an include. But it makes the structure of the config file clearer and provides a hook for future tweaks. It is most useful when you centralize and build all your site’s .cf files from .mc files kept in a single location.
Small sites do not usually need a domain file, but larger sites often use them for references to relay machines, site-wide masquerading or privacy options, and references to tables for mailers, virtual domains, and spam