CHAPTER 3 |
Sun Directory Services Directory Information Tree and Schema |
|
|
"Introduction" on page 203 |
|
|
"Producers and Consumers of the Mail Schema" on page 204 |
|
|
"Directory Schema and DIT Specification" on page 205 |
|
|
"Directory Information Tree" on page 206 |
|
|
"Data in OSI and DC trees" on page 209 |
|
|
"Attribute Syntax" on page 213 |
|
|
"Services and Functions" on page 214 |
|
|
"Object Classes Used by Sun Internet Mail Server 4.0" on page 215 |
|
|
"Directory Information Tree and Virtual Domain Object Classes" on page 215 |
|
|
"Internet Mail User Object Classes" on page 226 |
|
|
"Internet Mail Distribution List Object Classes" on page 242 |
|
|
"Internet Mail Routing Object Classes" on page 251 |
|
|
"Object Classes for Services" on page 252 |
This chapter describes a schema for Internet mail routing and delivery, but the core of this schema also serves as the core for other Internet services. It also describes the SIMS Directory Information Tree (DIT) and Schema. You use the DIT and schema information for provisioning and debugging.
The examples provided throughout the document show how the schema is suited for Internet mail and also illustrate the modularity that provides support for service- and vendor-independent interoperability.
For information on how Sun Directory Services relates to SIMS refer to the SIMS Concepts Guide and SIMS System Administration Guide. For detailed information on administration and usage, refer to the Sun Directory Services documentation.
The goal of this document is to precisely identify the format, type, and acceptable values of the directory entries used by Sun Internet Mail Server. This document has two intended audiences: engineering groups and customers who develop their own tools for populating the directory with data.
This document assumes that the reader is familiar and comfortable with installing and managing SIMS. Readers should be familiar with LDAP Directory Interchange Format (ldif(1)). It is also assumed that the reader has read and understands the following documents:
|
|
X.520 (1993) |
|
|
X.520 (1998) |
|
|
X.521 (1993) |
|
|
RFC 2256 |
|
|
http://www.ietf.org/Internet-drafts/draft-smith-ldap-inetorgperson-00.txt |
A producer is defined as any software component that can create, or subsequently modify a value for an attribute in an object class. A consumer is defined as any software component that retrieves and uses attributes in the process of accomplishing some task.
The following sections defining the LDAP mail schema specify the producer(s) and consumer(s) of each of the attributes. Here, an Internet mail system is subdivided into the following components:
Message Transfer Agent (mta) - Communicates through Simple Mail Transfer Protocol [SMTP] and is responsible for either routing mail to another MTA or delivering the message into a mailbox.
Message Store / Message Access agent (msma) - Responsible for supporting access by email client software to a user's mail folders. This component may be:
|
|
a traditional Message Store Agent, with local storage of user's mail folders |
|
|
a proxy server between the email client and another MSMA agent |
|
|
a referral agent that returns the name of another MSMA agent to the email client |
|
|
a combination of all three of the above. |
In proxy mode, the agent can be implemented as a protocol router for POP [POP] and/or IMAP [IMAP] requests. When functioning as an end-point for mail access requests, the MSMA agent will retrieve and delete messages, and otherwise manipulate the folders belonging to the user in the message store.
client - Any software agent producing and/or consuming mail directory entries and interpreting the semantics of object class attributes as specified here. These are usually user agents acting on behalf of a non-privileged end-user, and can range from stand-alone email clients to cgi-bin scripts or Java servlets invoked by a web server in response to HTTP commands from a user's web browser.
admin - Software agents that provision the directory (creation, update of entries). This class of producer/consumer is usually acting on behalf of a privileged user (for example, a site administrator). Such agents can range from GUI stand-alone or web-based administration consoles, to character-based scripts invoking low-level LDAP commands. The heading for each of the attribute sections lists the following:
(<matching rule>, <multi-valued>, {<producer/consumer>})Where:
<matching rule> - Matching rule for this attribute. For example, cis, ces,...
<multi-valued> - Number of attributes allowed per entry. For example, 1, 0-1, 0-many, ...
<producer/consumer> - A comma-separated list of the producers and/or consumers of this attribute from the list of Internet mail system components above.
Structural object classes are used to define nodes in the directory. Auxiliary object classes can be used to extend the set of attributes that a directory entry might contain. The data model used by SIMS is to extend entries, defined by standard object classes, by overlaying them with service-specific auxiliary object classes.
The shared auxiliary object classes hold a minimum of attributes and can be used to define generic entries in the directory (for example, inetSubscriber is used to define a basic user entry). Service-specific attributes are encapsulated in the auxiliary object classes. To enable a user/subscriber to start using a service or to enable a host object to hold service-specific attributes, these auxiliary object classes are used to extend the generic entries.
The sections that follow define the object classes used to define the directory entries (user, groups, hosted domains, host objects, and so on) and the specifications of the attributes in these object classes.
The role of a directory service is to support the storage and retrieval of data. Visualize the entries in an LDAP directory as a tree-like structure. This mirrors the tree model used by most file systems and is referred to as the directory information tree (DIT).
Just as a file path uniquely identifies a file within a file system, a directory entry is uniquely identified within the DIT using a distinguished name (DN). A DN identifies the entry with a comma-separated list of attribute and attribute value pair. The DN's left-most attribute-value pair is known as the relative distinguished name (RDN).
Following the RDN, each successive attribute-value pair is the RDN of the next parent node in the DIT hierarchy, each one representing a potential branch point above the entry. The final, or right-most, attribute-value pair represents the conceptual root point of the DIT.
SIMS 4.0 allows the data to be represented in two ways in the directory. The recommended approach is to have a single domain component tree (DC tree) that contains all the data used by their services: users, distribution lists, hosted domains entries, and so on. Starting with this release of SIMS, DC tree deployments will be recommended and the installer will always create the DC tree for all new installs.
For sites that need to maintain compatibility the OSI style tree, or that don't want to migrate the directory of SIMS 3.0 to conform with the recommended DIT, an alternate data layout is supported. This alternate layout uses a combination of primary and secondary tree.
The primary tree is the repository of all users and distribution list data and is patterned after an OSI DIT.
The secondary tree is a Domain Component tree (DC tree) that mirrors the DNS hierarchy. The secondary tree also holds the virtual domains, because domain data logically belongs in the DC tree.
The DC tree provides the mapping from the DNS namespace to the primary namespace where all users and distribution lists are defined. This mapping is used by message transfer agents for building routing tables and in making message routing decisions; it is also used by the IMAP/POP servers when authenticating users.
The root entry of the DIT is defined by the suffix value of the directory server. Therefore, the LDAP directory server will have to support multiple suffixes for multiple DITs to be created. Sun Directory Server and Netscape Directory Server support multiple DITs.
OSI trees with a shadow DC tree are deprecated with an eye towards discontinuing support for such deployments in the future.
As noted, SIMS 4.0 supports user/distribution list data in a DC tree or a combination of DC and OSI trees. Examples using both are shown below.
The recommended approach for setting up the directory information tree in a directory server is to create all entries that SIMS depends on in a tree that is patterned after a domain component tree. The tree should be rooted at o=Internet. Configure the directory server with this suffix.
All nodes directly below o=internet correspond to the top-level domains in the DNS namespace. For example, some of the nodes below the root would be dc=com,o=internet; dc=fr,o=internet; dc=edu,o=internet; and so on.
These top-level nodes that correspond to the top-level domains contain the node for organizations. Examples of these are dc=sun,dc=com,o=internet and dc=sfr,dc=fr,o=internet. DNS domains within an organization's top level DNS domain are represented by corresponding containers of the format dc=<sub_domain>,dc=sun,dc=com,o=internet. Each node representing the organization or sub-domain in the organization is required to have the following organizational units:
|
|
organizational unit: people - User entries are defined so that they are contained within the people organizational unit. |
|
|
organizational unit: groups - Distribution list entries are defined so that they are contained within the groups organizational unit. |
|
|
organizational unit: services - Entries for services are contained within the services organizational unit. |
In the figure below, the DN for a user entry in engineering organizational unit will have a suffix of ou=people,dc=engineering,dc=sun,dc=com,o=internet, preceded by the entry's RDN. For example:
cn=John Doe,ou=people,dc=engineering,dc=sun,dc=com,o=internet.
Each containers -- o=internet; dc=<top_level_dns_domain>,o=internet; dc=<dns_suffix_for_org>, dc=<top_level_dns_domain>,o=internet -- and then the organizational units people, groups, and services are directory entries themselves and are made up of the following object classes.
DN OF NODE IN DIT
o=internet
The directory entry for the root node is represented by the following LDIF:
The directory entry for the second level node is represented by the following LDIF:
The directory entry for the third level node is represented by the following LDIF:
The directory entry for people container is represented by the following LDIF (groups and services follow the same format).
You can add additional attributes to the above nodes, especially to the nodes defined with the inetDomain object class. Attributes of the inetDomain and SimsDomain object classes are used to set the various properties of a virtual domain.
The primary tree is patterned after an OSI tree and is rooted at c=<country-name>. Therefore, the suffix for the primary tree is set to c=<country_name>. The nodes in bold correspond to a site's organization structure. Each node in the DIT that corresponds to a valid DNS domain or sub-domain in the organization is required to have the following organization units:
|
|
organizational unit: people |
|
|
organizational unit: groups |
|
|
organizational unit: services |
User entries are defined so that they are contained within the people organizational unit. Distribution list entries are defined so that they are contained within the groups organizational unit. Service state is located within the services organizational unit.
In FIGURE 3-1, the DN for a user entry in the engineering organizational unit will have a suffix of ou=people,ou=engineering,o=sun.com,c=us, preceded by the entry's RDN.
Each container is a directory entry and is defined by the organizationalUnit object class. The directory entry for people container is shown below (groups and services follow the same format).
In the illustration above, the root of the DIT is defined by the suffix c=us. This directory entry is defined by country object class. The directory entry for the root entry is shown below.
Second level nodes correspond to the organizations contained in the directory server and are defined by organization object class. An example of the entry for a second level node is shown below.
The organization nodes are followed by entries for the containers for people (ou=people), groups (ou=groups), and services (ou=services) as described earlier. Organizations that have divisions and subdivisions (for example, engineering and marketing) should represent their organizational hierarchy by creating containers for each division and subdivision. These containers are defined by the organization object class. An example of the entry for a division is shown below.
Note - Each node for an organization or a division that can hold users and groups must have the three containers for people, groups, and services.
The secondary tree provides the mapping from DNS name space to the OSI name space and follows the recommendations of RFC 1279, section 11. The tree is rooted at o=internet and is structured exactly the same way as if the domain component tree was the primary tree--with one major difference. When the DC tree is not the primary tree, the attribute inetlabeledURI in the nodes created with inetDomain is set to point to the DN of the OSI tree containing the users and groups for that DNS domain (for example, ldap:///ou=engineering,o=sun.com,c=us??sub).
Each node corresponding to a DNS domain is created with the following object classes -- top, domain, inetDomain, and simsDomain. For example, the directory entry for the eng.sun.com domain is shown below.
FIGURE 3-2 SIMS Domain Component (Secondary) Directory Information Tree
Note - It is important that the associations between the domain component tree (secondary) and the OSI tree (primary) be set up for applications to search for users and groups within a given DNS domain
FIGURE 3-2 shows that the node dc=eng,dc=Sun,dc=com,o=Internet points to the DN ou=engineering,o=sun.com,c=us. SIMS looks for users in the eng.sun.com DNS domain in the sub-tree ou=People,ou=engineering,o=sun.com,c=us.
Clients of the directory should use the inetTreeStyle attribute of inetDomain object class to determine whether the users, groups, and services are under the DC tree (inetTreeStyle=DC) or under the OSI tree (inetTreeStyle=OSI). When inetTreeStyle=OSI, value of inetlabeledURI is used to determine the DN in the OSI tree that holds the user entries.
The description of the attributes includes, among other things, the syntax of the attribute. This syntax is a directive to the Directory Service Agent (DSA). The possible syntaxes are:
|
|
dn - A string distinguished name (as defined in rfc1779). |
|
|
cis - A case ignore string. |
|
|
ces - A case exact string (case is significant during comparisons). |
|
|
bin - A binary value. |
|
|
tel - A string telephone number (blanks and dashes are ignored during comparisons) |
|
|
utctime - UTC time stamp in the following format YYMMDDHHMMSS. |
|
|
protected - An encrypted value. In Sun Directory Server 1.0 and 3.1, a value prefixed with {crypt} denotes that it has already been encrypted according to UNIX crypt. A value with no prefix is assumed to be in the clear and is crypted by the directory before it is stored. In SunDS 3.1, a value prefixed with {sunds} denotes that the value is encrypted using a MD5 hashing scheme. Attributes with protected syntax are not returned in searches unless the credentials that the client is using when binding to the directory has the access (see ACL for Sun Directory Server) over the attribute with a protected syntax. |
Attributes may appear more than once in a directory entry. For each attribute in the object attribute tables that follow the possible number of attribute values are:
|
|
1 - one and only one value |
|
|
0-1 - zero or one value |
|
|
0-many - zero or more values |
|
|
1-many - one or more values |
This is the number of values required by the schema checking process.
SIMS provides a tool -- imldifsync -- that assists in migrating users and distribution lists from NIS and NIS+ into the directory.
The sections that follow describe the object classes, associated attributes, and the directory information tree pertinent to the functioning of services provided by SIMS.
SIMS provides the following services:
|
|
ms - Sun Message Store |
|
|
ma - IMAP/POP message access |
|
|
mta - SMTP mail service |
|
|
admin - SIMS administration service |
These services, individually or in combination, provide a set of functionality pertinent to an Internet customer. These are defined below:
|
|
auth - user authentication to mailbox and directory data. |
|
|
authorization - authorization to execute a privileged command, such as delete a mailbox. |
|
|
routing - routing of messages. Includes routing to the correct mail server and to the correct channel. |
|
|
access - access control over directory objects |
Object class attributes, described in the sections below, are marked with a list of services that depend on that attribute. The format of the notation is described by the following BNF.
service
The following section describes the object classes used to define the directory information tree (DIT), mail users, and distribution lists. Some of the object classes used to create the LDAP entries used by Sun Internet Mail Server 4.0 are defined in X.500 standard or Internet Drafts. SIMS extends the capabilities of those object classes and defines new mail specific object classes and relevant attributes. These are used to overlay basic LDAP entries so that additional mail specific attributes can be stored in them.
In the following sections, all the object classes used by SIMS are described. The first section contains information about the object classes used to create the LDAP entries that make the DIT. It also contains object classes used to make a domain object a virtual domain. This is followed by internet mail users and internet mail groups.
Users and distribution lists are leaf nodes in the DIT. The DIT is defined by the following object classes.
|
|
country - Attributes used to describe a country. |
|
|
organization - Attributes used to describe an organization. |
|
|
organizationalUnit - Attributes used to describe an organizational unit container. Used to create the OU=People, OU=Groups, and OU=Services containers, and to create other organizational units contained in the OSI tree. |
|
|
domain - Attributes used to describe the domain component nodes of the DC tree. These nodes may be containers (domain and sub-domains) and leaf nodes (hosts). |
|
|
inetDomain - Attributes used to describe the additional properties for a hosted domain. This object class is associated with directory containers that correspond to a DNS domains. In an Internet style DIT, this object class is associated with every DC (domain component) node that represents a DNS domain. |
|
|
simsDomain - Attributes used to describe the additional properties for an email domain. This object class is associated with directory containers that correspond to a DNS domains. In an Internet style DIT, this object class is associated with every DC (domain component) node that represents a DNS domain. |
Note - Attributes listed in the "Required Attribute" tables are used either for the basic functionality of SIMS or by one or more extended services. They are not necessarily required by the schema checking process. Some attributes listed as required can be omitted, and the object will still pass the schema checking process. If the number of values for an attribute is listed as either 1 (only one value) or 1-many (one or more values), then the attribute is required for the object to pass schema checking. If the number of values for an attribute is listed as either 0-1 (zero or one value) or 0-many (zero or more values), then the attribute is not required for the object to pass schema checking.
Optional attributes are not used by SIMS, or are for informational purposes only.
The country object class is used to define the country node. This is also the root node of the OSI tree. The country object class is defined as follows.
TABLE 3-1 shows the required country atributes.
TABLE 3-1 Required country Attributes Attribute
Description
countryName
(cis, 1, {}) 2-character country code. Defines the root node of the OSI tree.
TABLE 3-2 shows the optional country atributes.
The organization object class is used to create the second level nodes in the DIT. Used with domainRelatedObject object class. The object class is defined as follows.
TABLE 3-3 shows the required organization atributes.
TABLE 3-3 Required organization Attributes Attribute
Description
organizationName
(cis, 0 - many, { }) Name of the organization associated with this group.
TABLE 3-4 shows the optional organization atributes.
The organizationalUnit object class is used to create the container entries of the primary DIT. These entries are the organizational unit (ou) containers corresponding to an OSI tree based on geography (east, west, UK, Russia, and so on) or functional units (engineering, marketing, and so on). The ou entry is created using the organizationalUnit object class. Each organization unit is required to have three more ou entries -- people, groups, and services. The object class is defined as follows.
TABLE 3-5 shows the required organizationalUnit atributes.
TABLE 3-6 shows the optional organizationalUnit atributes.
The domain object class is used to create all the container entries (except for the root entry) in the Domain Component (DC) tree. These entries are the domain component representing DNS domains. The object class is defined as follows.
teletexTerminalIdentifier $ telexNumber $ userPassword $x121Address))
TABLE 3-7 shows the required domain atributes.
TABLE 3-8 shows the optional domain atributes.
The inetDomain object class is used to create those entries in the DC tree that correspond to a DNS domain. This object class is overlayed on nodes created with domain object class. The DC entry is created by using domain object classes. The object class is defined as follows.
TABLE 3-9 shows the required inetDomain attributes.
|
|
inetLabeledURI |
<ldapurl> ::= "ldap://" [<hostport>] "/" <dn> ["?" <attributes> ["?" <scope> "?" <filter>
<hostport> ::= <hostname> [":" <portnumber>]
<dn> ::= distinguished name (string) as defined in RFC 1779
<attributes> ::= NULL | <attributelist>
<attributelist> ::= <attributetype> | <attributetype> ["," <attributelist>
<attributetype> ::= a string as defined in RFC1777
<scope> ::= "base" | "one" | "sub"
<filter> ::= a string as defined in RFC1558
The simsDomain object class is used to create entries in the DC tree that correspond to a DNS domain. The DC entry is created by using domain, inetDomain, and simsDomain object classes. The object class is defined as follows.
TABLE 3-10 shows the required simsDomain attributes.
A user, including a SIMS email user, is represented by an entry in the directory. A user entry is extensible (as are all other directory entries) and may contain additional object classes/attributes once such schema extensions have been made in the directory. Take care to ensure that semantics of existing object classes are not changed by a schema extension.
An entry that stores user information for an email user consists of attributes drawn from -- at a minimum -- the following directory object classes.
The keyword in parentheses following the name of the object class, indicates whether the object class is standard, shared (by various services that use the directory data), or service-specific. If it is service-specific, the keyword is followed by the name of the service.
|
|
top (standard) - Attributes for describing the classifications of a directory object. This is a structural object class and all other object classes inherit from this base class. |
|
|
person (standard) - Attributes for describing a person. Inherits from top. |
|
|
organizationalPerson (standard) - Attributes for describing a person belonging to an organization. Inherits from person. |
|
|
inetOrgPerson (proposed standard) - Same as organizationalPerson and also one that interacts with the Internet. Inherits from organizationalPerson. |
|
|
inetSubscriber (shared; auxiliary) - Attributes for describing a basic Sun Internet Services user. This is an auxiliary object class. All users who are provisioned for email, Web, ftp, and so on, are described using this object class and a combination of one or more service-specific auxiliary object classes. The inetSubscriber object class is an auxiliary class shared by several Sun products. It requires an inetOrgPerson structural object class, because a number of auxiliary object classes depend on attributes from inetOrgPerson. |
|
|
IinetMailUser (service specific; SIMS; auxiliary) - Attributes for describing an email user. This is an auxiliary object class and is required for defining an email user. The inetMailUser object class, in conjunction with the auxiliary object classes inetSubscriber, inetMailRouting, and the structural object class inetOrgPerson, will be present in the LDAP directory entries for all users who will receive, send, or read Internet email. Internet email clients and servers should use this object class to store and retrieve information related to storage of incoming email and sending of outbound email. All email users must have this object class. |
|
|
imCalendarUser (service specific; SICS, auxiliary) - Attributes for describing a calendar subscriber. This is an auxiliary class and is required for defining users of Sun Internet Calendar Server. |
|
|
inetAdministrator (shared; auxiliary) - Attributes for describing an administrator for SIMS. |
|
|
inetMailRouting (service specific; SIMS; auxiliary) - Attributes containing the required routing information common to all Internet email recipients. |
|
|
inetMailGroup (service specific; SIMS; auxiliary) - Attributes that are key to determining how the mail is processed by the MTAs. Additionally, the inetMailRouting object class determines how messages are routed through the mail system. |
A detailed explanation of the attributes in this object class (including the valid range of values for the attribute, the effect on the behavior of SIMS as a result of changing the value, and the syntax for the attribute), follows the definition of the object class. The attribute list can have:
|
|
Required attributes that are used either for the basic functionality of SIMS (that is, required for the components to function) or by one or more service when extended features of these products are used. |
|
|
Reserved attributes reserved for future use by SIMS and should not be used by the end user for other purposes. |
|
|
Optional attributes that are not used nor planned to be used by SIMS. |
Attribute names are followed by -- within parenthesis -- attribute syntax and list of services that depend on the attribute.
The following attributes are used in this specification but are defined in other specifications: uid, userPassword, givenName, commonName, and surname.
|
|
uid (cis, 1, {client, msma, admin}) attribute - The name, unique within a domain, used by a subscriber to log in to a computer system. The uid attribute must be used to authenticate to the email message access service before the user may read messages in their mailbox(es). |
|
|
userPassword (cis, 1, {client, msma, admin}) attribute - The password used by the subscriber to authenticate to a server for access to a particular service. |
|
|
givenName (ces, 0-many, {admin}) attribute - Used to hold the part of a person's name which is not their surname or middle name. |
|
|
surname (ces, 0-1, {admin}) attribute - Used to hold a person's last, or family, name. |
|
|
commonName (ces, 0-many, {admin}) attribute - Used to hold the concatenation of a person's first and last (or family) name. In the directory the commonName of a person is a naming attribute. Because names are not always unique, provisioning software may optionally transform a non-unique commonName into a name that is unique within a domain; it may do this by further concatenating the value of the uid attribute to the default commonName value, and then using that now-unique value as the naming attribute. This is acceptable because the commonName attribute is defined as multi-valued. |
The top object class is the base class for all other structural object classes used by Sun Internet Services. The object class is defined as follows.
TABLE 3-11 describes the required attributes for the top object class.
|
(OID -- 2.5.6.6
NAME 'person'
STRUCTURAL
SUPERIOR 'top'
MUST (
surname $ commonname
)
MAY (
description $ seeAlso $ telephoneNumber $ userPassword
)
)
|
TABLE 3-12 shows the required person attributes.
TABLE 3-13 shows the optional person attributes.
Attributes for describing a person belonging to an organization.)
TABLE 3-14 describes the organizationalperson attributes.
Attributes use to describe a person using Internet services.
TABLE 3-15 shows the optional inetOrgPerson attributes.
inetSubscriber Object Class
The inetSubscriber object class is an auxiliary object class used to define an Internet subscriber. SIMS uses this object class along with inetMailRouting and inetMailUser to define an email user. The is object class defined as follows:
TABLE 3-16 shows the optional inetSubscriber attributes.
inetMailUser Object Class
This auxiliary object class is used to overlay LDAP entries defined by inetOrgPerson, and it allows that user to receive and send email. Two other auxiliary object classes are used along with inetMailUser for a user to become a SIMS user: inetMailRouting and inetSubscriber.
The inetMailUser object class is defined as follows:
TABLE 3-17 shows the optional inetMailUser: Membership attributes.
The inetAdministrator object class is used to tag inetSubscribers who have administrative capabilities. The object class name itself serves as the tag, and the inetAdministeredServices attribute is used to identify the type of service and the management scope for when administrative privileges are granted.
TABLE 3-18 shows the optional inetAdministrator attributes.
Use the imCalendarUser object class to define the calendar server attributes for an inetSubscriber. Use in conjunction with inetorgperson and inetSubscriber.
This object class promotes uid (alias userid) and userPassword to required attributes. These attributes are previously defined in inetOrgPerson and person object classes respectively.
TABLE 3-19 shows the required imCalendarUser attributes.
TABLE 3-20 shows the optional imCalendarUser attributes.
Distribution lists are of groups of users and groups to which message can be sent. An email distribution list is represented by an entry in the directory. An entry, which stores distribution list information, consists of attributes drawn from these object classes:
|
|
groupOfUniqueNames - Attributes for describing a collection of user objects. Inherits from top and is a structural object class. All SIMS email distribution lists are provisioned using this object class and the auxiliary object classes inetMailRouting and inetMailGroup. |
|
|
inetMailGroup - Attributes for describing an email distribution list. All distribution lists are provisioned using auxiliary object classes and is required for defining a SIMS distribution list. |
A distribution lists entry is extensible and may contain attributes from additional object classes once such object classes have been defined in the directory schema.
URL for Attributes Containing Addresses
Several inetMailGroup attributes contain either RFC-822 style mail addresses or distinguished names (DN) of LDAP entries. This is permitted because inetMailGroup is both an LDAP and email entity, and it is appropriate to allow both types of addresses. The attributes errorsTo, moderator, authorizedSubmitter, unauthorizedSubmitter, use URL's [URL] to allow this dual use. When preceded by ldap:/// the entry is used as an LDAP entry with the remaining value treated as the distinguished name of the entry. When preceded by mailto: the entry is interpreted as an RFC-822 address.
A missing prefix of ldap:/// or mailto: for the entry is assumed to be an RFC-822 address.
The URL has the form:
ldap:///[<server>[:<port>]]/<baseDN>?[<attrs>]?<scope>?<filter>
|
|
attrs is not applicable for this use and is ignored. |
|
|
Default value for server:port is the LDAP server being used by the MTA. |
|
|
The baseDN specifies the base for the search; if not present, the default is the baseDN used by the MTA. |
|
|
scope defines levels of the directory tree to be searched relative to the specified search base; its default value is base. |
|
|
The default for filter is (mail=*), because you want to include only entities in the distribution list that can accept mail. |
The groupOfUniqueNames object class contains attributes for describing a collection of directory entries (namely users and other groups). This object class inherits from top and is a structural object class. This structural class is used along with inetMailGroup and inetMailRouting to provision Sun Internet Mail Server distribution lists.
TABLE 3-21 shows the required groupOfUniqueNames attributes.
TABLE 3-22 shows the optional groupOfUniqueNames attributes.
The inetMailGroup object class contains attributes useful for describing an email distribution list. SIMS requires this object class for defining a distribution list. All distribution lists are provisioned using this auxiliary object class, the inetMailRouting auxiliary object class, and the structural object class groupOfUniqueNames. These object classes are overlayed on entries created with the groupofUniqueNames object class. This object class is defined as follows.
|
( 1.3.6.1.4.1.42.2.27.2.2.2
NAME 'inetMailGroup'
SUP top
AUXILIARY
MUST (
inetMailGroupVersion
)
MAY (
errorsTo $ joinable $ moderator $ multiLineDescription $
requestsTo $ seeAlso $ suppressEmailError $ userPassword $
authorizedDomain $ authorizedSubmitter $ dataSource $
inetGroupStatus $ expandable $ mailDeliveryFile $
mailDeliveryOption $ mailProgramDeliveryInfo $
rfc822Mailmember $
unauthorizedDomain $ unauthorizedSubmitter $ membershipFilter
)
)
|
The inetMailGroup object class attributes are grouped into the following categories.
Mail Processing Attributes
Several inetMailGroup attributes are key to determining how the mail is processed by the MTAs. Additionally, inetMailRouting determines how messages are routed through the mail system. One attribute indicates the version of the object class itself.
TABLE 3-23 shows the required inetMailGroup attributes.
TABLE 3-24 shows the optional inetMailGroup attributes.
Mail List Administration Attributes
The following defines the distribution lists attributes used by administration programs.
TABLE 3-25 shows the optional inetMailGroup: Mail List Administration attributes.
Mail Restriction Attributes
Several inetMailGroup attributes are key to determining who can submit messages to the distribution list. This proposal allows restrictions based on domains and addresses. One may call out the list of authorized domains/submitters or unauthorized domains/submitters.
Attributes that restrict who can submit messages to the list fall in two categories:
|
|
authorized - Users/domains who are explicitly allowed to submit messages to the distribution list. |
|
|
unauthorized - Users/domains who are explicitly disallowed to submit messages to the distribution list. |
Additionally, by specifying a moderator, the MTA can be directed to deliver submitted messages only to the moderators, unless the message is submitted by one of the moderators, in which case it is delivered to all distribution list members.
A distribution list that does not have authorizedDomain, unauthorizedDomain, authorizedSubmitter, and unauthorizedSubmitter attributes in the LDAP entry for the distribution list is treated as an unrestricted list and anybody can submit messages to this list.
If any of the authorizedDomain, unauthorizedDomain, authorizedSubmitter, and unauthorizedSubmitter attributes appear in the distribution list LDAP entry, the list is considered a restricted distribution list.
The following precedence rules are followed by the MTA when deciding whether it should accept the message for further processing or not (From: address is used in all the rules when looking for match):
|
|
if unauthorizedDomain exists in the LDAP entry, then sender's domain must not match the domain(s) listed in the unauthorizedDomain attribute. |
|
|
if authorizedDomain attribute exists in the LDAP entry, then sender's domain must match the domain(s) listed in the authorizedDomain attribute. |
|
|
if unauthorizedSubmitter attribute exists in the LDAP entry, the sender's address must not match either the mail attribute or rfc822MailAlias attribute of any DN listed in the form of an ldap:///<DN> address and must not match the RFC-822 address listed in the form of a mailto:<RFC-822> address. |
|
|
if authorizedSubmitter attribute exists in the LDAP entry, the sender's address must match either the mail attribute or rfc822MailAlias attribute of any DN listed in the form of an ldap:///<DN> address and must not match the RFC-822 address listed in the form of a mailto:<RFC-822> address. |
TABLE 3-26 shows the optional inetMailGroup: Mail Restriction attributes.
Membership Attributes
Several inetMailGroup attributes are key to determining who can submit messages to the distribution list. This proposal allows restrictions based on domains and addresses. One may call out the list of authorized domains/submitters or unauthorized domains/submitters. Additionally, the distribution list may be marked as moderated by specifying a moderator for the distribution list.
The members of an alias or distribution list are made up of the union of the users specified in the uniqueMember attribute of the groupOfUniqueNames object class as well as the rfc822MailMember and membershipFilter attributes of the inetMailGroup object class.
TABLE 3-27 shows the optional inetMailGroup: Membership attributes.
To avoid duplicating information, the inetMailRouting object class contains the required routing information common to all Internet email recipients. This class is required for entries describing either email users (inetMailUser) or email groups (inetMailGroup).
Note the distinction between a relay Message Transfer Agent (MTA) that relays a message and a destination MTA responsible for the final delivery of a message. A relaying MTA only needs to examine the mailHost attribute to determine the destination MTA. A destination MTA examines the mail and rfc822MailAlias attributes to determine the INBOX to which the message should be delivered.
The inetMailRouting object class is used to describe the mail sorting properties of mail recipients. This is used for both user and distribution lists. The object class is defined as follows.
TABLE 3-28 shows the required inetMailGroupRouting attributes.
SIMS services are represented in the directory by a entry defined with an inetService object class.
The algorithm for determining the distinguished name of this entry is to begin with an empty distinguished name (DN) and then attach Relative Distinguished Names (RDN) for each component of the domain, most significant first. Each of these RDNs is a single AttributeTypeAndValue, where the type is the attribute DC and the value is an IA5 string containing the domain name component. Finally, the DN gets the root suffix of the DC tree as a suffix. For example, if the root suffix of the DC tree is o=internet and the fully qualified DNS name of the mail server is mail.isp.net, the DN of the entry is dc=mail,dc=isp,dc=net,o=internet.
|
|
inetService - attributes for describing a SIMS service. Entries with these attributes are created under the ou=Service container of either the DC tree or OSI tree. The naming attribute of an inetService node is the version of the service. |
The inetService object class is used to represent state information for and about specific services. There may also be service entries under the Service subnode of any SIMS domain node.
The naming attribute for this object class is inetVersion. Nodes created with this object class are defined under the ou=<service_tag>,ou=Service, container of the domain node.
The following service_tag values are supported in this release:
|
|
imta - Message Transfer Agent service |
|
|
msma - Message Access and message store |
|
|
admin - Administrative server |
|
|
spm - Security Policy Manager |
|
|
provisioning - Subscriber provisioning |
|
|
SUNWftp - File Transfer Protocol |
|
|
SUNWsws - Sun Web Server |
|
(OID -- TBD
NAME 'inetService'
SUPERIOR 'top'
STRUCTURAL
MUST (
commonname $ inetVersion
)
MAY (
inetPrivateData $ mail $ userPassword
)
)
|
TABLE 3-29 shows the required inetService attributes.