Information may be easily changed without having to kill and restart sendmail, because database information is external to the configuration file.
The sendmail program starts up faster, because only the location of the information is stored at startup, rather than the information itself.
Rules are more versatile because database information can be used in the RHS side of rules. Class macros are still of use in the LHS.
To fully appreciate sendmail databases, consider the only
F configuration command.
For example, mail that is sent by using UUCP is a typical
application that requires lists of information:
Here, the external file /etc/mail/uuhosts contains a list
of UUCP hosts connected to the local machine.
If the list rarely changes, the
F command is appropriate.
On the other hand, if the list is volatile and changes often,
F command has drawbacks. The file /etc/mail/uuhosts
is read only when the configuration file is processed. Any change to
that file is ignored by a running sendmail (such as the daemon).
To make the change effective, the daemon needs to be killed and
 If you're running an old sendmail version with a freeze file, that file also will need to be recreated.
In such volatile situations, storing UUCP information in a database is preferred. A change to a database is immediately available to the running daemon, eliminating the need to kill and restart.
V8 sendmail is designed to rewrite addresses on the basis of
information looked up in external databases or in its internal symbol table.
It can use a wide variety of database forms, ranging from
ndbm(3) files (see Section 33.8.3, dbm) to Hesiod network maps
(see Section 33.8.6, hesiod).
K configuration command (see Section 33.3, "The K Configuration Command")
is used to declare the name,
location, and other parameters of databases or to modify use of
its symbol table.
$) database operators (see Section 33.4, "Use Maps with $( and $) in Rules")
are used in the RHS of rules to access and utilize that information.
Vendors that provide V8 sendmail in precompiled form may or may not provide access to all the types of databases that V8 sendmail supports. If your online documentation lacks this information, you can run strings(1) on sendmail to discover what it supports:
strings /usr/lib/sendmail | grep map_openndbm_map_open(%s, %s, %d) hash_map_open(%s, %s, %d) nis_map_open(%s, %s) text_map_open(%s, %s, %d) text_map_open: file name required text_map_open(%s): file name must be fully qualified text_map_open(%s): can not stat %s text_map_open(%s): %s is not a file text_map_open(%s): -k should specify a number, not %s text_map_open(%s): -v should specify a number, not %s text_map_open(%s): delimiter = %c stab_map_open(%s, %s) impl_map_open(%s, %s, %d) user_map_open(%s) switch_map_open(%s, %s, %d)
In this implementation of sendmail, NDBM (the
and Berkeley DB (the
hash_map_open) type database files are
available. Sun style NIS maps (the
nis_map_open) are also
The others (
switch) are always automatically included.
nisplus maps are not supported by
this particular sendmail binary.
If you download and compile sendmail yourself, you may include any supported databases. Support is declared on the DBMDEF= line in the appropriate Makefile for your system. Possible definitions for DBMDEF= are shown in Table 33.1.
|Definition||Database Support Included|
|-DHESIOD||Section 33.8.6||hesiod(3) aliases only|
|-DLDAPMAP||Section 33.8.9, ldapx||ldap(3) white pages|
|-DNDBM||Section 33.8.3||ndbm(3) database files|
|-DNEWDB||Section 33.8.1, btree||Berkeley db(3) database files|
|-DNIS||Section 33.8.11, nis||Sun NIS network databases|
|-DNISPLUS||Section 33.8.12, nisplus||Sun NIS+ network databases|
|-DNETINFO||Section 33.8.10, netinfo||NeXT netinfo(3) aliases only|
For example, the Makefile.ULTRIX file might include this line:
DBMDEF= -DNDBM -DNEWDB -DNIS
which includes support for ndbm(3), db(3), and nis(3) databases,  whereas the Makefile.SunOS.5.x file might include the following:
 If you declare support for both NDBM and NEWDB, be sure to remove ndbm.h and ndbm.o from the NEWDB distribution. Failure to remove them will confuse sendmail, causing it to fail in ugly ways.
DBMDEF= -DNDBM -DNIS -DNISPLUS
which excludes db(3) support but includes nisplus(3) support.
If you omit all database support (by undefining DBMDEF, for example,
or not supplying support indications after the equal sign), sendmail will
be unable to maintain its aliases in database format. Also, any
attempt to rebuild the aliases database (with newalias or
-bi) will fail with the following error message:
Cannot rebuild aliases: no database format defined Cannot create database for alias file /etc/aliases: No such device