it is an enormous barrier to exchanging, archiving, and retrieving vital corporate information.
Salvation may be within reach, thanks to e-mail systems based on Internet standards.
The core Internet protocols provide a lowest-common-denominator environment for sending key messaging functions across different e-mail architectures while opening the door to communicating with the outside world.
Right from the start, the Internet was built for large-scale implementations. Its proven family of protocols lets you send and receive e-mail to or from anyone with an IP connection. SMTP has proven its messaging reliability over almost two decades. Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) both handle message retrieval, and the latest version of IMAP lets you review messages and attachments before downloading them. You can leave entire messages, or parts of messages, on the server for easier archiving and sharing of messages. Application Configuration Access Protocol (ACAP), an evolving standard, will let you create address books, user options, and other data for universal access. Finally, Lightweight Directory Access Protocol (LDAP) provides a structure for small
, fast, and easy-to-implement clients.
The result? If you use e-mail only for messaging, the benefits of Internet e-mail are ready for you to use today. Even more important in the long run, Internet e-mail will be the basis for new types of collaborative applications.
However, there are
trade-offs
if you commit to Internet e-mail today. Key features of proprietary mail systems, such as group scheduling and calendaring, are still unproven. Also, Internet e-mail doesn't tell you when or if a message is delivered or provide a guaranteed delivery time. If you rely on these capabilities, Internet e-mail will probably disappoint you.
Whether you're willing to make the plunge to Internet e-mail today or you're making plans for the future, here are some key considerations for making the transition as smooth as possible.
Integrated Messaging
Messaging is at the heart of any enterprise network, and the Internet, with its ubiquitous presence and common standards,
can be the obvious messaging solution, especially for unifying and reducing the number of disparate systems you operate. Furthermore, Internet messaging opens up communication with business contacts outside the enterprise.
Some companies, mostly small businesses with few legacy systems, are adopting a pure Internet solution. Most businesses, however, can't just throw out their old messaging systems. Their features, plus the investments in equipment, training, and other resources, ensure the continued use of legacy messaging systems for the foreseeable future. The trick, then, is to integrate Internet messaging with the proprietary systems in a way that maximizes the benefits of both. (
See the figure
for a comparison of the different architectures; see the sidebar "Managing Multiple Messengers" for an example.)
Indeed, Internet support may be available even if companies aren't looking for it. Companies that want to stick with software they have today will be able to do so, beca
use even if they buy a solution from a proprietary system vendor, the protocol support and administration tools, including directory synchronization, will likely be there. Some vendors do not yet support the latest Internet protocols, such as IMAP4, but virtually all are expected to by the end of this quarter. (See the sidebar "Internet Standards".)
Therefore, companies that want to move slowly into an Internet messaging system can do so through their current suppliers. Those that want to be more aggressive can buy a pure Internet system and maintain interoperability for basic functions with legacy systems.
As companies rush to build intranets, they themselves provide TCP/IP connectivity to their networks and to their employees' desktops. But changing infrastructure takes time. Assuming the infrastructure is in place, however, three key issues emerge for adopting an Internet-based e-mail system: standards, cost, and flexibility.
The Standards
Every system, on both the server
and client side, must have a common language for data transmission and retrieval, popular file formats, directory services, security, and certain added features. Here, the Internet is strong because its standards are widely available and in some case have been used longer than proprietary standards.
As a result, the leading proprietary messaging systems, such as Lotus's Notes and Microsoft Exchange, already have integrated the basic Internet protocols into their products or will do so shortly. Novell, with Groupwise 5, has adopted Internet standards as the native platform. (On the other hand, pure Internet messaging products, like Software.com's Post.Office and Netscape Communications' SuiteSpot, work with proprietary systems because they also natively support established interoperability standards such as X.400 and MAPI.)
Vendors either implement Internet standards natively, as Novell does, or by conversion through a gateway, in the manner of Microsoft or Lotus. In both cases, the commitment is stro
ng. "[Support of Internet standards] is a core component of cc:Mail moving forward," according to Mike Maier, a cc:Mail product manager at Lotus.
The Costs
The cost of Internet e-mail is closely tied to scalability. As the number of users and locations with e-mail implementations increases, what happens to your hardware and software costs? Will you need more servers and more people to administer your system? Here again, the Internet crowd claims an advantage that proprietary-systems vendors refute.
In a typical proprietary system, a server can support a given number of people and features. Internet messaging is much more scalable. "The Internet is already larger than what anyone's enterprise has to deal with," notes Kevin Carosso, vice president of engineering at e-mail and fax-software vendor Innosoft (West Covina, CA). This scalability especially pays off when a company extends messaging services to a remote location. Often, an IP connection is all that's required at the remote
end; the headquarters server can handle the internal management.
Proprietary vendors argue that to provide equivalent functionality -- scheduling, for instance -- Internet systems would require extra servers, too. However, Internet messaging is more flexible about where a company places its servers.
Cost was the main reason that consulting firm Pyramid Solutions (Troy, MI) chose Ipswitch's IMail Server over Microsoft Exchange. This small company started out with Microsoft Mail. As employees connected to the Internet, "switching to a pure Internet system made more sense for us," says senior systems engineer Jerry Palardy.
Pyramid has 50 employees in two offices and in several customer locations. The Microsoft solution would have required servers at the remote locations and cost about $7000. The Internet mail server cost $700 and was installed on hardware already in place. Palardy says the company is happy with the system, but acknowledges that Exchange might have made more sense if Pyramid were a l
arger company.
The administrative overhead generally is less with an Internet system because proprietary systems must duplicate some of the services that are already in the Internet infrastructure. Tasks associated with maintaining a message store in a proprietary system, such as archiving and compressing the data, are not necessary in an Internet environment.
On the other hand, in environments with multiple messaging systems, adding administration tools for each to a proprietary system is somewhat more complex. Vendors of proprietary systems have a well-developed arsenal of tools to ease the administrative tasks, while only recently has there been any reasonably good software to manage Internet messaging. Still, Internet messaging shows real promise that it can reduce a company's messaging overhead costs.
One Size Doesn't Fit All
Vendors of messaging products have to consider two different constituencies within an organization: the users and the people who manage the system.
Both want choices in the products they use, and the solutions for both must be in sync.
A company might standardize on one or two messaging architectures, but it would be impractical, if not impossible, to require all employees to use the same messaging client. People work in different environments, depending on their jobs. A salesperson, for example, might spend computing time in an applications suite. Other employees might only occasionally use a computer, to access the Web through a browser or check e-mail through a dedicated reader. Any Internet, proprietary, or hybrid messaging system, therefore, must support multiple types and brands of e-mail clients. Through adherence to POP3 and, eventually, IMAP4, virtually all currently available products provide this flexibility.
This was important to Jeff Luck, manager of network and support systems at Pennsylvania State University's Continuing and Distance Learning department. Three years ago, the university had no POP3 system in place, so Luck chose Mic
rosoft Mail for his 350 mostly Mac users. He liked its user interface, directory services, and integration with other applications. The capability that let him leave messages on the server was important, too, as many people worked on multiple computers and needed access to mail from all of them.
POP3 Flexibility
A year and a half later, the university standardized on Eudora Lite and POP3. Rather than move with the university, Luck upgraded to Quarterdeck Mail 4.0 (formerly Microsoft Mail for the Mac). According to Luck, moving to Eudora Pro would have cost three times as much. Quarterdeck Mail lets him keep all the features he has now and have POP3 access to the rest of the university system. Luck says he will consider moving to a native IMAP4 system when the university does, especially if it means handing off responsibility of the mail server for his department.
On the back end, the people managing the system want to be able to mix and match servers and tools. Someone using Innos
oft's PMDF e-Mail Interconnect Internet backbone, for example, might want to integrate a Microsoft Exchange server with it.
Interoperability is not enough, however. You should be able to centrally manage the entire hybrid system, and this is where synchronization is important. You should be able to remotely configure and administer both servers and clients. Most major vendors now offer this capability, using the Web as the medium for remote administration.
Directory synchronization is critical, too. Vendors that use their own directory-services protocols, including Banyan's StreetTalk and Novell's NDS, have integrated the LDAP standard. Control Data's IntraStore Server has native X.500 support.
For some people, Internet messaging- administration tools don't stack up to those in proprietary systems. Paul Hoffman of the Internet Mail Consortium (IMC) expects the Internet to reach parity by the end of the year. Companies such as Ipswitch and Software.com now offer full suites of administration tools.
Also, tools designed to handle disparate messaging systems, such as Lotus's SoftSwitch or Hewlett-Packard's OpenVision, now accommodate Internet protocols.
Messaging's Missing Links
While the Internet fulfills the basic requirements for enterprise messaging today, companies are beginning to demand features that it cannot yet deliver easily. The most significant are scheduling (the ability to access calendars and plan schedules on-line) and calendaring (the ability only to view a calendar). Mainframe and Unix-based messaging systems, such as IBM's OfficeVision and Digital Equipment's All-in-One, have offered group scheduling and calendaring for over a decade. Businesses have come to depend on this capability and are loath to give it up. Ultimately, Internet messaging must not only provide group scheduling and calendaring, but provide backward compatibility with legacy systems. You can't just strand millions of users who may lack any other migration path.
Vendors of both Internet a
nd proprietary systems are now providing this compatibility, but on an ad hoc basis. Notable examples include Novell's Groupwise, Lotus Notes, and Microsoft Exchange. Versit is a standards-setting organization founded by Apple, AT&T, IBM, and Siemens to promote systems interoperability. The widely adopted Versit vCalendar and vCard open standards, which provide a common way to view a calendar and an address book, respectively, usually support these efforts. They do not provide a means to actually schedule meetings or other events. Similarly, group scheduling is now an integrated part of application suites, such as Microsoft Office 97 and Lotus's SmartSuite 96. They now provide integration points to the Internet and other messaging systems by way of APIs. (See the sidebar "Have Your Calendar Call My Calendar".)
Coming Attractions
Other desired features include e-mail-based faxing, paging, and voice. The goal for sending fax over an IP connection is not just to save the cost of the
call, but also to make it a desktop function -- to make it as simple as sending an e-mail message. Paging can perform two functions: to alert someone to an important message or to notify system administrators of a problem. Voice could be in the form of an audio attachment, like VocalTec's Internet Voice Mail 3.0, or making real-time voice contact over an IP connection through the desktop interface.
All these functions are currently available for Internet messaging systems, usually as third-party add-ons. However, no formal standards exist. As a result, the recipient needs compatible functionality, or the message must carry some kind of run-time module, the method that VocalTec uses.
Committees within the Internet Engineering Task Force (IETF) are working on specifications, likely as extensions of the Multipurpose Internet Mail Extensions (MIME) format, for all these features. The table
"The Internet Standards Picture"
provides estimated dates for completion. When wide-scale impl
ementation of those standards will take effect is anyone's guess.
When these features are available, you will likely access them through a universal mailbox. Already available with a number of products, a universal mailbox looks a lot like an ordinary mailbox with files and folders. The difference is it can manage multiple message types. In Novell Groupwise 5, for example, users can perform document-management tasks, send a fax, schedule appointments, maintain a task list, or perform other functions through the mailbox. (
See the screen
.) Folders can be public or private and are accessible to people who are traveling or working from a remote location.
Another area that is generating interest in some quarters is Electronic Data Interchange (EDI). This is a common way for businesses to perform purchasing transactions and is usually done over a secure, dedicated link. The ability to carry on EDI transactions through Internet messaging and the Web could dramatically reduce the require
d overhead. Instead of conducting on-line transactions with just the most important suppliers and customers, a company could do so with most of them. Some companies are now accomplishing EDI over the Internet using proprietary software from vendors such as Harbinger. A standard specification is due from the IETF sometime this year.
But lack of a standard protocol is not the major barrier to Internet-based EDI. Because of the sensitive data and large size of transactions, security must be tight. The technology exists for encrypting data and authenticating people, but practical issues, such as managing certificates (to verify identities) and encryption keys (to decrypt messages), are unresolved. (See the sidebar "Security: Who's Got the Key?")
What to Do?
Describing the move to intranets and Internet-standards-based messaging as a mad rush would be only slightly hyperbolic. The benefits of lower overhead and universal communications, not to mention the greater choice of products, a
re quite compelling.
However, most businesses are not quite ready to embrace Internet messaging. Reluctance to give up something that they know works for something with a relatively short track record is part of the reason. The greater hurdle remains the lack of standards for mission-critical applications, such as scheduling/calendaring or document management. Standards for most of these features should be in place by the end of the year, but widespread implementation will take longer.
What should you do today? Small companies with little legacy overhead are free to choose any path that meets their cost, feature, and scalability needs. As long as these companies require only basic messaging capabilities, Internet e-mail may be the best choice. By year's end, there will likely be standards that address missing elements in Internet messaging.
Managers for departments or divisions within larger companies should be aware of corporate-messaging planning. Choosing a compatible path could save effort, mo
ney, and headaches.
For larger companies, the issue is largely one of pulling together disparate systems and providing e-mail access to the outside world with minimal upheaval for users and administrators alike. Fortunately, this is doable now. Building from either proprietary or standards-based backbones, companies can ensure universal e-mail access and choice in both client software and administrative tools. What is not possible at this time is to duplicate the reliability, performance, and feature sets of established proprietary messaging systems in an all-native-Internet environment.
In any implementation where reliability or security is of the utmost concern, proprietary systems that use a standard dedicated phone connection rather than the distributed Internet infrastructure are still the safest bet. Internet messaging will eventually catch up to proprietary systems' reliability and security, but parity is at least a year away.
Still, the day when all enterprise messaging is based on Intern
et standards seems inevitable. "I would be surprised if by the turn of the century both Lotus and Microsoft weren't [natively] SMTP-based," says the IMC's Hoffman. Those two companies say that they'll do what their customers want. What those customers are saying is clear: Moving to Internet messaging is not a question of if -- it's a question of when.
Standard
Status
SMTP Widely deployed
POP3 Widely deployed
IMAP4 Soon to be widely deployed
IMSP Deployed mainly among native Internet products
ACAP IETF spec expected late 1997
MIME Widely deployed
S/MIME Spec not finalized, but some implementations exist
LDAP Widely deployed
Calendaring/ IETF spec expected mid-1997
Scheduling
Fax IETF spec expected mid-1997
EDI IETF spec expected lat
e-1997
Voice IETF spec expected mid to late 1997
Receipt IETF spec expected
Notification mid-1997
illustration_link (53 Kbytes)
illustration_link (19 Kbytes)
Although the structures appe
ar similar, proprietary mail architectures must use gateways to convert messages to their own formats.
screen_link (63 Kbytes)
Novell's Groupwise 5.0's universal mail box lets you manage not just e-mail messages, but faxes, documents, and phone messages.
m_nadeau@conknet.com
.
Your E-Mail is OBSOLETE
