[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03                                                   
Network Working Group                                         H. Lachman
INTERNET-DRAFT                             Netscape Communications Corp.
Intended Category: Informational                          September 1998
Expires: March 1999
Filename: draft-lachman-ldap-mail-routing-02.txt


          LDAP Schema Definitions for Intranet Mail Routing -
                     The mailRecipient Object Class

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

   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), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   A revised version of this draft document will be submitted to the RFC
   editor for consideration as an Informational RFC for the Internet
   community.  Discussion and suggestions for improvement are requested.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

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



Lachman                                                         [Page 1]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   interoperability, it is desirable to have a common schema for such
   email-related information.

   This document defines an object class called 'mailRecipient' to
   support SMTP [3] message transfer agents (MTAs) in routing RFC 822-
   based email messages [4] within an organization.  The intent is to
   suggest a model for MTA interoperability via the directory, to
   provide information about a solution that has been implemented and
   deployed, and to stimulate discussion about whether and how to
   standardize the functionality in question.

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).  Other information (e.g., login name,
   password, disk quota) is stored for use by one or more network
   applications or services.  This latter use of the directory suggests
   the opportunity to centralize the storage and management of user
   account information related to different services.  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.

   Thus, in our implementation, all account information for a given mail
   server user is stored in the directory entry that represents that
   user.  This includes the user's delivery options, access
   restrictions, mailbox quota, and vacation status, among other things.
   Now, if a given mail server can refer to the directory for its own
   users' account information, it follows that that same information can
   be made 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 among the mail servers in the
   organization.  If this assumption is met in our implementation, we
   can obviate other means currently employed to specify per-user
   message routing (such as the Unix "aliases" database).  The benefit



Lachman                                                         [Page 2]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   of this is to further consolidate per-user system information.

   If different vendors provide LDAP-aware mail server products, each
   having its own schema for 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 defines a schema designed to provide a means by which a
   directory entry that represents a mail recipient can provide
   information enabling MTAs to route messages to the recipient's "home"
   MTA.  This document considers only intra-enterprise SMTP message
   routing 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 any X.500-based directory service).

2.  Overview of the Approach Implemented

   In our design of Netscape Messaging Server, we identified all pieces
   of per-user account information, and assigned attributes such that
   the information for a given user can be held in the user's "LDAP
   entry" (the directory entry representing the user in an LDAP-based
   directory service).  We segregated the attributes into two
   categories:  those that are of interest only to the "target MTA"
   (i.e., the MTA that considers the recipient to be local), and those
   that are of interest to "intermediary MTAs" (i.e., MTAs that are not
   the target MTA).  Each subset of attributes is aggregated into an
   object class, the former being 'nsMessagingServerUser' (see
   Appendix), and the latter, 'mailRecipient'.  It is the latter object
   class that is the focus of this document.

   The 'mailRecipient' object class provides attributes that may be used
   to specify addressing and routing information pertaining to a given
   recipient.  This information may be used by an intermediary MTA to
   route a message to the recipient's designated target MTA, i.e., to
   the MTA that "takes responsibility" for messages to the recipient in
   question.  The target MTA then accepts the message and, regarding the
   recipient as local, handles the message as specified by attributes
   intended for use by the target MTA (such as those associated with the
   'nsMessagingServerUser' object class).






