A proxy message access server differs from a regular SIMS server in that instead of serving the POP/IMAP requests itself, it forwards the request to the message access server with the requested mail folders (FIGURE A-1). The proxy may or may not have a local message store, but it acts as a virtual message access server by forwarding POP/IMAP requests to the appropriate message store. Message access proxies are useful for a number of reasons such as horizontal scalability and internet access to private intranet mail systems. These are discussed in "Proxy Server Models" on page 303.
Proxies accept client POP/IMAP requests for mailbox access and authenticate requestor's passwords. The proxy's mail access daemon (imaccessd) forwards the request to the appropriate mail access server (i.e., the server containing the desired mailbox). The requestor is again authenticated by the mail access server where the mailbox resides. At this point, the proxy acts as a simple pipe between the client and the mail server, forwarding whatever one sends to the other, until either the client or the server closes the connection.
Although a proxy server may not have the requested message store, from the client's point of view, the proxy acts like the real mail access server. Because the proxy communicates with the requested mail server using POP/IMAP, from the requested mail access server's point of view the proxy appears as another mail client.
SIMS message access proxies have two configurations, a pure proxy, which acts only as a proxy for SIMS mail servers, and a message access proxy/message access server which can act as a proxy for some mail addresses and as a full mail server for local addresses. An example of these is shown in FIGURE A-1.
FIGURE A-1 Pure Proxy Server and Mail Access Proxy+Mail Access Server
Proxy servers are useful for a number of applications. How you deploy proxy servers depends on the configuration of your email system and what your goals are. This section describes three possible scenarios and models where proxy servers could be used.
Proxy Servers for Horizontal Scalability
Horizontal scalability is the ability to expand the capacity of a SIMS environment by adding more servers. Proxy servers make horizontal scalability possible by having clients point to a single host name which provides access to their mail. Proxies do the work of routing the protocol traffic to and from the appropriate Message Store server. Since proxies allow clients to access their mail folders through a host name which is independent of the actual message store host name, capacity can be added without any burden or reconfiguration on the clients. (For example, having to reconfigure the message access server on each client.)
You may not want to have a single SIMS server supporting the hundreds of thousands of users that Internet Service Providers (ISPs) need to support. Without proxy servers, each user would have to specify their server host name to retrieve mail. By using proxy servers, messages can be accessed through one virtual mail server, while any number of actual mail servers perform actual message storage and retrieval.
FIGURE A-2 Proxy Server in an ISP Environment
In the figure above, users log in to the system using the domain name, bridge.net. Mail requests are routed through the system and sent to a proxy via round-robin DNS (DNS that can return more than one IP address in round-robin fashion to distribute load among multiple proxy servers). The proxy authenticates the user through a replicated LDAP directory, then sends the request to the appropriate message access server. Additional capacity is achieved by adding more message access servers behind the proxies.
This deployment allows for easy expansion of capacity and, by virtue of round-robin DNS, allows proxies to be treated as field replaceable units. If bridge.net needs to expand message store capacity to accommodate new customers, they can do so either by expanding the capacity of an existing Message Store server by adding system resources, or they can add a new Message Store server. In either case, clients will not be required to change their mail server hostname setting.
Proxy Servers for the Internet Mail Access
FIGURE A-3 Proxy Server for Internet Access
In the figure above, an internet mail client accesses his mail through a proxy server on the firewall via a secure IMAP connection. The proxy authenticates the user, then forwards mail store requests to the SIMS message store server. The SIMS then sends message data to the proxy which forwards it to the mail client.
Proxy Servers for Migrating Users
As an organization grows, additional SIMS servers may be added, and users may be migrated from an old server to a new server. As users are migrated, it would be nice if they could maintain the same server domain address rather than have to adopt a new domain address.
FIGURE A-4 Proxy+Mail Server for Migrating Users
In FIGURE A-4 the top drawing shows the company's original email configuration. Users connect to a server called quackadero and access mail using the server name quackadero.com. In the bottom drawing, quackadero has been converted from a regular mail server to a message access proxy/message access server, and a new server called quasi has been added with a number users having been migrated to quasi. However, even though these users are now on quasi, they can still access their mail using the same quackadero.com domain name. quackadero provides service for users whose account it supports and forwards mail store requests for users supported by quasi.
The first step in deploying a SIMS proxy model at your site is to choose a model which will address the issues and problems you face. In this section we will describe how to deploy a pure proxy and a proxy+mail server within an organization. We will not specifically describe proxy deployment for horizontal scalability since how this is done will depend upon the platform used for the round-robin DNS which will differ from site to site.
Setting Up a Pure Proxy
In this section we will describe a generic configuration of a pure message access proxy. Details, such as where in relation to the firewall your proxy is placed or the configuration of a round-robin DNS server for a multiple proxy setup, will not be described.
Proxies need to be configured with the SIMS directory service before they can be operational. The proxy uses the directory to authenticate users and forward requests to the appropriate message store server. The proxy directory must be designated as a replicated slave to the master SIMS directory located on one of the mail servers. This is depicted in FIGURE A-5. It is possible to configure the proxy to use an LDAP server on a different machine (refer to the ims-ldap-server parameter in the sims.cnf man page), but for performance reasons, it is preferable to have a local LDAP replica on the proxy.
Note - Caution! The master and slave server must have the same replication configuration for the updates to work properly. The master and slave must also have the same schema since replication between servers with dissimilar schemas may lead to unpredictable results. Also, dsprepush must be run on the system with the master server if it is to be replicated. See the Sun Directory Services 3.1 Administration Guide.
FIGURE A-5 Pure Proxy Mail System Showing Master to Slave Directory Updates
 |
