CHAPTER 6 |
Domain Hosting with SIMS |
Service providers expect to be able to host a large number of email services for different organizations. These businesses have recognized that the ability to allocate their email services to the SPs would save time and cost for their organizations.
In observing the need of the SPs, SIMS 4.0 provides email services that enable multiple organizations to have their own virtual domain.
This chapter describes the SIMS domain hosting feature components and specifications.
Topics in this chapter include:
|
|
What is domain hosting? |
|
|
Domain hosting components |
|
|
Domain hosting authentication |
|
|
Domain hosting restrictions |
The service provider Bridge Corporation provides email services to the Stream company, which does not wish to manage its own Internet domain, stream.com (although it owns the domain name). Stream is dependent on bridge.net to supply email services to the stream.com domain. Although the mail server for all email users in the stream.com domain is <mailhost>.bridge.net, a user sends and receives mail as <user>@stream.com instead. That is, bridge.net does not appear in their email addresses.
SIMS 4.0 supports the ability to define such domains in the directory and host them on a shared mail server. This concept is referred to as domain hosting. It is also referred to as virtual hosting in Chapter 4, "Deployment Scenarios." FIGURE 6-1 shows a typical domain hosting configuration. Notice that the message stores are presented logically.
SIMS domain hosting capabilities comprise the following components:
|
|
Delegated Management Console |
|
|
Domain Management server |
|
|
Delegated administrator |
|
|
LDAP directory |
See Chapter 4, "Deployment Scenarios," for detailed information on the case study used in the examples in this chapter.
See Chapter 5, "SIMS Architecture," for an overall picture of all components that comprise SIMS architecture, including domain hosting components.
See Chapter 11, "Delegated Management Administration," for summaries of tools that different types of administrators could use to perform domain hosting administrative tasks.
The Delegated Management Console is a set of HTML forms and CGI programs that delegated administrators may use to perform management tasks. The delegated administrator submits requests from its browser through HTML forms. The Delegated Management Console component translates the delegated administrator's request into the Delegated Management server. The Delegated Management server returns values to the Delegated Management Console component, which, in turn, interprets server's responses and dynamically generates HTML forms from them.
See the Sun Internet Mail Server Delegated Management Guide for more information on the Delegated Management Console.
The Delegated Management server is an RPC server that provides directory services to the Delegated Management Console. Once it has interpreted a request from the console, it performs the necessary access control checking. If the access controls are positive, it then relays the request to the Directory Services and relays the directory's response back to the console. If the access controls are negative, it generates a negative response to the Delegated Management Console.
The delegated administrator is the administrator at the hosted domain site who is dedicated to managing these hosted domains.
See Chapter 11, "Delegated Management Administration," for summaries of tools that different types of administrators could use to perform domain hosting administration tasks.
See the Sun Internet Mail Server Delegated Management Guide for more information on different tasks that the delegated administrator can perform using the Delegated Management Console.
LDAP Directory is the master repository of all the information related to hosted domains.
None of the other SIMS components store permanent hosted domain information. That is, the message access server retrieves the necessary information to associate a client with a domain. Similarly, the IMTA retrieves hosted domain information to perform proper routing and address rewriting.
Each user must have a unique user ID within a hosted domain that they will use within the mail system. Although externally, user smith at Stream would receive his email at smith@stream.com, he would log in to POP3/IMAP4 using his user ID, smith, and domain name, stream.com. This method of logging in is very typical of how SPs set up the mail systems.
These user IDs are mapped to and from the user@host.com entries by the IMTA from the information stored in the directory.
All of SIMS components rely on unique user names that are used by the message store as the mailbox directory name and by the IMTA as keys in its alias database.
SIMS 4.0 uses the LDAP user attribute uid as the unique name. Besides being a unique key, uid also defines the IMAP/POP login name. Although this works in an environment where uid is guaranteed to be unique within the entire mail server, it is not the case with hosted domains, where uniqueness of the mail user names is enforced on a per-domain basis (one can have the same uid smith in both stream.com and in ocean.com), and a single server can host several domains.
To address this need, SIMS 4.0 uses a combination of the uid and the DNS domain name of the user to guarantee uniqueness.
A delegated administrator is not able to grant administrator-level rights to another user in its domain. It has to be done by the SIMS administrator at the SP site.
SIMS 4.0 requires that all delegated administrators have the same rights. It is not possible for the SIMS administrator to give different permissions to delegated administrators. The SIMS administrator can, however, assign multiple delegated administrators to perform different tasks. For example, some delegated administrators could be responsible for changing passwords while others can change user information. All delegated administrators will be able to make changes to all of these fields.
End-users can not browse the directory through the delegated admin interface.