Linking corporate electronic mail systems
has become a way of life for network managers. But the hardest part isn't
getting the pieces to talk to each other, it's building a single, unified
directory.
We tested OpenVMS-based directory synchronization products
from Alisa Systems (AlisaMail), Digital Equipment Corp. (MAILbus Directory
Synchronization Utility, or DSU), Innosoft International (PMDF-LAN and PMDF
X.500) and Wingra Technologies (Missive Directory Assistance). We'll be
testing the Unix-based ones in a future issue. Alisa's AlisaMail
provides the greatest amount of automated directory coordination for the
largest number of electronic mail systems. Although no e-mail network runs
without some manual intervention, AlisaMail--once we got it
started--required the least amount of tweaking and fiddling. In more
restricted environments running just MHS, cc:Mail, and Digital's MailWorks,
Wingra's Missive also worked, although without the performance and
flexibility of Alisa.
If you want to venture into the wild world of X.500 or need more e-mail
systems than Alisa supports, Innosoft and Digital both provide tool kits to
build generic directory synchronization engines. Using either package will
take much more work, but both give you the additional flexibility a big
e-mail network might require.
Alisa also supports links to Novell's MHS, Microsoft Mail for AppleTalk
Networks, and X.400 mail networks. With Alisa's gateways, you get a robust,
reliable and manageable gateway to the outside world. Alisa also offers a
broader range of off-the-shelf directory synchronization than anyone.
Although Alisa Systems normally sends someone out to install its product,
we did it on our own without major hang-ups. On the other hand, we do this
for a living. We'd advise first-timers to let Alisa come in and do the
installation.
Since any directory synchronization server needs to maintain a single
central database of all directory information, AlisaMail includes an OEM
version of the Sybase relational database product. While this gives
additional flexibility in building exactly the directory you need, Alisa
has hidden the complexity of Sybase behind its product. The only way to get
to the data is through Alisa-supplied software. This approach also consumes
resources quickly. Before our directory had a single user in it, AlisaMail
ate up about 12 MB of system memory and 140 MB of disk space.
Synchronizing our QuickMail and Microsoft Mail network was straightforward.
QuickMail's directory synchronization system automatically sends all
QuickMail addresses to AlisaMail using a MailCenter-to-MailCenter protocol.
This eventually becomes a mail message in Alisa's directory synchronization
agent.
Linking to Microsoft Mail requires a dedicated gateway PC to pass both
e-mail and directory information into AlisaMail. This PC replaced
Microsoft's own SMTP gateway. The gateway periodically pulled down all
directory information and mailed it to the AlisaMail directory
synchronization agent.
Once the directory synchronization agent received both sets of directory
information, it generated updates, which it mailed back to each of the LAN
e-mail systems for propagation into their directories. Once we got it set
up, the whole process ran automatically.
AlisaMail can provide tight control over which addresses get propagated.
For example, because we had some users we didn't want to appear in the
master directory, we set up an exclusion list that kept them from being
propagated to the other e-mail systems. Because Alisa pretends to be the
directory synchronization server for each network, any limitations in that
e-mail system's approach to synchronization become problems for the whole
network.
People Finder clients are available for Macintosh, DOS and OpenVMS systems,
but not for Unix systems. It works over any LAN transport.
Our DOS users used a "shadow" of the directory running on another DOS
system, and could search for users using many different criteria, such as
name, title, organization and location. Searches can be exact or fuzzy,
including the ever-popular "sounds like." For DOS-based mail systems such
as cc:Mail, Microsoft Mail and some Global MHS systems, People Finder is
available as a pop-up at the address prompt or as a command-line
application. Macintosh users bring up People Finder as a separate
application. They can search using the same capabilities DOS users have,
and then cut and paste addresses into their electronic mail application.
Because each user told People Finder what his or her preferred e-mail
system was, it always showed e-mail addresses in the correct format.
To use this automatic directory search, all we had to do was send e-mail
through the hub with an address of "first.last." This asks AlisaMail to try
to guess someone's real e-mail address. If "first.last" is unique, Alisa
forwards that mail to the end user. If not, it bounces it back with the
appropriate error messages.
Alisa's directory will also automatically generate correct return addresses
for anyone using the directory for outgoing mail. This means that if you
have an e-mail system that generates "ugly" return addresses, AlisaMail
will clean them up for you as they pass through the hub. For example, users
on our Mailworks mail system use their initials as mail addresses. Alisa
changes those to a full "First.Last" format for anything leaving the
system.
The major problem with Alisa's approach to foreign mail handling is that
you cannot easily send to anyone on the Internet (or any other foreign mail
system that isn't synchronized to your own) without entering your
correspondent into the directory. If you are willing to wait until someone
sends you a message, AlisaMail isn't too bad. It will automatically
register your correspondent's e-mail address and you can then easily reply
to the message.
If you want to be the first to write, though, you have to use your e-mail
system to create an address that ranges from convoluted to downright ugly.
For example, in Microsoft Mail, we had to send our message to a magic
gateway address inside the AlisaMail hub and place the real Internet e-mail
address in the text of the message.
To use Innosoft's PMDF X.500 to synchronize various systems, we first had
to install their base PMDF product, a high reliability e-mail backbone
system. Although PMDF connects many different LAN-based and mainframe-based
e-mail systems, a subset of those is supported by the directory
synchronization product. We used PMDF to build links to our cc:Mail,
Microsoft Mail and Mailworks systems, as well as SMTP (Internet), BITNET
and X.400 networks. Innosoft includes tools to synchronize DDS, cc:Mail,
Microsoft Mail and WordPerfect Office directories.
Installation wasn't difficult using the "cookbook" approach and automated
configuration procedures. We spent about two days getting everything up and
running smoothly.
PMDF X.500 stores directory information in an X.500 database. In the X.500
world, the Directory System Agent (DSA) is responsible for maintaining all
directory information. Innosoft has based its DSA X.500 directory database
on QUIPU--the ISODE Consortium's X.500 DSA. PMDF X.500 uses a combination
of disk and memory to store directory information for best response time
without adding a relational database.
Because products like cc:Mail and Microsoft Mail don't really have
directories, it's up to the network manager to fill in all of the other
interesting X.500 information for each user.
Like Digital's DDS, storing information in X.500 directories is a mixed
blessing. By using a commonly accepted format and a distributed database,
directory synchronization can be combined with directory access from
intelligent mail products that will search the directory as part of
composing an e-mail message. For example, Innosoft includes pop-up forms
and browsers to let OpenVMS users find X.500 directory entries from within
the standard VMSmail and DECwindows mail applications. Unfortunately, if
you're using Microsoft Mail and cc:Mail, you must use their internal
directory formats.
Internally, PMDF handles everything as Internet-standard e-mail using SMTP
and MIME message and addressing formats. Any time a PC LAN user wants to
send a message outside the LAN, the recipient's address looks like an
Internet-style SMTP address.
PMDF relies on the network manager to build a scheduler to export and
import directory information automatically at the appropriate time. Because
we were doing this as a test, we manually applied updates to each directory
rather than building the necessary scripts.
As network directory information percolated up to the X.500 directory, we
updated the X.500 directory and generated update commands for each of the
other electronic mail systems.
As in Digital's DSU, most of the process is left to you. You have to build
procedures to extract, reconcile and then redistribute the information to
the directories. PMDF's synchronization does not replace or work with the
directory propagation systems of each e-mail package.
LAN-based e-mail packages get the directory information as part of
directory propagation, so they don't need X.500 browsers. If you use X.500
but don't propagate every address into each e-mail system, Innosoft
provides Microsoft Windows, Windows NT and Macintosh X.500 client
browsers.
Innosoft also integrates the X.500 directory for both incoming and outgoing
mail. Incoming mail is handled automatically, with fuzzy name matching and
feedback to assist correspondents in finding the proper person. For
example, because there are multiple instances of "J Snyder" in our e-mail
system, a message sent to "JSnyder@Opus1.COM" would return a list of the
Snyders along with other relevant information, such as phone number or
title.
Outgoing mail from the organization is handled by tables within PMDF that
rewrite return addresses to a canonical format determined by the system
manager.
MAILbus DSU uses Digital's Distributed Directory Service (DDS) as a
centralized database for all directory information. DDS is included with
Message Router, Digital's first-generation mail back end.
Digital sees this product as a tool to leverage their consulting services
and normally sells it as part of a larger consulting contract where they
build the directory synchronization system using off-the-shelf and
customized Digital products.
Digital's DSU doesn't have any way of talking directly to any of the LAN
e-mail systems, so we used one of the other vendor's gateways to move
directory information to the DSU host. We also wrote a short mail-enabled
application on the host side to pull the directory out of an incoming
e-mail message automatically and kick off a directory synchronization
cycle.
Because the DSU doesn't know how it's going to get its directory
information, Digital defined RDF (Record Description Files), a special data
definition language to specify exported and imported directory data
formats.
RDF file logic is fairly rudimentary. Digital includes special support for
generating people's names, mostly because the personal name is used as a
mailbox indicator in most LAN-based e-mail systems. Other rule-based logic,
such as changing routing for a particular department has to be handled
separately from DSU. For example, we tried to force e-mail to a particular
remote site with routing information to make it flow over our X.400
connection instead of through the normal Microsoft Mail network
connections. To do this, we had to write a simple processor that ran after
the RDF conversion.
Our first task was to use the Microsoft Mail Import Utility to dump the
directory information out of a Microsoft Mail network into a file. Then, we
mailed that file to the DSU host, which extracted the data from the e-mail
message and imported it into the DDS.
Once it had imported all our directories, DSU generated update lists that
told each system how to change its directory to match the central DDS
directory. DSU's update lists were in a format acceptable to each of the PC
e-mail systems, thanks to complementary RDF files that we also put
together.
Unfortunately, there is no way to ship the update instructions to the
LAN-e-mail systems and have their directory import utilities apply the
updates automatically using Digital's tools. We could have written a
periodic batch script to go to the DSU host, grab the directory deltas and
apply them to each e-mail system. What we couldn't do is tie the DSU
directly into Microsoft Mail and cc:Mail automatic directory
synchronization systems.
Digital doesn't have anything like Alisa's People Finder to let users
easily search corporate directories. To find anything in the DDS, you would
have to use the cumbersome command-line interface of the DDS management
tool--MBMAN.
Wingra's Directory Assistance is an extension to Digital's DSU. Combined
with Missive, it gives you directory links between cc:Mail, Global MHS and
DDS, but not Microsoft Mail.
Missive, like Digital's DSU, uses the DDS as a database to store directory
synchronization information. But unlike Digital's DSU, Directory Assistance
is fully automatic. Once we put Wingra's PC software on the cc:Mail post
office, everything ran without significant intervention. Missive Directory
Assistance uses e-mail messages to pass the directory updates around.
Wingra has also added a simple rule-based facility for modifying address
entries as they pass through Directory Assistance. Although this is not
designed to filter out specific addresses, it does allow some reformatting
of name information.
Once we had mail flowing, we added Wingra's cc:Mail-specific directory
import/export programs and scheduler to the gateway PC. Once we configured
all the software and created the appropriate rules files, the
synchronization process proceeded automatically.
cc:Mail updates, generated at predetermined intervals, are sent to the
Missive hub and eventually make their way to DSU and then into the DDS. On
the OpenVMS side, Missive periodically kicks off a job to ask the DSU for
updates for the cc:Mail directory. These flow through Directory
Assistance's rules and generate an update file. The cc:Mail gateway PC
periodically checks for updates and, when it finds one, applies it to the
cc:Mail directory.
It's a pretty automated process. Once we got everything set up and locked
down, Missive happily kept our cc:Mail and DDS directories in sync without
requiring much additional work.
Because Missive is based on Digital's DDS, there are no prebuilt tools for
making directory searches easier. Missive does support automatic DDS
searches when processing e-mail. As mail passes through the hub, Missive
will reach into the DDS and attempt to figure out where a particular
message should be delivered. We tested this by sending mail from the
Internet to one of our cc:Mail users. As the user name, we picked the
unique identifier Missive automatically generated from the user's last
name. Missive correctly figured out where the user received mail and
delivered it properly.
Joel Snyder is a senior partner with Opus One, Tucson, Ariz.,
specializing in networks and international aspects of information
technology. He can be reached at jms@Opus1.com. Jan Trumbo is a
postmaster at the University of Arizona's Telecommunications
Department. She can be reached at trumbo@arizona.edu.
MAILbus Directory
Missive Directory Assistance:
AlisaMail: 5,000 users,
Alisa Systems AlisaMail
Alisa's AlisaMail is a full-featured e-mail backbone that connects to most
popular LAN-based electronic mail systems, and it supports global directory
support and synchronization. We installed AlisaMail and brought up links to
cc:Mail, Microsoft Mail, SMTP mail, QuickMail and Mailworks (formerly known
as All-in-One Mail).Synchronizing Easy and Automatic
Synchronizing with AlisaMail is a highly automated process. It includes
software to run on each LAN-based e-mail system, and it pretends to be the
directory synchronizer for that e-mail system. For example, with QuickMail,
AlisaMail appears as a QuickMail server offering one or more MailCenters.
But because of a limitation in the number of QuickMail addresses one
MailCenter can have, you must spread out large AlisaMail directories among
multiple "virtual" MailCenters.Searching is Flexible
Once we built synchronized directories, we were eager to use them. You
access the central directory through the People Finder utility, which adds
plenty of flexibility. For instance, in Microsoft Mail we only had 30
characters to enter information for each user. In Alisa's directory, we
were able to store additional information, including title, location,
address, and phone and fax numbers. It can also hold pictures.Not Just Directory Synchronization
Because AlisaMail is an e-mail hub as well as a directory server, AlisaMail
can use the directory to help deliver mail from the outside world. For
local e-mail, this is no big deal, since you've already got a copy of the
directory. However, if you have unsynchronized mail systems, such as SMTP
mail, this is a powerful feature.Innosoft PMDF
Innosoft's approach to directory synchronization is, like Digital's, very
tool-oriented. The base product, PMDF-MTA (Message Transfer Agent) doesn't
talk to any LAN-based e-mail systems directly. Add PMDF-LAN, and you get
direct links to Microsoft Mail for PC networks, cc:Mail MHS and WordPerfect
Office. To synchronize dissimilar e-mail systems, link all these to
PMDF-X500, which provides an X.500-format database to store and synchronize
directory information. (Note: the ITU-TS Recommendations covering the
directory are commonly called "X.500" even though there are 11
Recommendations, only one of which is numbered X.500 in the series.)Synchronizing: Build It and They Will Come
Innosoft's PMDF X.500 is similar in scope to Digital's DSU in that it
provides a tool kit which we had to use to build our own directory
synchronization scheme. If you don't want a centralized back-end database,
Innosoft doesn't require X.500. PMDF-LAN will synchronize e-mail
directories to each other but not to a central database.Searching the Directory
Directory searching with PMDF X.500, because it uses an X.500 directory,
benefits from a suite of freeware applications to browse X.500 directories.
Innosoft includes a browser for both command-line and X window system
access. OpenVMS e-mail users can also invoke Innosoft's pop-up directory
search to browse the directory and select an address for automatic
inclusion in a particular message.Digital Directory Synchronization Utility
Digital's DSU is really a tool kit for building directory synchronization
systems. Digital sells a MAILbus Directory Synchronizer (which we tested)
and an X.500 Directory Synchronizer.Synchronizing Is a Manual Process
We built the RDFs to synchronize Microsoft Mail for PC networks and cc:Mail
with our existing DDS database. Digital actually provides the Microsoft
Mail RDF as an example of how to synchronize PC mail systems, but building
the cc:Mail RDF wasn't very difficult; it was just a matter of identifying
which fields contain which information, and mapping them into a common
database format.Wingra Missive
We installed Wingra's e-mail backbone product, Missive, and brought up
links to our cc:Mail, Microsoft Mail and Mailworks e-mail systems along
with connections to the Internet over SMTP and to BITNET using Wingra's
Jnet product. Missive also supports links to Lotus Notes and Novell's
MHS.Synchronizing: It's Automatic
We used Missive Directory Assistance to synchronize our cc:Mail directory
with DDS. Installing Missive is, like installing all e-mail backbones, not
for the faint of heart. We set up our gateway PC and the Missive core in a
little over two days, with a few calls to Wingra for support. The gateway
PC is dedicated to exchanging mail between cc:Mail and the Missive
backbone.
Vendor Information
PMDF-LAN and PMDF X.500:
$20,750. Innosoft International,
(800) 552-5444. sales@innosoft.com.
Synchronization Utility (DSU):
$35,000 (Note: does not include any LAN gateways).
Digital Equipment Corp., (800) DIGITAL;
fax (800) 723-4431. info@digital.com,
http://www.digital.com.
$24,000. Wingra Technologies,
(800) 544-LINK, (608) 238-4454.
sales@wingra.com, http://www.wingra.com
$53,000. Alisa Systems, (800) 628-3274;
fax (800) 792-4068. sales@alisa.com,
http://www.alisa.com.
Unix Directory Synchronization Products To Watch
Network Computing will be looking at Unix-based directory synchronization
in a future issue, but until we do, here are some of the products to keep
an eye on.
Includes both e-mail backbone and directory synchronization to a very wide
variety of LAN-based e-mail systems, including cc:Mail, Beyond, Da Vinci,
Digital's DDS, Microsoft Mail, IBM's OfficeVision/PROFS, Unix and VMS, and
WordPerfect Office.Mail*Hub synchronizes directories to an internally
maintained X.500 directory.
Arden Hills, Minn., (800) 257-OPEN,
info@cdc.com.
Directory Synchronization Services supports an internal SQL database as a
repository of directory information from cc:Mail, Hewlett-Packard OpenMail,
Microsoft Mail, Lotus Notes and WordPerfect Office. Organizations that
already have an X.500 directory can use that directory as a further place
for Worldtalk to keep its databases.
Los Gatos, Calif.,
(408) 399-4000.
SyncWare stores directory information in an X.400-format database on a Unix
server. Agents run on cc:Mail, Global MHS, Microsoft Mail, QuickMail and
Unix systems to ship their directory information to the centralized server
for synchronization and updates.
Offers both an e-mail backbone (Messenger InterOFFICE) and an X.500
directory (Messenger 500). Directory synchronization of cc:Mail, Microsoft
Mail, Global MHS, Quickmail, Digital DDS, HP OpenMail and IBM OfficeVision
occurs inside of Messenger InterOFFICE, that can also propagate the
directory into their X.500 product.
Burnaby, British Columbia,
(604) 436-2922.
Linkage Directory Exchange (LDE) emphasizes compatibility with IBM host
environments. It synchronizes Shared Address Book, Enterprise Address Book
(OV/MVS), OfficeVision/400, cc:Mail, Microsoft Mail, Verimation MEMO, HP
OpenMail, and EMC2 mail directories.
(416) 862-7148,
call_us@linkage.com).