Lachman                                                         [Page 3]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   Consider a network with three hosts that run MTAs:

                                     +------+
           local                     |      |
           handling                  | MDA2 |
           layer                     |      |
                                     +------+
                                        ^
                                        |
                     +------+        +------+        +------+
                     |      |        |      |        |      |
           routing   | MTA1 | -----> | MTA2 | -----> | MTA3 |
           layer     |      |        |      |        |      |
                     +------+        +------+        +------+

                      host1           host2           host3

   The above illustrates a two-layer mail routing and delivery model.
   The attributes provided by the 'mailRecipient' object class are used
   by the lower layer (the routing layer) to support the routing of a
   message to the correct target MTA.  Other attributes may be used by
   the upper layer, which roughly equates to what is commonly called an
   MDA (message delivery agent), although the local handling may or may
   not involve delivery of the message to a mailbox (e.g., the message
   may be resent if the recipient is a mail group or a forwarded
   account).  (In this discussion, "target MTA" means "target Messaging
   Server" which includes both MTA and MDA functionalities.)

   In our implementation, an LDAP entry that represents a mail recipient
   will have two mail-related object classes, 'mailRecipient', plus an
   additional one that is used by the local handling layer to determine
   what kind of mail recipient it is and how messages for the recipient
   are to be handled on the target MTA.  A mail user account will have
   'mailRecipient' plus 'nsMessagingServerUser'.  A mail group will have
   'mailRecipient' plus 'mailGroup' [5].  An MTA need only look at
   attributes associated with 'mailRecipient' to determine whether a
   recipient is local, and if not, how to route the message.  The
   additional object class and attributes are of interest only if the
   recipient is local.

   (Note:  While the Messaging Server fully implements this approach,
   earlier versions of its account creation tool do not place all of the
   above-mentioned object classes in the entries it creates.  The
   Messaging Server is compatible with both the old and the new object
   class interpretations.)

   A Netscape Messaging Server can route messages to recipients on other
   vendors' MTAs if the users' LDAP entries have the 'mailRecipient'



Lachman                                                         [Page 4]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   object class and associated attributes.  (Other vendors' MTA
   implementations may or may not follow the above-described model of
   indicating recipient type and MDA-level account configuration in
   LDAP, since only 'mailRecipient' and associated attributes are
   required for MTA-level recognition.)

   Likewise, other vendors' MTAs can route messages to recipients on a
   Netscape Messaging Server if they recognize and interpret the
   'mailRecipient' object class and associated attributes as defined in
   Sec. 3.

   The intent of this model is to provide a framework within which any
   vendor can define new types of mail recipients, without requiring
   other vendors' implementations to have knowledge of the new recipient
   types; they need only have a consistent interpretation and
   application of the 'mailRecipient' object class and associated
   attributes.

   In short, the main advantage of the 'mailRecipient' object class is
   to define a single object class that can serve to identify an LDAP
   entry as an entity to which email can be addressed, and to aggregate
   the attributes that can provide multivendor MTA interoperability via
   the directory.

3.  Object Class and Attribute Definitions

   The 'mailRecipient' object class and associated attributes are
   defined as follows.

 3.1  The mailRecipient Object Class

       ( 2.16.840.1.113730.3.2.3
           NAME 'mailRecipient'
           SUP top
           STRUCTURAL
           MUST objectClass
           MAY ( cn $ mail $ mailAlternateAddress $
               mailHost $ mailRoutingAddress
           )
       )

   The 'mailRecipient' object class signifies that the entry represents
   an entity that can receive RFC 822-based email (such as an email
   user, or a mailing list).

   The 'cn' attribute (common name) is provided as a means for
   administrators to identify the entry [6].




Lachman                                                         [Page 5]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


 3.2  Address Attributes

       ( 0.9.2342.19200300.100.1.3
           NAME 'mail'
           DESC 'RFC 822 email address of this recipient'
           EQUALITY caseIgnoreIA5Match
           SYNTAX 'IA5String(256)'
           SINGLE-VALUE
       )

   The attribute name 'mail' is a synonym for 'rfc822Mailbox', as
   defined earlier in [7].  This attribute specifies the recipient's
   "primary" or "advertised" email address, i.e., that which might
   appear on a business card; for example, "user@example.com".

       ( 2.16.840.1.113730.3.1.13
           NAME 'mailAlternateAddress'
           DESC 'alternate RFC 822 email address of this recipient'
           EQUALITY caseIgnoreIA5Match
           SYNTAX 'IA5String(256)'
       )

   The 'mailAlternateAddress' attribute is used to specify alternate
   email addresses, if any, for the recipient; for example,
   "nickname@example.com".

   When determining the disposition of a given message, an MTA may
   search the directory for an entry with object class 'mailRecipient'
   and a 'mail' or 'mailAlternateAddress' attribute matching the
   message's recipient address.  If exactly one matching entry is found,
   the MTA may regard the message as being addressed to the entity that
   is represented by the directory entry.

   In short, address attributes may be used by an LDAP entry to answer
   the question "what is/are this account's email address(es)?"

 3.3  Routing Attributes

       ( 2.16.840.1.113730.3.1.18
           NAME 'mailHost'
           DESC 'fully qualified hostname of the SMTP MTA that
               handles messages for this recipient'
           EQUALITY caseIgnoreIA5Match
           SYNTAX 'IA5String(256)'
           SINGLE-VALUE
       )

   This attribute indicates which MTA considers the recipient's mail to



Lachman                                                         [Page 6]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   be locally handlable.  This information can be used for routing,
   in that an intermediary MTA may take it to be the destination
   for messages addressed to this recipient.

       ( 2.16.840.1.113730.3.1.47
           NAME 'mailRoutingAddress'
           DESC 'RFC 822 address to use when routing messages to
               the SMTP MTA of this recipient'
           EQUALITY caseIgnoreIA5Match
           SYNTAX 'IA5String(256)'
           SINGLE-VALUE
       )

   This attribute indicates a routing address for the recipient.  An
   intermediary MTA may use this information to route the message to the
   MTA that handles mail for this recipient.

   Only one of the above two attributes need be present in order to
   route messages on behalf of the recipient.  The 'mailRoutingAddress'
   attribute is more explicit in terms of providing an address that can
   be used to rewrite the SMTP envelope recipient address.  With
   'mailHost', the envelope address is either not rewritten, or is
   rewritten according to implementation-specific rules and/or
   configuration.

   In short, routing attributes may be used by an LDAP entry to answer
   the question "how should MTAs route mail to this account?"
   (analogous to using the Unix "aliases" database for per-user
   routing).  This is in contrast with "forwarding" (see Appendix);
   forwarding and delivery options may be used by an LDAP entry to
   answer the question "what happens to mail once it arrives at this
   account?", which may include forwarding to some other account
   (analogous to using the Unix ".forward" file).

4.  MTA Implementation Details

   This section provides details of the algorithms followed by the
   Netscape Messaging Server as they relate to the 'mailRecipient'
   object class and associated attributes.  Our implementation includes
   features that go beyond what is minimally needed to support the
   schema defined in Section 3, and other MTA implementations need not
   match our implementation in every detail in order to be interoperable
   (especially since various features described here can be disabled);
   but, in general, the features described here are recommended.

 4.1  Finding the LDAP Entry for a Given Email Address

   When the MTA receives a message, it attempts to determine whether



Lachman                                                         [Page 7]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   there is an LDAP entry that represents the recipient.  It takes the
   SMTP envelope recipient address, and performs a search in LDAP,
   spanning the directory subtree specified in the configuration, for an
   entry that has the object class 'mailRecipient', and has either a
   'mail' or 'mailAlternateAddress' attribute matching the recipient
   address in question.  If exactly one match is found, this is taken to
   be the LDAP entry that represents the recipient.

   If there were zero matches, but the domain part of the address
   matches the local MTA's hostname, we perform a fallback search with
   the same address except that the domain part is truncated to not
   include the host part (e.g., the search for
   "user@nsmail1.example.com" is retried as "user@example.com").  This
   fallback search is optional, as per the server configuration.

   If there were zero matches so far, but the domain part of the address
   is considered to be local (by configurable criteria), we perform a
   fallback search for an LDAP entry that has object class
   'mailRecipient' and a 'uid' attribute (i.e., login name; synonym for
   'userid' [7]) equal to the local part of the recipient address.  This
   fallback search is optional, as per the server configuration.

   If the MTA finds the LDAP entry representing the recipient, it
   proceeds with the logic discussed in Section 4.2.  Otherwise, it will
   rely on other information resources to determine whether to reject
   the message or route it elsewhere.

   Note that LDAP entries without the 'mailRecipient' object class are
   ignored.  This is necessary because some sites have LDAP entries that
   do not reprensent mail recipients, but have a 'mail' attribute
   nonetheless.  For example, a conference room might have an LDAP entry
   including an email address, telephone number, etc., that is the same
   as for the secretary who books reservations for the room.  In this
   example, the conference room's email address is for contact
   information only, and is not intended to imply that it has an email
   account.  Therefore, the MTA correctly ignores the conference room's
   LDAP entry, and avoids producing multiple matches on the search.

 4.2  Deciding Whether a Message can be Handled Locally

   If the MTA has found the LDAP entry representing the recipient, as
   per Section 4.1, it checks the LDAP entry's 'mailHost' value to see
   if it matches the MTA's local hostname.  If so, it handles the
   message locally.

   If not, it routes the message as specified by the 'mailHost' value
   and/or the 'mailRoutingAddress' value.  See Section 4.3 for further
   details.



Lachman                                                         [Page 8]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   If the recipient's LDAP entry contains no routing information (i.e.,
   no 'mailHost' nor 'mailRoutingAddress'), the MTA will bounce (reject)
   the message.  There are two exceptions to this rule, as follows.

   If the entry has no routing information, but is a mailing list (i.e.,
   has object class 'mailGroup'), the message is handled locally, i.e.,
   the MTA "receives" messages to the address in question, performs the
   mail group expansion, and resends to the group members.  Thus, it is
   not necessary to designate a particular Messaging Server to perform
   mail group expansion.

   If the entry has no routing information, but has one or more
   'mailForwardingAddress' attributes (see Appendix), it is handled
   locally, i.e., the MTA "receives" messages to the address in question
   under the assumption that it is a forwarding-only account, and
   forwards the message to the new address(es).  Thus, it is not
   necessary to designate a particular Messaging Server to perform
   forwarding on behalf of a forwarding-only account.  (This usage may
   be deprecated in a future version; in that case, a forwarding-only
   effect can still be had by indicating a specific 'mailHost' value, or
   by using a mail group, or by using 'mailRoutingAddress' if the
   desired action is actually "routing", not "forwarding" - see Sec. 3.3
   for clarification.  One might imagine a new object class, say,
   'mailForwardingAlias', that just provides a way to configure a
   recipient type that includes 'mailForwardingAddress' and allows the
   absense of routing information, as with 'mailGroup', but this may be
   overkill.)

   Note that if there were a non-Netscape MTA in the environment that
   implemented the 'mailRecipient' concept but did not mimic the
   Netscape MTA behavior regarding the above two exception cases, it
   would probably be unadvisable for administrators to leave out routing
   information on any 'mailRecipient' entries.

 4.3  Determing how to Route a Message

   If the recipient is not local, but has a 'mailHost' and/or
   'mailRoutingAddress' attribute in its LDAP entry, we route the
   message as follows.

   First, we determine a destination.  If a 'mailHost' value is present,
   that is taken to be the destination.  Otherwise, the domain part of
   the 'mailRoutingAddress' value is taken to be the destination.

   Second, we determine whether and how to rewrite the SMTP envelope
   recipient address.  If a 'mailRoutingAddress' value is present, the
   envelope address is rewritten to that.  Otherwise, depending on the
   configuration, the envelope address may be rewritten by combining the



