Recipe 2.2 Fixing the Alias0 Missing Map Error and Creating Simple Aliases

Problem

sendmail displays the following error message:

 hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory 

Solution

Create a text file named /etc/mail/aliases and populate that file with entries in the form of:

   alias   :   recipient   

where alias is an alias username and recipient is the address to which mail addressed to the alias is delivered.

Run newaliases to process the text file and build the aliases database file required by sendmail:

 #  newaliases  

Discussion

No m4 configuration commands are needed to access the aliases database. Any basic sendmail configuration should work.

Most systems come with an aliases database. All you need to do is add the aliases that you desire to the existing aliases text file and run the newaliases command. However, if your system displays the "missing map file" error shown in the problem description, you either do not have an aliases database or the one you have is placed in the wrong directory. In either case, you need to put a valid aliases database in the proper path . If your system does not have an aliases file, use one from a similar system or the sample aliases file from the sendmail directory of the sendmail distribution as a starting point. If the file you have is in the wrong path, move it or change the sendmail configuration to point to the place where you keep the aliases database.

Some older systems store the aliases database in the /etc directory. To keep it in that directory, add the following ALIAS_FILE define to the sendmail.mc file:

 define(`ALIAS_FILE', `/etc/aliases') 

The ALIAS_FILE define can accept various flags. You can make the aliases database optional using the -o flag exactly as it was used in Recipe 2.1 with the confCW_FILE define. However, this is not a good idea. The -o flag prevents sendmail from displaying the "missing map file" error, but it does not stop sendmail from turning off aliasing when it cannot find an aliases file (i.e., it hides the error but does not fix the problem).

Instead of changing the default path or hiding the error with an ALIAS_FILE define, place the aliases text file in the /etc/mail directory. This is probably the best solution for most versions of Unix because /etc/mail is the default directory where most administrators expect to find this file. The following example moves the aliases text file and runs newaliases to solve the "missing map file" problem:

 #  sendmail -bv ftp  hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory ftp... deliverable: mailer local, user ftp #  mv aliases /etc/mail/aliases  #  sendmail -bv ftp  hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory root... deliverable: mailer local, user root #  newaliases  /etc/mail/aliases: 40 aliases, longest 10 bytes, 395 bytes total #  sendmail -bv ftp  root... deliverable: mailer local, user root 

The mv command and the newaliases command solve the problem. The three sendmail -bv ftp lines are used to show the effect of the mv and newaliases commands. The first -bv command shows the error message that we expect, and it shows that mail addressed to ftp will be sent to username ftp via the local mailer. After the mv command is executed, the second -bv command again shows the error message because we have not yet built the aliases database from the aliases text file. However, this time the -bv command shows that mail addressed to ftp will be delivered to the root user account via the local mailer. Clearly something has happened , and that something is aliasing. sendmail used the aliases text file to find that the correct delivery address for the ftp alias is root . Finally, newaliases is executed to build the database, and the last -bv test is run. This time there is no error, and we are again told the mail will be delivered to root via the local mailer. The output of the newaliases command says that newaliases processed 40 aliases.

The three sendmail -bv tests show exactly how sendmail handles the aliases files. If sendmail can find the aliases database, it uses it. If no aliases database is found, sendmail displays an error and checks for the aliases text file. If it finds the text file, sendmail uses it. If neither the database nor the text file can be found, sendmail turns off aliasing.

Entries from the sample Red Hat aliases file are shown below:

 # Basic system aliases -- these MUST be present. mailer-daemon:  postmaster postmaster:     root # General redirections for pseudo accounts. bin:            root daemon:         root adm:            root lp:             root sync:           root shutdown:       root halt:           root mail:           root news:           root ftp:            root # trap decode to catch security attacks decode:         root # Person who should get root's mail #root:          marc 

Lines that begin with a hash mark ( # ) are comments and can be ignored. The active entries begin with an alias and a colon that is followed by the recipient address. Notice that the recipient can be another alias. For example, mailer-daemon points to postmaster , which is really an alias for root . A -bv test shows the effect of this double alias:

 $  sendmail -bv mailer-daemon  root... deliverable: mailer local, user root 

Most of the entries in the sample Red Hat aliases file route mail addressed to non-login system accounts to the root user. No one actually logs in as root , yet all of the mail addressed to system accounts is routed to the root account. Notice the last comment in the sample aliases file is a commented-out alias for root . Remove the hash mark from the beginning of this line and change the recipient field to the user ID of the administrator's login account to route mail addressed to root to someplace where it will be read. Here is an example:

 # Person who should get root's mail root:          logan 

In this example, the administrator logs in to the logan account to read root 's mail. A sendmail -bv command shows the effect of this alias:

 #  sendmail -bv bin  logan... deliverable: mailer local, user logan 

sendmail first looks up bin and finds that it points to root . It then looks up root and finds that it points to logan . logan is not an alias, so delivery is made to the logan account. In this case, the aliases were nested two levels deep. By default, sendmail will search up to 10 levels of nested aliases and then display the following error if the alias does not resolve to a delivery address:

 aliasing/forwarding loop broken (11 aliases deep; 10 max) aliasing/forwarding loop broken 

Add the confMAX_ALIAS_RECURSION define to the sendmail configuration to change the depth to which sendmail will search nested aliases; for example:

 define(confMAX_ALIAS_RECURSION, 5) 

The line shown above reduces recursion to a maximum of five nested aliases. However, there is usually no good reason to change the default provided by sendmail. Reducing the amount of recursion doesn't enhance performance because the only time the maximum amount of recursion is reached is on those rare occasions that you have created an alias loop. You never want more recursion because if you need more than 10 levels of nesting you have designed your aliases incorrectly, which impacts sendmail's performance. As with most sendmail defines, the default value is the best.

You can control alias recursion for individual aliases without using an m4 macro or changing the sendmail.cf file. Force aliasing to stop at a specific alias by placing a backslash in front of the recipient address for that alias. For example:

 bin:            \root 

This is a contrived example. Of course, you don't really want to deliver mail to the root account. However, this contrived example works well to illustrate the impact of the backslash because the specific recursion of bin to root to logan is described just a few paragraphs back. Rerunning the sendmail -bv test after this alias is inserted in the aliases database shows the following result:

 #  sendmail -bv bin  \root... deliverable: mailer local, user \root 

Here the bin alias resolves to root and aliasing terminates ”sendmail does not go on to resolve root to logan . Usually, this type of recipient address is used in combination with the mail being copied to a file or forwarded to a program, and it is most commonly found in the .forward file instead of the aliases file. It is used in a .forward file in Recipe 2.9.

After creating the aliases text file, run newaliases to build the aliases database. The aliases database is actually built by sendmail; newaliases is really a symbolic link to the sendmail program and is equivalent to the sendmail command with the -bi flag.

See Also

Recipe 2.3 is a related recipe that shows how aliases can be read from an LDAP server. The sendmail book covers the aliases database in Chapter 12.