You can integrate your OpenLDAP implimentation with your MTA to supply things such as email aliasing and forwarding. The book covers three different MTAs which can work with LDAP: *Sendmail, LDAPv2 *Exim, LDAPv2 *Postfix, LDAPv3
However, only Postfix can bind via LDAPv3. With this in mind, as well as the other security and efficiency arguments, we will only be focusing on Postfix in this class. (For more information, see UNIX02/What Is Posftix).
Postfix Integration
In order to use LDAP with Postfix, you must first ensure that it has been compiled to support it. Running postconf with "-m" shows the list of storage mediums for tables: $ /usr/sbin/postconf -m static nis regexp environ ldap btree unix hash
LDAP can provide table information for a variety of Postfix features. At any given time, Postfix maintains six tables, any which may be stored on any of the media reported by postconf -m. So what are these tables? Well, let's list them quickly: ;Access: Provides information about which messages to accept or reject based on sender, host, network, etc. ;Aliases: Provides information on redirecting mail received for local users. ;Canonical: Provides information on local and nonlocal addresses. ;Relocated: Provides information on "user has moved to new location" bounce messages. ;Transport: Provides information on delivery methods and relay hosts for the domain. ;Virtual: Provides information used in redirecting local and nonlocal users or domains.
One of the big advantages to using Postfix with LDAP is that you do not need any additional schemas to make the marriage work (unlike Sendmail). Postfix utilizes what posixAccount and inetorgPerson offer.
Alias Maps By way of an example, let's look at Alias mappings. What we show here will apply to any of the other mappings.
An alias entry maps a local username to an email address; this address can either be another local user or a user on a remote system. In your LDAP schema, a local user is represented by the uid attribute of the posixAccount object class. The aliased entry is represented by the mail attribute of the inetOrgPerson object class.
To inform the Postfix daemons that they should read the alias map from an LDAP directory, you must add the following line to your Postfix's main.cf: alias_maps = ldap:ldapalias
The ldap keyword denotes the type of lookup table. The ldapalias string is the name of the table. This name is used as a prefix for parameter names; it identifies which settings are associated with this table.
After specifying that Postfix should look up alias information from the directory, you have to define several parameters that tell Postfix how to search the directory. These should be familier by now. The most common settings include the LDAP server name, the search base, the search scope (subtree, etc.) the search filter, and the resulting attribute value to return. Each of these parameters is prefaced by the LDAP table name. So, for our odyssey.com setup we have been generating all class, we would add the following to our main.cf ldapalias_server_host = localhost ldapalias_server_base = ou=people,dc=odyssey,dc=com ldapalias_scope = sub ldapalias_query_filter = (uid=%s) ldapalias_result_attribute = mail
You can then test the alias table lookup using the postmap command to verify that mail to some user will be forwarded to another.
Table 7-7 on pages 152 and 153 include more parameters useful in Postfix and LDAP integration.
MTA Issues
You can integrate your OpenLDAP implimentation with your MTA to supply things such as email aliasing and forwarding. The book covers three different MTAs which can work with LDAP:
Sendmail, LDAPv2
Exim, LDAPv2
Postfix, LDAPv3
However, only Postfix can bind via LDAPv3. With this in mind, as well as the other security and efficiency arguments, we will only be focusing on Postfix in this class. (For more information, see UNIX02/What Is Posftix).
Postfix Integration
In order to use LDAP with Postfix, you must first ensure that it has been compiled to support it. Running postconf with "-m" shows the list of storage mediums for tables:
LDAP can provide table information for a variety of Postfix features. At any given time, Postfix maintains six tables, any which may be stored on any of the media reported by postconf -m. So what are these tables? Well, let's list them quickly:
Access
Provides information about which messages to accept or reject based on sender, host, network, etc.
Aliases
Provides information on redirecting mail received for local users.
Canonical
Provides information on local and nonlocal addresses.
Relocated
Provides information on "user has moved to new location" bounce messages.
Transport
Provides information on delivery methods and relay hosts for the domain.
Virtual
Provides information used in redirecting local and nonlocal users or domains.
One of the big advantages to using Postfix with LDAP is that you do not need any additional schemas to make the marriage work (unlike Sendmail). Postfix utilizes what posixAccount and inetorgPerson offer.
Alias Maps
By way of an example, let's look at Alias mappings. What we show here will apply to any of the other mappings.
An alias entry maps a local username to an email address; this address can either be another local user or a user on a remote system. In your LDAP schema, a local user is represented by the uid attribute of the posixAccount object class. The aliased entry is represented by the mail attribute of the inetOrgPerson object class.
To inform the Postfix daemons that they should read the alias map from an LDAP directory, you must add the following line to your Postfix's main.cf:
alias_maps = ldap:ldapalias
The ldap keyword denotes the type of lookup table. The ldapalias string is the name of the table. This name is used as a prefix for parameter names; it identifies which settings are associated with this table.
After specifying that Postfix should look up alias information from the directory, you have to define several parameters that tell Postfix how to search the directory. These should be familier by now. The most common settings include the LDAP server name, the search base, the search scope (subtree, etc.) the search filter, and the resulting attribute value to return. Each of these parameters is prefaced by the LDAP table name. So, for our odyssey.com setup we have been generating all class, we would add the following to our main.cf
ldapalias_server_host = localhost
ldapalias_server_base = ou=people,dc=odyssey,dc=com
ldapalias_scope = sub
ldapalias_query_filter = (uid=%s)
ldapalias_result_attribute = mail
You can then test the alias table lookup using the postmap command to verify that mail to some user will be forwarded to another.
Table 7-7 on pages 152 and 153 include more parameters useful in Postfix and LDAP integration.
