Recipe 2.13 Enabling the User Database

Problem

Despite the fact that the sendmail developers discourage its use, you have decided to configure the user database.

Solution

Use the sendmail debug option -d0.1 to check that sendmail was compiled with the USERDB flag. If necessary, recompile sendmail to include user database support.

Create the user database source file and place a balanced pair of maildrop and mailname entries in the file for each username that will be mapped by the user database.

Use the makemap script to convert the completed source file into the required btree map type.

Assuming that the database file is created in the /etc/mail directory and is named userdb , add the following define to the sendmail configuration:

 define(`confUSERDB_SPEC', `/etc/mail/userdb')

Rebuild the sendmail.cf file, copy the new file to /etc/mail , and restart sendmail as described in Recipe 1.8.

Discussion

Three things are required before sendmail will check for a user database: sendmail must be compiled with the USERDB compiler flag, the mailer must have @ flag set, and the path to the user database must be defined inside the sendmail configuration using the confUSERDB_SPEC define. The Solution section assumes the file is named userdb and is placed in the /etc/mail directory.

The sendmail -d0.1 debug option displays the compiler flags used to create the sendmail binary. Examine the compiler flags listed after "Compiled with:". If USERDB is not listed, recompile the sendmail source code using either the NEWDB or HESIOD compiler flag and reinstall sendmail. (When either NEWDB or HESIOD are used, the USERDB flag is automatically set.) Select NEWDB or HESIOD based on whether the user database information will be stored on a Hesiod server or locally in a database file. Chapter 1 provides several examples of recompiling sendmail and, in particular, Recipe 1.4 shows how to add an optional map type to sendmail.

The user database file must be converted to a true database before it can be used by sendmail. Use the makemap command to build the database. For example, to create a database file named userdb from a user database source file named /etc/mail/userdb , use the following makemap command:

 #  cd /etc/mail  #  makemap btree userdb < userdb

The makemap program reads the standard input and writes out the specified database of the type selected. The command generally has two arguments: the database type and the name of the database to be written. The user database must be of the btree type, and the name of the user database must be the one defined inside the sendmail configuration. The makemap command is used extensively in this book with a variety of command-line options.

The user database is applied to inbound mail after the aliases database and before the .forward file when the mailer has the @ flag set.

The user database is not recommended. The sendmail developers tell me that it will probably be removed from the distribution sometime in the future. This recipe is shown only because you might have a great idea of how to use it. Just remember that the user database is not recommended for simply mapping outbound sender addresses. If you use it, you should have a special reason for doing so.

The entries in the user database look something like the entries in the aliases database except for the addition of a keyword, either maildrop or mailname . Generally, user database entries are balanced pairs, where each user has both a maildrop and a mailname entry. A pair of entries for the andy user account might be:

 andy.wright:maildrop andy andy:mailname andy.wright@wrotethebook.com

The entries that use the keyword maildrop are almost exactly like entries in the aliases database. The value before the colon (:) is the user alias and the value after the keyword maildrop is the recipient address. The sample maildrop entry shown above performs exactly the same function as the following line placed in the aliases database:

 andy.wright: andy

Both of these entries take mail addressed to andy.wright and deliver it to the andy user account. Of course maildrop lines are not needed if they replicate lines in the aliases file. The aliases file has already mapped inbound addresses before the user database is called. Real maildrop entries don't duplicate entries already found in the aliases database.

The similarity between entries in the aliases database and maildrop entries in the user database is very strong. The only difference in these entries, other than the addition of the keyword maildrop , is that maildrop entries cannot point to aliases. The recipient address in a maildrop entry must be a real address.

The added feature of the user database is that, unlike the aliases and .forward files, the user database also applies to outbound mail. mailname entries in the user database transform the sender address to create a reverse alias . In a mailname entry, the value before the colon (:) is the local username, and the value following the keyword mailname is the sender address that should be used for mail originating from the user. The mailname entry shown above converts the sender address on all mail from the user andy to andy.wright@wrotethebook.com .

However, the user database is not the only way, or even the recommended way, to rewrite outbound addresses. The sendmail FAQ, in question 3.3, states "the user database is no longer the recommended solution" for rewriting sender addresses. The genericstable database is the recommended tool for this task. Chapter 4 covers the genericstable .

The aliases database and the genericstable are preferred alternatives to the user database because:

The user database is more difficult to use than the alternatives. The aliases database is available in all sendmail configurations, but the user database requires m4 changes to the configuration. The genericstable also requires m4 changes, but in addition to m4 changes, the user database requires that the sendmail source code be compiled with a special compiler flag.
The user database replicates, but does not replace, the aliases database. For example, the user database cannot point an alias to an alias. Even if you create a user database, you still need an aliases database, meaning you now have two files to maintain.
The user database interacts with other features in ways you might not anticipate, as the sendmail FAQ makes clear in questions 3.3 and 3.4.

The sendmail developers make it clear in the response to FAQ question 3.4 that the user database was developed for a specific configuration requirement at UC Berkeley, and that it may not be applicable to a wide range of configurations. If you still insist on using it for something, this recipe points out the steps necessary to enable the user database.

Recipe 2.13 Enabling the User Database