Sendmail Operation Guide

The alias database

The alias database exists in two forms. One is a text form, maintained in the file /etc/aliases. The aliases are of the form

   name: name1, name2, ...
Only local names may be aliased; for example:
   eric@prep.ai.MIT.EDU: eric@CS.Berkeley.EDU
will not have the desired effect (except on prep.ai.MIT.EDU.)

Aliases may be continued by starting any continuation lines with a space or a tab, or by putting a backslash directly before the newline. Blank lines and lines beginning with a hash sign (#) are comments.

The second form is processed by the ndbm(3bsd) library. This form is in the files /etc/aliases.dir and /etc/aliases.pag (if using NEWDB). This is the form that sendmail actually uses to resolve aliases. This technique is used to improve performance.

The control of search order is actually set by the service switch. Essentially, the entry

   O AliasFile=switch:aliases
is always added as the first alias entry; also, the first alias filename without a class (for example, without nis: on the front) will be used as the name of the file for a ``files'' entry in the aliases switch. For example, if the configuration file contains:
   O AliasFile=/etc/aliases
and the service switch contains:
   aliases     nis files nisplus
then aliases will first be searched in the NIS database, then in /etc/aliases, then in the NIS+ database.

You can also use NIS-based alias files. For example, the specification:

   O AliasFile=/etc/aliases
   O AliasFile=nis:mail.aliases@my.nis.domain
will first search the /etc/aliases file and then the map named mail.aliases in my.nis.domain.


NOTE: If you build your own NIS-based alias files, be sure to provide the -l flag to makedbm(1Mnis) to map upper case letters in the keys to lower case; otherwise, aliases with upper case letters in their names won't match incoming addresses.

Additional flags can be added after the colon exactly like a K line; for example:

   O AliasFile=nis:-N mail.aliases@my.nis.domain
will search the appropriate NIS map and always include null bytes in the key.

Rebuilding the alias database

The hash or dbm version of the database may be rebuilt explicitly by executing the newaliases command. This is equivalent to giving sendmail the -bi flag:

/usr/lib/sendmail -bi

If the RebuildAliases (old D) option is specified in the configuration, sendmail will rebuild the alias database automatically if possible when it is out of date. Auto-rebuild can be dangerous on heavily loaded machines with large alias files; if it might take more than the rebuild timeout (option AliasWait, old a, which is normally five minutes) to rebuild the database, there is a chance that several processes will start the rebuild process simultaneously.

If you have multiple aliases databases specified, the -bi flag rebuilds all the database types it understands (for example, it can rebuild NDBM databases but not NIS databases).

Potential problems

There are a number of problems that can occur with the alias database. They all result from a sendmail process accessing the DBM version while it is only partially built. This can happen under two circumstances: one process accesses the database while another process is rebuilding it, or the process rebuilding the database dies (due to being killed or a system crash) before completing the rebuild.

Sendmail has three techniques to try to relieve these problems. First, it ignores interrupts while rebuilding the database; this avoids the problem of someone aborting the process leaving a partially rebuilt database. Second, it locks the database source file during the rebuild, but that may not work over NFS or if the file is unwritable. Third, at the end of the rebuild it adds an alias of the form

@: @

This is not normally legal. Before sendmail will access the database, it checks to insure that this entry exists. The AliasWait option is required in the configuration for this action to occur. This should normally be specified.

List owners

If an error occurs on sending to a certain address, such as x, sendmail will look for an alias of the form owner-x to receive the errors. This is typically useful for a mailing list where the submitter of the list has no control over the maintenance of the list itself; in this case the list maintainer would be the owner of the list. For example:

   unix-wizards: eric@ucbarpa, wnj@monet, nosuchuser,
        sam@matisse
   owner-unix-wizards: unix-wizards-request
   unix-wizards-request: eric@ucbarpa
would cause eric@ucbarpa to get the error that will occur when someone sends to unix-wizards due to the inclusion of nosuchuser on the list.

List owners also cause the envelope sender address to be modified. The contents of the owner alias are used if they point to a single user, otherwise the name of the alias itself is used. For this reason, and to obey Internet conventions, the owner- address normally points at the -request address; this causes messages to go out with the typical Internet convention of using list -request as the return address.


© 2000 The Santa Cruz Operation, Inc. All rights reserved.