Network Working Group H. Lachman
INTERNET-DRAFT Netscape Communications Corp.
Expires: 30 September 1997 March 1997
Intended Category: Informational
LDAP-based Routing of SMTP Messages:
Approach Used by Netscape
<draft-ietf-asid-email-routing-ns-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Directory services based on the Lightweight Directory Access Protocol
(LDAP) [1] and X.500 [2] provide a general-purpose means to store
information about users and other network entities. One of the many
possible uses of a directory service is to store information about
users' email accounts, such as their email addresses, and how
messages addressed to them should be routed. In the interest of
interoperability, it is desirable to have a common schema for such
email-related information.
This document discusses some of the fundamental questions to be
considered in the development of a common schema for LDAP-based
routing of SMTP [3] messages, presents an approach that has been
implemented and deployed, and discusses possible extensions to that
approach that may serve to make it more complete and general. The
intent is to provide information about an existing implementation,
and to stimulate discussion about whether and how to standardize the
relevant aspects of LDAP-based messaging management.
Lachman [Page 1]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
1. Background and Motivation
LDAP-based directory services are currently being used in many
organizations as a repository of information about users and other
"network entities" (such as groups of users, network resources,
etc.). Some information is stored in the directory for the
consumption of persons browsing for information (e.g., telephone
numbers, postal addresses, secretary's name), while other information
(e.g., login name, password, disk quota) is stored for use by one or
more network applications or services. It is the latter kind of
information that is of interest in this discussion. In general, it
is advantageous for different network applications and services to
refer to the directory for user account information, rather than each
service keeping its own collection of user account records, which
requires the network administrator to separately create or destroy
user entities, passwords, etc., in many different systems each time a
user joins or leaves the organization. The goals of centralized user
management and sharing of information with other service types drove
our decision in the design of Netscape Messaging Server (an SMTP-
based mail server product) to use LDAP-based directory services as a
common repository for user account information.
Now, if a given mail server can refer to the directory for its own
users' account information, it follows that that same information is
visible to other LDAP-aware mail servers in the same organization,
and therefore that information can aid those other mail servers in
correctly routing messages to users of the mail server in question.
This assumes that there is an agreed-upon set of per-user attributes
to support message routing. If this assumption is met, we can
obviate other means currently employed to specify per-user message
routing (such as the Unix "aliases" database). The benefit of this
is to further consolidate per-user system information.
If each vendor's mail server product has its own schema for LDAP-
based message routing, then the above benefits can be achieved for
single-vendor customers, but customers who have multiple vendors'
mail server products would not be well served. They will likely
expect interoperability, which will require a common schema to be
supported by the various vendors' products. Thus, it is worthwhile
to consider how to develop a common schema.
This document does not attempt to define a standard. It does attempt
to define what the relevant questions are, and goes on to describe
one vendor's solution plus possible extentions to generalize it. It
is hoped that this discussion helps to characterize the issue, and
encourages the development of a common solution.
This document considers only intra-enterprise SMTP message routing
Lachman [Page 2]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
using LDAP-based directory services. Solutions and issues involving
inter-enterprise routing, non-SMTP message handling, non-LDAP
directory services, and other messaging management topics not related
to message routing, are outside the scope of this document (except
that the concepts presented may also be applicable in the case of
X.500 directory services).
2. Terminology
In the context of this document, a "mail server" is a Simple Mail
Transfer Protocol (SMTP) message transfer agent (MTA). It either
includes, or has associated with it, a local message delivery agent
(MDA) that performs delivery to accounts that are considered local to
the particular mail server. A mail server may offer related services
as well, such as providing a means for mail user agents (MUAs) to
pick up messages, but that is outside the scope of this discussion.
The term "account" is used to refer to any entity that can receive
mail. This includes mail user accounts, as well as mail group
accounts (mail distribution lists). A "delivery" is said to have
occured when an MTA passes a message to the local MDA, having first
ascertained that the message is destined for a particular account
that can be delivered to locally. The MDA may then place the message
in a local message store, and/or take other actions as specified by
the account's attributes.
"Routing" and "forwarding" are distinct actions. "Routing" is said
to have occured when an MTA passes a message to a "next-hop" MTA,
having ascertained that the addressed entity is not a local account
but may exist elsewhere. "Forwarding" is said to have occured when a
message has successfully arrived at a particular account and the MDA
determines that the message must be resent to one or more new
destinations as specified by the account's attributes. "Forwarding"
may be configurable by the user, while "routing" is normally
configurable only by a network administrator. With this definition,
it might also be said that when a message arrives at a mail group
account, and the MDA resends the message to all of the individual
group members, this is also "forwarding".
3. Questions to Consider
When a message arrives at an MTA, the MTA must determine whether to
deliver the message to a local account, route the message to another
MTA, or, in the case of an unresolvable recipient address, take some
remedial action such as "bouncing" the message. In the course of
making this determination, an MTA may reference information from a
variety of sources, including its own local configuration, one or
more directory services, and perhaps other sources. This document
Lachman [Page 3]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
discusses only per-account routing and addressing information
provided by an LDAP-based directory service, and what role that
information might play in helping the MTA determine what to do with a
message.
The question of how an MTA might use such information can be broken
down into three subquestions:
Question (1): For a given recipient address, which LDAP entry does
it belong to?
Question (2): For a given LDAP entry, should a message addressed to
it be delivered locally or routed?
Question (3): If a message addressed to a given LDAP entry needs to
be routed, to where should the message be routed?
In order for these questions to be answerable by the MTA, LDAP
entries that represent mail accounts should include attributes that
specify addressing and routing information. These attributes should
be advertised to (i.e., readable by) the MTAs that are expected to
act on them, and there should be a definition of what attributes are
involved and how they are to be interpreted. With this definition,
an MTA can be implemented or configured to correctly use such
information to answer the above questions, and therefore, correctly
handle messages addressed to accounts represented as LDAP entries.
4. Description of Solution Implemented
In the design of Netscape Messaging Server, we defined two new LDAP
object classes, 'mailRecipient', which is used to represent a mail
user account, and 'mailGroup', which is used to represent a mail
group account (mail distribution list). An LDAP entry of either
class may have attributes that are of an "account configuration"
nature and are used solely by the MDA handling mail for the account,
while other attributes are used by the account's "home" MTA as well
as other MTAs. It is this latter set of attributes that are of
interest in this discussion, since we are concerned with the behavior
of MTAs.
Our MTA implementation uses the following attributes:
mail primary email address
mailAlternateAddress additional email addresses
mailHost server hosting mail account
uid user id (login name)
The 'mail' and 'mailAlternateAddress' attributes are used to specify
Lachman [Page 4]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
the email addresses [4] that are considered valid for an account.
They must all be complete email addresses (e.g., "joe@example.com",
as opposed to "joe" or "joe@mars"). 'mailHost' is the fully-
qualified domain name [5] of the mail server that considers the
account to be locally deliverable (e.g., "mars.eng.example.com").
'uid' is the user's login name. A 'mailGroup' is not expected to
have a 'uid' attribute, and may or may not have a 'mailHost'
attribute, but both attributes should be present for a
'mailRecipient'. For a detailed description of the 'mailRecipient'
and 'mailGroup' object classes and associated attributes, refer to
Appendices A and B.
Our MTA implementation looks for the above attributes, and uses them
to answer the three fundamental questions considered above, as
follows.
4.1. Mapping an Address to an LDAP Entry
To resolve Question (1), we take the recipient address from the SMTP
"envelope", and see if there is exactly one LDAP entry that
advertises that address as one of its valid addresses. Specifically,
we search for an LDAP entry that has a 'mail' or
'mailAlternateAddress' attribute whose value is the address in
question. The search is performed across all LDAP entries in a given
directory subtree, which is configured in the MTA as its "base
subtree" of interest.
If the above search fails, we may also perform a fallback search.
Specifically, if the above search yields zero matches, we split the
address in question at the "@" sign, yielding a "local part" and a
"domain part". If the MTA configuration specifies that it is the
final authority on messages addressed to the domain part in question
(i.e., it has the authority to bounce messages addressed to that
domain), then we search for an LDAP entry whose 'uid' attribute
equals the local part. If we get exactly one match, then we regard
this as a successful match.
In theory, the fallback search may not be required, but since our MTA
rewrites envelopes to 'uid'@'mailHost' (as discussed in Section 4.3),
it is clearly advantageous for receiving MTAs in this environment to
be able to unconditionally recognize an address thusly rewritten.
4.2. Determining Whether or not to Perform Local Delivery
To resolve Question (2), we look up the LDAP entry's 'mailHost'
attribute. If the value of this attribute matches the fully-
qualified domain name (FQDN) specified in the MTA configuration, then
the message is passed to the local MDA.
Lachman [Page 5]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
If the value of the 'mailHost' attribute does not match the MTA's
FQDN, then the message is routed.
If the LDAP entry has no 'mailHost' attribute, this is considered
invalid for a 'mailRecipient', but for a 'mailGroup', the MTA will
pass the message to the local MDA to perform group list expansion and
forwarding to the individual recipients. In other words, for a
'mailGroup', a missing 'mailHost' means any mail server may perform
group handling for the message.
4.3. Determining How to Route the Message
To resolve Question (3), we look up the LDAP entry's 'mailHost' and
'uid' attributes. The 'uid' attribute is normally present for a
'mailRecipeint', and is not normally present for a 'mailGroup'. If
the 'uid' attribute is present, we rewrite the recipient address in
the SMTP envelope to 'uid'@'mailHost', i.e., we combine the
respective values of these two attributes and add an "@" sign to
formulate a new recipient address. If the 'uid' attribute is not
present, we do not rewrite the recipient address.
The message is routed to the destination indicated in the 'mailHost'
attribute. This may or may not mean that the MTA will open an SMTP
connection to the host identified as the 'mailHost', since the MTA
configuration may specify routing rules that prevent this (e.g., in
sites that are configured so that all message traffic follows a fixed
"star" topology). Also, some sites may use DNS MX records [6] for
internal message routing. For example, an MTA "mail.example.com" may
receive a message for "joe@example.com", find that the 'mailHost' for
this account is "mars.eng.example.com", and then discover that mail
for "*.eng.example.com" is MX'ed to "hub.eng.example.com", which will
then be the "next hop".
5. Possible Ways to Generalize the Solution Implemented
The following are serveral ways our approach could be extended to
make it more general. None of these suggestions are reflected in our
existing implementation as of this writing. We have no specific
plans to follow or not follow these suggestions in any subsequent
implementation. The intent is to provide ideas as to what a more
general approach might look like. Whether or not these ideas should
be implemented, or should become the basis for a future standard, are
left as open questions.
5.1. More Flexible Envelope Rewrites
One might argue that it is not really necessary for MTAs to rewrite
envelopes when performing intra-enterprise message routing. The
Lachman [Page 6]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
argument is as follows. Taking an example from above, suppose Joe's
account is on "mars.eng.example.com", and Joe's account advertises
"joe@example.com" as one of its valid email addresses. One would
expect that Joe's "home" MTA knows what Joe's valid email addresses
are. When mail arrives on "mail.example.com" for "joe@example.com",
and it finds Joe's LDAP entry that advertises this address, it should
be able to route the message without rewriting the envelope under the
assumption that Joe's "home" MTA (and other MTAs such as
"hub.eng.example.com" that are "closer" to Joe's "home" MTA than
"mail.example.com") can also correctly identify the address as
belonging to Joe.
However, existing practice in sites that use SMTP-based messaging
often includes the rewriting of addresses to be host-specific. In
order to avoid going against existing practice, our MTA
implementation rewrites envelopes to 'uid'@'mailHost', as explained
above. This is a fixed behavior, and some sites may desire more
flexibility.
One way to provide more flexibility is to add an attribute, say:
mailRoutingAddress address for internal mail routing
This could be added to the 'mailRecipient' and 'mailGroup' object
classes as a way to explicitly specify how to rewrite the envelope
when routing a message. Then, if the 'mailRoutingAddress' is
present, the envelope is rewritten to the indicated address,
otherwise, the address is not rewritten. This provides flexibility
for site-specific policy governing whether or not envelopes are
rewritten, and if so, how they are to be rewritten. It obviates the
fixed 'uid'@'mailHost' behavior in our implementation (see Section
4.3), because the same information can then be stored in the
'mailRoutingAddress' attribute.
It should be noted that if the 'mailRoutingAddress' attribute were
used as described here, that attribute would need to be added to the
search specified in Section 4.1. That is, an MTA receiving a message
should search the directory for any entry whose 'mail',
'mailAlternateAddress', or 'mailRoutingAddress' is the address in
question, since any of those addresses could appear in the envelope.
Also, the 'uid'@'mailHost' search could be removed from the method
specified in Section 4.1, but some sites may still regard this as a
desirable fallback, although in this case the reasons to keep it are
more along the lines of the reasoning in Section 5.2.
One might observe that 'mailRoutingAddress' and 'mailHost' may be
partially redundant, and, in general, it is desirable to avoid
Lachman [Page 7]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
redundancy of information in the directory. Having both attributes
would be useful, however, if for some reason a network administrator
wanted to separately control "next-hop" determination and envelope
rewrites. So if both attributes were present, 'mailHost' would
determine where to route the message, and 'mailRoutingAddress' would
determine how to rewrite the envelope. If only 'mailRoutingAddress'
were present, then the right-hand side (the domain part) of the
routing address would determine the next destination. If only
'mailHost' were present, then the envelope would not be rewritten.
5.2. Localpart-only Searches
Our implementation performs searches on email addresses as complete
addresses (e.g., "joe@example.com"). We do not split the address at
the "@" sign and search on the "local part", except in the case
characterized above as a "fallback" search. This approach is
probably sufficient for most customers since they can always add more
addresses to an account as needed. It also reduces the risk of
"namespace crossovers" that could result if customers with multiple
distinct domains (e.g., with "joe" being a different person in each
domain) did localpart-only searches.
Nevertheless, some sites may desire the flexibility to configure
their MTAs to perform "localpart-only" searches, once the MTA has
ascertained that the domain part is considered to be "local". They
may then want the search to attempt matches against arbitrary
attributes, like 'uid', 'cn' (with spaces and other illegal
characters matching underscores or dots in the address), or some
attribute whose purpose is to contain localpart-only email addresses.
Site-specific needs can vary considerably in this area, and the most
appropriate solution may be to make this part of an MTA's
functionality as configurable as possible.
5.3. Mail Address Mappings
Some sites have a need to perform what might be called a "transit
service" whereby email sent to a given address is resent to another
address (say, for a person who wants their former Internet service
provider to resend their mail to their new account elsewhere). This
is often called an "alias", but, in a strict sense, "alias" means "an
alternate name for something" (which is the purpose of
'mailAlternateAddress'), so this might more properly be called a
"mail address mapping".
This effect can be accomplished with our existing implementation in
several ways. One way is to maintain a 'mailRecipient' entry that
includes a forwarding address ('mailForwardingAddress' attribute).
Another way is to maintain a "group of one" entry, i.e., a
Lachman [Page 8]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
'mailGroup' with only one member.
However, some network administrators may not wish to represent such
"transit" users in their directory service as being actual users or
groups. Therefore, it may be desirable to define a new object class
for this purpose, e.g.:
Object class: mailAddressMapping
Required attribute:
objectClass
Allowed attributes:
cn
mail
mailAlternateAddress
mailTransitAddress
The MTA would treat mail addressed to such an entry the same as it
would for a non-local user who has a 'mailRoutingAddress' specified
and no 'mailHost'; i.e., a message addressed to a
'mailAddressMapping' entry (as per its 'mail' or
'mailAlternateAddress' attributes) is resent to the address specified
as its 'mailTransitAddress'. The reason not to use
'mailRoutingAddress' for this purpose is that the transit address
must not participate in the Question (1) search (since doing so would
cause the search to yield duplicate matches in the case where the
targeted recipient is within the same organization).
5.4. More Configurability
In lieu of a standard, mail server vendors could also achieve
interoperability by providing a high degree of configurability in
their products. For example, each mail server product could provide
a means to configure or program its methods of resolving each of
Questions (1), (2), and (3); if all of the mail servers in a given
site were configured to use the same methods, then they would, in
theory, interoperate in terms of LDAP-based SMTP message routing as
described in this document. However, this approach to
interoperability simply shifts the burden of standardization to the
customer, and then there might still be a demand for a "recommended
configuration profile" (i.e., a standard) for customers who desire
solutions that work "right out of the box".
On the other hand, some level of configurability with regard to the
functionality discussed here may be desirable.
6. Security Considerations
As in all cases where account information is stored in an LDAP-based
Lachman [Page 9]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
directory service, network administrators must be careful to ensure
that their directory service controls users' access to the entries
and attributes stored therein, according to site policy (e.g.,
allowing users to modify, say, their 'mailForwardingAddress'
attribute, but not their 'mailHost' attribute). Mail server products
and their associated user management tools should help administrators
to ensure this, and should also help administrators avoid
configurations that would result in misdelivered mail due to
"namespace crossovers" and other reasons.
7. References
[1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[2] "Information Processing Systems - Open Systems Interconnection -
The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC
1/SC21, International Standard 9594-1, 1988.
[3] J. Postel, "Simple Mail Transfer Protocol", RFC 821, August
1982.
[4] D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982.
[5] P. Mockapetris, "Domain names - concepts and facilities", RFC
1034, November 1987.
[6] C. Partridge, "Mail routing and the domain system", RFC 974,
January 1986.
[7] M. Smith, "Definition of the inetOrgPerson Object Class",
Internet-Draft (work in progress), November 1996.
[8] "Information Processing Systems - Open Systems Interconnection -
The Directory: Selected Object Classes", Recommendation X.521,
ISO/IEC JTC 1/SC21, International Standard 9594-7, 1993.
[9] T. Howes, M. Smith, "An LDAP URL Format", RFC 1959, June 1996.
8. Author's Address
Hans Lachman
Netscape Communications Corp.
501 East Middlefield Road
Mountain View, CA 94043
USA
Lachman [Page 10]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
Phone: (415) 254-1900
EMail: lachman@netscape.com
Appendix A. mailRecipient Object Class and Attributes
The following is an informal description of the 'mailRecipient'
object class and associated attributes. It was designed to be used
as a "mix-in" object in combination with a person's LDAP entry (in
our implementation, an 'inetOrgPerson' entry [7]) to enable a person
to be recognized and handled as a mail user.
Object class: mailRecipient
Required attribute:
objectClass
Allowed attributes:
cn
Common name (person's full name).
mail
"Primary" email address. This is the address that
would likely be displayed by "white-pages" lookup
applications. Must be a complete email address
(e.g., "joe@example.com").
mailAccessDomain
Domains and IP addresses from which user may do POP
or IMAP login.
mailAlternateAddress
Email addresses that are considered valid for this
user in addition to their 'mail' address. Must be
complete email addresses.
mailAutoReplyMode
Auto-reply mode, may be one of: 'vacation' (send
reply text to sender, but only once per vacation),
'reply' (send reply text unconditionally), or 'echo'
(like 'reply' but include original message in the
reply).
mailAutoReplyText
Reply text to use with 'mailAutoReplyMode'.
mailDeliveryOption
Mail delivery option, one or more of: 'mailbox'
(deliver to user's POP/IMAP mailbox), 'native'
(deliver with platform's native delivery method,
e.g., "/usr/bin/mail"), or 'program' (perform program
delivery). There must be at least one
'mailDeliveryOption' and/or 'mailForwardingAddress',
otherwise, mail to this account is undeliverable.
mailForwardingAddress
User-specifiable mail forwarding address(es).
mailHost
Lachman [Page 11]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
Fully-qualified domain name of the MTA that is the
final SMTP destination for mail addressed to this
account. Used for routing (see Section 4.3), and
also used to determine which LDAP entries represent
accounts that are to be considered local to a given
mail server (see Section 4.2).
mailMessageStore
Identifier for the message store containing this
user's POP/IMAP mailbox. Contains absolute path of
the message store directory (may be some other
identifier in the future).
mailProgramDeliveryInfo
Command text for program delivery.
mailQuota
Quota in bytes for user's POP/IMAP mailbox.
multiLineDescription
User-specifiable personal description.
uid
User's login name.
userPassword
User's password.
Appendix B. mailGroup Object Class and Attributes
The following is an informal description of the 'mailGroup' object
class and associated attributes. It was designed to be used as a
"mix-in" object in combination with an LDAP group entry (in
particular, a 'groupOfUniqueNames' entry [8]) to enable a group to be
recognized and handled as a mail group.
Object class: mailGroup
Required attributes:
objectClass
mail
"Primary" email address (as above).
Allowed attributes:
cn
Common name (name of the group).
mailAlternateAddress
Additional email addresses (as above).
mailHost
FQDN of the MTA (as above). For a group, if no
'mailHost' is specified, this implies that any mail
server may perform group handling for messages
addressed to this group (i.e., perform group list
expansion, and forward the message to the individual
recipients).
mgrpAllowedBroadcaster
Lachman [Page 12]
INTERNET-DRAFT LDAP-based Routing of SMTP Messages March 1997
RFC 1959-style [9] specification of users who may
send mail to the group (if such restriction is
desired).
mgrpAllowedDomain
Domains from which users may send mail to the group
(if such restriction is desired).
mgrpDeliverTo
RFC 1959-style filter expression specifying a search
criteria to identify users who should receive copies
of all messages to the group (in addition to the
formal group members, i.e., those who are specified
as members of the 'groupOfUniqueNames' with a
'uniqueMember' attribute), e.g., to include all
persons in the "Sales" organizational unit.
mgrpErrorsTo
RFC 1959-style specification of users whom to notify
of mail delivery problems.
mgrpModerator
RFC 1959-style specification of a user whom to send
rejected messages (rejected because they came from
other than an "allowed broadcaster" or from outside
of the "allowed domains"), but only if the
'mgrpMsgRejectAction' attribute is present with value
'toModerator'.
mgrpMsgMaxSize
Size in bytes of largest message that may be sent to
the group.
mgrpMsgRejectAction
Action to take if a message is rejected due to
violating "allowed broadcaster" and/or "allowed
domain" restrictions (if any). May be one of:
'reply' (send rejection notice to sender), 'bounce'
(send rejection notice to sender, including the
original message), or 'toModerator' (forward to
moderator).
mgrpMsgRejectText
Text of rejection notice to use with
'mgrpMsgRejectText'.
mgrpRfc822MailMember
Email addresses of users who should receive copies of
all messages to the group (in addition to the formal
group members). These users and those specified via
'mgrpDeliverTo' are also called "CC recipients",
since they are not formal group members.
owner
Distinguished name (DN) of the person responsible for
the group.
Lachman Expires: 30 September 1997 [Page 13]
