Meeting the E-Mail Challenge


By Joel Snyder

Electronic mail has wedged itself firmly into the consciousness of most Mac users. The easily realized benefits of internal electronic communications sent E-mail into the limelight, while the potential for fast and easy communication with the rest of the world over the Internet added a million watts of bright white spotlight.

The goal of having an organization-wide E-mail system bring easy communications to everybody's desktop looks good in a strategic plan, but network managers charged with making it happen have their hands full. Building large E-mail systems often involves making separate systems interoperate, share directory information, and work across different platforms.

I looked at the problems companies have in building large E-mail networks and the software tools that are available to solve them. The news is good: large E-mail networks that work well are possible. By finding the right software tools, spending time planning, and making a few compromises, network managers can build enormous networks that work.


Challenge One: Scalability

Ask most organizations about their Mac-based E-mail, and you're likely to hear about CE Software's QuickMail (100 users $4749; 515/221-1801), Lotus Development Corporation's cc:Mail (server software $95, 100 users $4760; 415/961-8800), and Microsoft Mail (server software $269, 100 users $3659 estimated retail price; 206/882-8080). According to the market-research firm International Data Corporation, this trio accounts for more than 6 million mailboxes on PCs and Macs. The three packages use a similar paradigm for electronic mail. A client user on a Mac or PC connects to a server (called a post office or mail center) to retrieve, send, and file electronic mail.

End users of these applications appreciate the interfaces that make organizing mail and sending documents simple. Training costs are low, but experienced users may find these interfaces limiting.

Network managers aren't so happy with the server side of the LAN-based E-mail equation. Mac and PC E-mail systems are designed for small networks with only a few users. Once the mailbox count jumps to 500, let alone 5000 or 50,000, most products begin to break down.

E-mail is a disk-intensive and network-intensive application. An E-mail user can easily send and receive 20 to 100 messages a day. Multiply that by a couple hundred users, and you'll never get a single AppleShare server to handle the kind of load E-mail demands. Apple's high-speed servers, such as the Apple Workgroup Server 8150, just can't move more than about 500 kilobytes per second through the Macintosh Operating System, the AppleShare software, and the AppleTalk protocol stacks.

For realistic response time, even high-speed servers should be limited to between 20 and 150 active E-mail users--fewer if you use E-mail to move large files around. If you've got an active user community larger than that, plan for multiple servers now. Don't try to save money on your server--this is one place where speed really does count. For best results, choose an Apple Workgroup Server with two SCSI buses and install the RAID software that comes with the server, spreading the load across the two buses. In my tests using Apple RAID in dual-SCSI configurations, E-mail server response time improved by between 9 and 12 percent. (For more information about RAID, see "The RAID Option," in this issue.)

These basic architectural limitations aren't the only things holding back performance. Although vendors use the terms client and server, this isn't true client-server computing: the E-mail server is typically little more than a file server, and the clients use it primarily as a shared storage medium. So instead of asking for and receiving a message (as would happen in a true client-server scenario), the steps involved in getting a message might be opening a directory, then reading the directory, closing the directory, opening a file, reading the file, and closing the file. This puts a tremendous load on the file server, as it responds to low-level requests for disk services rather than high-level requests for E-mail messages.

File servers handling mail are also heavily stressed if you use your E-mail network to share files. To keep performance high, teach users to use shared disks on a file server or with System 7 file sharing, public folders, and folder protections--instead of E-mail--to distribute large documents. Also consider providing people who share large documents or who work on group projects, with alternatives to E-mail such as On Technology's Instant Update ($495; 617/374-1400) or Pacer Software's PacerForum ($549 for five users; 508/898-3300).

E-mail vendors use a not-really-client-server approach because the E-mail market demands it: vendors are writing for the personal-computer market, where a network of 20 workstations is much more common than a network of 200, and network managers prefer an E-mail server that sits easily on their existing AppleShare server. This isn't some hidden truth. When I tested Microsoft Mail, cc:Mail, and QuickMail, the vendors gave me frank admissions about the capacity limits of their products. For tips on preparing for growth with each of these E-mail systems, see the sidebar "Tips for Growing E-Mail Networks."

