Sendmail Inc. Directory Usage

Sendmail Messaging Directory Usage

Note: This article is specifically tailored for Sendmail Inc. commercial software deployments. Much of the information here also pertains to sendmail opensource versions, as well as to other full-featured mailers such as Postfix and others that implement the LACHMAN-LASER draft specifications for email routing.

This article is provided to describe the LDAP attribute/value pairs used by Sendmail software. Specific information on how to configure the Sendmail software for LDAP lookups will be found in a future article.

Sendmail Inc's commercial software utilizes LDAP directories heavily, for a number of functionalities. Here is a partial list, all of these features can be used :

MTA: Message routing for individual accounts, and optionally for email lists
MTA: Email List expansion for one-to-many email lists. (aka alias expansion)
Authentication for use by SMTP AUTH, POP/IMAP login, and administrative interfaces
Per-sender rewrite of the From: header (aka genericstable)
Optional LDAP lookups for any Sendmail MTA map lookup or class file lookup
Per-user, per-domain, and per-site message filtering information (using Sieve rules)
Internal software settings used throughout Sendmail's suite of software
Delegated permissions information at site and domain levels for user account, email list, and administrative purposes.

The following information in broken down into specific areas: basics, followed by per-functionality writeups.

Just a few email and directory basics

Legacy data sources, such as "aliases" and "virtusertable" files, have a number of problems:

For any given user, you may have one to several lines in the aliases file. This might include alternate email addresses, a routing entry, and so on.
Emil lists are also stored as one to several lines in the aliases file. This might include the list itself (with all of the recipients), alternate email addresses for the list, and so forth.
There is no easy way to programmatically differentiate between alternate addresses for individuals, alternate addresses for lists, and email lists that simply have a single recipient on the list.
Aliases files are generally "flat", meaning that the @domain information is not present (or is ignored) in the left hand side. Even the recipient addresses (for email lists) are often specified without complete domain information.
Some information is present in aliases files, additional information is in virtusertable files. To completely process email for a given individual, one might have to look at at least one virtusertable line and two or more aliases file lines!
There is a lot of additional information that could be useful for automated message processing, but no truly official place to store it.
Orphaned information is extremely prevalent; such as an alternate email address that used to point to a user account, but where the user account has subsequently been removed.
Local account information (such as program delivery, special accounts, etc) is mixed with

When converting from legacy data sources (such as alias files) to directory data source, the single hardest task is simply identifying which of the entries are lists, which are users, which are alternate entries for each of the above, which are orphaned accounts, and so forth. Plus the inevitable dirty data that finds its way into the system over time.

LDAP-based storage simplifies management by starting with the following design points:

All information for a given user is present in that user's single LDAP entry. This might include

Primary email address within the system - full email address including domain.
Alternate email addresses for the user - full email addresses including domain.
FQDN of the server that hosts the mail for this user, or the Mail Gateway used for that user.
Quota and retention class information
Encrypted Password information
Additional controls to enable/disable authentication, mail delivery, mail relay, and more.

All information for an email distribution list user is present in that list's single LDAP entry. This might include

Primary email address within the system - full email address including domain.
Alternate email addresses for the list - full email addresses including domain.
FQDN of the server that hosts the mail for this user, if the list must be routed to a specific host or cluster for list expansion.
The recipients who are on the list. (All recipient addresses stored as full email addresses.)
One or more owners for the list.
Additional controls to enable/disable delivery to the list when accepting from the Internet vs. from internal, maximum message size allowed for the list, and so forth.

The consolidation of all pertinent information to a single directory entry is essential, in that it immensely simplifies long-term management. And it helps prevent orphaned accounts and dirty data.

Recipient Address lookups - Feature LDAP Routing

When any MTA looks at an email recipient address, it has to determine three pieces of information -- this is called the "mailer triple". These pieces are:

The envelope recipient address that should be used when delivering to the next MTA
The host name (or MX cluster name) of the next MTA
The method used when delivering to the next MTA. (ESMTP, SMTP, etc)

Sendmail's LDAP routing is used to determine the first two parts of the triple. The third part of the triple is usually left at the default value, but it too can use LDAP lookups

Basic MTA lookups make use of the following LDAP attribute/value pairs. None of these are case-sensitive.

