Handling Multiple Domains and Unique Names with NIMS
Articles and Tips: tip
NIMS Product Manager
lmadsen@novell.com
07 Jun 2000
The Novell Internet Messaging Service (NIMS) is an e-mail service that is built on open standards that are in wide use today. While NIMS was originally designed for Internet Service Providers (ISPs) and Application Service Providers (ASPs), it can meet the messaging needs of any large or small organization.
As administrators and IT managers seek to implement NIMS, they have encountered a number of issues that need addressing. Many of these involve multiple domains and unique naming. This NetNote provides answers to some of the most common questions relating to these aspects of NIMS.
Supporting Multiple Domains
First, NIMS is capable of hosting multiple domains on the same physical box. This is accomplished through the configuration of the SMTP agent. You simply input the SMTP domains that you want to service in the Domains field.
With NIMS, user IDs be unique within a domain. Having two identical user IDs in the same domain would result in duplicate e-mail addresses. This may sound basic, but Novell Technical Support is asked this question quite often.
What About Unique User IDs?
Customers also ask if it is possible to have the same user ID exist in different domains. In other words, if NIMS is hosting abc.com and xyz.com, can you have a user "john" in each domain? The simple answer is yes, but this often confusing issue bears some explanation.
First, we'll look at an example of what many customers want to do but which will not work because of certain NIMS design issues. NIMS does not support the idea of "context" domains. In other words, you cannot specify a context or contexts as being equivalent to an e-mail domain and then place all of the users that belong to that domain in the appropriate context(s), as shown in Figure 1.
Figure 1: Example of non-supported "context" domains.
At first glance, it appears that supporting such a structure would be the preferred solution to the issue of non-unique user names across domains. After all, any software should be able to tell the difference between "john" in Context A and "john" in Context C. However, this approach is problematic in two areas: performance and login procedure.
Performance Considerations. Since NIMS assumes each user name is unique, it only has to "remember" the name. This makes NDS calls for locating a user ID fast and efficient. If we were to require a context along with the user name, all NIMS agents would be forced to remember the domain associated with the user and then figure out which context(s) are associated with that domain. Implementing this model would severely degrade system performance.
The NIMS engineers considered doing this for a future release of NIMS (which would have required a complete redesign of NIMS agents), but they came to the conclusion that the "convenience" could not be justified in view of the resultant performance degradation. It's a tradeoff they were not willing to make.
Login Procedure. The second issue is the login procedure. Today, NIMS has contextless login. It doesn't need to know the context since every user ID is unique. Under the model outlined above, users would somehow need to specify a context when logging in. Even if they provided the context as part of the login procedure, NIMS would still have to "remember" the domain for that user in all NIMS agents.
This brings up a number of other sticky issues. For example, how many Internet e-mail users understand the "context" issues of NDS? In a hosted services scenario, do you really want to force users to log in as .contexta.john or .contextb.john? What happens if users are moved to a different context? Context management becomes a nightmare in such a scenario.
A Better Solution
Now that you understand what doesn't work with NIMS, it will be easier to see how it is possible to host multiple domains and have the same e-mail name in one or more domains.
All releases of NIMS starting with version 2.1 support NDS User object names in Internet e-mail address format, such as john@abc.com. By allowing domains to be included in the User object name, NIMS can provide mail services to users who have the same user ID in different Internet domains. For example, john@xyz.com and john@abc.com can exist in the same container or in different containers (see Figure 2).
Figure 2: By supporting NDS user object names in Internet e-mail format, NIMS allows users with the same ID to exist in the same or different contexts.
With this structure, you can organize users in contexts alphabetically, geographically, or in other ways without respect to the domain name. This usually results in fewer NDS contexts and thus provides better overall performance.
Limitations to Keep in Mind
When implementing this scenario in NIMS, you need to be aware of a few limitations. First, users whose object names include an "@" sign must provide their full e-mail address when prompted for a login name. Also, you must add domains included in these object names to the SMTP Agent Object's "Hosting Domain(s)" list. User objects that do not include domains in their names can still be addressed at any of the domains listed in the SMTP object's traditional "Domains" list. All domains and hostnames that resolve to the IP address of an SMTP Agent should be added to one of these two lists. No domain or hostname should be added to both lists.
When creating such user objects through the NWAdmin or Webadmin utilities, you must "escape" the periods in a user name by preceding the period ( . ) with a backslash (\). For example, the user name bob@xyz.com will be entered and displayed in NWAdmin as bob@xyz\.com. (This "escaped period" feature should not be used on NetWare 4.x, as users with periods in their names will not be able to log in.)
Netscape Communicator's POP clients cannot be used with these users because these clients currently strip "@" signs and trailing characters from user login names. Netscape Communicator (Messenger) will work with these users in IMAP mode only. However, the users names must be manually added in Preferences because the User Profile wizard strips the "@" sign as well.
If NIMS is used with Novell's BorderManager Authentication Services (BMAS), you must create Alias objects for User objects containing an @ sign (this is due to current limitations in BMAS).
Because Finger clients strip off the domain, only users that do not have an @ sign in their names can be fingered. All other mail services are available to these users.
Of course there is always the Aliasing Agent method, whereby each user has a unique NDS ID (john, johnj, johnc, and so on) and the e-mail addresses john@abc.com, john@xyz.com and john@isp.com are "aliased" to the corresponding NDS ID.
Hopefully this explanation clears up most of the confusion that may exist with the handling of multiple domains and unique IDs with NIMS.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.