Lachman                                                         [Page 9]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   'uid' value, if present, with the 'mailHost' value (e.g.,
   "uid@mail.host"), or, it is rewritten by combining the original
   envelope address local part with the 'mailHost' value (e.g.,
   "orig.localpart@mail.host"), or it is not rewritten at all.

   Third, we determine the next SMTP hop.  This may or may not be the
   same as the destination determined above.  Given the destination, the
   MTA will consult the routing table in the MTA configuration, and/or
   consult DNS for "MX" and/or "A" records [8].

   The message is then relayed to the next SMTP hop, with the SMTP
   envelope recipient address set as determined above.

   Note that if both 'mailHost' and 'mailRoutingAddress' are present,
   the 'mailHost' attribute determines the destination while the
   'mailRoutingAddress' attribute determines the envelope rewrite.  It
   is expected that specifying both is unnecessary, although not
   inherently harmful, and may be useful in some peculiar cases.

5.  Examples

   The following is a set of directory entries, shown in LDIF [9]
   format, that illustrates the use of the 'mailRecipient' object class.
   Examples based on this set of entries are provided in the sections
   that follow.  Each example explains what happens when a message
   arrives on nsmail1.example.com for the indicated recipient.

       dn: cn=Joe Blow,o=Example Corp,c=US
       objectclass: top
       objectclass: person
       objectclass: organizationalPerson
       objectclass: inetOrgPerson
       objectclass: mailRecipient
       objectclass: nsMessagingServerUser
       cn: Joe Blow
       sn: Blow
       uid: joeblow
       userpassword: {crypt}y9LyrzNBT49Ao
       mail: joeblow@example.com
       mailhost: nsmail1.example.com
       maildeliveryoption: mailbox

       dn: cn=John Doe,o=Example Corp,c=US
       objectclass: top
       objectclass: person
       objectclass: organizationalPerson
       objectclass: inetOrgPerson
       objectclass: mailRecipient



