UNIX System Administration Handbook - Evi Nemeth [326]
See page 560 for more information about LDAP.
LDAP alone does not work for mailing lists aliases; these are better handled with the standard aliasing mechanisms.
sendmail uses an LDAP server much like it uses the DNS name server. It calls on the DNS server to resolve names into IP addresses so that messages can be sent. It calls on the LDAP server to look up aliases to reroute messages to the right place. In both cases, the lookups have moved from flat files (/etc/hosts and /etc/aliases) to databases, with servers managing the queries.
We cover LDAP in more detail in three places in this chapter, and we also mention it in Chapter 18, Sharing System Files. We introduce and explain LDAP on page 560. Then, we describe LDAP’s interaction with sendmail and with sendmail’s configuration file on page 582, and our first example, on page 590, uses LDAP to do aliasing and virtual hosting.
Before diving into LDAP, however, we first describe the traditional aliasing mechanisms. Aliases can be defined in the following three places (unfortunately, with three different syntaxes).
• In a user agent’s configuration file (by the sending user)
• In the system-wide /etc/mail/aliases file (by the sysadmin)
• In a user’s forwarding file, ~/.forward (by the receiving user)
The user agent looks for aliases in the user’s config files and expands them before injecting the message into the mail system. The transport agent, sendmail, looks for aliases in the global aliases file and then in the system’s or recipients’ forwarding files. Aliasing is applied only to messages that sendmail considers to be local.
Here are some examples of aliases in the aliases file format:
nemeth: evi
evi: evi@mailhub
authors: evi,garth,scott,trent
The first line says that mail sent to “nemeth” should be delivered to the user evi on the local machine. The second line says that all mail to evi should be delivered on the machine mailhub, and the third line says that mail addressed to “authors” should be delivered to the users evi, garth, scott, and trent. Recursion is supported, so mail sent to “nemeth” actually ends up going to “evi@mailhub”.
Global aliases are defined in /etc/mail/aliases (which used to be /usr/lib/aliases or /etc/aliases on some systems). The path to the aliases file is specified in sendmail’s configuration file. Sites may have multiple aliases files, and they can also use alternate mechanisms such as NIS or database files.
See Chapter 18 for more information about NIS.
The format of an entry in the aliases file is
local-name: recipient1,recipient2,...
where local-name is the original address to be matched against incoming messages and the recipient list contains either recipient addresses or the names of other aliases. Indented lines are considered continuations of the preceding lines.
From mail’s point of view, the aliases file supersedes /etc/passwd, so the entry
david: david@somewhere-else.edu
would prevent the local user david from ever getting any mail. Therefore, administrators and adduser tools should check both the passwd file and the aliases file when selecting new user names.
The /etc/mail/aliases file should always contain an alias named “postmaster” that forwards mail to whoever maintains the mail system. An alias for automatic messages from sendmail must also be present; it’s usually called Mailer-Daemon and is often aliased to postmaster.
You should redirect root’s mail to your site administrators or to someone who logs in every day. The bin, sys, daemon, nobody, and hostmaster accounts (and any other pseudo-user accounts you set up) should also have aliases that forward mail to a human. The file sendmail/aliases in the distribution is a good template for the system-wide aliases that should be included. It also includes security suggestions and an