From df3df5258118c07b35b7a6f6f22d0024fd815ebd Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Thu, 16 Sep 1999 02:37:19 +0000 Subject: [PATCH] Replace lachman mail routing (03) with lachman/laser mail routing (00). --- ...aft-lachman-laser-ldap-mail-routing-xx.txt | 613 ++++++++++ .../draft-lachman-ldap-mail-routing-xx.txt | 1067 ----------------- 2 files changed, 613 insertions(+), 1067 deletions(-) create mode 100644 doc/drafts/draft-lachman-laser-ldap-mail-routing-xx.txt delete mode 100644 doc/drafts/draft-lachman-ldap-mail-routing-xx.txt diff --git a/doc/drafts/draft-lachman-laser-ldap-mail-routing-xx.txt b/doc/drafts/draft-lachman-laser-ldap-mail-routing-xx.txt new file mode 100644 index 0000000000..e900da2360 --- /dev/null +++ b/doc/drafts/draft-lachman-laser-ldap-mail-routing-xx.txt @@ -0,0 +1,613 @@ +Network Working Group H. Lachman +INTERNET-DRAFT Netscape Communications Corp. +Intended Category: Standards Track May 1999 +Expires: November 1999 +Filename: draft-lachman-laser-ldap-mail-routing-00.txt + + + LDAP Schema for Intranet Mail Routing + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This draft is being discussed on the Laser mailing list at + . Subscription requests can be sent to + (send an email message with the + word "subscribe" in the body). More information on the mailing list + along with an archive of back messages is available at + . + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document defines an LDAP [1] object class called + 'inetLocalMailRecipient' and associated attributes that provide a way + to designate an LDAP entry as one that represents a local (intra- + organizational) email recipient, to specify the recipient's email + address(es), and to provide routing information pertinent to the + + + +Lachman [Page 1] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + + recipient. This is intended to support SMTP [2] message transfer + agents in routing RFC 822-based email [3] within a private enterprise + only, and is not to be used in the process of routing email across + the public Internet. + +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.). + In cases where LDAP entries are used to represent entities that are + email recipients (e.g., a mail user or a mailing list), the LDAP + entries provide a convenient place to store per-recipient data, such + as a recipient's email address. + + In many organizations, an email recipient may have an email address + (e.g., "joe@example.com") that does not specify the host that + receives mail for that recipient (e.g., "host42.example.com"). A + message transfer agent (MTA) responsible for routing mail within the + organization needs some way to determine the appropriate target host + for such a recipient. A common solution is the sendmail "aliases" + database which may contain a record that provides the necessary per- + recipient routing information (e.g., "joe: joe@host42"). A drawback + of this solution is that if the organization hosts more than one DNS + domain (e.g., "example.com" and "example.org", with "joe" in each + domain being different recipients), a more explicit mapping is + desirable. The schema defined in this document provides a way to + represent such mappings in LDAP and X.500 [4] directory services. + + An LDAP entry that represents an email recipient could conceivably + contain a variety of attributes related to email, such as disk quota + and delivery preferences. We consider here only attributes that + specify address information and routing information; these attributes + may be useful to multiple MTAs within the organization since one or + more MTAs may be responsible for intra-organizational routing. The + various MTAs in an organization may have been developed by different + implementors, so a common schema is desirable for such attributes. + +2. Overview + + The 'inetLocalMailRecipient' object class and associated attributes + identify an LDAP entry as representing an SMTP mail recipient (in the + sense "recipient" is used in RFC 821). A recipient may be a mail + user, a mailing list, an auto-responder of some kind (e.g., a mailing + list subscription program), a network device such as a printer or fax + machine, or other recipient type. Address attributes and routing + attributes are provided to aid SMTP MTAs in routing mail within an + organization to the appropriate target MTA for each recipient. + + + +Lachman [Page 2] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + + Once on the target MTA, a message is handled as per the recipient + type and options (which may be specified using other auxiliary object + classes and is outside the scope of this document). For example, the + message may be delivered to a user mailbox, or to a program or + network device, and/or forwarded to another recipient. Or, the + target MTA may be a gateway to a non-SMTP mail routing and delivery + system including non-SMTP MTAs. Note that, in this discussion, + "target MTA" refers to the final SMTP destination of messages for the + recipient in question, as we are considering routing of mail only + among the SMTP MTAs within an organization. + + Routing of mail between different organizations across the public + Internet is outside the scope of this document, as the mechanism for + this is already standardized [5,6]. An 'inetLocalMailRecipient' + entry represents a mail recipient that is local to the organization + in question, not recipients in other organizations. This means that + the domain names that appear within the 'mail', + 'mailAlternateAddress', 'mailHost', and 'mailRoutingAddress' + attribute values in an 'inetLocalMailRecipient' entry must be DNS + domain names that are within the administrative authority of the + organization in question (i.e., the organization within which MTAs + are accessing such entries and using these attributes for mail + routing). + + LDAP entries that are not 'inetLocalMailRecipient' entries should be + ignored by MTAs for the purpose of routing. Such entries may contain + a 'mail' attribute since this attribute is used in other object + classes. An example is a conference room whose LDAP entry contains + contact information (e.g., email address and telephone number) for + the person who books reservations for the room; the conference room + is not a mail recipient, and can safely be ignored by MTAs doing + route determination based on recipient address. + +3. Object Class and Attribute Definitions + + The 'inetLocalMailRecipient' object class and associated attributes + are defined (using syntaxes given in [7]) as follows. + + 3.1 The inetLocalMailRecipient Object Class + + ( 2.16.840.1.113730.3.2.[[TBD]] + NAME 'inetLocalMailRecipient' + SUP top + AUXILIARY + MAY ( mail $ mailAlternateAddress $ + mailHost $ mailRoutingAddress + ) + ) + + + +Lachman [Page 3] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + + The 'inetLocalMailRecipient' object class signifies that the entry + represents an entity within the organization that can receive SMTP + mail, such as a mail user or a mailing list. + + 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}' + ) + + 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". The + address conforms to the syntax of an 'addr-spec' as defined in RFC + 822. + + ( 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". The address conforms to the syntax of an + 'addr-spec' as defined in RFC 822. + + When determining the disposition of a given message, an MTA may + search the directory for an entry with object class + 'inetLocalMailRecipient' 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. + + The 'mailAlternateAddress' attribute may also be used to represent a + "wildcard domain" address, e.g., "@example.org", meaning that if mail + arrives for "someone@example.org", and there is no recipient with + that address specified as 'mail' or 'mailAlternateAddress', then the + recipient with the wildcard domain address should receive the mail. + + In short, address attributes may be used by an LDAP entry to answer + the question "what is/are this account's email address(es)?" + + + + +Lachman [Page 4] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + + 3.3 Routing Attributes + + ( 2.16.840.1.113730.3.1.18 + NAME 'mailHost' + DESC 'fully-qualified hostname of the MTA that is the final + SMTP destination of messages to this recipient' + EQUALITY caseIgnoreIA5Match + SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}' + SINGLE-VALUE + ) + + The 'mailHost' attribute indicates which SMTP MTA considers the + 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. The hostname + is specified as a fully-qualified DNS hostname with no trailing dot + (e.g., "host42.example.com"). + + ( 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. The address conforms to the syntax of an 'addr-spec' + in RFC 822. An intermediary MTA may use this information to route + the message to the MTA that handles mail for this recipient. This is + useful in cases where, for a given recipient, the target MTA prefers + a particular address to appear as the recipient address in the SMTP + envelope. So, 'mailRoutingAddress' may be used as an alternative to + 'mailHost', and is intended to have the same effect as 'mailHost' + except that 'mailRoutingAddress' suggests an address for rewriting + the envelope. With 'mailHost', the envelope address either is not + rewritten, or is rewritten according to implementation-specific rules + and/or configuration. + + If both 'mailHost' and 'mailRoutingAddress' are present, the + suggested interpretation is that messages are to be routed to the + host indicated by 'mailHost', while rewriting the envelope as per + 'mailRoutingAddress'. In theory, there could be peculiar cases where + this is necessary, but this is not normally expected. + + Absense of both 'mailHost' and 'mailRoutingAddress' should be + considered an error, unless "location-independent" recipient types + + + +Lachman [Page 5] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + + are supported by the various MTAs within the organization. This + would allow any MTA in the organization to handle the processing of + mail for, say, a mailing list. This presumes that the various MTAs + all recognize the recipient type in question, suggesting a need to + standardize recipient types that could be "location-independent". + + 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"; forwarding and delivery options may be specified in 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). Such options are outside the scope of the + 'inetLocalMailRecipient' schema definition. + +4. Examples + + The following examples illustrate possible uses of the + 'inetLocalMailRecipient' object class. + + Here is an example of an LDAP entry representing a mail user: + + dn: uid=joe,o=Example Corp,c=US + objectclass: top + objectclass: person + objectclass: organizationalPerson + objectclass: inetOrgPerson + objectclass: inetLocalMailRecipient + objectclass: nsMessagingServerUser + cn: Joe User + sn: User + uid: joe + userpassword: {crypt}y2KxtbzMYnApU + mail: joe@example.com + mailhost: nsmail1.example.com + maildeliveryoption: mailbox + mailquota: 1000000 + mailforwardingaddress: mary@example.com + + Joe User is a user of a hypothetical mail system called NS Messaging. + Let's say mail arrives on an MTA called "mx.example.com", addressed + to "joe@example.com". The MTA searches the directory for a mail + recipient with that address, using an LDAP search filter [9] such as: + + (&(objectClass=inetLocalMailRecipient) + (|(mail=joe@example.com) + + + +Lachman [Page 6] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + + (mailAlternateAddress=joe@example.com))) + + It finds Joe's LDAP entry, and routes the message to the target MTA + "nsmail1.example.com", while not rewriting the SMTP envelope + recipient address. Then, "nsmail1.example.com" receives the message, + searches for and finds the recipient in the directory, ascertains + that it is the recipient's target MTA, and handles the message as per + other attributes in the recipient's entry and/or the MTA + configuration (in this case, the message is delivered to a mailbox, + and forwarded to another recipient). + + Note that this document does not specify what search filters are to + be used by MTAs (although the one above is recommended), nor does it + specify the rules an MTA is to use to ascertain whether or not it is + the target MTA for a given recipient (it could check the recipient's + 'mailHost' value against its own hostname, or check the recipient's + 'mailRoutingAddress', or check the MTA configuration, or some + combination of these), nor does it specify how and when MTAs should + rewrite envelopes (it may depend on the MTA configuration). + + Here is another example of an LDAP entry representing a mail user: + + dn: uid=john,o=Example Corp,c=US + objectclass: top + objectclass: person + objectclass: organizationalPerson + objectclass: inetOrgPerson + objectclass: inetLocalMailRecipient + objectclass: xyzMailUser + cn: John Doe + sn: Doe + uid: john + userpassword: {crypt}y2KxtbzMYnApU + mail: john@example.com + mailroutingaddress: John_Doe@xyz-gw.example.com + xyzpostofficename: PO_1 + xyzclusternumber: 3 + xyzmessagestoreid: 9 + + John Doe is a user of a hypothetical mail system called XYZ Mail. + Let's say mail arrives on an MTA called "mx.example.com", addressed + to "john@example.com". The MTA searches the directory for a mail + recipient with that address, and routes the message to "xyz- + gw.example.com", rewriting the SMTP envelope recipient address to + "John_Doe@xyz-gw.example.com", as per the 'mailRoutingAddress'. On + "xyz-gw.example.com", the message is gatewayed into the XYZ Mail + system and then dealt with as per other attributes. + + + + +Lachman [Page 7] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + + Here is an example of an LDAP entry representing a mailing list: + + dn: cn=Scuba Group,o=Example Corp,c=US + objectclass: top + objectclass: groupOfUniqueNames + objectclass: inetLocalMailRecipient + objectclass: mailGroup + cn: Scuba Group + mail: scuba@example.com + mailhost: host42.example.com + mgrprfc822mailmember: joe@example.com + mgrprfc822mailmember: john@example.com + + The Scuba Group is a mail group (mailing list) that includes two + members. A message addressed to "scuba@example.com" is routed to + "host42.example.com" where it is then resent to the mailing list + members. The 'mailGroup' object class is specified elsewhere [10]. + + Here is an example of an LDAP entry representing a forwarding alias: + + dn: cn=Jane Roe Forwarding Alias,o=PU,c=US + objectclass: top + objectclass: inetLocalMailRecipient + objectclass: mailForwardingAlias + mail: janeroe@pu.edu + mailhost: mail.pu.edu + mailforwardingaddress: janeroe@elsewhereville.edu + cn: Jane Roe Forwarding Alias + + This entry uses a hypothetical object class 'mailForwardingAlias' + that is not specified here, but is used as an example of how an LDAP + entry might represent such a recipient type. A message addressed to + "janeroe@pu.edu" is routed to "mail.pu.edu" where it is then + forwarded. In this case, Jane Roe may be a former student of a + university called PU, and they are forwarding her mail to her new + address elsewhere. + +5. 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. In + particular, mail routing information should not be accessible from + outside the organization, since it is intended for use only by MTAs + within the organization. + +6. Acknowledgements + + + +Lachman [Page 8] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + + The 'inetLocalMailRecipient' object class is based on an earlier + design done by the Netscape Messaging and Directory Server teams, + which was implemented and deployed to customers as part of Netscape + Messaging Server. Various team members contributed to the design, + including Bill Fitler, Bruce Steinback, Prabhat Keni, Mike Macgirvin, + John Myers, John Kristian, Tim Howes, Mark Smith, and Leif Hedstrom. + Thanks also to Jeff Hodges of Stanford for contributing to the early + design discussions, and to the other participants in the IETF LASER + BOF, including, from Sun Microsystems, John Beck, Anil Srivastava, + and Darryl Huff. + +7. References + + [1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access + Protocol", RFC 1777, March 1995. + + [2] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, + August 1982. + + [3] D. Crocker, "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, August 1982. + + [4] "Information Processing Systems - Open Systems Interconnection - + The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC + 1/SC21, International Standard 9594-1, 1988. + + [5] C. Partridge, "Mail routing and the domain system", STD 14, RFC + 974, January 1986. + + [6] R. Braden, "Requirements for Internet hosts - application and + support", STD 3, RFC 1123, October 1989. + + [7] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500 + Directory Access Protocol (v3): Attribute Syntax Definitions", RFC + 2252, December 1997. + + [8] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC + 1274, November 1991. + + [9] T. Howes, "The String Representation of LDAP Search Filters", + RFC 2254, December 1997. + + [10] B. Steinback, "Using LDAP for SMTP Mailing Lists and Aliases", + Internet-Draft (work in progress). + + [11] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical + Specification", Internet-Draft (work in progress). + + + + +Lachman [Page 9] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + + [12] M. Smith, "The inetOrgPerson Object Class", Internet-Draft + (work in progress). + +8. Author's Address + + Hans Lachman + Netscape Communications Corp. + 501 East Middlefield Road + Mountain View, CA 94043 + + Phone: (650) 254-1900 + EMail: lachman@netscape.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lachman [Page 10] + +INTERNET-DRAFT LDAP Schema for Intranet Mail Routing May 1999 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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: November 1999 [Page 11] + diff --git a/doc/drafts/draft-lachman-ldap-mail-routing-xx.txt b/doc/drafts/draft-lachman-ldap-mail-routing-xx.txt deleted file mode 100644 index 0802340621..0000000000 --- a/doc/drafts/draft-lachman-ldap-mail-routing-xx.txt +++ /dev/null @@ -1,1067 +0,0 @@ - - - - - - -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] - -- 2.39.5