<>Once you have more than a few hundred users in a single location, you can either increase the number of post offices (servers) or find software (not QuickMail, cc:Mail, or MS Mail) that can handle a single large post office. Although scaling up by adding post offices looks attractive--because it includes known servers, known clients, and existing practices--the cost for adding and maintaining many sites is higher than that for making the leap to a different E-mail system: a true client-server system costs less per user to own, manage, and operate. However, this cost shows up as one huge budget item rather than as lots of little budget items.

One way of stretching the single-post office option is to move out of the AppleShare arena and into a faster, AppleTalk Filing Protocol (AFP)-compatible server. For example, Windows NT's built-in file server offers higher performance than AppleShare does on equivalent hardware. In fact, when it ships, the Microsoft Exchange Server, the next-generation server for MS Mail, will require a PC running NT Advanced Server (NTAS) 3.5.

Digital Equipment Corporation's (DEC) TeamLinks ($52 to $80 per user; 508/493-5111) client-server E-mail system is designed to support thousands of users, including Mac, Windows, DOS, dumb-terminal, and X window system users. The TeamLinks server, called Mailworks (starts at $930), runs on Unix and OpenVMS. Clients connect via DECnet, TCP/IP, or dial-in.

DEC plans to provide client-server access to LAN E-mail systems, such as cc:Mail and MS Mail, by letting existing clients plug into a Mailworks server. This would combine the advantages of a high-performance mail server with a familiar user-interface. Unfortunately, the Mac versions won't ship until later this year.

If you're considering using another platform such as Unix for the server, check out Eudora, from Qualcomm (for 2 to 49 users $45; 619/587-1121), which has mail clients for Macs and Windows PCs. Eudora's automatic filtering and categorizing of incoming E-mail messages equals that of the most sophisticated filters of the Mac E-mail systems.

<>In many cases, more than one post office (or server) is required. Geography, lack of resources, and an installed base of different mail systems are all factors that might necessitate a multiple-post office network. When many employees are spread across many locations, but no single location has more than a few hundred users, a single post office is not cost-effective.

If you must break up your network into multiple post offices, put as many users as possible on each to keep management costs down. When you need to link only one or two E-mail post offices from different kinds of E-mail systems, gateways can accomplish the task.

With the various gateways that are available you should be able to build a system that can link most Mac-based E-mail systems to each other. Many vendors--for example, Microsoft--sell gateways for their E-mail packages. But in my experience, third-party gateways--particularly those to SMTP mail--are more reliable, easier to manage, and offer better support than the gateways offered by the mail-package vendors. The reigning royals of the third-party, Mac E-mail-gateway business are StarNine Technologies (510/649-4949) and InterCon Systems Corporation (703/709-5500).

As the number of E-mail servers grows, gatewaying from post office to post office becomes a nightmare of configurations and customizations. If your E-mail network looks like it will ever have more than three post offices, you should immediately begin to investigate an E-mail backbone. Unlike gateways, which require one-to-one connections between systems, every E-mail post office connects to the backbone directly, and all E-mail travels over the backbone.

Electronic-mail backbones are particularly useful when you need to link heterogeneous E-mail systems, because backbones solve not only scalability problems but also interoperability problems.


Challenge Two: Interoperability

Very few large E-mail networks are composed of just Macintosh users. Large organizations tend to grow computing systems over time, and users are loath to give up what they're used to. This means that a network manager trying to build an organization-wide E-mail system may have to link E-mail from minicomputers and mainframes. Even if the plethora of mainframes have been banished to computing purgatory, the problem of multiple personal computer E-mail systems often raises its ugly head: any site with thousands of users has streams of parallel evolution that guarantee the need to link personal computer systems.

Add to this mixture some links to the outside world of the Internet, X.400, and other public E-mail systems, and you'll find that interoperability is more difficult than E-mail vendors make it sound.

<>To build an E-mail backbone, you need to find a backbone that can connect to all of your E-mail post offices.