To Configure a Pure Proxy
|
This section describes how to configure a pure proxy server as a replicated LDAP directory slave server. In this example the fully qualified proxy hostname is called proxy.stream.com. The master LDAP directory server is called master.stream.com.
| |
1. |
Install SIMS on the proxy machine |
| |
2. |
Configure this system to be a proxy server. |
In our example you would bring up the Advanced Options of the Sun Message Store property book on proxy.stream.com and press the Proxy Server Button to On.
FIGURE A-6 Message Advanced Options Section (Extended View)
| |
3. |
Configure the proxy to replicate a local directory from a master LDAP server (FIGURE A-5), or specify another LDAP server to serve as the directory server for the proxy. |
Note - The Sun Directory Services documentation can be found at http://docs.sun.com:80/ab2/coll.297.1/@Ab2CollToc?subject=sysadmin. The Netscape Directory Services documentation can be found at (http://home.netscape.com/eng/server/directory/
| |
a. |
To configure thenew proxy to replicate a local directory from a master LDAP
server:
|
| |
|
The process will differ depending whether you use the Netscape or Sun Directory Server, however, the basic steps are the same. |
| |
i. |
Create naming contexts (subtrees) to be replicated.
|
| |
|
If you require OSI and DC naming contexts, create them both. OSI trees must be mapped to a DC tree refer to the schema section in the SIMS Reference Manual. |
| |
ii. |
Specify the naming contexts to be replicated slaves and designate a master
LDAP host server for the slaves.
|
| |
|
In our example, master.stream.com is designated as the LDAP master server to the LDAP slave proxy.stream.com. We'll assume we only have a DC tree and that the naming context to be replicated is dc=stream,dc=com,o=internet. |
| |
|
Refer to the directory service documentation for replication details. |
| |
b. |
To specify another LDAP server to serve as the directory server for the proxy:
|
| |
|
If you choose this configuration, the proxy will not use a local directory server, but use a directory server on another machine. See the imadmin-modify-currentldap man page. |
| |
4. |
Create a new replica from the master LDAP server. |
| |
|
Go to the master LDAP server and create a new replica of the naming context to be replicated. Specify the naming context to be replicated and the host that will act as a replicated slave. In our example, the replicated naming context is dc=stream,dc=com,o=internet and the replicated slave is proxy.stream.com. Again, if there are mirrored OSI and DC naming contexts, you'll need to create replicas for both. |
| |
5. |
Initialize the replica. |
| |
|
How this process is done will differ depending whether you are using the Netscape or Sun Directory Services. |
| |
6. |
Synchronize the replica and set synchronization schedule. |
| |
|
At this point you have set up a LDAP slave and configured its LDAP master to create a replica for the slave. You now need to synchronize the slave directory with the master directory and set up a synchronization schedule for the updates. (Refer to directory service documentation. |
| |
7. |
When synchronization occurs, the proxy is operational. |
| |
To Configure IMAP Capabilities in the Proxy
|
Note - Read this section if you are configuring a SIMS proxy with a non-SIMS back end mail server.
CAPABILITY is an IMAP command that lists commands in addition to the standard (RFC2060) commands that a given server will support. Since CAPABILITY is valid even before the client has been authenticated (capabilities can include authentication mechanisms), the proxy has no way of knowing in advance to which server the user will be connected to, and therefore can't list the capabilities supported by this server.
So, when the proxy is enabled in imaccessd, the only capabilities that will be returned to the client when capability is executed are:
* CAPABILITY IMAP4 IMAP4rev1
plus the authentication mechanisms supported by the proxy.
This means that all the remote server(s) MUST support IMAP4 and IMAP4rev1. If you have servers connected to the proxy that do not support both protocols, or, if you need to have the proxy advertise capabilities supported by the real servers, then you need to define the parameter ims-caps-proxy in
/etc/opt/SUNWmail/ims/ims.cnf that will contain these capabilities. This can also be done in the Admin Console (see "To Configure IMAP Capabilities in the Proxy" on page 310).
This parameter, if absent, is equivalent to IMAP4 IMAP4rev1. You can disable either IMAP4 or IMAP4rev1 if the back end server doesn't support both, or you can add new capabilities to the list.
One caveat: some additional capabilities include commands that are supported once the client is authenticated (example: the SCAN command in SIMS). There is no harm in advertising these in the proxy since the client can only issue them at a time the real server will receive and process them. However, for some extensions that enable a behavior of the server (such as IMAP4SUNVERSION in SIMS), it is not recommended that you add these to the list because the client could send the command before authentication is completed, and the proxy server would not forward the command to the real server.
Setting Up a Proxy+Mail Server
This section describes how to convert a SIMS mail server to a message access proxy/message access server. We will use the hypothetical example of an administrator migrating a number of users on the original SIMS mail server to a new SIMS server, and converting the original SIMS mail server to a proxy/message access server (FIGURE A-4 on page 306). The basic steps for completing these steps are as follows:
| |
1. |
Install new SIMS machine. |
| |
2. |
Convert the old SIMS machine to a proxy+mail server. |
| |
3. |
Confiure the new machine as a slave LDAP server, and configure the old machine to be a master server. |
| |
4. |
Temporarily disable mailbox accounts of users who are to be migrated and send incoming mail to the Hold Channel for temporary storage. |
| |
5. |
Using the command imbackup and imrestore, migrate the users from the old machine to the new machine. |
| |
6. |
Change the Mailhost attribute in the entries of the migrated users |
| |
7. |
Enable the disabled mailbox accounts so that they can receive mail. |
| |
8. |
Delete all the migrated accounts from the old machine. |
FIGURE A-7 Converting Mail Server to Proxy+Mail Server.
| |
To Migrate Users by Converting a Mail Server to a Proxy+Mail Server
|
| |
1. |
Install new SIMS host. |
| |
2. |
Convert the old SIMS host to a SIMS proxy+mail host. |
| |
3. |
Populate the new machine with the directory information. |
| |
|
For example, configure the new machine as an LDAP slave server and the old machine (now a proxy+mail server) as an LDAP master server. Follow the instructions described in "To Configure a Pure Proxy" on page 308. |
| |
4. |
Temporarily disable mailbox accounts of users who are to be migrated so that mail sent to these users will be put on hold until the accounts are restarted. |
| |
|
For each user and group LDAP entry to be migrated, add the value mailDeliveryOption: hold (you do not have to remove the other mailDeliveryOption values like mailbox). Run an imta dirsync to synchronize the alias table. Execute the command hold_slave to send incoming mail to the Hold Channel. (See the section on the Hold Channel in the SIMS Reference Manual and the hold_slave man page). |
| |
5. |
Migrate mailboxes from one machine to another. |
| |
a. |
Identify users to be moved to the new machine and have these users log out of
their mail clients.
|
| |
|
They must not use their mail client until after migration is complete. |
| |
b. |
Use imbackup -f bak -u username_file to backup the mailboxes to be
migrated.
|
| |
|
bak is the name of the file in which to back up the mailboxes. username_file is a file containing a list of user names to be migrated. Each name must be separated by spaces, tabs, or carriage returns. See the imbackup man page for details. |
| |
c. |
Use imrestore -t3 -f bak -u username_file to restore the backed up
mailboxes to the new SIMS machine.
|
| |
6. |
Change the Mailhost attribute in the entries of the migrated users and groups. |
| |
7. |
Enable the disabled mailbox accounts so that they can receive mail. |
| |
|
For each user and group LDAP entry migrated, remove the
mailDeliveryOption: hold value and run imta dirsync. Execute the command hold_master to deliver message in the Hold Channel to the migrated mailboxes. (See the section on the Hold Channel in the SIMS Reference Manual and the hold_master man page). |
| |
|
Proxy+mail server should be running as planned. |
| |
8. |
If the system is working, delete the migrated accounts from the old machine. |
Copyright© 1999 Sun Microsystems, Inc. All Rights Reserved.