From: Kurt Zeilenga Date: Thu, 16 Sep 1999 02:34:53 +0000 (+0000) Subject: Add draft-lachman-ldap-mail-routing-03.txt X-Git-Tag: UCDATA_2_4~428 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=7ea7c51c4dca411b2095d08d6ea4a2e534d077f7;p=openldap Add draft-lachman-ldap-mail-routing-03.txt --- diff --git a/doc/drafts/draft-lachman-ldap-mail-routing-xx.txt b/doc/drafts/draft-lachman-ldap-mail-routing-xx.txt new file mode 100644 index 0000000000..0802340621 --- /dev/null +++ b/doc/drafts/draft-lachman-ldap-mail-routing-xx.txt @@ -0,0 +1,1067 @@ + + + + + + +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] +