• Choose a category
• All
• Classic-Fiction

Two database libraries are supported: the dbm/ndbm library that is standard with most versions of UNIX, and Berkeley DB, a more extensible library that supports multiple storage schemes. Your choice of database libraries must be specified at compile time. We recommend DB if you can install it; it’s faster than dbm and creates smaller files.

Three database map types are available:

• dbm – uses an extensible hashing algorithm (dbm/ndbm)

• hash – uses a standard hashing scheme (DB)

• btree – uses a B-tree data structure (DB)

For most table applications in sendmail, the hash database type—the default—is the best. Use the makemap command to build the database file from a text file; you specify the database type and the output file base name. The text version of the database should appear on makemap’s standard input, for example:

# makemap hash /etc/mail/access < /etc/mail/access

At first glance this command looks like a mistake that would cause the input file to be overwritten by an empty output file. However, makemap tacks on an appropriate suffix, so the actual output file is /etc/mail/access.db and in fact there is no conflict. Each time the text file is changed, the database file must be rebuilt with makemap (but sendmail need not be HUPed).

The longest possible match is used for database keys, so the order of entries in the input text file is not significant. FEATUREs that expect a database file as a parameter default to hash as the database type and /etc/mail/tablename.db as the filename for the database. To override this behavior, either specify the desired type to both the makemap command and the FEATURE or reset the default by defining a different value for the variable DATABASE_MAP_TYPE, for example:

define('DATABASE_MAP_TYPE', 'dbm')

To use your new access.db database, you’d add the following line to your .mc file:

FEATURE('access_db', 'hash /etc/mail/access')

Since this line uses the default type and naming scheme, you could just write

FEATURE('access_db')

You can specify the database filename either with or without the suffix (.db); without is preferred.

Don’t forget to rebuild the database file with makemap every time you change the text file, or your changes will not take effect.

We cover the mailertable, genericstable, and virtusertable FEATUREs in the next few sections. The access_db is covered later in the spam section. The user_db is not covered at all, since it is not in widespread use today.

The mailertable feature

The mailertable feature redirects mail addressed to a particular host or domain to an alternate destination via a particular mailer. It is applied as the mail goes out from a site. It only looks at the host portion of the address, not the user portion. The envelope address is not rewritten, so the mail continues to be addressed to the same user but is sent to a different host via a different mailer. mailertable was originally designed to deal with other mail systems such as UUCP, DECnet, and BITNET, but since these systems are no longer in common use, many sites no longer need constructs like mailertable.

An entry in the mailertable has the form:

old_domain mailer:user@new_domain

A leading dot in front of the key on the left side is a wild card that means any host in that domain. Only host and domain names are allowed as mailertable keys; usernames are not allowed. The user@new_domain value on the right side can be null, in which case the mail headers are not changed. The mailer value must be the name of a mailer defined in a MAILER clause; see page 576.

To use a mailertable, include the following line in your .mc file.

FEATURE('mailertable')

The genericstable feature

The genericstable feature (“generics table,” not “generic stable”) is like aliasing for outgoing mail. For example, it can map trent@xor.com to trent.hein@xor.com on outbound mail. It is the headers that are rewritten, not the envelope. Mail delivery is not affected, only replies.

Several mechanisms can be used to map hostnames, but the