Lachman                                                        [Page 10]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


       objectclass: nsMessagingServerUser
       cn: John Doe
       sn: Doe
       uid: johndoe
       userpassword: {crypt}y9LyrzNBT49Ao
       mail: johndoe@example.com
       mailalternateaddress: jonjon@example.com
       mailhost: nsmail2.example.com
       maildeliveryoption: mailbox

       dn: cn=Scuba Group,o=Example Corp,c=US
       objectclass: top
       objectclass: groupOfUniqueNames
       objectclass: mailRecipient
       objectclass: mailGroup
       cn: Scuba Group
       mail: scuba@example.com
       mgrprfc822mailmember: joeblow@example.com
       mgrprfc822mailmember: johndoe@example.com

       dn: cn=Tuba Group,o=Example Corp,c=US
       objectclass: top
       objectclass: groupOfUniqueNames
       objectclass: mailRecipient
       objectclass: mailGroup
       cn: Tuba Group
       mail: tuba@example.com
       mailhost: nsmail2.example.com
       mgrprfc822mailmember: joeblow@example.com
       mgrprfc822mailmember: janeroe@example.com

       dn: cn=Jane Roe,o=Example Corp,c=US
       objectclass: top
       objectclass: person
       objectclass: organizationalPerson
       objectclass: inetOrgPerson
       objectclass: mailRecipient
       objectclass: nsMessagingServerUser
       cn: Jane Roe
       sn: Doe
       uid: janeroe
       userpassword: {crypt}y9LyrzNBT49Ao
       mail: janeroe@example.com
       mailhost: nsmail1.example.com
       maildeliveryoption: mailbox
       mailforwardingaddress: babs@example.com

       dn: cn=J Random User,o=Example Corp,c=US