Mac network managers won't be happy to hear that the core software from backbone vendors requires a Unix or OpenVMS minicomputer. However, minicomputers offer advantages. Because these platforms run multitasking operating systems, a good backbone won't have to stop all E-mail to deal with a long or complex message. Backbones are responsible for document conversion between different E-mail systems, a task best done in the background. Also, only minicomputer backbones provide in-depth logging facilities that allow you to trace a message's path through a system step-by-step.

The following are the leading companies' personal computer E-mail backbone products, along with entry-level prices: Alisa Systems' AlisaMail (from $10,000; 818/792-9474), The Boston Software Works' InterOffice (from $4500; 617/482-9898), Control Data System's MailHub (from $20,500; 612/482-6736), Hewlett-Packard's OpenMail (from $144 per user; 800/637-7740), Innosoft's PMDF (from $6000; 818/919-3600), Wingra's Missive (from $6000; 608/238-4454). All of these backbone vendors support MS Mail, SMTP, and cc:Mail. Only Alisa Systems and The Boston Software Works support QuickMail. Most of the vendors support X.400 and Novell MHS.

Choosing a backbone vendor can be treacherous and expensive. The lists of features, platforms, restrictions, and options are complex and confusing. Each product takes a slightly different approach to moving E-mail into the backbone. Little features such as document conversion can turn into major stumbling blocks if the software doesn't support the document types you need. For more about finding the package that is right for you, see the sidebar "Picking a Backbone."

In my experience, E-mail backbone products from Alisa, DEC, and Innosoft provide the best management and user interfaces and the greatest compatibility with a wide range of E-mail systems.


Challenge Three: Directory Services

One benefit of an electronic-mail system is a unified directory of users, but managing E-mail addresses is a problem when multiple E-mail systems are involved. Microsoft, CE Software, and Lotus all support directory synchronization for their own post offices but don't give you any help with a heterogeneous environment. If you insist on having one organization-wide E-mail directory, be prepared to spend time and money to run it.

One mistake many organizations make is trying to make E-mail addressing as simple as knowing a person's name. As the number of E-mail users grows, this scheme backfires because names are not enough to uniquely identify individuals. To avoid this problem, add location-specific information to E-mail addresses.

Resist the temptation to attempt to include the corporate power structure in your E-mail addresses. If a dozen departments all coexist on the same E-mail server, assigning addresses based on who works for which department is unnecessary micromanagement--and is likely to cause mishaps and waste time while network managers try to keep up with the fluid movement of people and names.

Another approach to directory coordination is to simply ignore the problem and not support a unified E-mail directory. Organizations with a decentralized structure, such as most universities, have taken this tack and ignored E-mail directories or maintained them on paper or in a separate, uncoordinated database. In companies where users don't need coddling and can handle a few bounced E-mail messages, this is cost-effective. Directoryless E-mail is also good preparation for interaction with the Internet, where directories are few and far between.

Building a single directory across heterogeneous E-mail systems requires software to collect and reconcile directory information. Most E-mail backbone vendors include software and tools for maintaining a unified directory. For a backboneless environment or one where the backbone vendor doesn't support all your E-mail systems, use directory-synchronization software. StarNine Technologies offers Mac-based MailLink Directory Services ($2995). Hitachi Computer Products offers Unix-based SyncWare (starts at $4995; 408/986-9770).

If directories are important to you, insist on support for X.500, the ITU-T international standard for distributed directories. By storing your E-mail directory in an X.500-compatible format, you will easily be able to share it with the outside world when you link your organizational E-mail systems to the Internet or to a public X.400 E-mail network.


The Last Word

Building large, integrated E-mail systems requires planning with a corporate scope. It's equally important to set users' expectations early on. Large heterogeneous E-mail networks can be just as reliable and powerful as small systems if you pick the right E-mail backbone partner. You will find that some of the features of small networks, such as unified directory services and nearly instantaneous delivery of messages, may not be possible or desirable in larger networks. By planning and setting expectations, you can ease the growth into a true organization-wide E-mail system.

__________________________________________________
Sidebar

Picking A Backbone


* Know exactly what systems you have to link. Are post offices running on Mac or PC servers? What network transport do you use? Does the vendor support exactly that configuration?

* Know your applications. What kinds of documents are people mailing? Can the vendor convert between all of those types correctly? Insist on a demonstration using your documents.

