UNIX System Administration Handbook - Evi Nemeth [330]
The hashed alias database
Since entries in the aliases file are in no particular order, it would be inefficient for sendmail to search this file directly. Instead, a hashed version is constructed with either the Berkeley DB database system or the ndbm database system that is standard on most versions of UNIX. This hashing significantly speeds alias lookups, especially when the file gets big.
The files derived from /etc/mail/aliases are called aliases.db for DB and aliases.dir and aliases.pag, for ndbm. The dir file is an index for the pag file, in which the data actually resides. Every time you change the aliases file, you must rebuild the hashed database with the newaliases command. newaliases is really just sendmail in disguise with command-line flags (-bi) that tell it to rebuild the database. Save the error output if you run newaliases automatically—you might have introduced formatting errors.
When you compile sendmail, you should include database library support for the dbm/ndbm routines, the new Berkeley DB routines, or both. If both are included and sendmail needs to create a database file but the type is not specified, it uses DB. If you are using NIS, sendmail creates both but uses only the DB version.
See Chapter 18 for more information about NIS.
The DB library, written and maintained by Keith Bostic and Margo Seltzer, is available at www.sleepycat.com. It is much better (faster access, smaller database files) than the ndbm system. DB is open source and free unless you ship it in a proprietary product; then, you need a license.
Mailing lists and list wrangling software
A mailing list is a giant alias that sends a copy of each message posted to it to each person who has joined the list. It’s like a Usenet newsgroup that is delivered by email. Some mailing lists have thousands of recipients.
Mailing lists are usually specified in the aliases file but maintained in an external file. Some standard naming conventions are understood by sendmail and most mailing list software. Experienced users have come to rely on them as well. The conventions are illustrated by the following aliases:
mylist: :include:/etc/mail/include/mylist
owner-mylist: mylist-request
mylist-request: evi
owner-owner: postmaster
In this example, mylist is the name of the mailing list. The members are read from the file /etc/mail/include/mylist. Bounces from mailing to the list are sent to its owner, evi, as are requests to join the list. The indirection from “owner” to “request” to evi is useful because the owner’s address (in this case, mylist-request) becomes the Return-Path address on each message sent to the list. mylist-request is a bit better than the actual maintainer for this field. Errors in messages to the owner-mylist alias (evi, really) would be sent to owner-owner.
The case when a message is undeliverable is called a bounce. The case when the error message sent about the bounce cannot be delivered is a double bounce. So in our example, double bounces are sent to owner-owner or postmaster.
If you use a site-wide aliases file, you need to add an extra level of indirection pointing mylist to myreallist@master, so that the data file containing the list of members only needs to exist in one place.
Several software packages automate the maintenance of mailing lists. They typically allow users to add and remove themselves from the list, obtain information about the list, and obtain files through email. A few of the popular mailing list managers (and their download sources) are
• Majordomo, from www.greatcircle.com
• Mailman, the GNU mailing list processor, from www.list.org
• ListProc, from www.cren.net
• SmartList, from ftp.informatik.rwth.aachen.de
• LISTSERV Lite, from www.lsoft.com12
A good FAQ by Norm Aleks on mailing list software is available from rtfm.mit.edu via FTP (look under comp.answers/mail/list-admin). Unfortunately, the FAQ is no longer maintained and so might be a bit