--- /dev/null
+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
+ <laser@sunroof.eng.sun.com>. Subscription requests can be sent to
+ <laser-request@sunroof.eng.sun.com> (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
+ <http://playground.sun.com/laser/>.
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group H. Lachman
-INTERNET-DRAFT Netscape Communications Corp.
-Intended Category: Informational October 1998
-Expires: April 1999
-Filename: draft-lachman-ldap-mail-routing-03.txt
-
-
- LDAP Schema Definitions for Intranet Mail Routing -
- The mailRecipient Object Class
-
-Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- To learn the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
-Abstract
-
- Directory services based on the Lightweight Directory Access Protocol
- (LDAP) [1] and X.500 [2] provide a general-purpose means to store
- information about users and other network entities. One of the many
- possible uses of a directory service is to store information about
- users' email accounts, such as their email addresses, and how
- messages addressed to them should be routed. In the interest of
- interoperability, it is desirable to have a common schema for such
- email-related information.
-
- This document defines an object class called 'mailRecipient' to
-
-
-
-Lachman [Page 1]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- support SMTP [3] message transfer agents (MTAs) in routing RFC 822-
- based email messages [4] within an organization. The intent is to
- suggest a model for MTA interoperability via the directory, to
- provide information about a solution that has been implemented and
- deployed, and to stimulate discussion about whether and how to
- standardize the functionality in question.
-
-1. Background and Motivation
-
- LDAP-based directory services are currently being used in many
- organizations as a repository of information about users and other
- network entities (such as groups of users, network resources, etc.).
- Some information is stored in the directory for the consumption of
- persons browsing for information (e.g., telephone numbers, postal
- addresses, secretary's name). Other information (e.g., login name,
- password, disk quota) is stored for use by one or more network
- applications or services. This latter use of the directory suggests
- the opportunity to centralize the storage and management of user
- account information related to different services. In general, it is
- advantageous for different network applications and services to refer
- to the directory for user account information, rather than each
- service keeping its own collection of user account records, which
- requires the network administrator to separately create or destroy
- user entities, passwords, etc., in many different systems each time a
- user joins or leaves the organization. The goals of centralized user
- management and sharing of information with other service types drove
- our decision in the design of Netscape Messaging Server (an SMTP-
- based mail server product) to use LDAP-based directory services as a
- common repository for user account information.
-
- Thus, in our implementation, all account information for a given mail
- server user is stored in the directory entry that represents that
- user. This includes the user's delivery options, access
- restrictions, mailbox quota, and vacation status, among other things.
- Now, if a given mail server can refer to the directory for its own
- users' account information, it follows that that same information can
- be made visible to other LDAP-aware mail servers in the same
- organization, and therefore that information can aid those other mail
- servers in correctly routing messages to users of the mail server in
- question. This assumes that there is an agreed-upon set of per-user
- attributes to support message routing among the mail servers in the
- organization. If this assumption is met in our implementation, we
- can obviate other means currently employed to specify per-user
- message routing (such as the sendmail "aliases" database). The
- benefit of this is to further consolidate per-user system
- information.
-
- If different vendors provide LDAP-aware mail server products, each
-
-
-
-Lachman [Page 2]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- having its own schema for message routing, then the above benefits
- can be achieved for single-vendor customers, but customers who have
- multiple vendors' mail server products would not be well served.
- They will likely expect interoperability, which will require a common
- schema to be supported by the various vendors' products. Thus, it is
- worthwhile to consider how to develop a common schema.
-
- This document defines a schema designed to provide a means by which a
- directory entry that represents a mail recipient can provide
- information enabling MTAs to route messages to the recipient's "home"
- MTA. This document considers only intra-enterprise SMTP message
- routing using LDAP-based directory services. Solutions and issues
- involving inter-enterprise routing, non-SMTP message handling, non-
- LDAP directory services, and other messaging management topics not
- related to message routing, are outside the scope of this document
- (except that the concepts presented may also be applicable in the
- case of any X.500-based directory service).
-
-2. Overview of the Approach Implemented
-
- In our design of Netscape Messaging Server, we identified all pieces
- of per-user account information, and assigned attributes such that
- the information for a given user can be held in the user's "LDAP
- entry" (the directory entry representing the user in an LDAP-based
- directory service). We segregated the attributes into two subsets:
- those that are of interest only to the "target MTA" (i.e., the MTA
- that considers the recipient to be local), and those that are of
- interest to "intermediary MTAs" (i.e., MTAs that are not the target
- MTA). Each subset of attributes is aggregated into an object class,
- the former being 'nsMessagingServerUser' (see Appendix), and the
- latter, 'mailRecipient'. It is the latter object class that is the
- focus of this document.
-
- The 'mailRecipient' object class provides attributes that may be used
- to specify addressing and routing information pertaining to a given
- recipient. This information may be used by an intermediary MTA to
- route a message to the recipient's designated target MTA, i.e., to
- the MTA that "takes responsibility" for messages to the recipient in
- question. The target MTA then accepts the message and, regarding the
- recipient as local, handles the message as specified by attributes
- intended for use by the target MTA (such as those associated with the
- 'nsMessagingServerUser' object class).
-
-
-
-
-
-
-
-
-
-Lachman [Page 3]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- Consider a network with three hosts that run MTAs:
-
- +------+
- local | |
- handling | MDA2 |
- layer | |
- +------+
- ^
- |
- +------+ +------+ +------+
- | | | | | |
- routing | MTA1 | -----> | MTA2 | -----> | MTA3 |
- layer | | | | | |
- +------+ +------+ +------+
-
- host1 host2 host3
-
- The above illustrates a two-layer mail routing and delivery model.
- The attributes provided by the 'mailRecipient' object class are used
- by the lower layer (the routing layer) to support the routing of a
- message to the correct target MTA. Other attributes may be used by
- the upper layer, which roughly equates to what is commonly called an
- MDA (message delivery agent), although the local handling may or may
- not involve delivery of the message to a mailbox (e.g., the message
- may be resent if the recipient is a mail group or a forwarded
- account). (In this discussion, "target MTA" means "target Messaging
- Server" which includes both MTA and MDA functionalities; while the
- implementation is not necessarily layered internally as implied
- above, the product nonetheless exhibits the functionality described.)
-
- In our implementation, an LDAP entry that represents a mail recipient
- will have two mail-related object classes, 'mailRecipient', plus an
- additional one that may be used by the local handling layer to
- determine the recipient type and how messages for the recipient are
- to be handled on the target MTA. A mail user account will have
- 'mailRecipient' plus 'nsMessagingServerUser'. A mail group will have
- 'mailRecipient' plus 'mailGroup' [5]. An MTA need only look at
- attributes associated with 'mailRecipient' to determine whether a
- recipient is local, and if not, how to route the message. The
- additional object class and attributes are of interest only if the
- recipient is local.
-
- (Note: While the Messaging Server fully implements this approach,
- earlier versions of its account creation tool do not place all of the
- above-mentioned object classes in the entries it creates. The
- Messaging Server is compatible with both the old and the new object
- class interpretations.)
-
-
-
-
-Lachman [Page 4]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- A Netscape Messaging Server can route messages to recipients on other
- vendors' MTAs if the users' LDAP entries have the 'mailRecipient'
- object class and associated attributes. (Other vendors' MTA
- implementations may or may not follow the above-described model of
- indicating recipient type and MDA-level account configuration in
- LDAP, since only 'mailRecipient' and associated attributes are
- required for MTA-level recognition.)
-
- Likewise, other vendors' MTAs can route messages to recipients on a
- Netscape Messaging Server if they recognize and interpret the
- 'mailRecipient' object class and associated attributes as defined in
- Sec. 3.
-
- The intent of this model is to provide a framework within which any
- vendor can define new types of mail recipients, without requiring
- other vendors' implementations to have knowledge of the new recipient
- types; they need only have a consistent interpretation and
- application of the 'mailRecipient' object class and associated
- attributes.
-
- In short, the main advantage of the 'mailRecipient' object class is
- to define a single object class that can serve to identify an LDAP
- entry as an entity to which email can be addressed, and to aggregate
- the attributes that can provide multivendor MTA interoperability via
- the directory.
-
-3. Object Class and Attribute Definitions
-
- The 'mailRecipient' object class and associated attributes are
- defined (using syntaxes given in [6]) as follows.
-
- 3.1 The mailRecipient Object Class
-
- ( 2.16.840.1.113730.3.2.3
- NAME 'mailRecipient'
- SUP top
- AUXILIARY
- MAY ( cn $ mail $ mailAlternateAddress $
- mailHost $ mailRoutingAddress
- )
- )
-
- The 'mailRecipient' object class signifies that the entry represents
- an entity within the organization that can receive SMTP mail, such as
- a mail user account or a mail group account (mailing list).
-
- The 'cn' attribute (common name) is provided as a means for
- administrators to identify the entry [7].
-
-
-
-Lachman [Page 5]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- 3.2 Address Attributes
-
- ( 0.9.2342.19200300.100.1.3
- NAME 'mail'
- DESC 'RFC 822 email address of this recipient'
- EQUALITY caseIgnoreIA5Match
- SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
- SINGLE-VALUE
- )
-
- The attribute name 'mail' is a synonym for 'rfc822Mailbox', as
- defined earlier in [8]. This attribute specifies the recipient's
- "primary" or "advertised" email address, i.e., that which might
- appear on a business card; for example, "user@example.com".
-
- ( 2.16.840.1.113730.3.1.13
- NAME 'mailAlternateAddress'
- DESC 'alternate RFC 822 email address of this recipient'
- EQUALITY caseIgnoreIA5Match
- SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
- )
-
- The 'mailAlternateAddress' attribute is used to specify alternate
- email addresses, if any, for the recipient; for example,
- "nickname@example.com".
-
- When determining the disposition of a given message, an MTA may
- search the directory for an entry with object class 'mailRecipient'
- and a 'mail' or 'mailAlternateAddress' attribute matching the
- message's recipient address. If exactly one matching entry is found,
- the MTA may regard the message as being addressed to the entity that
- is represented by the directory entry.
-
- In short, address attributes may be used by an LDAP entry to answer
- the question "what is/are this account's email address(es)?"
-
- 3.3 Routing Attributes
-
- ( 2.16.840.1.113730.3.1.18
- NAME 'mailHost'
- DESC 'fully qualified hostname of the SMTP MTA that
- handles messages for this recipient'
- EQUALITY caseIgnoreIA5Match
- SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
- SINGLE-VALUE
- )
-
- The 'mailHost' attribute indicates which MTA considers the
-
-
-
-Lachman [Page 6]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- recipient's mail to be locally handlable. This information can be
- used for routing, in that an intermediary MTA may take it to be the
- destination for messages addressed to this recipient.
-
- ( 2.16.840.1.113730.3.1.47
- NAME 'mailRoutingAddress'
- DESC 'RFC 822 address to use when routing messages to
- the SMTP MTA of this recipient'
- EQUALITY caseIgnoreIA5Match
- SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
- SINGLE-VALUE
- )
-
- The 'mailRoutingAddress' attribute indicates a routing address for
- the recipient. An intermediary MTA may use this information to route
- the message to the MTA that handles mail for this recipient.
-
- Only one of the above two attributes need be present in order to
- route messages on behalf of the recipient. The 'mailRoutingAddress'
- attribute is more explicit in terms of providing an address that can
- be used to rewrite the SMTP envelope recipient address. With
- 'mailHost', the envelope address either is not rewritten, or is
- rewritten according to implementation-specific rules and/or
- configuration.
-
- In short, routing attributes may be used by an LDAP entry to answer
- the question "how should MTAs route mail to this account?"
- (analogous to using the sendmail "aliases" database for per-user
- routing within an organization). This is in contrast with
- "forwarding" (see Appendix); forwarding and delivery options may be
- used by an LDAP entry to answer the question "what happens to mail
- once it arrives at this account?", which may include forwarding to
- some other account within or outside the organization (analogous to
- using the sendmail ".forward" file).
-
-4. MTA Implementation Details
-
- This section provides details of the algorithms followed by the
- Netscape Messaging Server as they relate to the 'mailRecipient'
- object class and associated attributes. Our implementation includes
- features that go beyond what is minimally needed to support the
- schema defined in Section 3, and other MTA implementations need not
- match our implementation in every detail in order to be interoperable
- (especially since various features described here can be disabled);
- but, in general, the features described here are recommended.
-
- 4.1 Finding the LDAP Entry for a Given Email Address
-
-
-
-
-Lachman [Page 7]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- When the MTA receives a message, it attempts to determine whether
- there is an LDAP entry that represents the recipient. It takes the
- SMTP envelope recipient address, and performs a search in LDAP,
- spanning the directory subtree specified in the configuration, for an
- entry that has the object class 'mailRecipient', and has either a
- 'mail' or 'mailAlternateAddress' attribute matching the recipient
- address in question. If exactly one match is found, this is taken to
- be the LDAP entry that represents the recipient.
-
- If there were zero matches, but the domain part of the address
- matches the local MTA's hostname, we perform a fallback search with
- the same address except that the domain part is truncated to not
- include the host part (e.g., the search for
- "user@nsmail1.example.com" is retried as "user@example.com"). This
- fallback search is optional, as per the server configuration.
-
- If there were zero matches so far, but the domain part of the address
- is considered to be local (by configurable criteria), we perform a
- fallback search for an LDAP entry that has object class
- 'mailRecipient' and a 'uid' attribute (i.e., login name; synonym for
- 'userid' [8]) equal to the local part of the recipient address. This
- fallback search is optional, as per the server configuration.
-
- If the MTA finds the LDAP entry representing the recipient, it
- proceeds with the logic discussed in Section 4.2. Otherwise, it will
- rely on other information resources to determine whether to reject
- the message or route it elsewhere.
-
- Note that LDAP entries without the 'mailRecipient' object class are
- ignored (except as may be needed for backward compatibility). This
- is necessary because some sites have LDAP entries that do not
- represent mail recipients, but have a 'mail' attribute nonetheless.
- For example, a conference room might have an LDAP entry including an
- email address, telephone number, etc., that are the same as for the
- secretary who books reservations for the room. In this example, the
- conference room's email address is for contact information only, and
- is not intended to imply that it has an email account. Therefore,
- the MTA correctly ignores the conference room's LDAP entry, and
- avoids producing multiple matches on the search.
-
- 4.2 Deciding Whether a Message can be Handled Locally
-
- If the MTA has found the LDAP entry representing the recipient, as
- per Section 4.1, it checks the LDAP entry's 'mailHost' value to see
- if it matches the MTA's local hostname. If so, it handles the
- message locally. (Note that since accounts hosted on a Netscape MTA
- are expected to have a 'mailHost' value, they typically do not have a
- 'mailRoutingAddress' value; other implementations could make
-
-
-
-Lachman [Page 8]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- different design choices, and still be compatible.)
-
- Otherwise, it routes the message as specified by the 'mailHost' value
- and/or the 'mailRoutingAddress' value. See Section 4.3 for further
- details.
-
- If the recipient's LDAP entry contains no routing information (i.e.,
- no 'mailHost' nor 'mailRoutingAddress'), the MTA will bounce (reject)
- the message. There are two exceptions to this rule, to accommodate
- location-independent accounts, as follows.
-
- If the entry has no routing information, but is a mailing list (i.e.,
- has object class 'mailGroup'), the message is handled locally, i.e.,
- the MTA "receives" messages to the address in question, performs the
- mail group expansion, and resends to the group members. Thus, a mail
- group can be configured as "location-independent", meaning that it
- does not require a particular Messaging Server to perform the mail
- group expansion.
-
- If the entry has no routing information, but has one or more
- 'mailForwardingAddress' attributes (see Appendix), it is handled
- locally, i.e., the MTA "receives" messages to the address in question
- under the assumption that it is a forwarding-only (or "redirect")
- account, and forwards the message to the new address(es). Thus, it
- is not necessary to designate a particular Messaging Server to
- perform forwarding on behalf of a forwarding-only account. (This
- exception may be deprecated in a future version, and then all
- 'nsMessagingServerUser' accounts will require a 'mailHost' value. If
- location-independent redirects are still desired, a 'mailGroup' entry
- can be used to achieve the same effect. Or, one could imagine a new
- object class to combine with 'mailRecipient', say,
- 'mailForwardingAlias', that just provides a way to configure a
- location-independent recipient that has a 'mailForwardingAddress',
- but this may be overkill. One might also consider whether the
- desired action is actually "routing", not "forwarding" - see Sec. 3.3
- for clarification. The point is that a mail server should never
- perform "forwarding" unless it also takes responsibility for the
- account's other attributes that specify delivery-time handling, if
- any; this is to ensure that all of the account's forwarding and
- delivery preferences are acted upon exactly once in the life of a
- message.)
-
- Note that if there were a non-Netscape MTA in the environment that
- implemented the 'mailRecipient' concept but did not mimic the
- Netscape MTA behavior regarding the above exception cases, it would
- probably be unadvisable for administrators to configure any accounts
- as location-independent. (This suggests that if it is generally
- useful to configure a certain recipient type as location-independent,
-
-
-
-Lachman [Page 9]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- e.g., 'mailGroup', it ought to be standardized.)
-
- 4.3 Determining how to Route a Message
-
- If the recipient is not local, but has a 'mailHost' and/or
- 'mailRoutingAddress' attribute in its LDAP entry, we route the
- message as follows.
-
- First, we determine a destination. If a 'mailHost' value is present,
- that is taken to be the destination. Otherwise, the domain part of
- the 'mailRoutingAddress' value is taken to be the destination.
-
- Second, we determine whether and how to rewrite the SMTP envelope
- recipient address. If a 'mailRoutingAddress' value is present, the
- envelope address is rewritten to that. Otherwise, depending on the
- configuration, the envelope address may be rewritten by combining the
- 'uid' value, if present, with the 'mailHost' value (e.g.,
- "uid@mail.host"), or, it is rewritten by combining the original
- envelope address local part with the 'mailHost' value (e.g.,
- "orig.localpart@mail.host"), or it is not rewritten at all.
-
- Third, we determine the next SMTP hop. This may or may not be the
- same as the destination determined above. Given the destination, the
- MTA will consult the routing table in the MTA configuration, and/or
- consult DNS for "MX" and/or "A" records [9].
-
- The message is then relayed to the next SMTP hop, with the SMTP
- envelope recipient address set as determined above.
-
- Note that if both 'mailHost' and 'mailRoutingAddress' are present,
- the 'mailHost' attribute determines the destination while the
- 'mailRoutingAddress' attribute determines the envelope rewrite. It
- is expected that specifying both is unnecessary, although not
- inherently harmful, and may be useful in some peculiar cases.
-
- Note also that envelope rewrites may be considered unnecessary (e.g.,
- in Netscape-only MTA sites), and perhaps undesirable (e.g., if the
- user has multiple addresses and the target MTA allows the user to
- configure server-side filters that read the envelope; also, envelope
- rewrites may increase the chances of "namespace crossovers" in
- multi-domain sites, as mentioned in Sec. 5.8). Envelope rewrites
- become necessary when routing to MTAs whose reckoning of their
- accounts' email addresses is not consistent with the accounts'
- respective LDAP entries (which could be the case with MTAs that are
- not 'mailRecipient'-compatible).
-
-5. Examples
-
-
-
-
-Lachman [Page 10]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- The following is a set of directory entries, shown in LDIF [10]
- format, that illustrates the use of the 'mailRecipient' object class.
- Examples based on this set of entries are provided in the sections
- that follow. Each example explains what happens when a message
- arrives on nsmail1.example.com for the indicated recipient.
-
- dn: cn=Joe Blow,o=Example Corp,c=US
- objectclass: top
- objectclass: person
- objectclass: organizationalPerson
- objectclass: inetOrgPerson
- objectclass: mailRecipient
- objectclass: nsMessagingServerUser
- cn: Joe Blow
- sn: Blow
- uid: joeblow
- userpassword: {crypt}y9LyrzNBT49Ao
- mail: joeblow@example.com
- mailhost: nsmail1.example.com
- maildeliveryoption: mailbox
-
- dn: cn=John Doe,o=Example Corp,c=US
- objectclass: top
- objectclass: person
- objectclass: organizationalPerson
- objectclass: inetOrgPerson
- objectclass: mailRecipient
- objectclass: nsMessagingServerUser
- cn: John Doe
- sn: Doe
- uid: johndoe
- userpassword: {crypt}y9LyrzNBT49Ao
- mail: johndoe@example.com
- mailalternateaddress: jonjon@example.com
- mailhost: nsmail2.example.com
- maildeliveryoption: mailbox
-
- dn: cn=Scuba Group,o=Example Corp,c=US
- objectclass: top
- objectclass: groupOfUniqueNames
- objectclass: mailRecipient
- objectclass: mailGroup
- cn: Scuba Group
- mail: scuba@example.com
- mgrprfc822mailmember: joeblow@example.com
- mgrprfc822mailmember: johndoe@example.com
-
- dn: cn=Tuba Group,o=Example Corp,c=US
-
-
-
-Lachman [Page 11]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- objectclass: top
- objectclass: groupOfUniqueNames
- objectclass: mailRecipient
- objectclass: mailGroup
- cn: Tuba Group
- mail: tuba@example.com
- mailhost: nsmail2.example.com
- mgrprfc822mailmember: joeblow@example.com
- mgrprfc822mailmember: janeroe@example.com
-
- dn: cn=Jane Roe,o=Example Corp,c=US
- objectclass: top
- objectclass: person
- objectclass: organizationalPerson
- objectclass: inetOrgPerson
- objectclass: mailRecipient
- objectclass: nsMessagingServerUser
- cn: Jane Roe
- sn: Doe
- uid: janeroe
- userpassword: {crypt}y9LyrzNBT49Ao
- mail: janeroe@example.com
- mailhost: nsmail1.example.com
- maildeliveryoption: mailbox
- mailforwardingaddress: babs@example.com
-
- dn: cn=J Random User,o=Example Corp,c=US
- objectclass: top
- objectclass: mailRecipient
- objectclass: nsMessagingServerUser
- cn: J Random User
- sn: User
- mail: jruser@example.com
- mailforwardingaddress: random@pu.edu
-
- dn: cn=Babs Jensen,o=Example Corp,c=US
- objectclass: top
- objectclass: person
- objectclass: organizationalPerson
- objectclass: inetOrgPerson
- objectclass: mailRecipient
- objectclass: xyzMailUser
- cn: Babs Jensen
- sn: Jensen
- uid: babs
- userpassword: {crypt}y9LyrzNBT49Ao
- mail: babs@example.com
- mailalternateaddress: bj@schooldist12.k12.ca.us
-
-
-
-Lachman [Page 12]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- mailroutingaddress: Babs_Jensen@xyz1.example.com
- xyzPostOfficeName: Example_PO_1
- xyzUserType: regular
- xyzQuota: 1000000
-
- dn: cn=Charlie Hacker,o=Example Corp,c=US
- objectclass: top
- objectclass: person
- objectclass: organizationalPerson
- objectclass: inetOrgPerson
- objectclass: mailRecipient
- objectclass: nsMessagingServerUser
- cn: Charlie Hacker
- sn: Hacker
- uid: hacker
- userpassword: {crypt}y9LyrzNBT49Ao
- mail: hacker@schooldist12.k12.ca.us
- mailhost: nsmail2.example.com
- mailroutingaddress: hacker@schooldist12.k12.ca.us
- maildeliveryoption: mailbox
- mailforwardingaddress: babs@example.com
-
- dn: cn=Conference Room 102,o=Example Corp,c=US
- objectclass: top
- objectclass: conferenceRoom
- mail: babs@example.com
- roomNumber: 102
-
- 5.1 Example #1
-
- When a message arrives on nsmail1.example.com for
- joeblow@example.com, the message is deposited in Joe Blow's mailbox.
-
- 5.2 Example #2
-
- When a message arrives on nsmail1.example.com for johndoe@example.com
- or for jonjon@example.com, the message is relayed to
- nsmail2.example.com, with "johndoe@nsmail2.example.com" in the
- envelope (assuming the "uid@mail.host" rewrite option is enabled on
- nsmail1.example.com). On nsmail2.example.com, the message is
- identified as belonging to John Doe by virtue of
- "nsmail2.example.com" being local and "johndoe" being the 'uid' of
- John Doe (assuming the 'uid' fallback search is enabled on
- nsmail2.example.com). So the message is deposited in his mailbox on
- nsmail2.example.com.
-
- The above case would also succeed if the "truncate host part"
- fallback search were enabled on nsmail2.example.com, or if no
-
-
-
-Lachman [Page 13]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- fallback searches or envelope rewrites were configured on either
- machine (in which case the envelope recipient address would remain
- unchanged).
-
- 5.3 Example #3
-
- When a message arrives on nsmail1.example.com for scuba@example.com,
- the message is resent to joeblow@example.com and johndoe@example.com.
- (The message is considered to be locally handlable since the
- recipient is a mail group with no routing information.)
-
- 5.4 Example #4
-
- When a message arrives on nsmail1.example.com for tuba@example.com,
- the message is relayed to nsmail2.example.com with
- "tuba@nsmail2.example.com" (assuming that the
- "orig.localpart@mail.host" option is enabled). On
- nsmail2.example.com, the message is identified as belonging to the
- Tuba Group by virtue of the "truncate host part" fallback search, so
- the message is accepted and resent to the group members.
-
- As in Example #2, the above case would also succeed if no fallback
- searches or envelope rewrites were configured on either machine.
-
- 5.5 Example #5
-
- When a message arrives on nsmail1.example.com for
- janeroe@example.com, the message is delivered to Jane's mailbox, and
- is also forwarded to Babs. Perhaps Jane is on leave.
-
- 5.6 Example #6
-
- When a message arrives on nsmail1.example.com for jruser@example.com,
- it is forwarded to random@pu.edu. Perhaps he has left the company to
- go back to school, and the company is forwarding his mail as a favor.
-
- Note that the presence or absence of the usual object classes such as
- 'person' do not affect the Messaging Server. Also, the absence of
- 'uid' and 'userPassword' is probably a good idea since a person who
- has left the company should not be able to login. Note also that a
- 'mailHost' could have been specified, e.g., as "nsmail2.example.com",
- with no difference in overall effect, except that it would require
- all messages addressed to this user to be passed to
- nsmail2.example.com where the forward action would then be performed.
-
- (This is an example of a location-independent "redirect" account,
- which may be deprecated in a future release; see Sec. 4.2.)
-
-
-
-
-Lachman [Page 14]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- 5.7 Example #7
-
- When a message arrives on nsmail1.example.com for babs@example.com,
- or for bj@schooldist12.k12.ca.us (the company is doing a favor to a
- local school district by hosting their mail accounts on the company
- servers; Babs is both an employee in the company and a volunteer at
- the school district, and so she has both addresses), the message is
- relayed to the SMTP MTA on host xyz1.example.com (which may be an
- SMTP-to-XYZ gateway), with "Babs_Jensen@xyz1.example.com" in the
- envelope.
-
- Note that Conference Room 102 is not identified by the MTA as a
- recipient of mail addressed to babs@example.com, despite it's having
- the matching 'mail' address. This is because it does not have the
- 'mailRecipient' object class.
-
- 5.8 Example #8
-
- When a message arrives on nsmail1.example.com for
- hacker@schooldist12.k12.ca.us, the message is relayed to
- nsmail2.example.com with "hacker@schooldist12.k12.ca.us" in the
- envelope. Mail arriving on nsmail2.example.com for this user is
- deposited into his mailbox, and a copy is forwarded to Babs. Charlie
- is a guest user from a local school district, and is not in the
- company, and therefore does not have an address with "example.com".
-
- The reason to force the envelope using 'mailRoutingAddress' is to
- avoid having it rewritten to "hacker@nsmail2.example.com", which
- would happen if envelope rewrites using 'mailHost' are enabled.
- Thus, we avoid a "namespace crossover" that could result in
- misdelivered mail if there were some other user with address
- "hacker@example.com". This is one of the peculiar cases where having
- both 'mailHost' and 'mailRoutingAddress' is useful, since
- 'mailRoutingAddress' overrides the default rewrite rule (although the
- problem could also be solved by disabling envelope rewrites, assuming
- they are not needed). Any site that hosts multiple domains (e.g., an
- Internet service provider) must be especially careful in considering
- whether and how envelopes are to be rewritten when mail is routed
- among its MTAs. (See also Sec. 4.3.)
-
-6. Security Considerations
-
- As in all cases where account information is stored in an LDAP-based
- directory service, network administrators must be careful to ensure
- that their directory service controls users' access to the entries
- and attributes stored therein, according to site policy (e.g.,
- allowing users to modify, say, their 'mailForwardingAddress'
- attribute, but not their 'mailHost' attribute). Mail server products
-
-
-
-Lachman [Page 15]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- and their associated user management tools should help administrators
- to ensure this, and should also help administrators avoid
- configurations that would result in misdelivered mail due to
- "namespace crossovers" and other reasons.
-
-7. Acknowledgements
-
- Many members of the Netscape Messaging Server and Directory Server
- teams contributed to the design of this schema, including Bill
- Fitler, Prabhat Keni, Mike Macgirvin, Bruce Steinback, John Myers,
- Tim Howes, Mark Smith, and John Kristian (who coined the object class
- name 'mailRecipient'). Special thanks to Leif Hedstrom, Netscape's
- Chief Dogfood Taster, for his "real world" insights. Thanks also to
- Jeff Hodges for contributing to the discussion that led to this memo,
- and to Stuart Freedman for providing review comments.
-
-8. References
-
- [1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol", RFC 1777, March 1995.
-
- [2] "Information Processing Systems - Open Systems Interconnection -
- The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC
- 1/SC21, International Standard 9594-1, 1988.
-
- [3] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821,
- August 1982.
-
- [4] D. Crocker, "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [5] B. Steinback, "Using LDAP for SMTP Mailing Lists and Aliases",
- Internet-Draft (work in progress).
-
- [6] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500
- Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
- 2252, December 1997.
-
- [7] M. Wahl, "A Summary of the X.500(96) User Schema for use with
- LDAPv3", RFC 2256, December 1997.
-
- [8] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC
- 1274, November 1991.
-
- [9] C. Partridge, "Mail routing and the domain system", STD 14, RFC
- 974, January 1986.
-
- [10] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
-
-
-
-Lachman [Page 16]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- Specification", Internet-Draft (work in progress).
-
- [11] M. Smith, "The inetOrgPerson Object Class", Internet-Draft
- (work in progress).
-
-9. Author's Address
-
- Hans Lachman
- Netscape Communications Corp.
- 501 East Middlefield Road
- Mountain View, CA 94043
-
- Phone: (650) 254-1900
- EMail: lachman@netscape.com
-
-10. Appendix - nsMessagingServerUser Object Class and Attributes
-
- The following is an informal description of the
- 'nsMessagingServerUser' object class and associated attributes. It
- was designed to be used in combination with the 'mailRecipient' and
- 'inetOrgPerson' [11] object classes to define a Netscape Messaging
- Server user account. This definition is not considered part of the
- 'mailRecipient' definition, and is provided here purely as
- supplemental information. These attributes may change across
- releases, and such changes would not affect MTA interoperability.
-
- Object class: nsMessagingServerUser
- Allowed attributes:
- cn
- Common name (person's full name).
- mailAccessDomain
- Domains and IP addresses from which user may do POP
- or IMAP login.
- mailAutoReplyMode
- Auto-reply mode, may be one (or none) of: 'vacation'
- (send reply text to sender, but only once per
- vacation), 'reply' (send reply text unconditionally),
- or 'echo' (like 'reply' but include original message
- in the reply).
- mailAutoReplyText
- Reply text to use with 'mailAutoReplyMode'.
- mailDeliveryOption
- Mail delivery option, one or more of: 'mailbox'
- (deliver to user's POP/IMAP mailbox), 'native'
- (deliver with platform's native delivery method,
- e.g., "/usr/bin/mail"), or 'program' (perform program
- delivery). There must be at least one
- 'mailDeliveryOption' and/or 'mailForwardingAddress',
-
-
-
-Lachman [Page 17]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
- otherwise, mail to this account is undeliverable.
- mailForwardingAddress
- User-specifiable mail forwarding address(es). This
- is different from 'mailRoutingAddress' in that it is
- intended to be configurable by the user, and may be
- multi-valued. Thus, forwarding and delivery options
- may be thought of as "account preferences", while
- routing attributes are used to get a message to the
- MTA that will take responsibility for handling the
- message as per the recipient's account preferences.
- mailMessageStore
- Identifier for the message store containing this
- user's POP/IMAP mailbox.
- mailProgramDeliveryInfo
- Command text for program delivery.
- mailQuota
- Quota in bytes for user's POP/IMAP mailbox.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lachman [Page 18]
-\f
-INTERNET-DRAFT The mailRecipient Object Class October 1998
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lachman Expires: April 1999 [Page 19]
-\f
projects / openldap / commitdiff