Alias expansion of local addresses

Once an address has been determined to be associated with the local channel it automatically undergoes alias expansion. The alias expansion process examines a number of sources of information, including:

1. The alias file (part of the compiled configuration).

2. The alias database.

3. Alias URLs.

The exact alias sources that are checked and the order in which they are checked depends on the setting of the ALIAS_MAGIC MTA option in the option.dat file. For direct LDAP, set the option to 8764. This means that the URL specified by the ALIAS_URL0 MTA option is checked first, then the URL specified by the ALIAS_URL1 MTA option, then the URL specific by the ALIAS_URL2 MTA option, and finally, the alias file. The alias database is not checked when this setting is active.

Alias Checking with LDAP URLs

Checking of aliases in LDAP is implemented by specifying two special LDAP URLs as alias URLs. The first of these handles regular users and groups; vanity domains are handled by subsequent alias URLs. The first URL is specified as ALIAS_URL0:

ALIAS_URL0=ldap:///$V?*?sub?$R

The $V Metacharacter

Metacharacter expansion occurs prior to URL lookup. The two metacharacters used in the ALIAS_URL0 value are $V and $R.

The $V metacharacter converts the domain part of the address into a base DN. This is similar to the initial steps performed by the $V rewrite rule metacharacter described previously in the section entitled Rewrite Rule Machinery. $V processing consists of the following steps:

1. Get the base DN for user entries in the current domain.

2. Get the canonical domain associated with the current domain. In Sun LDAP Schema 1, the canonical domain name is given by the inetCanonicalDomainName attribute of the domain entry if the attribute is present. If the attribute is absent the canonical name is the name constructed in the obvious way from the DN of the actual domain entry. This will differ from the current domain when the current domain is an alias. The name attribute used to store the canonical name may be overridden with the LDAP_DOMAIN_ATTR_CANONICAL MTA option in the option.dat file.

   In Sun LDAP Schema 2, the canonical name is simply the value of the SunPreferredDomain attribute.

3. If the base DN exists, substitute it into the URL in place of the $V.

4. Any applicable hosted domain for this entry is now determined. This is done by comparing either the canonical domain (if bit 2 (value = 4) of DOMAIN_UPLEVEL is clear) or the current domain (if bit 2 (value = 4) of DOMAIN_UPLEVEL is set) with the service.defaultdomain configutil parameter. If they do not match, the entry is a member of a hosted domain. The service.defaultdomain configutil parameter can be overridden by setting the LDAP_DEFAULT_DOMAIN MTA option in the option.dat file.

5. If the base DN determination fails, remove a component from the left hand side of the domain and go to Step 1. The substitution fails if no components remain.

$V also accepts an optional numeric argument. If it is set to 1 (for example, $1V), a failure to resolve the domain in the domain tree will be ignored and the base of the user tree specified by the local.ugldapbasedn configutil option will be returned.

If the attempt to retrieve the domain's base DN succeeds, the MTA also retrieves several useful domain attributes which will be needed later. The names of the attributes retrieved are set by the following MTA options in the option.dat file:

• LDAP_DOMAIN_ATTR_UID_SEPARATOR (default domainUidSeparator)

• LDAP_DOMAIN_ATTR_SMARTHOST (default mailRoutingSmartHost)

• LDAP_DOMAIN_ATTR_CATCHALL_ADDRESS (default mailDomainCatchallAddress)

• LDAP_DOMAIN_ATTR_BLOCKLIMIT (default mailDomainMsgMaxBlocks)

• LDAP_DOMAIN_ATTR_REPORT_ADDRESS (default mailDomainReportAddress)

• LDAP_DOMAIN_ATTR_STATUS (default inetDomainStatus)

• LDAP_DOMAIN_ATTR_MAIL_STATUS (default mailDomainStatus)

• LDAP_DOMAIN_ATTR_CONVERSION_TAG (default mailDomainConversionTag)

• LDAP_DOMAIN_ATTR_FILTER (default mailDomainSieveRuleSource)

• LDAP_DOMAIN_ATTR_DISK_QUOTA (no default)

• LDAP_DOMAIN_ATTR_MESSAGE_QUOTA (no default)

• LDAP_DOMAIN_ATTR_AUTOREPLY_TIMEOUT (no default)

• LDAP_DOMAIN_ATTR_NOSOLICIT (no default)

• LDAP_DOMAIN_ATTR_OPTIN (no default)

• LDAP_DOMAIN_ATTR_RECIPIENTLIMIT (no default)

• LDAP_DOMAIN_ATTR_RECIPIENTCUTOFF (no default)

• LDAP_DOMAIN_ATTR_SOURCEBLOCKLIMIT (no default)

Calling a Mapping from a URL

There might be unusual cases where the mapping from domain to base DN is done some other way. In order to accommodate such setups, the URL resolution process has the ability to call an MTA mapping. This is done with a metacharacter sequence of the general form:

$|/mapping-name/mapping-argument|