mailLocalAddress - multi-valued. The mailLocalAddress is used by the mail server to "find" the correct LDAP entry when an inbound message is being processed, so the mailer triple can be processed. The values should be the list of all valid inbound email addresses for a specific recipient that would be accepted by this server as a "local" address. (If you host mail for "domain1.com" and "domain2.org", any address in these domains is "local".)
```
     mailLocalAddress: donnelly@ldapman.org
     mailLocalAddress: mdonnelly@ldapman.org
     mailLocalAddress: mdonnelly@domain2.org
     mailLocalAddress: Michael.Donnelly@ldapman.org
     mailLocalAddress: Michael_Donnelly@ldapman.org
     mailLocalAddress: mfd5524@ldapman.org
```
mailRoutingAddress - single-valued. The value of mailRoutingAddress is used when routing the message to the next location, primarily for rewriting of the envelope address. Don't let the name fool you, the mailRoutingAddress may not be used for routing purposes at all if mailHost is in use. Current usage no longer requires the use of envelope rewriting as a means to perform routing; that approach was developed in 1987 because there was not a better option at the time. In today's environment, one should generally use mailHost for routing instead, reserving mailRoutingAddress for either "the primary email address as used on the local mail store" or "the off-site email address" in other cases.
```
     mailRoutingAddress: mfd5524@ldapman.org
```
Or, if the mail is being forwarded to a remote email address, the full off-site address is listed. The MTA in this case will proceed to use the @domain information for routing of this recipient, unless overridden with the mailHost value.
```
     mailRoutingAddress: abc123456@yahoo.com
```
If the mailRoutingAddress value is not populated, the recipient is still valid and the message will still be processed, possibly using the mailHost value to continue processing.
mailHost - single-valued. This is the fully qualified host name of the server that either hosts this user's mail or it is the next MTA in that direction. (Consider the case where MTAs are relaying to a Domino SMTP gateway, the gateway server name would be listed here.) To really understand how this value is used, one needs to understand the way in which MTAs process mail -- this is all based on MX records. If the LDAP lookup returns a mailHost value like this,
```
     mailHost: domino-gateway.mydomain.com
```
the MTA will immediately proceed to perform an MX lookup for that value. The MX behavior is very important, as it allows you to provide redundant email pathways to the Domino environment without using a load balancer. (Load balanacers can be "a very bad thing" in MTA to MTA communication.) If the DNS lookup for the MX record does not return a result, the MTA will then perform a DNS A record lookup. (For more details on DNS MX records and how every Internet-routing MTA uses them, please see the world's best book on the subject, DNS and Bind by Cricket Liu and Paul Albitz.)

Instead of a DNS MX cluster, one might want to designate a specific mail store. (If using Sendmail Mailcenter, for example.) In this case, one can use square brackets to tell the MTA to skip the MX record lookup and go straight to the A record:
```
     mailHost: [mailstore1.mydomain.com]
```
If the value of mailHost is not populated, then the MTA will rely on the domain information in the mailRoutingAddress for routing.
mail - single-valued. The mail attribute is not used for the LDAP Routing feature, but I am mentioning it here because you'll always see it. The mail attribute is "the user's preferred email address". This is generally used only when end users are performing directory lookups against the directory, it may also be used for GenericsTable rewrites. GenericsTable is not related to message routing, and will be covered seperately.

A few caveats and notes:

For any given value of mailLocalAddress, no more than one directory entry may have that as a value. If two or more entries have the same value for mailLocalAddress, the MTA will treat this as a configuration error. In effect, you have told message should be routed to two different recipients, and email addresses must be unique. (Do not confuse this with email lists, which is a different matter and uses different attribute/value pairs.)
More than one entry might have the same mailRoutingAddress value. This does not break the "one entry, one address" rule so long as the routing MTA has distinct mailLocalAddress values for each entry.
The MTA can be configured to "Bounce recipient if not found in LDAP". If this is enabled, two additional checks are enabled as a result:

One and only one LDAP entry must be found to match the mailLocalAddress value.
If the single entry found does not have a mailHost value and if it does not have a mailRoutingAddress value, the recipient is bounced.

EXAMPLE:

Consider an LDAP entry that includes the following attribute-value pairs:

dn: mailLocalAddress=mfd5524@ldapman.org,ou=People,dc=ldapman,dc=org
mailLocalAddress: donnelly@ldapman.org
mailLocalAddress: mdonnelly@ldapman.org
mailLocalAddress: mdonnelly@ldapman.NET
mailLocalAddress: michael.donnelly@ldapman.org
mailLocalAddress: Michael_Donnelly@ldapman.org
mailLocalAddress: mfd5524@ldapman.org
mailHost: mailstore1.ldapman.org
mailRoutingAddress: mfd5524@ldapman.org
mail: Michael.Donnelly@ldapman.org
...

In our example case, we have email coming in for "mdonnelly@ldapman.net".

To determine how to route the message to this recipient, the Sendmail MTA LDAP routing feature performs all of the following lookups and checks:

Check - is "ldapman.net" in the list of LDAP route domains? (Yes in this example.)
Perform an LDAP lookup, searching for a single entry where mailLocalAddress=mdonnelly@ldapman.net
Single entry found? Yes. (With zero, or greater than one entry found, we would bounce it.)
mailRoutingAddress value found, of "mfd5524@ldapman.org", so the recipient envelope is rewritten using this address.
mailHost value found, with value of "mailstore1.ldapman.org"
If mailertable feature is enabled, MTA performs a mailertable lookup on "mailstore1.ldapman.org" to see if default delivery mechanism and/or routing has been overridden. (Nothing found in this example.)
MTA does an MX lookup of "mailstore1.ldapman.org". (No such entry found in DNS in this example.)
MTA does an A record lookup of "mailstore1.ldapman.org", and finds an IP address of 12.34.56.78
MTA now knows to deliver the message to 12.34.56.78 with an envelope recipient value of "mfd5524@ldapman.org"

To test the LDAP routing lookups and the results they return, one could use the test command:

sendmail -bv mdonnelly@ldapman.net

You would expect to see something like this:

donnelly@ldapman.net... deliverable: mailer relay, host mailstore1.ldapman.org, user mfd5524@ldapman.org

A final note, regarding LDAP-based routing as they pertain to email lists. In many respects, an email list is the same as any other email address- it may be routed to another machine if the LDAP entry specifies that the message should be routed to another mailHost or to a non-local mailRouting address. This is frequently done for Exchange and Domino environments, where the message must be accepted on Sendmail MTAs and passed on to the back-end mail server for list expansion.

Email distribution lists - Implementing LDAP lookups for Aliases feature

A directory entry for an email distribution list may include all of the attribute/value pairs mentioned above for single entries, including:

mail
mailHost
mailRoutingAddress
mailLocalAddress

Each attribute is used in the same way as above. The new attribute/value pairs used for email lists are:

mgrpRFC822MailMember - multi-valued. Each value corresponds to a single, full email address that is "on the list".
owner - multi-valued. The DNs of one or more LDAP accounts that correspond to the administrators of this list. Note: this is not used during alias expansion, it is only for administratitive purposes when using the Sendmail Directory server.
Other attributes are also used for administrative purposes only. They will be covered seperately.

If LDAP-based aliases expansion has been configured in combination with LDAP-based routing, the mailHost value is used to determine what happens next. Each MTA knows a list of local host names, which is determined by looking at the local-host-names file and by probing its own interfaces on startup.

If the MTA sees that the mailHost value is a "local" host name, it will proceed to the aliases expansion step, and the mailRoutingAddress value is ignored. Otherwise the MTA will route the message to the server specified in mailHost just as with any other LDAP routed message.

EXAMPLE:

Consider an LDAP entry that includes the following attribute-value pairs:

dn: mailLocalAddress=mylist@ldapman.org,ou=messageRecipientGroups,dc=ldapman,dc=org
mailLocalAddress: mylist@ldapman.org
mailLocalAddress: my_list@ldapman.org
mailLocalAddress: my-list@ldapman.NET
mailHost: ldap-mta.ldapman.org
mailRoutingAddress: My_List@ldapman.org
mail: My_List@ldapman.org
mgrpRFC822MailMember: donnelly@ldapman.org
mgrpRFC822MailMember: otheruser@ldapman.org
mgrpRFC822MailMember: somebody@pogonip.org
...

In our example case, we have email coming in for "mylist@ldapman.net", and the local-host-names file includes the host name "ldap-mta.ldapman.org". (All of the MTAs in this environment include that name in the file, allowing all of them to perform LDAP-based aliases expansion.)

To determine how to route the message to this recipient, the Sendmail MTA LDAP routing feature performs all of the following lookups and checks:

Check - is "ldapman.org" in the list of LDAP route domains? (Yes in this example.)
Perform an LDAP lookup, searching for a single entry where mailLocalAddress=mylist@ldapman.org
Single entry found? Yes. (With zero, or greater than one entry found, we would bounce it.)
mailRoutingAddress value found, of "mylist@ldapman.org", so the recipient envelope is rewritten using this address if external routing is going to happen
mailHost value found, with value of "ldap-mta.ldapman.org"
ldap-mta.ldapman.org is found in local-host-names, so MTA proceeds to aliases expansion phase
MTA performs another LDAP query, once again looking for mailLocalAddress=mylist@ldapman.org, this time to retrieve the values in mgrpRFC822MailMember.
The complete list of email values in mgrpRFC822MailMember is now used as envelope recipients, instead of mylist@ldapman.org. For each value, the MTA will perform the same LDAP routing and list expansion steps.

To test the LDAP routing lookups and aliases expansion, use the test command:

sendmail -bv mylist@ldapman.net

You would expect to see output like this:

otheruser@ldapman.org... deliverable: mailer relay, host [exchange.mydomain.com], user otheruser@ldapman.org
donnelly@ldapman.net... deliverable: mailer relay, host mailstore1.ldapman.org, user mfd5524@ldapman.org
somebody@pogonip.org... deliverable: mailer esmtp, host pogonip.org., user somebody@pogonip.org