UNIX System Administration Handbook - Evi Nemeth [333]
Mail aliases are a particularly good match for LDAP, especially now that sendmail supports LDAP internally. sendmail can query the LDAP server for alias lookups instead of doing them directly. LDAP can also manage mail routing and virtual domains. LDAP support must be compiled into the sendmail binary.
If you are looking for an LDAP implementation, we recommend the server produced by the OpenLDAP group at www.openldap.org. This group took over and enhanced the code of an earlier server that was developed at the University of Michigan. For a bit more information about LDAP-related software, see page 534.
LDAP database entries resemble a termcap entry with longer variable names. The attributes (variable names) in the LDAP database are not yet fully standardized, and this fact can result in incompatibilities among different implementations.
The attributes on the first line of a database entry are defined by the LDAP configuration file. The examples in this section assume that the LDAP server daemon (slapd, in the OpenLDAP case) was configured with a root distinguished name (rootdn) of:
"cn=root, dc=synack, dc=net"
The dc attribute appears twice because the domain component values cannot contain a dot; to express the domain synack.net, two entries are necessary. Further attributes, or variable names, can be whatever you want. They are case insensitive. sendmail (whose code looks for specific attribute names and assigns them predetermined interpretations), the LDAP server, and the builder of the LDAP database must all cooperate and use the same naming conventions.
Some possible attributes that can appear on the first line of a database entry (the database keys) are dn for a domain name, dc for a domain component, o for an organization name, c for a country name, and uid for a unique ID (e.g., a login name).
sendmail recognizes the following data tags:
mailLocalAddress
mailRoutingAddress
mailHost
Here is an example of a slapd ldap.conf file
# LDAP Defaults, ldap.conf file, should be world-readable.
#
BASE dc=synack, dc=net
HOST gw.synack.net
PORT 389
that supports database entries of the form
dn: uid=jon, dc=synack, dc=net
objectClass: inetLocalMailRecipient
mailLocalAddress: jon@synack.net
mailRoutingAddress: stabilej@cs.colorado.edu
uid:jon
The incoming recipient is matched against the mailLocalAddress field. If it matches, the mail is redirected to the mailRoutingAddress. The objectClass line has to be there—it comes from the draft RFC that defines the interaction of LDAP and mail systems. On the host gw.synack.net, this database entry corresponds to the alias:
jon: stabilej@cs.colorado.edu
A bit long-winded, isn’t it? These database entries could replace the typical entries in the aliases file for defining a mail home for each user. However, the aliases file is still the best way to define mailing lists (with the :include: directive). Mailing list software typically pipes the message to a wrapper script and resends it. An LDAP query can return a local address that handles the mailing list (by way of the aliases file), but it cannot directly call a program.
See page 582 for information about configuring sendmail to use LDAP and page 590 for an example that uses LDAP to implement aliases and virtual hosting.
19.5 SENDMAIL: RINGMASTER OF THE ELECTRONIC MAIL CIRCUS
sendmail is the most complex and complete mail transport system in common use. It was written by Eric Allman while he was a student at Berkeley. Eric had recently taken a computer science course in which he used production systems, so he decided to tackle the mail delivery problem with a similar approach. At the time, he thought he was attacking a fly with a sledgehammer and was intending to move to a simpler technique once he understood the problem better.
As it turned out, sendmail’s generality allowed Eric to keep up with the fast-paced world of email standards. Several important standards