The DC tree domain entry is found using an LDAP lookup. Messaging Server lookup code builds the DN needed for the lookup using the domain specified to the right of the separator (@) in the email address. For Calendar Server the DN is created from the domain name in the fully qualified unique identifier, uid. Once retrieved, the entry is processed as described in How Alias Domains Are Handled In Schema Version 1 Mode.
For Messaging Server, if the original search did not find a match in the DC tree, the DOMAIN_UPLEVEL option can be used to search a domain from one level higher in the tree. You must set this option to a value of either 1 or 3 to enable uplevel searches. The default is for this feature to be turned off.
For more information on this option, see the Sun Java System Messaging Server 6.3 Administration Guide.
This mode implements the Access Manager model, with all domain nodes residing directly below the root node. Messaging Server and Calendar Server retrieve the correct LDAP domain entry using a search template. The system compares each node with the search criteria until it finds the correct domain. All domains are treated as if they were at the same level. There is no hierarchical structure for retrieval. once retrieved, the entry is processed as described in How Alias Domains are Handled in Schema Version 2 Native Mode.
Search queries are constructed using templates as with native mode, but the LDAP entry retrieved is in the DC tree. Once retrieved, the domain LDAP entry is processed as if it were Schema version 1 mode. For more information, see How Alias Domains are Handled in Schema Version 2 Compatibility Mode.
While earlier Calendar Server versions supported multiple domains, it was optional. In a non-domain environment, all user and group records are located directly under the root, with no domain node present. However, starting with Calendar Server 6.3, the system default is for multiple domains. That is, the system assumes at least one domain below the root for all schema modes.