Lachman                                                        [Page 11]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


       objectclass: top
       objectclass: mailRecipient
       objectclass: nsMessagingServerUser
       cn: J Random User
       sn: User
       mail: jruser@example.com
       mailforwardingaddress: random@pu.edu

       dn: cn=Babs Jensen,o=Example Corp,c=US
       objectclass: top
       objectclass: person
       objectclass: organizationalPerson
       objectclass: inetOrgPerson
       objectclass: mailRecipient
       objectclass: xyzMailUser
       cn: Babs Jensen
       sn: Jensen
       uid: babs
       userpassword: {crypt}y9LyrzNBT49Ao
       mail: babs@example.com
       mailalternateaddress: bj@schooldist12.k12.ca.us
       mailroutingaddress: Babs_Jensen@xyz1.example.com
       xyzPostOfficeName: Example_PO_1
       xyzUserType: regular
       xyzQuota: 1000000

       dn: cn=Charlie Hacker,o=Example Corp,c=US
       objectclass: top
       objectclass: person
       objectclass: organizationalPerson
       objectclass: inetOrgPerson
       objectclass: mailRecipient
       objectclass: nsMessagingServerUser
       cn: Charlie Hacker
       sn: Hacker
       uid: hacker
       userpassword: {crypt}y9LyrzNBT49Ao
       mail: hacker@schooldist12.k12.ca.us
       mailhost: nsmail2.example.com
       mailroutingaddress: hacker@schooldist12.k12.ca.us
       maildeliveryoption: mailbox
       mailforwardingaddress: babs@example.com

       dn: cn=Conference Room 102,o=Example Corp,c=US
       objectclass: top
       objectclass: conferenceRoom
       mail: babs@example.com
       roomNumber: 102



