 Understanding gateways
A gateway is a bridge between your system and another device or system. FirstClass supports several types of gateways:
• server-to-server gateways
• gateways to other email systems
• outbound gateways
• inbound gateways.
Gateways are configured from the Gateways and Services folder on the administrator’s Desktop. There are a number of third-party gateways supporting other systems and hardware. This document explains how to configure a server-to-server gateway. Information on configuring other gateway types will be found in the documentation accompanying those products.
Server-to-server gateways
Server-to-server gateways connect multiple FirstClass servers and FirstClass servers with FirstClass add-on modules, like Internet Services and Voice Services. Using server-to-server gateways, you can set up a large, integrated mail and conferencing network supporting conference replication, Directory synchronization, and multi-hop delivery. Your FirstClass server has built-in server-to-server gateway software.
The main reason for setting up a server-to-server gateway is so users on one server can communicate with users on another. Although the users could connect to the remote server by having a user account on that remote server, it is much more efficient to have users always connect to their local server, and have the servers handle the message exchange. If your users have Internet access, sending messages directly to the receiver’s email address is the easiest option.
Gateways to other email systems
Gateways to other email systems connect your FirstClass server to other mail systems such as Microsoft Mail, and cc:Mail.
Outbound gateways
Outbound gateways allow users to send messages out, but not to receive incoming messages. Fax gateways, pager gateways, and printer gateways are examples of outbound gateways.
Inbound gateways
Inbound gateways accept messages from the remote system, but do not allow your users to send replies. Newswire gateways and gateways that retrieve satellite weather map pictures are examples of inbound gateways.
About conference replication
In addition to allowing you to exchange private mail between servers, gateways also allow you to replicate conferences. This means that a complete copy of a conference with all its contents can be seen and used on both servers. Any messages posted to the conference on the local server are replicated in the conference on the remote server, and vice versa.
 NoteDeletions are not synchronized between replicated conferences. Only new and existing items are replicated. Therefore, if a message in a conference must be deleted on all servers, the administrator of the server where the message was deleted must contact the administrators of all systems where the replicated conference exists and tell them to also delete the message.
Conference replication requires coordination between the FirstClass administrators on all servers on which the conference is to be replicated.
Once conference replication has been set up items in the local conference will be replicated to the remote conference the next time the gateway connects.
Remember the administrator of the remote server must also set up conference replication on the remote site for items in the conferences on the remote server to be replicated to your local conference.
Avoiding replication loops
A replication loop occurs when you replicate a conference to another server, which replicates it to another server, which replicates it back to your server.
Be careful you do not set up a replication loop. For example, you might set up the following replication scheme : for the Product News conference:
In this example, an item posted in Tokyo is replicated to Boston, which replicates it to Stockholm, which replicates it back to Tokyo, which replicates it to Boston...
The FirstClass server detects loops in the item history. When it finds a loop, it reports a Type 1 replication error (both on the server console and in the log file), and breaks the loop. In the preceding example, the Tokyo server would report such an error when it receives the item from Stockholm.) When this occurs, contact the other sites participating in the conference to solve the problem. (For example, this could be done by removing the conference alias from the gateway connecting Tokyo and Stockholm.)
To avoid replication loops, we suggest that you prepare a diagram of your conference replication scheme. Look for servers that can replicate conferences over multiple paths, like Boston and Tokyo. These two servers can replicate conferences directly, or indirectly, through Stockholm.
About self–serve replication
If there are many conferences on your server, and several different servers in your network, you may find that the administrators of the other servers may not want or need to replicate all of your conferences. In this case, you can allow the other administrators to select only the conferences on your server that they are interested in. This is called self-serve replication.
Whenever you create new conferences or delete old ones, update your self-serve conference and keep the other administrators informed.
Controlling access to replicated conferences
One of the standard user groups is named Other Sites. This group contains all gateways and all users on remote servers. You can use this group to increase daily time limits for your gateways and you can also use it to prevent users on other servers from contributing to conferences on your server.
For example, Husky Planes Toronto and Husky Planes Boston have replicated the Sales Reports conference. Husky Planes Toronto’s FirstClass administrator does not want users on Husky Planes Boston to contribute directly to the Toronto conference. (Normally, they could do so by addressing mail to “Sales Reports, Husky Planes Toronto”.) The administrator wants Boston users to contribute to their local conference. Therefore, the Husky Planes Toronto administrator disallows access to the conference by the Other Sites user group.
Remember that conference replication involves a certain amount of communication between the administrators at each site. Permissions are not passed from one server to the other during conference replication. All messages in the conference at the remote site are replicated into your conference, no matter how you define your local conference permissions. Therefore, if you are concerned about submissions from users who are permitted on the remote conference, but are not permitted on your local conference, contact the other administrator to try to make the conference permissions comparable at both sites.
Setting up multisite mail
Using the Multisite Mail feature of FirstClass, you can set up large distributed mail networks consisting of many servers. FirstClass automatically decides how to route mail from one site to another through all of the intermediate server-to-server gateways.
When a FirstClass server receives a piece of mail destined for another site, it first determines whether it has a gateway to that site. If it does, it delivers the mail to the gateway. If it has no gateway, it checks to see if it has a route to that site. A route is a pointer to the next gateway on the path to the destination. If it has a route, it forwards the mail to the gateway specified in the route.
You can only have a route if you have a gateway to another FirstClass server which in turn has a gateway or route to the server that is your final destination. Each intermediary gateway is called a hop. The complete set of hops required to deliver a piece of mail to the end-point of the route is called a path. To add a route, you must first obtain the serial number and site name of the final remote server. This can be obtained from the administrator of the intermediary gateway, or from the administrator of the server to which you are creating the route.
Let’s look at the Husky Planes Boston network:
 On a multisite mail network, users can address mail to routes, just as they can address mail to gateways. For example, a user at Husky Planes Toronto is sending mail to a user at Husky Planes Tokyo: The Husky Planes Toronto server delivers the message to the Husky Planes Boston gateway and Husky Planes Boston delivers the message to Husky Planes Tokyo.
