LDAP ROUTING

FEATURE(`ldap_routing')

can be used to implement the IETF Internet Draft LDAP Schema for Intranet Mail Routing (draft-lachman-laser-ldap-mail-routing-01). This feature enables LDAP-based rerouting of a particular address to either a different host or a different address. The LDAP lookup is first attempted on the full address (e.g., user@example.com) and then on the domain portion (e.g., @example.com).

Be sure to setup your domain for LDAP routing using LDAPROUTE_DOMAIN() or LDAPROUTE_DOMAIN_FILE, e.g.:

Additionally, you can specify equivalent domains for LDAP routing using LDAPROUTE_EQUIVALENT() and LDAPROUTE_EQUIVALENT_FILE().
'Equivalent' hostnames are mapped to $M (the masqueraded hostname for the server) before the LDAP query. For example, if the mail is addressed to user@host1.example.com, normally the LDAP lookup would only be done for 'user@host1.example.com' and '@host1.example.com'. However, if

is used, the lookups would also be done on 'user@example.com' and '@example.com' after attempting the host1.example.com lookups.

By default, the feature will use the schemas as specified in the draft and will not reject addresses not found by the LDAP lookup. However, this behavior can be changed by giving additional arguments to the FEATURE() command:

where

• <mailHost> is a map definition describing how to lookup an alternative mail host for a particular address;
• <mailRoutingAddress> is a map definition describing how to lookup an alternative address for a particular address;
• the <bounce> argument, if present and not the word "passthru", dictates that mail should be bounced if neither a mailHost nor mailRoutingAddress is found;
• and <detail> indicates what actions to take if the address contains +detail information -- `strip' tries the lookup with the +detail and if no matches are found, strips the +detail and tries the lookup again; `preserve', does the same as `strip' but if a mailRoutingAddress match is found, the +detail information is copied to the new address.

The default <mailHost> map definition is:

The default <mailRoutingAddress> map definition is:

Note that neither includes the LDAP server hostname (-h server) or base DN (-b o=org,c=COUNTRY), both necessary for LDAP queries. It is presumed that your .mc file contains a setting for the confLDAP_DEFAULT_SPEC option with these settings. If this is not the case, the map definitions should be changed as described above. The "-T<TMPF>" is required in any user specified map definition to catch temporary errors.

The following possibilities exist as a result of an LDAP lookup on an address:

The term "local" host above means the host specified is in class {w}. If the result would mean sending the mail to a different host, that host is looked up in the mailertable before delivery.

Note that the last case depends on whether the third argument is given to the FEATURE() command. The default is to deliver the message to the original address.

The LDAP entries should be set up with an objectClass of inetLocalMailRecipient and the address be listed in a mailLocalAddress attribute. If present, there must be only one mailHost attribute and it must contain a fully qualified host name as its value. Similarly, if present, there must be only one mailRoutingAddress attribute and it must contain an RFC 822 compliant address.

Some example LDAP records (in LDIF format):

This would deliver mail for tom@example.com to thomas@mailhost.example.com.

This would relay mail for dick@example.com to the same address but redirect the mail to MX records listed for the host eng.example.com (unless the mailertable overrides).

This would relay mail for harry@example.com to the MX records listed for the host mktmail.example.com using the new address harry@mkt.example.com when talking to that host.

This would send all mail destined for any username @virtual.example.com to the machine server.example.com's MX servers and deliver to the address virtual@example.com on that relay machine.