 | Chapter 24 Aliases |  |
| Chapter 24 Aliases | |
Reading the aliases file every time sendmail begins to run can slow mail delivery and create a lot of unnecessary computational overhead. To improve efficiency, sendmail has the ability to store aliases in a separate database format on disk. In this format, sendmail rarely needs to read the aliases file. Instead, it merely opens the database and performs lookups as necessary.
The sendmail program builds its database files by reading the aliases(5) file and rewriting that file in database format. Usually, the aliases file is called aliases. With that name, ndbm(3) database files are called aliases.pag and aliases.dir, and the db(5) database file is called aliases.db.
The sendmail program offers several forms of database, one of which is chosen at compile time (see Section 18.4.1, "DBMDEF=").
You tell sendmail to rebuild its database files
by running it in -bi mode. This mode can be executed in
two different ways:
%newaliases%/usr/lib/sendmail -bi
The first form is shorthand for the second. Either causes sendmail to rebuild those files. If the database is successfully built, sendmail prints a single line:
895 aliases, longest 565 bytes, 30444 bytes total
This shows that 895 local entries appeared to the left of
colons in the aliases file. The longest list of addresses
to the right of a colon was 565 bytes (excluding the newline).
And there were 30,444 total bytes of noncomment information in
the file.
V8 sendmail supports multiple alias database files (see the
AliasFile (A) option, Section 34.8.1).
Consequently, each line of its output is prefixed with the name
of the alias file being rebuilt. For example,
/etc/aliasdir/users: 895 aliases, longest 565 bytes, 30444 bytes total /etc/aliasdir/lists: 34 aliases, longest 89 bytes, 1296 bytes total
When V8 sendmail rebuilds the alias database files, it can optionally
be told to check the legality of all addresses to the right of the
colons. The CheckAliases (n) option
(see Section 34.8.6, CheckAliases (n)) turns on this check:
O CheckAliases=True # validate RHS in newaliases
Each address is validated by running it through rule set 3, then rule set 0. Rule set 0 must select a delivery agent for the address. If it does, the address is silently validated and accepted. If not, the address is skipped, and the following warning is printed:
address... bad address
Other errors may be printed before the above line that indicate more specific reasons for the failure. For example,
... Unbalanced '<'
The -d20.1 debugging switch
(see Section 37.5.66, -d20.1) can be used to gain a better idea of
why the address failed. But be forewarned: The
-d20.1 switch can produce many screens of output.
In general, we do not recommend setting the CheckAliases (n) option
to true in the configuration file, because it can cause each right-side address to
be resolved through DNS and thus slow down the rebuild considerably.
For better efficiency, leave the CheckAliases (n) option off
in the configuration file and turn it on only when rebuilding by hand:
%newaliases -on
The alias database files can be automatically rebuilt in three ways:
by the daemon
(if the AutoRebuildAliases (D) option, see Section 34.8.4, AutoRebuildAliases (D),
is true), by users sending mail (and thereby
indirectly running sendmail), and by users intentionally rebuilding
the database with
newaliases (or the -bi command-line switch). To prevent
one rebuild from compromising and corrupting another, sendmail
uses file locking.
The sendmail program uses flock(2) or fcntl(2) with F_SETLK to lock the aliases file (depending on how it was compiled). If the aliases file is already locked (because the database is currently being rebuilt), sendmail prints the following message:
Alias filenameis already being rebuilt
If sendmail is attempting to rebuild because it was
run as newaliases or with the -bi command-line
switch, the above message is printed, and the program exits.
Otherwise, the above message is printed, and sendmail waits
for the aliases file to become unlocked.
Once the aliases file is locked, sendmail next
looks to see whether the key @ appears in the database. If that key
is missing, sendmail knows that the database is still
being rebuilt. If the AliasWait (a) option
(see Section 34.8.2, AliasWait (a)) has a value, sendmail
waits that amount of time for the other rebuild to finish.
If the AliasWait (a) option is missing or has a zero value,
sendmail plows ahead, trusting the previous
lock to prevent simultaneous rebuilds.
The sendmail program waits the number of seconds
specified by the AliasWait (a) option for an @ key to
appear in the database. If that key doesn't appear within that
wait, sendmail continues with the rebuild, assuming that
some other process died while attempting to rebuild.
Before entering the key (the name to the left of the colon) and contents
(everything to the right of the colon) pairs into the database, sendmail
truncates the database (reduces it to size zero), thereby
removing the @ key.
After all the key and contents pairs have been written to the
database, sendmail adds a new @ key to show
that it is done.
Finally, sendmail closes the database and the aliases file. Closing the aliases file releases all locks it has on that file.
Some versions of UNIX do not provide the libraries that are needed to compile sendmail with database support. When neither the db(3) nor ndbm(3) library is available, and when no other method for getting aliases is declared (such as nis), sendmail keeps aliases in its internal symbol table.
When the symbol table is used, sendmail builds its alias database only once. When sendmail is run as a daemon, the aliases file is read only once. If the file changes, the daemon needs to be killed and restarted. In general, it is not recommended to run sendmail in daemon mode without external database files.
|  | |
| 24.4 Special Aliases |  | 24.6 Prevent Aliasing with -n |