You can also include remote names in your Directory. Remote names are Directory entries for users on remote servers. If you include remote names, users can address mail to the user’s name only — they don’t need to include the route.
You can add routes and remote names to your Directory manually, but this method is time-consuming and subject to error. Instead, you might prefer to use Directory synchronization to automate the sharing of Directories. Both methods are described in the following sections.
Using Directory synchronization to automate multisite mail
Use Directory synchronization to set up automatic multisite mail in a network. When you designate the users, routes and gateways on your server that you want to synchronize, and then enable synchronization, they are added to the Directories of all the other servers. Users and remote names are defined as remote names, and gateways and routes are defined as routes.
Directory synchronization uses FirstClass FirstClass scripting. Each server’s Directory is exported from its source server and imported into the target server using FirstClass scripting commands.
Directory synchronization considerations
Consider the following factors before enabling synchronization on all the servers on your network:
• If your network is large, Directory synchronization can produce very large Directories, containing many thousands of names, making them more difficult to use.
• If your servers communicate over expensive connections, the cost of doing full synchronizations can be high.
• If your Directories are large (2,000 names or more), the Directory export process can slow down your server. Schedule exports for a time when server activity is low.
• If your synchronized Directory will be large (2,000 names or more), you must allocate more memory on your server. As a guideline, for each session add 10 KB of memory for every 1,000 names.
• If you want some of the benefits of synchronization, but you want to limit the size of the lists, you can perform site synchronization. This produces a smaller synchronization list because it does not include remote names.
Based on these considerations, you may decide that you don’t want to set up Directory synchronization on your network. You can still send mail to users at remote servers by adding and maintaining remote names and routes manually.
Types of Directory synchronization
You can schedule one of the following types of Directory synchronization:
Periodic Full Directory Synchronization
Synchronizes your entire Directory, based on a schedule you define.
Demand Directory Synchronization
Synchronizes only when you add or delete an entry in your Directory.
Manual Directory Synchronization
Synchronizes only when you initiate it manually.
Planning your network
If you’ve decided you want to use Directory synchronization, the next step is to plan your network. Design a propagation scheme for your network, like the one in the following illustration, and be careful not to create replication loops.
Here again is the Husky Planes network, this time with Directory synchronization enabled (shown as a “D” on each server).
 Note that even though the Stockholm and Boston servers have a direct gateway, the Directories are replicated through the Tokyo server to avoid replication loops.
Manual multisite mail
The previous section described how to set up automatic multisite mail on your FirstClass network using Directory synchronization. If you decide that you do not want to use site or Directory synchronization, you can still send mail to users at remote servers by adding and maintaining remote names and routes manually.
|