* Know your hardware. Some backbones are hardware-software solutions; others are just software. If you already have Unix or OpenVMS systems, pick a server that will run on those. Most turnkey systems aren't as maintenance-free as vendors promise.

* Know your E-mail style. All backbones use some protocol internally to communicate; usually it is TCP/IP's SMTP/MIME (Simple Mail Transport Protocol/Multipurpose Internet Mail Extensions) or X.400. If the backbone's protocol is proprietary, choose another vendor. If you use a lot of SMTP or X.400, pick a backbone that matches your E-mail style. If you would use X.400 only to communicate across the backbone, you're probably looking at too complex a system.

* Know your vendor. Some integrate products from different companies. That can mean technical-support headaches when you have a problem. If you can get everything directly from the developing company, you'll get problems solved more quickly.

* Know your budget. Each backbone has different pricing. How much does it cost to add post offices and backbone nodes?

* Know your growth path. Macs should be able to connect directly to the backbone using a client-server protocol such as X.400 or POP3/SMTP.

* Know your buzzwords. If the vendor supports X.500 directory services or the emerging MADMAN (the Internet's Mail and Directory Management) management standards, it's a good sign. Any vendor you pick should support SMTP and MIME and have a gateway to X.400.

__________________________________________________
Sidebar

Tips for Growing E-Mail Networks


CE Software QuickMail

* Assign each department to its own mail center, but consolidate multiple mail centers on a single mail server to keep the number of users at around 250 per server.

* The ideal QuickMail server is a Quadra 800 or 900 system that has lots of disk space and is running System 7. QuickMail doesn't run on A/UX-based servers and won't run natively on Power Macs until the networking system software runs natively, according to CE Software.

* The biggest problem in large QuickMail networks is the surfeit of mail that users don't delete from the server. QuickMail has no automated archiving tools, so you need to keep a close eye on disk space and train users to delete or move mail once they've read it.

* For best directory synchronization, use StarNine Technologies' MailLink Directory Services ($2995).


Lotus cc:Mail

* Read the company's cc:Mail Router Administrator's Manual, which is the best document on building cc:Mail networks of any size. cc:mail Router ($95) is the add-on software required for a multiple-post office network.

* Don't use peer-to-peer communications; establish a central cc:Mail router and post office to poll the other post offices.

* Keep post offices at around 150 users, certainly no more.

* OS/2 reliability has greatly improved; use OS/2 to run multisession cc:Mail Router and cc:Mail Mobile for Mac ($195, add-on software for remote users).


Microsoft Mail

* A Windows NT post office on a fast server can handle about 200 users, no more.

* MS Mail on a Macintosh server has a much nicer user interface than on a PC server, but Microsoft will not upgrade the Mac server. Use the uglier but speedier PC-server version for a large network.

* Microsoft no longer offers any free phone support for its advanced-system products. Check in often with its fax-back service (800/936-4400) and CompuServe forum to pick up bug-fixes and updates.


Any Mail System

* When you install client software, you should make it as easy as possible to update it later via electronic software distribution, remote-management software (such as Farallon's Timbuktu Pro, $199; 510/814-5000), or Apple events.

* Use remote-management software to manage servers.

* Watch distribution lists, which can eat up your network if they're misused.

* Preconfigure clients to delete the text of the original message in replies as a default. Use ResEdit if you have to.

* If you have an Internet connection, provide alternatives (such as a conferencing system like Pacer Software's PacerForum) for users to read Internet-based mailing lists. Otherwise, you could end up with 20 copies of the same mailing list sending 1000 messages a day into your E-mail system.

__________________________________________________

Joel Snyder (jms@opus1.com) is a senior partner at Opus One, a Tucson, Arizona, consulting firm that specializes in the problems of building large networks. His book, Macworld Networking Bible, second edition (IDG Books Worldwide, 1994), coauthored with Dave Kosiur, has a chapter on E-mail integration for Mac networks.

Related File(s):
E-Mail Comparison Chart File size: 6 K

April 1995, page: 110-114

Copyright © 1995 Macworld Communications, Inc.