The double quotation (“) initiates and terminates the callout. The character immediately following the $ is the separator between the mapping name and argument; a character should be chosen that does not collide with the expected character values used in either the mapping name or argument.

The $R Metacharacter

The $R metacharacter provides an appropriate filter for the URL. The intent is to produce a filter that searches all the attributes that might contain an email address for a particular user or group. The list of attributes to search comes from the configutil parameter local.imta.mailaliases. If this parameter is not set, the local.imta.schematag configutil parameter is examined, and depending on its value, an appropriate set of default attributes is chosen as follows:

sims401 mail, rfc822mailalias

nms41 mail,mailAlternateAddress

ims50 mail,mailAlternateAddress,mailEquivalentAddress

The value of local.imta.schematag can be a comma-separated list. If more than one schema is supported, the combined list of attributes with duplicates eliminated is used. The LDAP_SCHEMATAG MTA option can be used to override the setting of local.imta.schematag specifically for the MTA.

Additionally, the filter searches not only for the address that was originally supplied, but also for an address with the same local part but the domain that was actually found in the domain tree, which was saved in the second step in the section entitled The $V Metacharacter. The iterative nature of the domain tree lookup means the two addresses may be different. This additional check is controlled by bit 1 (value = 2) of the DOMAIN_UPLEVEL MTA option in the option.dat file. Setting the bit enables the additional address check. The default value of DOMAIN_UPLEVEL is 0.

For example, suppose that the domain siroe.com appears in the domain tree. Assuming Sun LDAP Schema 1 is in force, a lookup of the address

u@host1.siroe.com

The filter that results from the expansion of $R and an ims50 schematag looks like:

(|(mail=u@siroe.com)
    (mail=u@host1.siroe.com)
    (mailAlternateAddress=u@siroe.com)
    (mailAlternateAddress=u@host1.siroe.com) 
    (mailEquivalentAddress=u@siroe.com)
    (mailEquivalentAddress=u@host1.siroe.com))

If, on the other hand, DOMAIN_UPLEVEL was set to 1 rather than 3, the filter would be:

(|(mail=u@host1.siroe.com)
       (mailAlternateAddress=u@host1.siroe.com)
       (mailEquivalentAddress=u@host1.siroe.com))

Determining the Attributes to Fetch

If the URL specifies an * for the list of attributes to return, we replace the asterisk with the list of attributes the MTA is able to use. This list is dynamically generated from the various MTA option settings that specify the options the MTA consumes.

Handling LDAP Errors

At this point the resulting URL is used to perform an LDAP search. If an LDAP error of some kind occurs, processing terminates with a temporary failure indication (4xx error in SMTP). If the LDAP operation succeeds but fails to produce a result, the catchall address attribute for the domain retrieved from the LDAP_DOMAIN_ATTR_CATCHALL_ADDRESS MTA option is checked. If it is set, its value replaces the current address.

If no catchall address attribute is set the smarthost attribute for the domain retrieved from the LDAP_DOMAIN_ATTR_SMARTHOST MTA option is checked. If it is set, an address of the form

@smarthost:user@domain

is created and alias processing terminates successfully with this result. Additionally, the conversion tag for the domain obtained from the LDAP_DOMAIN_ATTR_CONVERSION_TAG MTA option will, if present, be attached to the address so that conversions can be done prior to forwarding to the smarthost. If no catchall address or smarthost exists for the domain, processing of this alias URL terminates unsuccessfully.

Sanity Checks on the LDAP Result

After the LDAP search has returned a result, it is checked to verify that there is only one entry in it. If there are more than one, each entry is checked to see if it has the right object class for a user or a group, a non-deleted status, and for users, a UID. Entries that do not pass this check are ignored. If the list of multiple entries is reduced to one by this check, processing proceeds. If not, a duplicate or ambiguous directory error is returned.

Support for Vanity Domains

The ALIAS_URL0 check is for a conventional user or a user in a hosted domain. If this fails a vanity domain check is also made. This is done with the following alias URL:

ALIAS_URL1=ldap:///$B?*?sub?(&(msgVanityDomain=$D)$R)

Support for Catchall Addresses

Finally, a check for a catchall address of the form @host needs to be made in the mailAlternateAddress attribute. This form of wildcarding is allowed in both hosted and vanity domains, so the proper alias URL for it is:

ALIAS_URL2=ldap:///$1V?*?sub?(mailAlternateAddress=@$D)

The +* subaddress substitution mechanism has always worked with catch-all addresses in direct LDAP mode, but the string that was substituted was the subaddress only, not the entire local part. This has been changed so that the entire local part of the original address will be plugged into the catch-all address as a subaddress when this construct is used.

For example, given an address of the form foo+bar@domain.com, no local user foo in the domain.com domain, and a catch-all address for domain.com of bletch+*@example.com, the resulting address will now be bletch+foo+bar@example.com. It used to be bletch+bar@example.com.