Lachman                                                        [Page 12]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


 5.1  Example #1

   When a message arrives on nsmail1.example.com for
   joeblow@example.com, the message is deposited in Joe Blow's mailbox.

 5.2  Example #2

   When a message arrives on nsmail1.example.com for johndoe@example.com
   or for jonjon@example.com, the message is relayed to
   nsmail2.example.com, with "johndoe@nsmail2.example.com" in the
   envelope.  On nsmail2.example.com, the message is identified as
   belonging to John Doe by virtue of "nsmail2.example.com" being local
   and "johndoe" being the 'uid' of John Doe.  So the message is
   deposited in his mailbox on nsmail2.example.com.

   The above assumes that 'uid'-based routing is the selected
   configuration, and the "truncate host part" fallback search is
   disabled (but if "truncate host part" were enabled, the scenario
   would still succeed, only in a different way).

 5.3  Example #3

   When a message arrives on nsmail1.example.com for scuba@example.com,
   the message is resent to joeblow@example.com and johndoe@example.com.
   (The message is considered to be locally handlable since the
   recipient is a mail group with no routing information.)

 5.4  Example #4

   When a message arrives on nsmail1.example.com for tuba@example.com,
   the message is relayed to nsmail2.example.com with
   "tuba@nsmail2.example.com" (assuming that the
   "orig.localpart@mail.host" option is enabled).  On
   nsmail2.example.com, the message is identified as belonging to the
   Tuba Group by virtue of the "truncate host part" fallback search, so
   the message is accepted and resent to the group members.

   (If "truncate host part" were disabled on nsmail2.example.com, the
   search would fail.  However, if that were disabled, and
   "orig.localpart@mail.host" on nsmail1.example.com were also disabled,
   the scenario would succeed because the envelope would not be
   rewritten and the search on the "tuba@example.com" would succeed on
   nsmail2.example.com.)

 5.5  Example #5

   When a message arrives on nsmail1.example.com for
   janeroe@example.com, the message is delivered to Jane's mailbox, and



Lachman                                                        [Page 13]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   is also forwarded to Babs.  Perhaps Jane is on leave.

 5.6  Example #6

   When a message arrives on nsmail1.example.com for jruser@example.com,
   it is forwarded to random@pu.edu.  Perhaps he has left the company to
   go back to school, and the company is forwarding his mail as a favor.

   Note that the presence or absence of the usual object classes such as
   'person' do not affect the Messaging Server.  Also, the absense of
   'uid' and 'userPassword' is probably a good idea since a person who
   has left the company should not be able to login.  Note also that a
   'mailHost' could have been specified, e.g., as "nsmail2.example.com",
   with no difference in overall effect, except that it would require
   all messages addressed to this user to be passed to
   nsmail2.example.com where the forward action would then be performed.

 5.7  Example #7

   When a message arrives on nsmail1.example.com for babs@example.com,
   or for bj@schooldist12.k12.ca.us (the company is doing a favor to a
   local school district by hosting their mail accounts on the company
   servers; Babs is both an employee in the company and a volunteer at
   the school district, and so she has both addresses), the message is
   relayed to the SMTP MTA on host xyz1.example.com (which may be an
   SMTP-to-XYZ gateway), with "Babs_Jensen@xyz1.example.com" in the
   envelope.

   Note that Conference Room 102 is not identified by the MTA as a
   recipient of mail addressed to babs@example.com, despite it's having
   the matching 'mail' address.  This is because it does not have the
   'mailRecipient' object class.

 5.8  Example #8

   When a message arrives on nsmail1.example.com for
   hacker@schooldist12.k12.ca.us, the message is relayed to
   nsmail2.example.com with "hacker@schooldist12.k12.ca.us" in the
   envelope.  Mail arriving on nsmail2.example.com for this user is
   deposited into his mailbox, and a copy is forwarded to Babs.  Charlie
   is a guest user from a local school district, and is not in the
   company, and therefore does not have an address with "example.com".

   The reason to force the envelope using 'mailRoutingAddress' is to
   avoid having it rewritten to "hacker@nsmail2.example.com" (which
   would happen if envelope rewrites using 'mailHost' are enabled;
   disabling envelope rewrites could also solve the problem).  Thus, we
   avoid a "namespace crossover" that could result in misdelivered mail



