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: madroneleaf@gmail.com
mailLocalAddress: mmadroneleaf@gmail.com
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: madroneleaf@gmail.com
mailLocalAddress: mmadroneleaf@gmail.com
mailLocalAddress: mdonnelly@ldapman.NET
mailLocalAddress: michael.donnelly@ldapman.NET
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: madroneleaf@gmail.com
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