Article: Lotus cc:Mail and Domino Mail Backbones

This article discusses how and why customers consider implementing cc:Mail or Domino mail backbones for coexistence and migration of cc:Mail and Domino. The concept of a messaging backbone is nothing new. Large corporations often implement a common e-mail technology, such as X.400 or SMTP across business units while a variety of disparate e-mail systems may exist throughout the enterprise.

An e-mail backbone means that mail originating in a local e-mail system travels from that point onto the e-mail routing backbone (typically through a gateway or MTA) and is transported through the backbone system to another point where it is passed to another local system. The most important features of the backbone system are reliability and performance. The technology of the backbone system must be inherently reliable. The backbone technology must also be ubiquitous. It must be possible to connect almost any system to the backbone.

Another important feature of a backbone system is directory synchronization. Directory synchronization means that addresses from one e-mail system appear in others so that user’s in one local system must be able to address e-mail to users of another system. Strictly speaking, directory synchronization need not be a part of the e-mail backbone technology itself but a superior solution will provide directory synchronization.

One common backbone implementation is SMTP. However, SMTP by itself does not provide any directory technology. In recent years the industry has selected LDAP to fill that role. LDAP-enabled SMTP implementations such as Netscape Messaging Server and Sun Internet Mail Server (SIMS) are increasingly popular. LDAP technology has been widely adopted and the ability to synchronize directory information from disparate sources and make it available through LDAP has developed into a number of metadirectory products.

For Lotus messaging customers, there are multiple e-mail backbone options including LMS and Domino. It is almost always desirable to avoid running parallel e-mail routing infrastructures. When migrating from cc:Mail to Domino customers may want to route e-mail across business units exclusively through Domino. Compared with cc:Mail Domino provides a more reliable e-mail routing system. In a typical Domino system there can be many more users per server than can be supported using cc:Mail. This means fewer average hops between any two points in the e-mail routing topology and this translates into better performance. Through the cc:Mail MTA Domino also provides consistency and synchronization of directory information with cc:Mail.

To create a Domino backbone for cc:Mail there will be multiple cc:Mail MTAs. Each MTA will ‘see’ a specific group of users. E-mail 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 Automatic Directory Exchange (ADE).

What messages are routed to what MTA server is controlled through manipulating which MTAs ‘see’ which cc:Mail users. In the Domino NAB 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 internal by Domino for e-mail 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 (at the MTA server console TELL CCMTA SYNCH <HUB> and TELL CCMTA REQUEST <HUB> or from the cc:Mail side with Router express calls using the EXCH/DS and EXCH/RS parameters, for example, "ROUTER DOMINO_DOMAIN MODEM/NONE M:\CCDATA EXCH/DS").

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 TELL CCMTA SYNCHTEST <HUB>).

One drawback of the Lotus method for building Domino e-mail 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 offices. 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. The solution is simple.

A new cc:Mail post office can be introduced between the cc:Mail system and the MTA servers. These ‘buffer’ post offices contain only the directory information intended for the associated MTA to see (this is controlled through cc:Mail ADE between post offices, or can be administered manually on a temporary basis during migration). In this way, the Enterprise ADE relationship may be used and cc:Mail post office data do not appear in the NAB.

In the above diagram two MTAs exist, one in North America and one in Europe. This is a common scenario because it avoids routing of e-mail back and forth from North America to Europe which would be very inefficient.

In the reverse scenario, cc:Mail is used as an e-mail routing backbone for Domino. This is recommended where Notes and Domino are used only for workgroup solutions in a minority of locations, particularly where there are multiple Domino domains. In this case, the Domino servers do not route mail to one another. Directory information is synchronized through cc:Mail so that each Domino MTA ‘sees’ other users as being at cc:Mail.

In summary, it is desirable to avoid running parallel e-mail routing infrastructures. For customers migrating from cc:Mail to Domino using Domino as an e-mail backbone is recommended. In rare cases, the reverse can also be implemented.