-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
projects / openldap / commitdiff