E-mail interoperability software A backbone to the world Not only is
PMDF e-Mail Interconnect 5.0 the least expensive messaging switch we've
evaluated, but its interoperability is as predictable as partisan
politics. And its tools won't take no for an answer -- you can
configure any option if you have the time.
CONTRIBUTORS:
Written and tested by
Joel Snyder and
Jan Trumbo
Introduction and editing by Diane Mehta
Publication Date: March 4, 1996 (Vol. 18, Issue 10)
PRODUCT REVIEWED: PMDF e-Mail Interconnect 5.0 Innosoft International Inc.
Much as a political party rallies congressional support in order to pass a bill, Innosoft International Inc.'s PMDF e-Mail Interconnect 5.0 aligns different messaging systems toward a common goal: letting users talk to one another without worrying about truncated messages or lost attachments. If you can imagine each message acting as a potential vote, you would want to find some way to direct those votes to your party -- or, in the case of E-mail integration, to your platform.
As E-mail usage has increased, corporations have been looking to increase the capacity of their messaging systems. The prevalence of mergers and acquisitions, resulting in workgroups being thrown together in one corporation, has raised the issue of interoperability among disparate systems. Instead of simply switching all their users to a single system, corporations have integrated existing E-mail systems. The worldwide growth of E-mail use in businesses, in homes, and via on-line services has created a monster: Millions of messages are being shuttled among gateways or singular desktops via disparate platforms and protocols. This volume of E-mail has in recent years prompted a response by vendors to provide an E-mail backbone that fuses those systems in a way that's reliable and, theoretically, seamless.
The variety of issues for managers who are considering an E-mail integration solution are as diverse as the users' individual choices for E-mail. Not only do you have to be aware of different server platforms, but you must also consider the types of attachments people send. And because E-mail has evolved into a mission-critical application in most organizations, you'll want to make sure you get reliable support from the vendor.
THE INTERNET. With all the politicians and media hounds buzzing about the Internet as the most important communication medium of the year, don't be surprised if "interconnect" becomes a household word. The relevant issues concern how well E-mail interoperability packages handle mail from the Internet or from dissimilar E-mail systems. Most LAN-based E-mail systems use Simple Mail Transfer Protocol (SMTP) to connect to the Internet. But despite the SMTP standard for Internet mail, problems persist in two areas: addressing and attachments. Each SMTP gateway may handle addressing schemes differently, which can cause conflicts during routing.
Attachments run an even riskier course. Not every SMTP gateway can reliably handle multiple or large attachments. As the message gets transferred, it gets encoded and decoded (it converts a binary file to text and includes it in the body of the message, and then converts it back to a binary file at the other end), which may cause it to get mangled or truncated. Even worse, the message could remain encoded in the body of the text, making it unreadable unless you want to decode it manually. Furthermore, different mail systems have character limits for the body of the text, so if the attachments are too large or too many, you may lose parts of them.
But if all goes well, the SMTP E-mail will arrive without much ado and get converted to a format that, for example, Lotus Development Corp.'s cc:Mail can understand. For simplicity, imagine the switch -- PMDF's software solution -- as a one-stop solution. Instead of requiring an SMTP gateway between the Internet and cc:Mail, another SMTP gateway between the Internet and Microsoft Corp.'s Microsoft Mail, and yet another gateway between cc:Mail and Microsoft Mail, PMDF's software coordinates protocols among all of the systems.
However, the question remains: Is the interconnect market being overshadowed by other issues? Internet access, because it facilitates worldwide commerce, is vital to keeping a business competitive in today's marketplace. Corporations that expected to use X.400-based products are finding SMTP has become the dominant corporate E-mail protocol. With this in mind, standardizing to a single E-mail system may ease preparation for the evolution that E-mail will inevitably undergo.
On the other hand, interconnect software alleviates worries about trying to bring so many disparate elements together. The X.400 protocol is still widely implemented in Europe and within the U.S. government -- areas in which the Internet has not been as large a driving force. Stimulated in the past two years by the Internet, the SMTP protocol has taken hold of the commercial market in the rush to connect heterogeneous systems.
George Selleck, information distribution services manager of Tyson Foods Inc., defends PMDF. After acquiring three different E-mail systems due to acquisitions, Selleck wanted to go with a backbone TCP/IP suite, which implied that SMTP would be Tyson's E-mail system. None of the installed systems were SMTP compliant out of the box, but because users were happy with their existing mail systems, his priority was to link those systems together and then move toward the goal of distributing SMTP as a mailer to the client. And for less than $20,000, vs. the $120,000 some other backbone systems cost, he didn't waste a lot of money.
"PMDF is like an army bridge layer [which carries bridging equipment]," Selleck says. "It may take you a day to ford that data stream, but when you're done, you can drive a tank across it and it will tell you how heavy the tank is, how fast it's going, and who's driving it."
LOST IN TRANSLATION. Fundamental to an effective E-mail interconnect solution is the integrity of the messages you're sending and receiving. In our interoperability tests, we evaluated the quality of received messages, replies, and attachments among 12 different E-mail products. We also sent messages to three other recipients -- fax machines, alphanumeric pagers, and users who receive their E-mail on printers. The bottom line is that the problems we experienced were due to limitations in the LAN mail systems we tested. Despite occasional truncated subject lines or lost file creation dates, we found PMDF to be resilient about transferring files in one piece.
We were particularly interested in the problem of attachments -- how to get binary E-mail attachments from system A to system B so that they would be as useful and readable to the recipient as they were to the sender. Although the attachments we used represented those of a typical business user, the prevalence and distribution of large files across the wires are rising issues -- issues that may have consequences for current messaging infrastructures and the capability of products such as PMDF to deal with attachments.
Directory synchronization and maintenance, one of the major hassles in large E-mail networks, was also an important part of our testing procedure. Could PMDF truly synchronize our network so that cc:Mail users could send messages to people on other E-mail systems as easily as they send messages to people on their own? We looked at directory synchronization from two perspectives. First, would it be possible to synchronize two directories so that E-mail magically moved from one to the other? What would foreign E-mail addresses look like on your current E-mail system? Second, how much effort would be needed to set up the synchronization? Was this an out-of-the-box service, as we saw in Alisa Systems Inc.'s AlisaMail package (see product analysis, Nov. 7, 1994, page 74), or was it something else entirely? Unfortunately, PMDF doesn't offer automatic directory synchronization but does include a plethora of tools to help you configure and centralize your directories as you see fit.
HOW WE TESTED -- E-MAIL INTEROPERABILITY
* In addition to the more popular messaging systems, we tested options such as Network Job Entry, Unix to Unix Copy, fax, and pager gateways.
The only way to tell if an E-mail backbone is any good is to move a lot of different kinds of E-mail around and see what breaks. We took the specifications of Innosoft International Inc.'s PMDF e-Mail Interconnect 5.0 at its literal worst: If it said it could link to an E-mail system -- and we could build it in our lab -- we made Innosoft keep its promise.
We modified the testing methodology previously used to evaluate E-mail interoperability software. First, testing for PMDF differed from some products in that we set up the product in-house instead of receiving the product already set up from the vendor; we tested a different group of E-mail clients; and we modified our directory maintenance and interoperability tests for those sections.
Our testing system was a Digital Equipment Corp. Alpha 250 266-MHz machine with an EV4 chip set, 128MB of RAM, and two 2-gigabyte Seagate Technology Inc. Barracuda SCSI hard disks. Using the Alpha machine was especially nice because we could boot the system using Digital OpenVMS, Digital Unix, or even Windows NT. The 250 4/266 isn't considered a server-class system (it's sold as a workstation), but at 266 MHz it was fast enough for our tests. We discovered how quickly the new RISC systems use memory: realizing that our 48MB of installed memory wasn't enough, we upgraded to 128MB.
PMDF runs on two platforms: Digital Unix on Alpha systems (formerly called OSF/1) and OpenVMS on either VAX or Alpha systems. The Unix port is barely 1 year old; our CD-ROM distribution was handmade by the developers, and we could tell during testing that the Unix port was not as stable as the OpenVMS version. Because Innosoft released the Unix version while we were testing, we first configured and tested on OpenVMS; then we moved our configuration and retested on Unix.
Innosoft is working on ports to other versions of Unix, including Sun Microsystems Inc.'s Solaris, which will be available this summer. Although OpenVMS may not be your first choice for an E-mail gateway, we had our best experiences working on that platform.
Most LAN E-mail systems require a gateway PC to move E-mail in and out of post offices. The only exception to this is the newest version of Novell Inc.'s Message Handling Service (MHS), called Global MHS, which includes a NetWare Loadable Module that runs on the NetWare server and does what the gateway PC would do. Because it was inconvenient to stack up piles of PCs for our test configuration, we used a single Windows NT machine running on a 66-MHz 486 system from Digital to simulate the PCs. (We tested for interoperability, not performance.) To make sure Windows NT wasn't complicating things, we also ran the same gateways under Windows 3.11 and experienced no differences.
We installed all four PC LAN E-mail systems; for Novell MHS, which is a backbone itself, we used the Da Vinci eMail (from On Technology Corp.) user agent to send and receive E-mail.
We installed the optional PMDF-MR (message routing module) and brought up a Digital TeamLinks mail system with Windows and Macintosh clients to connect to our PMDF backbone.
We did not, unfortunately, have the time and resources to test PMDF-MB400, the link to Mailbus-400.
To satisfy our thirst for really complex systems, we also installed PMDF-X400 and linked our test system to MCI Communications Corp.'s X.400 E-mail network. X.400 goes hand-in-hand with X.500, the ITU's directory services standard, so we also installed and configured PMDF-X500.
Naturally, we also needed to get Simple Mail Transfer Protocol (SMTP) in on the act, so we connected the whole system to the Internet and to some Windows and Macintosh systems running Eudora Light, the SMTP E-mail client for Qualcomm Inc.
This was getting more than complicated; it was getting downright baroque. In fact, we may have had the most complicated E-mail backbone on earth right here in our lab.
PERFORMANCE: Setup
In previous test scenarios, E-mail backbones were installed by the vendors.
Innosoft will install PMDF for a price, but because it's a lower cost system than some of the others we've tested, we thought most users would opt to install PMDF themselves.
Thus, to emulate a typical user setup, that's what we did. But be warned: This is not for beginners.
We started with a base score of satisfactory and worked our way down based on the number of times we ran into roadblocks. We added points when the software figured out problems with the interconnected systems (preferably before we got to them) or when it configured itself.
We divided this scoring category in two parts: Two-thirds of the setup score is based on base configuration and one-third is based on the features. The base configuration involved getting the software running so that we could move E-mail around our test network. That process included sending messages back and forth, providing essential management facilities such as error logs, and shifting addresses so we could send out a message and reply to it, even if the addresses were ugly as sin.
The high-end features phase included all tasks performed after we established a connection, such as playing with addresses, converting message body parts and attachments from one format to another, moving headers around, and other fun customization options. Although not everyone will need all of the features we tested, almost every configuration will use one or two.
Directory maintenance
We used two test scenarios to gauge directory synchronization. In the first, we wanted all of the client E-mail systems to look identical: Each local E-mail system had to see all the addresses in the global system (including all the other E-mail systems) and also had to propagate the server's global directory back to all the local directories. That means if a Microsoft Mail user pulls up the directory and starts typing the letters of someone's last name, the system should jump to foreign users as easily as native users -- and the sender should be able to select and add these addresses to messages as easily as if there were no directory synchronization.
In the second scenario, we wanted to have a centralized directory on the server, which never got propagated back into the client PC E-mail systems. Using this technique, the same Microsoft Mail user would have to run a separate application or use a hot-key to query the directory, then cut and paste the E-mail addresses into Microsoft Mail. This kind of directory has its advantages: You can store all kinds of other interesting information about people, such as phone number, title, office address, salary, and beverage preference, that the PC E-mail systems don't have room for.
A product that could handle either scenario got a score of satisfactory; a product that could do both was rated as good. We added and subtracted points based on how hard it was for us to coerce the product to perform these tasks. We assumed that some manual tuning would be necessary but wanted to minimize required customization.
To confuse the directory synchronization system, we used different standards for names in the different E-mail systems. In one we entered names such as "Gates, Bill," and in another we used the "Andy Grove" style. Directory synchronization that gave us the freedom to alter these names as we saw fit accrued extra points.
Directory synchronization goes hand in hand with the management interface. We wanted to see how the global directory looked to the E-mail manager. For example, is it easy to manage? Are there nice GUI tools, or do we have to descend to the command line? When users query the directory, what tools are available to them? A directory that requires end-users to log on to the mail hub is poor; a directory that can be queried directly from PC and Macintosh systems is key to today's LAN-based environments. Depending on the quality of the interface, we added or subtracted points from the final score.
Interoperability
To test interoperability among the different E-mail products, we used a series of escalating tests: recipient, reply-to, and attachments.
The simplest of these, the recipient test, included checking whether every E-mail system could send unmolested text-only E-mail to every other system. We used a 10KB file that had no "funny" characters (for example, 8-bit international characters) or long lines, in the main body of the message. Simply getting the message through without mangling anything was worth 75 points; we subtracted 5 points for anything lost or truncated in the process.
We set up 15 different E-mail systems as recipients. Three of these (fax recipients, alphanumeric-pager recipients, and users receiving E-mail on a printer) did not undergo the other two tests.
First we created mailing lists on each system, which then sent messages to two recipients on every other system. This meant that we sent out 11 messages, each of which was received by 28 different addressees.
The reply-to test determined whether each message we sent could be answered. We tested whether each message could be replied to as a "reply all," returning an answer not just to the original sender but to everyone on the address list. We also wanted to find out whether the reply to the original sender could be replied to itself (that's a reply to a reply, in case you're counting). This was worth another 75 points. Any message or recipient lost cost five points.
Attachments were the third criteria we evaluated in this category. We wanted to move documents built on PCs through the network without mangling them. Testing this caused some real problems -- not because of the switch, but because of the capabilities of the various E-mail packages. We only subtracted points if an attachment disappeared or could not be reconstructed from the message. We used Microsoft Office as the basic attachment generator, and sent out three files -- an Excel spreadsheet, a Word document, and a PowerPoint presentation -- which together were 1MB in size. Because PC LAN systems don't support the Internet attachment protocol, Multipurpose Internet Mail Extensions, we classified our documents by extension: .DOC for Word, .XLS for Excel, and .PPT for PowerPoint.
Using the same mailing lists that we set up for the recipient test, we awarded 75 points if the product managed its attachments without a hitch and subtracted five points each time the E-mail backbone broke something.
SUPPORT AND VALUE: Documentation
To receive a score of satisfactory, the manuals had to clearly describe the setup, management, and maintenance of every aspect of the software. Products received higher scores for including useful examples, tutorials, and figures that further clarified concepts. We gave bonus points to products that included extras, such as a glossary, a comprehensive index, and tuning and troubleshooting tips. We subtracted points for factual errors, incorrect tables of contents, and poor index entries.
Support
The score for support had two parts: support policies and technical support. Each contributed 50 percent to the total score for this category.
Because the majority of users who need support will require it during installation and configuration, we started with a base score of satisfactory if the vendor offered free phone and/or E-mail support for the first 90 days after installation, during nationwide business hours. We gave bonuses for a comprehensive support program that included free phone support, maintenance releases, and upgrades. Products with a toll-free support number, extended support hours, and alternative access methods -- such as CompuServe, a private BBS, or the Internet -- also accrued bonus points.
We based the technical support score on the quality of service we received during multiple anonymous support calls to the vendor and on the availability of knowledgeable technicians. If the support team returned our phone call or E-mail query within 4 hours and offered acceptable answers to our questions, we gave the product a score of satisfactory. The product received extra points if our calls got through immediately, if we were connected to a developer, and if we received responses that were above and beyond the call of duty.
Every time we sent a support query via E-mail (and we sent more than 30), we tracked how long it took to get an answer. Anything beyond 24 hours cost the product points; anything under 1 hour gained points. We spaced our queries across a whole week, ranging from 3 a.m. on a Saturday (hard) to 1 p.m. on a Wednesday (easy).
Value
We weighed PMDF's integration of our E-mail products against the estimated cost in time and money that it took to install and maintain it. We considered how much effort was necessary to maintain the system compared with smaller-scale strategies, such as connecting all of the E-mail products around Novell's MHS or maintaining a series of different gateways between the products.
We looked at PMDF in the light of a corporate backbone for an E-mail system of at least 500 users. The final value score reflects the cost-benefit ratio of using PMDF as an E-mail integration strategy.
Product overview
* You can access the World Wide Web for more information on Innosoft International Inc. at http://www.innosoft.com.
PMDF e-Mail Interconnect 5.0
According to Innosoft International Inc., if you use the PMDF e-Mail Interconnect 5.0 backbone software, all your E-mail connectivity problems will go away. After putting PMDF through the paces for a couple of months, we think the company might be right.
Back when corporate IS ruled the computing roost, a company would have only one E-mail system. It might have been IBM's Profs, or Digital Equipment Corp.'s All In 1, or even Data General Corp.'s CEO -- but it was a single, monolithic E-mail system, and you were either on it or you weren't.
Now things are different. The mainframe-based E-mail system is a tiny part of the picture. Microsoft Corp. is basically giving away Microsoft Mail. Other packages such as Lotus Development Corp.'s cc:Mail and Notes, Novell Inc.'s GroupWise, CE Software Inc.'s QuickMail, and Novell's Message Handling Service (MHS)-based packages (such as On Technology Corp.'s Da Vinci eMail) are also prevalent. Add to that list other E-mail systems -- the Internet's Simple Mail Transfer Protocol (SMTP), X.400, and nifty fax gateways -- and corporate E-mail gets really complex really fast.
Ask an E-mail expert how to link all of this confusion and you get one word of advice: backbone. He or she will tell you not to buy dozens of gateways to ship your Internet mail through cc:Mail to Microsoft Mail, and out X.400 to MCI Mail, for example. Instead, you should link each E-mail system only once to the backbone; let the backbone route the mail.
All backbones work the same way. Mail gets translated into the backbone format from each E-mail system. The backbone fiddles with the addressing and content data in each message and ships it back out to another E-mail system. The backbone's job is to clean up any mess the other E-mail systems have created and to move mail around the network. Backbones also have a major role in E-mail management in terms of keeping logs of who sent what to whom.
Inside the backbone, mail is converted into one of three formats: proprietary; RFC-822, the format used on the Internet; or X.400, an internation-al standard for E-mail published by the International Telecommunications Union. PMDF happens to use the RFC-822 format, combined with Multipurpose Internet Mail Extensions, to handle binary attachments to E-mail messages. Although backbone vendors like to crow about how progressive they are at choosing a format, your concern is whether your mail goes in and comes back without losing information.
PMDF supports a bewildering array of E-mail systems, which makes it equally difficult to test. The base PMDF backbone product (PMDF-MTA, or message transfer agent) handles SMTP mail; DECnet mail, a Digital-only standard for moving mail among DECnet systems; and some obscure gateways such as Network Job Entry, an IBM protocol used on the Bitnet network; Phonenet, a dial-up protocol; and Unix to Unix Copy, which lets you copy information between Unix machines. Innosoft has a pile of options, and we installed most of them.
PMDF supports two platforms: Digital's OpenVMS and Digital Unix. There are four major differences between the two, but most of these will be fixed in a PMDF release scheduled for this summer. First, both platforms support Post Office Protocol and Internet Message Access Protocol servers, but PMDF is multithreaded in OpenVMS and single-threaded in Digital Unix. Second, the list server functionality available with OpenVMS isn't available on Digital Unix. Third, PMDF-Fax will not be available on Digital Unix until the summer release. Fourth, Digital Unix does not support delivery of SMTP messages across TCP/IP X.25 and X.29 networking standards. (According to Innosoft, they are the only company that currently supports this task on any platform.)
PMDF's LAN E-mail gateway add-on, PMDF-LAN, talks to Microsoft Mail for PC networks, cc:Mail, MHS, and GroupWise. By this summer, it will also support Notes.
PMDF also supports Digital's backbone E-mail systems: Message Router and Mailbus 400 (an X.400 backbone). Message Router is used to communicate with All In 1 and Digital's client/server PC LAN system, TeamLinks.
This E-mail backbone business is not for a small 10-person office's Internet connection (although it will do that, if you insist -- much better than Microsoft's, Lotus', or Novell's own gateways -- for about 20 times the price). PMDF is for big E-mail networks with lots of complexity or those which handle a lot of traffic -- or both. If you think that 10,000 or more messages per day passing between E-mail systems is normal, then PMDF is about the right size for you.
Setup
* In places where PMDF was easy to install, it was really easy; but where it was hard to install, it was really hard. Plan to spend some time with the setup.
PMDF e-Mail Interconnect 5.0: GOOD
We found the setup to be pretty easy, but we've been installing E-mail backbones for several years. If you're going to be setting up an organizationwide E-mail system, you'd be wise to set aside a good chunk of time and patience unless you want to pay either Innosoft or a consultant to install it.
However, installing the PMDF backbone itself was a cakewalk: We put the CD-ROM in the drive, ran the standard installation program, and let it run. During installation and initial configuration, we only had to answer a few simple questions about our site, such as which disks and queues to use, what our system name was, and how we were connected to the world.
Users will be happy to know that the installation program let us pick between expert and beginner modes. The first time we installed PMDF, we used the beginner mode, which meant each of the above questions got a paragraph (or more) of discussion. When we reinstalled PMDF, we used the expert mode. Our advice: Use the beginner mode, even if you think you're an expert.
We started with the basic PMDF product and the LAN E-mail packages (Lotus Development Corp.'s cc:Mail, Microsoft Corp.'s Microsoft Mail, and Novell Inc.'s Message Handling Service and GroupWise). The installation and configuration program saved a checklist of tasks it couldn't do (such as changing the system start-up procedures), which we dutifully printed and followed exactly. That was it: We were up with basic connectivity, and it wasn't even dinnertime.
Well, not exactly. There's a certain amount of hand-waving when it comes to getting the PMDF-LAN E-mail systems configured for PC clients and that took an extra day. Users who are comfortable in the DOS environment won't find the LAN side of the setup daunting. If you're coming from Digital Equipment Corp.'s OpenVMS or Unix side and have long avoided PCs, you'll be in for a rude awakening. To properly install PMDF-LAN, you have to be comfortable in both the mail hub environment (either OpenVMS or Unix) and in the PC client environment.
The installation procedure and documentation walked us through moving a single message from the LAN E-mail system into PMDF and back, and that worked fine. The key is that there's an extra piece in the picture -- a little MS-DOS PC -- to move E-mail back and forth. It has to pull E-mail from the LAN E-mail system to give it to PMDF and vice versa. If that PC gets stuck, hung, lost, or confused, either the E-mail doesn't move back and forth, or you get infinite copies of each message sent in one direction or the other.
If you're an MS-DOS or Windows NT guru, you can probably whip up a set of .BAT files, protocol stacks, and other procedures to make sure this poor little PC keeps running reliably. It was no problem for us, but it doubled the amount of time we spent installing that part of PMDF.
Most E-mail packages store mail in a proprietary format and require a bridge to translate the message to a non-proprietary format. For example, with cc:Mail, we had to install Lotus' Import/Export package (it allows messages to go in and out of cc:Mail post offices), which comes with the cc:Mail Router software. All of this hunting took a couple of days, most of which we spent waiting for overnight delivery services to do their part. Fortunately, the PMDF documentation gave us all the information we needed to prepare, including the part and model numbers of the PC software.
By the end of the first week, we were sending test messages among all of the LAN E-mail systems, Bitnet, the Internet, our corporate DECnet, and out to alphanumeric pagers, laser printers (which don't reply to messages), and Windows and Macintosh clients running Qualcomm Inc.'s Eudora Light, a Post Office Protocol (POP)/Simple Mail Transfer Protocol E-mail package.
The second week, we focused on bringing up X.400, Digital's TeamLinks and All In 1 mail via Digital's Message Router, and the fax gateway.
Getting Message Router and TeamLinks installed was no pleasant picnic, but making PMDF talk to them only required a few hours of work. PMDF's configuration procedures have the same expert and beginner modes, which make it easy to answer the right questions and get the software running immediately.
In our case, PMDF's checklist gave us a single command to enter on our existing Message Router installation, and we were done. Be warned, however, that if the Message Router network is complex, the PMDF configuration is much more difficult.
Setting up the fax gateway also was pretty simple, although we had to deal with recalcitrant modems and communications servers along the way. Again, we leaned heavily on the documentation to speed our installation. PMDF is not one of those packages you can operate without reading the manuals. Innosoft says it supports Class 2 fax/modems, but highly recommended that we use a modem of a small set of brands. Not wanting to tempt the fates, we pulled an old modem from MultiTech Systems Inc. off the shelf. It got along well with our fax software. We were sending and receiving faxes between two PMDF-connected fax/modems within a day.
One disappointing part of PMDF's fax support is that it's really just an E-mail-to-fax gateway; it doesn't offer the ease of use or options to which most users are accustomed.
Although PMDF can work with your printer driver under Windows or under the Macintosh Chooser, it's not always convenient. If we wanted to fax a document, we had to first save it as a Postscript file, pull it into our LAN E-mail package, then mail it to the fax gateway. This requires putting a tag at the beginning of the file to specify the name of the recipient.
However, this only works reliably if you're generating ASCII. You can't easily send a Microsoft Word or PowerPoint file without fiddling with settings beforehand. The fax gateway has some nice features for high-volume corporate use, but it isn't a good general-purpose solution.
Installing the X.400 gateway was not a pleasant task. X.400 requires Digital's networking software, DECnet/OSI (Version 3.1 and later for Digital Unix; Version 5.7 and later for OpenVMS). Unfortunately, making DECnet/OSI work just to send X.400 E-mail is a little like going from San Francisco to Los Angeles via Tokyo, Moscow, Paris, and New York. It can be done, but it seems like a lot of work for a pretty simple task. We spent four days arguing with Digital, our X.400 vendor, and the phone company just to move a single X.400 message in and out. PMDF wasn't a barrier, but it wasn't much help, either.
Contrary to setting up the backbone and the other ancillary products, setting up the X.500 software wasn't entirely bug-free. A large part of four days was spent finding problems in the X.500 package and getting patches from Innosoft. To its credit, we got new versions amazingly fast, usually within a few hours of reporting a problem. The X.500 directory is the newest piece of PMDF, and it definitely shows its age -- young and not fully tested (it began shipping in the summer of 1994). If privacy isn't an issue and you want to link your directory to the global X.500 directory, you have to notify the U.S. "wizards" (X.500 administrators) via E-mail. It took about a week to make links to us. (You can try this yourself: Point your X.500 browser to c=us, st=arizona, o=opus one. This will get you in the X.500 InfoWorld test directory.)
In general, installing PMDF was really easy for the easy parts and really hard for the hard parts. In some places, Innosoft could take a little more initiative in providing bug-free software, tools, or better documentation.
Directory maintenance
* Innosoft could take a lesson from Alisa Systems Inc. about directory synchronization. See our product analysis of AlisaMail in the Nov. 7, 1994, issue, page 74.
PMDF e-Mail Interconnect 5.0: GOOD
Innosoft could learn something from Alisa Systems Inc.'s AlisaMail about directory synchronization. It does not offer an out-of-the-box directory- synchronization system, but takes a toolkit approach that's as flexible as it is inconvenient. Although you get all of the tools you need to synchronize your E-mail systems, you have to put them together yourself. One of the hardest parts of our testing was deciding which options to evaluate. For example, PMDF let us synchronize our directories so that all of our E-mail packages would look the same. It also let us use an external directory to store information -- and offered a choice of several others, including X.500 (an extra-cost option) and Ph, a free directory initially designed by the University of Illinois.
PMDF includes tools to synchronize directories from LAN E-mail packages (Lotus Development Corp.'s cc:Mail, Microsoft Corp.'s Microsoft Mail, and Novell Inc.'s GroupWise) as well as the directory that comes with Digital Equipment Corp.'s Message Router package, Distributed Directory Service. We tested the synchronization of those four and used PMDF's X.500 product to create a centralized directory. Because the documentation takes a cookbook approach to directory services, this phase of the testing went smoothly. Altogether, we spent four days getting everything running.
In the X.500 world, the Directory System Agent (DSA) is responsible for maintaining all directory information. The DSA acts as the server in this client/server protocol. PMDF's X.500 DSA is based on the ISO Development Environment Consortium's Quipu package, which most commercial X.500 packages have chosen to use. PMDF-X500 uses a combination of disk and memory to store directory information for the best response time without adding a relational database. Of course, most PCs won't have a fully ISO-compliant stack, so Innosoft also provides a lightweight directory-access protocol server, which lets TCP/IP-connected systems retrieve X.500 information.
Storing information in X.500 directories is a mixed blessing. Using a commonly accepted format and a distributed database, directory synchronization can be combined with directory access from intelligent mail products. Unfortunately, none of the LAN-based E-mail packages do that; they all stubbornly insist on using their own internal directories. Of course, everyone claims that X.500 support is just around the corner, but the only E-mail system we found that had X.500 built in was Digital's native OpenVMS mail -- not a very popular option.
PMDF relies on the network manager to build a scheduler to automatically export and import directory information at the appropriate time. As network directory information surfaced to the X.500 directory, we updated the X.500 directory and generated update commands for each E-mail system.
Because we were doing this as a test, we manually applied updates to each directory rather than building the necessary scripts. However, just as in the setup of PMDF-LAN, this is a hole that Innosoft needs to fill. We had to build procedures to extract, reconcile, and then redistribute the information to the directories.
Getting the directories synchronized was a chore, but once everything settled down, it all worked beautifully. We pulled addresses up without problems, using the LAN E-mail packages we had included in the synchronization. Things worked equally well whether we were drawing names from a local directory or querying the X.500 directory itself.
To test the X.500 query capabilities, we needed X.500 browsers. Innosoft includes several browsers for users located on OpenVMS systems: a simple command-line browser, an X Windows system browser, and a pop-up search capability that's available within the native mail system. The pop-up browser was especially nice because once we found the address we were looking for, it was automatically put into the E-mail message.
For Windows, Windows NT, and Macintosh clients, you can download copies of freeware X.500 browsers from Innosoft's World Wide Web page. These worked fine as well. Innosoft is also now shipping an X.500-to-World Wide Web gateway so you can use Web browsers such as Netscape Communications Corp.'s Navigator to query the directory.
Innosoft also gave us an early copy of its X Windows system management interface to the X.500 directory. This was a great help because we could see the directory from the user point of view and perform management operations at the same time. (This beta software has since been included in the full PMDF product.)
The alternative to a GUI-based interface was to drop back to the command line for management and manipulation. Because Innosoft's directory synchronization is made up of tools rather than a single integrated product, there were times when we had to use the command line to manipulate directory information, particularly when importing and exporting directory information from the LAN packages.
One of PMDF's more interesting features is its capability to handle centralized naming. The X.500 directory is integrated into the E-mail backbone itself 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. (Fuzzy name matching gives you the closest match to the name, instead of throwing out your request if the spelling is incorrect.) For example, because there are multiple people named "Snyder" in our E-mail system, a message sent to "Snyder" would return a list of the Snyders along with other relevant information, such as phone number or title. PMDF wouldn't let us add two identical users to the X.500 directory, but if, for example, you try to synchronize Joel Snyder from cc:Mail with Joel Snyder from Microsoft Mail, the X. 500 directory accommodates both names.
If you then send a message to Joel Snyder, PMDF will send a message that there are two Joel Snyders and will identify which Joel Snyder goes with which E-mail package.
For outgoing E-mail, PMDF also integrates with the directory. As mail passes through the backbone, PMDF changes the address to an alias set by the system manager (setting an alias simply requires defining a rule). For example, real addresses inside the network included the E-mail system name. That means that a user Macanudo on the cc:Mail system would be called macanudo@ccmail.opus1.com. But using PMDF's directory, we could publish her address as just Julia.Macanudo@opus1.com. PMDF took care of rewriting that address in both directions.
After we finished testing interoperability, we went back and did the same tests using the directory. We got the same results with one difference: Not only was nothing lost, but everyone's E-mail address got cleaned up by the PMDF directory.
Interoperability
PMDF e-Mail Interconnect 5.0: VERY GOOD
As testers, we like things to break. That tells us we're testing the right things. Unfortunately, Innosoft doesn't seem to believe in broken software. When we thought we had caught Innosoft with its pants down, we told the company about it. Generally when that happened, we received an answer telling us how we had misconfigured (or forgotten to configure) our system. This held true for situations in which PMDF, despite all its advantages, couldn't forestall messages with truncated subjects and lose a complete list of recipients.
The bottom line on PMDF interoperability was close to super, relatively speaking. We couldn't find a problem in our mail exchanges that was not apparently due to basic bugs in the LAN E-mail systems we tested. But the bottom line is that E-mail interoperability is far from perfect; there are inherent defects within current E-mail systems. Therefore we couldn't give PMDF a perfect score. (This holds true for all of the E-mail interoperability software we've evaluated in the past few years.) Furthermore, our tests were aimed not only at whether different packages interoperate, but at how well PMDF handled the inevitable bugs and configuration problems we experienced.
The first set of tests for raw connectivity -- the recipient tests -- helped to shake out most of the problems in our network. We ended up losing a few messages in the process, but it was always a configuration error. Of course, had Innosoft given us a better set of tools for transferring to the LAN E-mail systems, we probably wouldn't have lost anything.
But all in all, we discovered that PMDF is remarkably resilient. For example, if a message couldn't be delivered, PMDF would hold it and retry delivery as often and for as long as we wanted. Sometimes we piled up lots of messages trying to make our test work. When everything was finally configured properly, we could tell that it had started working by the frantic beeping of the PCs at each end. If we sent a message to someone who was not a user at that address, PMDF would send us an error message and tell us that the address was illegal.
We also discovered that unless you tell it otherwise, PMDF will cut up an alphanumeric-pager message into pager-size pieces and transmit them one after the other -- which solves the problem of a limited display but results in a slew of messages. We, like most people, got impatient: It took our pager about a half-hour to receive and process 40 messages. The default partitions the message into 80-character chunks, but you can always tell PMDF to truncate messages at a certain number of characters.
Our second set of tests were the reply-to tests. After running through the first set, this second set was a cinch. For each message we received, we replied twice: once to the sender and once to every other recipient on the list.
It was during our third group of interoperability tests, attachments, that we learned the most about the differences between E-mail systems. Some systems, such as Microsoft Corp.'s Microsoft Mail, Lotus Development Corp.'s cc:Mail, and Novell Inc.'s GroupWise, don't know anything about the files they attach to E-mail messages. Files have names and it's up to the user to determine the file type from the name. If you get a file called POST.PPT, you have to be able to identify it as a PowerPoint presentation and not a WordPerfect document.
Inside PMDF, everything is converted to Multipurpose Internet Mail Extensions (MIME), the Internet standard for multimedia mail. MIME follows two steps. First, it labels each piece of each message by type. Thus, a Microsoft Word document is called a Word document, no matter what the file name is. Macintosh users will appreciate this. Second, MIME encodes the pieces so that they can be sent across the network without losing or corrupting data.
PMDF maps between MIME's rich scheme for labeling and encoding documents and the more limited style of LAN E-mail systems. However, we had to define each file name for PMDF (it defaults to shipping it as an unknown type) so that it could convert into and out of MIME without losing any information. But once we figured out what our standard document types were, we were able to send them between the LAN E-mail systems and other systems, such as X.400 and Post Office Protocol mail using Qualcomm Inc.'s Eudora Light, without losing anything.
In many ways, MIME was a panacea for our E-mail problems. Where other E-mail backbones had mangled text, inserted extra carriage returns, or simply lost data, the MIME encapsulation at the heart of PMDF won our applause and accolades. This mail backbone stubbornly refused to fold, spindle, or mutilate our mail.
In our standard testing, PMDF could not magically work around limitations in the LAN E-mail systems. For example, with Microsoft Mail, we saw that subject lines were truncated at 40 characters when going from Microsoft Mail on Windows NT to the other E-mail systems. When we asked Innosoft about this, they faxed us the pages from Microsoft's technical library, which document this limitation in Microsoft Mail. When we complained that file creation dates were lost when they were sent via E-mail, we discovered that none of the LAN packages were passing the file creation dates to PMDF.
After our most difficult tests were finished, we could not find a single case where PMDF lost mail, wrote out addresses that couldn't be replied to, or mangled our attachments.
Documentation
PMDF e-Mail Interconnect 5.0: VERY GOOD
PMDF's documentation, including manuals for system managers and users, is decidedly above average. Much of the work of configuring E-mail systems is figuring out how to handle a strange situation. From the documentation, it looks like Innosoft has not only learned how to handle such situations but has documented those in the manuals. For example, when we needed to know how to set up centralized naming as part of our directory synchronization testing, the documentation not only gave us the proper commands, it also explained how and why such a procedure would be done.
The documentation covers all aspects of system management, tuning and performance management, and user applications. The system managers' guide includes two large manuals, an installation guide, and release notes. The users' manual is mostly applicable to Digital Equipment Corp.'s OpenVMS users. All of the optional add-ons for PMDF are covered in the core documentation set, with the exception of the X.500 package. This made it very easy to find things -- we weren't constantly flipping back and forth between books to link all the pieces together.
Innosoft also provides all of the documentation on-line, and the on-line manuals are slightly more accurate than the printed versions. To get the most up-to-date information, you would have to combine the printed manuals with a set of release notes. For quick reference, we found that the on-line documentation was a smart choice. The fact that Innosoft provides both types of documentation resulted in extra points and a high score. The only thing both the written and on-line documentation didn't have was enough information on the X.400 gateway -- which, although inconvenient, wasn't a big deal considering the fact that most users won't require this information.
Support
* To use Innosoft's try-before-you-buy program, call (818) 919-3600. You can try PMDF free for 30 days.
PMDF e-Mail Interconnect 5.0: EXCELLENT
Unlimited technical support is available for free, as are upgrades, as long as PMDF is under a maintenance contract. You can reach Innosoft on a toll-free line or via E-mail. Support hours are from 9 a.m. to 5 p.m. Pacific time by phone and E-mail; however, there's always someone at Innosoft checking the E-mail, so you can usually get support during off-hours. PMDF also comes with a 90-day warranty. None of the support is available if your maintenance contract expires, and you won't get any new releases unless you pay the maintenance cost each year; it isn't cheap, either. Maintenance costs $780 for the core backbone product; $364 for PMDF-LAN; $1,100 for PMDF-MR; $1,300 for PMDF-X.400; and $1,300 for PMDF-X.500.
Innosoft offers a try-before-you-buy program: Call and you can try PMDF for 30 days for free. It's not like testing a screen saver, but at least the company doesn't ask you to pony up $10,000 just to take a good look at the manuals.
Innosoft also runs a mailing list, a newsgroup on the Internet, and has a World Wide Web site with plentiful support information, including patches and bug fixes as well as white papers and technical reports. It doesn't get much better than this.
The E-mail backbone business is a complex one. Fortunately, the folks at Innosoft were there to help us fight the good fight for uncorrupted attachments and unadjusted address lists. It was rare for us to have a problem unsolved for more than a few hours. The few times that this happened, we always got an acknowledgment telling us who was going to answer our question and when.
The best thing about PMDF support is who you're talking to: the developers. These are actual, real, living and breathing programmers who have been there, done that, and printed up their own T-shirts. We quickly learned who had written what pieces of the product by noting who answered our questions. In fact, Innosoft developers are active members of the Internet E-mail standardization effort and are coauthors of the MIME specifications and the E-mail Mail and Directory Management specification, MADMAN.
Having the developers do technical support meant that when we did unearth a bug, we usually had an updated copy of the software within a few hours. Because we were one of the first sites to use the new PMDF, Version 5.0, we found a handful of problems, all of which were fixed within days.
One hard part of the E-mail backbone business is having to deal with other companies' poorly written software. We had a complex problem involving strange behavior in cc:Mail during our directory synchronization testing, and we got a three-page message from one of the developers explaining exactly what the problem was, the best way to work around it, and how cc:Mail was fundamentally broken in this regard. Innosoft didn't just solve our problems; its staff explained what was going on, so working with its technical support team was a learning experience every step of the way.
Value
PMDF e-Mail Interconnect 5.0: VERY GOOD
One thing we've learned in all this backbone investigation is that this is not a product for small businesses. PMDF fits into a specific niche: big E-mail. PMDF meets some other needs: it's dependable, reliable, manageable, and trackable. That means that if someone sent a message from here to there, you could not only make sure that it got there, but you could see entries every step of the way.
Not everyone has the kind of E-mail environment that would profit from a product such as PMDF. The least expensive configuration starts at $6,000 for the backbone, but the pieces we tested, including the backbone, LAN, Message Router, X.400, and X.500 connections, bring the total price to $27,300. But few would have as complex a network as we built, so typical costs should be lower. Add to that price your hardware: A midrange Digital Equipment Corp. Alpha 250 capable of handling the load of a medium-size corporation would be at least $10,000. Finally, you've got to find someone who can manage Digital's OpenVMS or Unix system. But you should balance these costs against the money required to build gateways to E-mail packages that range from almost free to around $50 per desktop.
It would be nice if PMDF were inexpensive enough to be affordable for all E-mail environments, but it's not. For organizations with more than 500 mailboxes (our test scenario), PMDF is well priced and reasonable. Like any major network application, it requires some management and, as we've seen, a lot of configuration.
What's the value of having all of your E-mail reliably connected and managed? For organizations that depend on E-mail for intraorganizational communication, PMDF is the best solution we've seen. If users have become so disillusioned with the quality of the E-mail gateways that they no longer trust E-mail for anything important, PMDF may also be a good investment because it can help restore confidence.
On the other hand, if E-mail management is a catch-as-catch-can task that never gets any attention or serious thought, throwing an E-mail backbone at the problem isn't going to help.
Report Card E-mail interoperability software
PMDF e-Mail Interconnect 5.0
(Weighting)
Performance:
Setup (150) Good 93.75
Directory maintenance (225) Good 140.62
Interoperability (225) Very Good 168.75
Support and value:
Documentation (100) Very Good 75.00
Support (200) Excellent 200.00
Value (100) Very Good 75.00
Final score 7.5
GUIDE
InfoWorld reviews only finished, production versions of products, never beta-test versions. Products receive ratings ranging from unacceptable to excellent in various categories.
Scores are derived by multiplying the weighting of each criterion by its rating, where:
Excellent = 1.0 - Outstanding in all areas.
Very Good = 0.75 - Meets all essential criteria and offers significant advantages.
Good = 0.625 - Meets essential criteria and includes some special features.
Satisfactory = 0.5 - Meets essential criteria.
Poor = 0.25 - Falls short in essential areas.
Unacceptable or N/A = 0.0 - Fails to meet minimum standards or lacks this feature.
Scores are summed, divided by 100, and rounded down to one decimal place to yield the final score out of a maximum possible score of 10 (plus bonus). Products rated within 0.2 points of one another differ little. Weightings represent average relative importance to InfoWorld readers involved in purchasing and using that product category. You can customize the Report Card to your company's needs by using your own weightings to calculate the final score.
The Test Center Hot Pick is InfoWorld's award for outstanding products. To receive the Test Center Hot Pick seal, a product has to offer what InfoWorld deems to be a stand-out feature or technology that is unusually valuable or revolutionary compared to competitors. The product must also score at least satisfactory in all Report Card categories and receive a final score of 7.0 or more.
ANCILLARIES
PMDF includes a $6,000 backbone per geographical-site license. Innosoft also offers six ancillary products:
* PMDF-LAN integrates all PC LAN E-mail systems; $2,800;
* PMDF-MR hooks up Digital Equipment Corp.'s Message Router; $5,500;
* PMDF-MB400 is the Simple Mail Transfer Protocol/Multipurpose Internet Mail Extensions connection for Digital's Mailbus 400 Message Transfer Agent; $5,500;
* PMDF-X400 is the gateway that ties into any X.400 mail system; $6,500;
* PMDF-X500 provides X.500-based directory service; $6,500; and,
* PMDF-Fax provides E-mail to a fax gateway; $5,500.
STANDARDS
The X.400 message handling system is the International Standards Organization's decade-old original messaging standard. Other common proprietary standards include Microsoft Corp.'s Messaging API, Lotus Development Corp.'s Vendor Independent Messaging, and Novell Inc.'s Message Handling Service.
According to International Data Corp., more than 50 percent of installed mailboxes represent different standards, but Simple Mail Transfer Protocol and X.400 are beginning to tie those systems together so they can communicate.
MIME
Because PMDF supports Multipurpose Internet Mail Extensions (MIME), the Internet standard for multimedia file attachments, we had no problems sending attachments between disparate systems. PMDF converts all attachments to MIME, which we found to be a better method of labeling and encoding pieces than typical LAN-based E-mail systems. Although we did have to define each type of file, it was a small price to pay considering the fact that we never lost any information during conversion.
DOING ITS BEST
Although PMDF could do a lot of things, it could not get around the limitations of LAN-based E-mail systems.
Unfortunately, this is the state of the art, and no backbone we know of can correct the defects of existing systems.
FOR THE FORGETFUL
X.500 is the international standard for directories. If you think Internet addresses (such as jms@mail.opus1.com) are complicated, you haven't seen anything yet. An X.500 address is an entire database entry, so you can send mail to anything that uniquely finds the database entry. For example, in X.500, if you can't remember someone's address, you could send a message to their phone number or office location instead. X.500 is an excellent solution for folks who can't remember E-mail addresses.
THE REVIEWERS
Joel Snyder and Jan Trumbo are senior partners at Opus One, a consulting company in Tucson, Ariz., which specializes in network and telecommunications technologies. Together they have installed more than 50 corporate E-mail backbones for clients stretching from San Francisco to Moscow. They can be reached via E-mail at jms@opus1.com and trumbo@opus1.com.
* According to International Data Corp., E-mail is the No. 1 application used on the Internet, with World Wide Web browsing coming in second, followed by file transfer and Usenet newsgroups.
* By summer, expect to see PMDF-LAN ported to Sun Microsystems Inc.'s Solaris. Not only that, but X.500 will be available on Digital Unix, and Innosoft will also offer support for Lotus Development Corp.'s Notes.
* Please send questions, comments, and feedback concerning this article to Victor R. Garza at victor_garza@infoworld.com.
RELATED ARTICLES
Nov. 13, 1995, page 118; A gold-plated solution
Although Lotus Messaging Switch is a solid solution for integrating E-mail systems on different platforms, its price may scare away users. On the other hand, this article details the many benefits of choosing this solution.
Nov. 7, 1994, page 74; AlisaMail: The best yet, but don't attach your sales contract
This product ran on a VAX and sold for about $40,000; overall, we found it to be a pretty good solution.
RESULTS AT A GLANCE
The E-mail network we set up in our lab took weeks to put together -- we glued together E-mail systems in ways that would try the toughest switch available. But as we laid out challenges of interconnection, conversion, routing, and addressing, Innosoft International Inc.'s PMDF e-Mail Interconnect 5.0 rose to the occasion. There may be no absolutely perfect E-mail backbone in the world, but PMDF has come closer to ideal than any we've seen so far.
Compared to some of the other E-mail interoperability software we've reviewed, which cost upward of $100,000, PMDF is a bargain. Our configuration only cost $27,300 for the backbone and four of Innosoft's ancillary products. And our system was quite complicated, so you can expect to spend slightly less.
For starters, PMDF can link most popular PC LAN-based E-mail systems, mainframe E-mail systems (such as Digital Equipment Corp.'s All In 1), X.400 mail, fax services, and Simple Mail Transfer Protocol Internet gateways to a single, smooth-running backbone. We used PMDF to merge 15 completely different kinds of messaging systems into one huge network where no one had to worry about which E-mail system his or her correspondents were using.
Interconnections aside, we prize PMDF for letting network managers fiddle with each message as it passes through the system, and for its capability to rewrite addresses, convert attachments, and reroute mail. Aside from that, PMDF's high-powered E-mail management provides a log of every message and keeps statistics on the general health of the E-mail network.
We also liked the fact that PMDF came with a lot of extras, including mailing-list servers, links to paging services, directory synchronization tools, and a program to sort and answer your E-mail while you're on vacation.
Perhaps the most outstanding aspect of PMDF is how it does everything it promises. During our lab tests, we never found anything that it couldn't do -- that is, if we were willing to go through the trouble to configure or program it. In the words of one Innosoft developer: "If you insist on hanging yourself, PMDF will provide all the rope."
When we couldn't solve a problem, Innosoft's technical support team responded to our E-mail within hours (even on weekends) to steer us straight.
Building an E-mail backbone using PMDF is not for the faint of heart. The configuration is complex and can be daunting. But also keep in mind that PMDF is not for trivial E-mail problems: It's perfectly suited for enterprisewide E-mail networks with hundreds, thousands, or even hundreds of thousands of users.
PMDF runs on heavy-duty systems, either Digital's OpenVMS or Digital Unix, and requires lots of memory and plenty of disk space. You can't build a corporate E-mail network using a couple of 486 PCs running Windows, and fortunately, Innosoft doesn't try.
--------------------------------The Score-------------------------------
PMDF e-Mail Interconnect 5.0 7.5
