To create a Domino backbone for cc:Mail there will be multiple cc:Mail MTAs. Each MTA will "see" a specific group of users. Email from Domino to cc:Mail or from one part of the cc:Mail system to another will be routed to the appropriate MTA. Which MTAs see which users is controlled through directory synchronization. The cc:Mail MTA supports cc:Mail's directory synchronization and update technology, ADE (Automatic Directory Exchange).

What messages are routed to what MTA server is controlled through manipulating which MTAs '"see" which cc:Mail users. In the Domino NAB (Name and Address Book), each MTA will have a particular cc:Mail Post Office associated with it. The cc:Mail users appearing in the NAB have a cc:Mail Post Office name associated with them. This is the key to associating some users with one MTA server and other users with another MTA server.

One issue is that cc:Mail directories are often synchronized. This presents the problem that when any cc:Mail Post Office is synchronized with Domino it will cause all of the cc:Mail users in the system to appear at that Post Office or one of its subordinates. The Post Office server associated with the MTA is an entry point into the cc:Mail routing topology. Each MTA is also associated with a foreign cc:Mail domain which is used internally by Domino for email routing.

By default the Domino will "see" the rest of the cc:Mail system as being part of a hierarchy beginning with the point of entry. The MTA assumes that the Post Office it communicates with is a cc:Mail routing hub which may or may not be the case. To solve this problem, each MTA configuration can synchronize directory information only for a subset of Post Offices. In the cc:Mail MTA configuration Post Offices can be included or excluded from directory synchronization.

The first-time synchronization of the MTA server with the Post Office it communicates with can be done either from the Domino side or the cc:Mail side. If you're doing so from the Domino side, you'll be using these commands at the MTA server console:

If you're doing first-time synchronization from the cc:Mail side with Router express calls, you'll use the EXCH/DS and EXCH/RS parameters. Here's an example of how that might work:

If you're setting up the cc:Mail MTA and doing a first-time sync with cc:Mail, make sure that the Notes client is not running on the MTA server. If synchronization does not occur, stop and restart the server. Also, for a first time sync it is advisable to run a test synchronization. At the MTA server console type:

Drawbacks
One drawback of the Lotus method for building Domino email backbones for cc:Mail is that all cc:Mail Post Offices will appear in the Domino NAB as cc:Mail Post Office servers. This clutters the NAB with unnecessary information. Lotus' plan is to represent the cc:Mail routing topology within the NAB and to associate each user name with a specific Post Office. In cc:Mail, however, user names are already unique; thus it is not necessary for Domino to contain a complete representation of the cc:Mail system. A better way is to use the "Enterprise" ADE relationship. Unfortunately, Enterprise ADE is not compatible with the idea of including and excluding different Post Office names from directory synchronization because it requires that all users have the same Post Office name.