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.
<
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.
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.
<
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.
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.
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.
__________________________________________________
Picking A Backbone
* 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.
__________________________________________________
Tips for Growing E-Mail Networks
* 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).
* 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).
* 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.
* 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):
Copyright © 1995 Macworld Communications, Inc.
Challenge Two: Interoperability
Challenge Three: Directory Services
The Last Word
Sidebar
* 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?
Sidebar
CE Software QuickMail
Lotus cc:Mail
Microsoft Mail
Any Mail System
E-Mail Comparison Chart
File size: 6 K
