[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                         H. Lachman
INTERNET-DRAFT                             Netscape Communications Corp.
Intended Category: Informational                            October 1998
Expires: April 1999
Filename: draft-lachman-ldap-mail-routing-03.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).

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
   interoperability, it is desirable to have a common schema for such
   email-related information.

   This document defines an object class called 'mailRecipient' to



Lachman                                                         [Page 1]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   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 sendmail "aliases" database).  The
   benefit of this is to further consolidate per-user system
   information.

   If different vendors provide LDAP-aware mail server products, each



Lachman                                                         [Page 2]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   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 subsets:
   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         October 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; while the
   implementation is not necessarily layered internally as implied
   above, the product nonetheless exhibits the functionality described.)

   In our implementation, an LDAP entry that represents a mail recipient
   will have two mail-related object classes, 'mailRecipient', plus an
   additional one that may be used by the local handling layer to
   determine the recipient type 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.)




Lachman                                                         [Page 4]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   A Netscape Messaging Server can route messages to recipients on other
   vendors' MTAs if the users' LDAP entries have the 'mailRecipient'
   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 (using syntaxes given in [6]) as follows.

 3.1  The mailRecipient Object Class

       ( 2.16.840.1.113730.3.2.3
           NAME 'mailRecipient'
           SUP top
           AUXILIARY
           MAY ( cn $ mail $ mailAlternateAddress $
               mailHost $ mailRoutingAddress
           )
       )

   The 'mailRecipient' object class signifies that the entry represents
   an entity within the organization that can receive SMTP mail, such as
   a mail user account or a mail group account (mailing list).

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



Lachman                                                         [Page 5]

INTERNET-DRAFT       The mailRecipient Object Class         October 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 '1.3.6.1.4.1.1466.115.121.1.26{256}'
           SINGLE-VALUE
       )

   The attribute name 'mail' is a synonym for 'rfc822Mailbox', as
   defined earlier in [8].  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 '1.3.6.1.4.1.1466.115.121.1.26{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 '1.3.6.1.4.1.1466.115.121.1.26{256}'
           SINGLE-VALUE
       )

   The 'mailHost' attribute indicates which MTA considers the



Lachman                                                         [Page 6]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   recipient's mail to 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 '1.3.6.1.4.1.1466.115.121.1.26{256}'
           SINGLE-VALUE
       )

   The 'mailRoutingAddress' 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 either is 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 sendmail "aliases" database for per-user
   routing within an organization).  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 within or outside the organization (analogous to
   using the sendmail ".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




Lachman                                                         [Page 7]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   When the MTA receives a message, it attempts to determine whether
   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' [8]) 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 (except as may be needed for backward compatibility).  This
   is necessary because some sites have LDAP entries that do not
   represent 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 are 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.  (Note that since accounts hosted on a Netscape MTA
   are expected to have a 'mailHost' value, they typically do not have a
   'mailRoutingAddress' value; other implementations could make



Lachman                                                         [Page 8]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   different design choices, and still be compatible.)

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

   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, to accommodate
   location-independent accounts, 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, a mail
   group can be configured as "location-independent", meaning that it
   does not require a particular Messaging Server to perform the 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 (or "redirect")
   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
   exception may be deprecated in a future version, and then all
   'nsMessagingServerUser' accounts will require a 'mailHost' value.  If
   location-independent redirects are still desired, a 'mailGroup' entry
   can be used to achieve the same effect.  Or, one could imagine a new
   object class to combine with 'mailRecipient', say,
   'mailForwardingAlias', that just provides a way to configure a
   location-independent recipient that has a 'mailForwardingAddress',
   but this may be overkill.  One might also consider whether the
   desired action is actually "routing", not "forwarding" - see Sec. 3.3
   for clarification.  The point is that a mail server should never
   perform "forwarding" unless it also takes responsibility for the
   account's other attributes that specify delivery-time handling, if
   any; this is to ensure that all of the account's forwarding and
   delivery preferences are acted upon exactly once in the life of a
   message.)

   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 exception cases, it would
   probably be unadvisable for administrators to configure any accounts
   as location-independent.  (This suggests that if it is generally
   useful to configure a certain recipient type as location-independent,



Lachman                                                         [Page 9]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   e.g., 'mailGroup', it ought to be standardized.)

 4.3  Determining 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
   '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 [9].

   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.

   Note also that envelope rewrites may be considered unnecessary (e.g.,
   in Netscape-only MTA sites), and perhaps undesirable (e.g., if the
   user has multiple addresses and the target MTA allows the user to
   configure server-side filters that read the envelope; also, envelope
   rewrites may increase the chances of "namespace crossovers" in
   multi-domain sites, as mentioned in Sec. 5.8).  Envelope rewrites
   become necessary when routing to MTAs whose reckoning of their
   accounts' email addresses is not consistent with the accounts'
   respective LDAP entries (which could be the case with MTAs that are
   not 'mailRecipient'-compatible).

5.  Examples




Lachman                                                        [Page 10]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   The following is a set of directory entries, shown in LDIF [10]
   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
       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



Lachman                                                        [Page 11]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


       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
       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



Lachman                                                        [Page 12]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


       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

 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 (assuming the "uid@mail.host" rewrite option is enabled on
   nsmail1.example.com).  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 (assuming the 'uid' fallback search is enabled on
   nsmail2.example.com).  So the message is deposited in his mailbox on
   nsmail2.example.com.

   The above case would also succeed if the "truncate host part"
   fallback search were enabled on nsmail2.example.com, or if no



Lachman                                                        [Page 13]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   fallback searches or envelope rewrites were configured on either
   machine (in which case the envelope recipient address would remain
   unchanged).

 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.

   As in Example #2, the above case would also succeed if no fallback
   searches or envelope rewrites were configured on either machine.

 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
   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 absence 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.

   (This is an example of a location-independent "redirect" account,
   which may be deprecated in a future release; see Sec. 4.2.)




Lachman                                                        [Page 14]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


 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.
   Thus, we avoid a "namespace crossover" that could result in
   misdelivered mail 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, since
   'mailRoutingAddress' overrides the default rewrite rule (although the
   problem could also be solved by disabling envelope rewrites, assuming
   they are not needed).  Any site that hosts multiple domains (e.g., an
   Internet service provider) must be especially careful in considering
   whether and how envelopes are to be rewritten when mail is routed
   among its MTAs.  (See also Sec. 4.3.)

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



Lachman                                                        [Page 15]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   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",
   Internet-Draft (work in progress).

   [6]  M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500
   Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
   2252, December 1997.

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

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

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

   [10]  G. Good, "The LDAP Data Interchange Format (LDIF) - Technical



Lachman                                                        [Page 16]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


   Specification", Internet-Draft (work in progress).

   [11]  M. Smith, "The inetOrgPerson Object Class", Internet-Draft
   (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' [11] object classes to define a Netscape Messaging
   Server 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
       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),
                   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',



Lachman                                                        [Page 17]

INTERNET-DRAFT       The mailRecipient Object Class         October 1998


                   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 18]

INTERNET-DRAFT       The mailRecipient Object Class         October 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 implementation 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: April 1999                  [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/