Lachman                                                        [Page 14]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   if there were some other user with address "hacker@example.com".
   This is one of the peculiar cases where having both 'mailHost' and
   'mailRoutingAddress' is useful, and may be a consideration for
   Internet service providers who host mail accounts for multiple
   companies on the same server.

6.  Security Considerations

   As in all cases where account information is stored in an LDAP-based
   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.  Acknowledgements

   Many members of the Netscape Messaging Server and Directory Server
   teams contributed to the design of this schema, including Bill
   Fitler, Prabhat Keni, Mike Macgirvin, Bruce Steinback, John Myers,
   Tim Howes, Mark Smith, and John Kristian (who coined the object class
   name 'mailRecipient').  Special thanks to Leif Hedstrom, Netscape's
   Chief Dogfood Taster, for his "real world" insights.  Thanks also to
   Jeff Hodges for contributing to the discussion that led to this memo,
   and to Stuart Freedman for providing review comments.

8.  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", STD 10, RFC 821,
   August 1982.

   [4]  D. Crocker, "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822, August 1982.

   [5]  B. Steinback, "Using LDAP for SMTP Mailing Lists and Aliases"
   (work in progress).




Lachman                                                        [Page 15]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


   [6]  M. Wahl, "A Summary of the X.500(96) User Schema for use with
   LDAPv3", RFC 2256, December 1997.

   [7]  P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC
   1274, November 1991.

   [8]  C. Partridge, "Mail routing and the domain system", STD 14, RFC
   974, January 1986.

   [9]  G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
   Specification" (work in progress).

   [10]  M. Smith, "The inetOrgPerson Object Class" (work in progress).

9.  Author's Address

   Hans Lachman
   Netscape Communications Corp.
   501 East Middlefield Road
   Mountain View, CA  94043

   Phone: (650) 254-1900
   EMail: lachman@netscape.com

10.  Appendix - nsMessagingServerUser Object Class and Attributes

   The following is an informal description of the
   'nsMessagingServerUser' object class and associated attributes.  It
   was designed to be used in combination with the 'mailRecipient' and
   'inetOrgPerson' [10] object classes to define a mail user account.
   This definition is not considered part of the 'mailRecipient'
   definition, and is provided here purely as supplemental information.
   These attributes may change across releases, and such changes would
   not affect MTA interoperability.

   Object class:  nsMessagingServerUser
       Required attribute:
           objectClass
       Allowed attributes:
           cn
                   Common name (person's full name).
           mailAccessDomain
                   Domains and IP addresses from which user may do POP
                   or IMAP login.
           mailAutoReplyMode
                   Auto-reply mode, may be one (or none) of:  'vacation'
                   (send reply text to sender, but only once per
                   vacation), 'reply' (send reply text unconditionally),



Lachman                                                        [Page 16]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


                   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).  This
                   is different from 'mailRoutingAddress' in that it is
                   intended to be configurable by the user, and may be
                   multi-valued.  Thus, forwarding and delivery options
                   may be thought of as "account preferences", while
                   routing attributes are used to get a message to the
                   MTA that will take responsibility for handling the
                   message as per the recipient's account preferences.
           mailMessageStore
                   Identifier for the message store containing this
                   user's POP/IMAP mailbox.
           mailProgramDeliveryInfo
                   Command text for program delivery.
           mailQuota
                   Quota in bytes for user's POP/IMAP mailbox.























Lachman                                                        [Page 17]


INTERNET-DRAFT       The mailRecipient Object Class       September 1998


11.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Lachman                   Expires: March 1999                  [Page 18]