Microsoft Corporation
August 1, 1995
Standards in messaging are vital. Without them, the chances of having different messaging systems communicate and share information are slim. This article discusses how Microsoft® Exchange Server uses four messaging standards—X.400, X.500, the simple mail transfer protocol (SMTP), and the messaging application programming interface (MAPI)—to achieve compatibility with other messaging and information systems.
E-mail systems are nearly as ubiquitous in companies as telephone systems. Yet, unlike the telephone, your e-mail system might not make it easy—or even possible—to send mail to a person on a different kind of e-mail system.
Customers have been clear—they have told us they want a powerful, manageable corporate messaging system to improve all forms of business communications within and beyond the enterprise. And because business communications take all shapes and sizes, and come from all type of systems (from PCs to mainframes, fax machines to voice mail machines, and so on), the only way to ensure interoperability is through standards.
Standards are vital and the design of a standards-based system that enables communications and information sharing with other messaging systems is also essential.
This paper describes how Microsoft® Exchange Server incorporates four important standards to help ensure the widest possible compatibility with other messaging and information systems. These four standards are:
X.400 is widely recognized and accepted by the messaging industry as the framework for global messaging. A core component of the Microsoft Exchange Server, the message transfer agent (MTA), is a conformant implementation of the 1988 X.400 MTA standard.
The X.400 standard is a set of recommendations for computer-based handling of electronic messages. It was developed by the International Consultative Committee on Telephony and Telegraphy (CCITT)—an agency of the United Nations—based on the Open Systems Interconnection (OSI) reference model and the protocols defined by the International Organization for Standardization (ISO). (CCITT is now a sub-delegation of the International Telegraph Union [TU] which was established in 1992.)
The goal of the X.400 recommendations is to enable electronic mail users to exchange messages no matter which computer-based messaging system they may use. Today, most messaging pundits would agree that X.400 has succeeded in this goal.
Because X.400 is based on the store-and-forward message-transfer model, people and applications do not need to perform any coordinated, simultaneous actions to share information.
Other advantages of X.400 are as follows:
As mentioned earlier, these advantages are important for companies who have more than one kind of e-mail system, as well as those who want to communicate with business partners and associates through public carriers. X.400 is especially important where hardware, network, and communication standards have not been enforced, and the only opportunity for interoperability exists in standards such as X.400.
Microsoft Exchange Server supports X.400 over the following OSI transports:
By supporting a full suite of the more popular, reliable, and secure networking transports, Microsoft Exchange Server lets customers choose the transport that best meets their needs. Companies can communicate with sites that are geographically dispersed and with companies that use different networking protocols.
Microsoft Exchange Server also allows customers to configure different transports on the same server. Customers get the flexibility to install their choice of transports on a single Microsoft Exchange Server to simultaneously support a wide array of messaging options.
Microsoft Exchange Server supports the following textual body parts:
Customers will benefit from the textual body part support that Microsoft Exchange Server offers, because it makes it possible for most language characters to be used and transferred. This allows for seamless interoperability between different mail systems across national boundaries.
Microsoft Exchange Server supports the following binary body parts:
With binary body part support, Microsoft Exchange Server gives customers options for:
A single Microsoft Exchange Server provides compatibility with 1984, 1988, and future MTAs, and the administrator can select the body part conversion for each MTA connection. This gives you the flexibility to communicate via X.400 with companies that are in different stages of X.400 technology implementation.
Microsoft Exchange Server supports both the sending and receiving of messages from other X.400 mail systems that act as a relay MTA. It can act as a private management domain (PRMD)-to-PRMD MTA, providing rich backboning functionality for customers. This removes the requirement to subscribe to a public X.400 service to transfer information between two different companies or from two different geographic locations of the same company.
Microsoft Exchange Server has two convenient ways to make foreign addresses available to users:
Figure 1. From Microsoft Exchange Server Beta 1: X.400 Addressing Template
To receive X.400 messages from someone on another X.400 system, you need to supply the sender with the following information:
These fields make up the default mapping of your X.400 address. However, because these fields can be customized, your specific address may not map exactly to the example shown in Figure 1, above. Your specific X.400 address can be found under the E-Mail Addresses property page in your Microsoft Exchange client address book.
It's one thing to claim that you're designing a product to an industry standard; it's another thing to prove through rigorous testing and government-approved test suites that the product actually conforms with the standard.
Test suites for testing X.400 conformance and interoperability have been developed by a number of organizations (principally government agencies in various countries). Vendors who want to sell their products to governments must pass a battery of stringent, government-run conformance tests. Although these tests are not mandatory for selling to private corporations, everyone benefits from the knowledge that an MTA has met the standards test for conformance. The following section describes the conformance and interoperability testing that Microsoft Exchange Server will undergo before its final release.
Microsoft already has much experience in the area of conformance testing. With the release of the Microsoft Mail Gateway to X.400, we achieved OSTC P1 and RTS conformance and Afnor certification.
Conformance testing verifies that an X.400 implementation meets the ISO and CCITT standards. Conformance testing must be done on a country-by-country basis because each country can choose to implement its own subset of the ISO and CCITT standards. Through a process called profiling, a government-established standards consortium determines what subset of the ISO and CCITT standards are required to meet its country's needs, and then develops its own conformance tests. Any X.400 vendor who wants to do business with a country's government must be certified by its standards consortium.
Conformance testing is therefore important for both government and corporate customers because it helps ensure that the X.400 product meets a high level of fidelity with the standards. We plan for Microsoft Exchange Server to be certified by the most important standards consortiums in the world, as shown in the following table.
| Standards Consortium | Standard | Testing Status (as of the time of this report) | |
| U.S. Government Open Systems Interconnection Profiles (GOSIP) 2.0 | MHS 1984 1 | Conformance achieved in October 1994. | |
| U.S. GOSIP | MHS 1988 2 | Testing to be completed by the final release date of Microsoft Exchange Server. | |
| Open Systems Testing Consortium (OSTC)—European standard | MHS 1988 | Testing to be completed by the final release date of Microsoft Exchange Server. | |
| United Kingdom GOSIP | MHS 1988 | Testing to be completed by the final release date of Microsoft Exchange Server. | |
| 1 84 MTA conformance includes: P1, RTS, Session, and TP0. 2 88 MTA conformance includes: P1+X.410, RTSE, ACSE, Presentation, and Session. |
|||
In the area of interoperability testing, Microsoft already has much experience. With the Microsoft Mail gateway to X.400, we performed interoperability testing with several X.400 vendors, including Data General, NCR, Touch, Digital Equipment, Retix, Unisys, Hewlett-Packard, Soft-Switch, Northern Telecom, and Tandem. We were also certified for interoperability with a number of X.400 mail systems, including Arcom 400 (Swiss PTT—Switzerland), AT&T Mail (AT&T—U.S.), Atlas 400 (TRANSPAC—France), EasyLink (AT& T—U.S.), Envoy 100 (Telecom Canada—Canada), MCI Mail (MCI—U.S.), Notice 400 (Infonet—US), Quickcomm (G.E. Information Services—U.S.), Sprintmail (U.S. Sprint Communications— U.S.), Telebox 400 (German PTT—Germany), Telemail (Sprint International—U.K.), Dutch PTT (Netherlands), and Telecom Australia (Australia).
Because it is done on a country-by-country basis, conformance testing alone does not verify that different X.400 implementations will interoperate with each other. Interoperability testing is required to ensure that different X.400 MTAs communicate with one another.
Using the OSINET (North America) and EUROSINET (Europe) interoperability test suites for the 1984 and 1988 versions of the X.400 standard, Microsoft will evaluate the interoperability between Microsoft Exchange Server MTA and the following X.400 mail systems:
(If your system isn't listed, this does not necessarily mean that it will not interoperate with Microsoft Exchange Server. It does mean, though, that we are not planning interoperability testing for that system in our system test labs. However, many of our customers are testing other X.400 MTAs not listed here. Our extensive conformance and interoperability testing give us a high degree of confidence that our MTA will work with most other "compliant" X.400 MTAs.)
The test suites will cover the following test protocols and scenarios:
Protocol 1 (P1) Interop—This protocol contains the envelope of the message—information about the message's originator and intended recipients. This protocol is used to verify that we can communicate with other X.400 MTAs and interchange the MTA name, password, and OSI addressing information. The testing scenarios are:
Protocol 2 (P2) and Protocol 22 (P22) Interop—These protocols cover the content of the message. The P2 protocol is for X.400 MHS 1984 mail systems, while P22 is for X.400 MHS 1988 mail systems. Both protocols cover all interpersonal messaging (IPM) body parts or attachments sent by the originator of the message, including the text of the message. Depending on whether we are using the 1984 version or the 1988 version, Microsoft will verify that Microsoft Exchange Server can generate and accept body part 14 and body part 15, and the file transfer body part. We will verify that we can receive and originate both textual and binary body parts such as T.61 (Teletex), ISO 6937, ISO 8857-1, and body part 9. The testing scenarios are:
OSI Transports and Network Configuration Testing—Microsoft Exchange Server can operate with other X.400 mail systems by using any one of the three more popular OSI transport and network configurations. These configurations are: TP0/X.25, TP4/CLN, and TP0/RFC1006 to TCP/IP.
We will evaluate the interoperability of the Microsoft Exchange Server with the following versions of these transport and network configurations:
PTT Interop Testing—PTTs are the post, telephone, and telegraph authorities responsible for providing OSI services. In the X.400 world, these are known as administrative management domains (ADMDs). We expect Microsoft Exchange Server to be certified by the PTTs for PRMD interoperability support using their X.400 and OSI Services. We will test with the following major PTTs in the U.S. and around the world:
Note French, German, and other European PTTs are covered by OSTC conformance testing standards.
Microsoft Mail Server users connect to the Microsoft Exchange Server via the Microsoft Mail Connector, which then connects to a private or a public X.400 mail system through the native Microsoft Exchange Server X.400 MTA (see Figure 2 below).
Figure 2. This figure illustrates how Microsoft Mail users can connect to an X.400 mail system via the Microsoft Exchange Server.
The Microsoft Exchange Server X.400 MTA connects an Exchange Server site to private and public X.400 mail systems. As shown in Figure 2 above, Microsoft Mail Server users connected to the Microsoft Exchange Server site via the Microsoft Mail Connector can also connect to the public X.400 mail system. This is done through the native Microsoft Exchange Server X.400 MTA.
Figure 3. This figure illustrates how users of Microsoft Exchange Server and Microsoft Mail Server can connect to any other mail system with X.400 connectivity.
The Microsoft Exchange Server X.400 MTA can also connect two (or more) Exchange Server sites through a private or public X.400 mail system. As shown in Figure 4, two Microsoft Exchange Server sites are connected and users are given access to the X.400 messaging system. Each of the Microsoft Exchange Server systems being connected must use its own Exchange Server X.400 MTA.
Figure 4. This figure illustrates how X.400 is used to provide WAN connectivity between two Microsoft Exchange Server sites, a process known as backboning.
Companies can use the Microsoft Exchange Server X.400 MTA and the Microsoft Mail Gateway to X.400 to connect Exchange Server sites to a Microsoft Mail Server post office. As shown in Figure 5 below, Microsoft Exchange Server users are given access to the X.400 messaging system, the Microsoft Mail Server post office, and any foreign messaging systems that are accessible through the post office.
Figure 5. This figure illustrates how X.400 is used to provide connectivity between geographically dispersed Microsoft Exchange Servers and Microsoft Mail Servers.
In the purest sense, X.400 specifies a user agent, message store, and MTA, and the means by which each component interacts with the other. There are messaging companies that provide a pure X.400 environment from the user agent on down to the MTA. However, we believe that the primary benefit of using X.400 as a standard for corporate messaging is its ability to allow disparate mail systems to communicate with one another.
To meet the needs of our customers, Microsoft has gone beyond the X.400 specification for the user agent and message store in many areas. The following is just a sampling of these areas:
In addition to electronic mail messages, Microsoft Exchange Server must store heterogeneous object types such as Schedule+ meeting requests, electronic forms, documents, and so on. Microsoft Exchange Server therefore requires a rich message store that goes beyond the message store specified by the 1988 X.400 standard.
X.400 implementations generally assume a one-user to one-mailbox relationship. Microsoft Exchange Server must support a many-to-one mailbox relationship for features such as delegate access (the ability for more than one person to access the same mailbox).
Because the 1988 X.400 message store provides no specifications for the support of public folders, it does not support discussion, bulletin board, or threaded conversation applications. Customers have asked for these applications, and now they can build them with Microsoft Exchange Server public folders.
Although X.400 supports distribution lists, it provides no specification for support or management once the distribution lists are created. With Microsoft Exchange Server, users can manage distribution lists and reduce the administrative overhead these lists can create. Also, in a pure X.400 system, if distribution lists are nested, a user will receive one copy of a message each time it appears in the nested lists. With Microsoft Exchange Server, the recipient receives only one message, even though that message may appear in many nested lists.
With 200 function calls and a subsystem that interfaces with both the client and server, MAPI provides a rich vendor-to-vendor interoperability that is independent of the underlying messaging service. Much of this richness is not supported by X.400.
Electronic data interchange (EDI) is a natural and attractive complement to electronic mail, especially as companies strive for paperless operation. However, most current EDI applications are complex, proprietary, and highly customized for particular industries. Standards for EDI are evolving rapidly. The X.435 standard specified in 1990 and the use of the P2 Interop are two examples of this recent evolution. The X.435 standard defines the methods by which EDI processes can transmit documents over an X.400 transport. The P2 Interop is the content type for X.400 messages and is being widely used in Europe for EDI.
EDI is a complex issue that involves both messaging and security. But because Microsoft Exchange Server is an X.400 messaging system, it can act as the transport infrastructure for the delivery of EDI documents. Third-party EDI vendors are working on solutions that will take advantage of Microsoft Exchange Server's rich messaging functionality in the near future.
The 1988 and 1993 X.500 directory service standards were designed to provide a global directory. Although it has received much press, X.500 has yet to be implemented by many customers.
In simplifying the X.500 model, we can divide X.500 into two requirements: one that defines the directory structure and one that defines directory access. The X.500 directory structure outlines the logical directory object schema, each object's attributes, and how each object relates to one another. Directory access refers to how these objects can be queried and replicated with other X.500 directory systems.
Microsoft Exchange Server supports a rich X.500 object schema that is described later in this section. Standards-based directory querying and replication across different e-mail systems however will not be feasible until other vendors support X.500 querying and updating. (Customers who want to synchronize their e-mail directories with Microsoft Exchange Server will be able to do so via the directory interface agent provided in the Microsoft Exchange Software Development Kit.) Because managing directories is such a difficult task, we envision that directory services, such as those defined by the X.500 standard, will become a cornerstone component of most messaging systems in the future.
This section will provide an overview of the X.500 standard and describe how this standard is used by Microsoft Exchange Server.
In the article "Focus: The X.500 Market" in The Messaging Technology Report, Volume 3, Number One (January 1994), Dr. Sara Radicatti states that the X.500 has grown in popularity because it meets the main needs of customers. Many industry pundits would agree with this assessment. The following customer needs are among those addressed by X.500:
Most analysts agree, however, that large challenges still must be overcome before X.500 will meet the needs of most customers. Although Microsoft Exchange uses an X.500 object schema, the initial release will not support directory inquiry or updating through the directory access protocol (DAP) or the Directory Service Protocol (DSP). The Microsoft Exchange directory service agent (DSA) handles directory distribution and replication within Microsoft Exchange while the Microsoft Exchange directory synchronization agent (DXA) handles directory synchronization with other e-mail systems.
The 1988 X.500 directory service recommendations form the basis of the directory service in Microsoft Exchange Server. This directory service stores all objects that conform to the X.500 object classes in an X.500 schema.
The table below illustrates how the X.500 name space maps to Microsoft Exchange Server directory objects.
| X.500 | Microsoft Exchange Server |
| Country | Country |
| Organization | Organization |
| Organizational unit | Site name |
| Common name | Microsoft Exchange Server recipient container |
| Common name | Microsoft Exchange Server recipient. |
Figure 6, below, illustrates the Microsoft Exchange Server directory schema as it relates to X.500 object classes.
Figure 6. The Microsoft Exchange Server directory schema
The object classes provided by X.500 are not sufficient for Microsoft Exchange Server functionality, so Exchange Server defines and supports additional object classes and attributes. For example, Microsoft Exchange Server also supports:
Much of the complexity of X.500 is shielded from the administrator and user. To the administrator, the object classes are exposed through easy-to-navigate property pages that are part of the Microsoft Exchange Server administration program. The mapping between the X.500 object and the X.400 proxy addresses for routing purposes is handled automatically by Microsoft Exchange Server. There is no reason for users to be aware of directories as a separate function. Looking at the address book is just a normal part of the client function.
The 1993 X.500 directory service recommendations for directory access (DAP/DSP) will be available in future releases of Microsoft Exchange Server. With our X.500 directory schema in the initial release of Microsoft Exchange Server, we are well-positioned to provide rich directory access services in the future. Our goal is to unify the Microsoft Exchange Server directory with the name spaces in the operating system, file system, Exchange Server public folder hierarchy, security database, and so on.
The Internet has long used several e-mail standards published as RFCs: RFC 821, which defines the SMTP, defines how Internet mail is transferred; RFC 822 defines the message content for plain text messages; and RFC 1521 (multipurpose Internet mail extensions [MIME]), extends the definition of message content to include multi-part textual and non-textual body parts. Microsoft Exchange Server supports these RFCs through the Exchange Server Internet Mail Connector, an important component for customers who rely on SMTP connectivity.
(RFC 1154 is an experimental protocol that enables the mailing of multi-part, multi-structured messages.)
The Microsoft Exchange Server Internet Mail Connector connects Exchange Server to other mail systems that use SMTP (RFC 821) to transfer mail. This component is called the Internet Mail Connector because it refers to the format of the Internet messages that are sent over the SMTP transport. The Internet message is defined by RFC 822 (the message format). RFC 822 can be supplemented by RFC 1521 (MIME), which enables structured message bodies in Internet mail. In addition to RFC 822 and RFC 1521, the Internet Mail Connector supports RFC 1154, which is used by the existing Microsoft Mail gateway to SMTP.
The table below includes more specific descriptions of the RFCs that Microsoft Exchange Server supports.
| RFC | Description |
| RFC 821 (STD10) | RFC 821 describes the sequence of control messages that are passed between computers to effect the transfer of a mail message. RFC 821 defines the SMPT. |
| RFC 822 (STD 11) | RFC 822 defines the message format, including headers (to, from.....) and the plain (7-bit U.S. ASCII) unstructured text message. All parts of the message body are concatenated, with no distinct headings separating the different body parts or specifying content types, encodings, attachment attributes, or other properties. One attachment follows the next and consecutive text attachments can be combined into a single part. The most common way of handling non-text attachments is by encoding and decoding them with UUENCODE and UUDECODE. If there is any non-text data in the message body, the entire message is encoded with UUENCODE or decoded with UUDECODE. |
| RFC 1521 (MIME) | RFC 1521 defines the actual message body parts and allows different kinds of data to be sent as different body parts (such as images, sound, video, and different types of text). RFC 1521 specifies how to tag each of the body parts so that each one can be identified. |
| RFC 1154 (for support of the Microsoft Mail version 3.2 message format) |
This message format is created by the Microsoft Mail gateway to SMTP. The first body part is always text; it contains references to the attachments. The attachments are appended after the first body part. Non-text attachments are encoded with UUENCODE. The additional message header, X-MS-Attachment, itemizes each attachment by its name, attributes, and creation date and time. |
Microsoft Mail users can access the Internet via the Microsoft Exchange Server Internet Mail Connector. Messages pass through the Exchange Server's Microsoft Mail Connector to the Internet.
Figure 7. This figure illustrates how Microsoft Mail users can connect to the Internet via Microsoft Exchange Server.
Connecting a Microsoft Exchange Server site to an SMTP messaging system
The Microsoft Exchange Server Internet Mail Connector connects an Exchange Server site to the Internet or another system that uses SMTP for message exchange. As shown above, Microsoft Mail Server users connected to the Microsoft Exchange Server site with the Microsoft Mail Connector can also connect to the SMTP messaging system through the Exchange Server Internet Mail Connector.
Figure 8. This figure illustrates how users of Microsoft Exchange Server and Microsoft Mail Server can connect to any other mail system with SMTP connectivity.
The Microsoft Exchange Server Internet Mail Connector can also connect two (or more) Microsoft Exchange Server sites through the Internet or another system that uses SMTP for message exchange. This scenario connects the two Microsoft Exchange Server sites and gives Exchange Server users access to the SMTP messaging system. Each of the Microsoft Exchange Server systems being connected is required to use its own Microsoft Exchange Server Internet Mail Connector.
Figure 9. This figures illustrates the use of SMTP for connectivity between two geographically dispersed Microsoft Exchange Server sites (backboning).
Companies can use the Microsoft Exchange Server Internet Mail Connector and the Microsoft Mail Gateway to SMTP to connect Exchange Server sites to a Microsoft Mail Server post office. This gives Microsoft Exchange Server users access to the SMTP messaging system, the Microsoft Mail Server post office, and any foreign messaging systems that are accessible through the post office.
Figure 10. This figure illustrates how SMTP is used to provide connectivity between geographically dispersed Microsoft Exchange Servers and Microsoft Mail Servers.
Microsoft Windows® 95 includes the Microsoft Exchange client, a universal inbox with direct access to the Internet via a MAPI-based Internet Mail provider (see MAPI section). The Internet Mail provider will be available through Microsoft Plus! for Windows 95. Through this provider, an individual using Windows 95 can send and receive Internet Mail with others on the Internet. This includes Microsoft Exchange Server users who send and receive Internet mail through the Internet Mail Connector.
Figure 11. This figure illustrates how a Windows 95 user can use the Internet independent of Microsoft Exchange to communicate with other mail systems, including Microsoft Exchange Server.
The Microsoft Exchange Server Internet Mail Connector is very easy to install, setup and administer. It is an integral component of Microsoft Exchange Server that is installed with the Exchange Server setup program and is administered through the Exchange Server Administrative program. Because it is an Microsoft Exchange Server service, it can be monitored, stopped and started, and managed like any other Windows NT service.
The Internet Mail Connector provides a number of administrative options that will help the administrator manage and control their company's Internet traffic. Examples of these controls include:
The Internet Mail Connector provides flexible interoperability between existing Microsoft Mail Server users, e-mail systems that support just the RFC 822 message format, and those that support the MIME extensions. This is important because you may need to communicate with companies over the Internet that are at different stages of technology implementation.
The Internet Mail Connector supports the following three message formats: RFC 822, RFC 1521 (MIME), and RFC 1154 (Microsoft Mail 3.2 compatibility mode). Administrators can set defaults for the Internet Mail Connector and override the default behavior based on addresses.
Different language characters can be supported and transferred using one of these international content types:
The Internet Mail Connector will support multiple simultaneous inbound and outbound connections. Administrators can control the number of simultaneous connections in and out of the Internet Mail Connector.
The complexity of encoded Internet messages is hidden from the user. Inbound messages are automatically resolved, whether they are sent as an RFC 822, RFC 1521, or RFC 1154 message. UUENCODE, Base 64, and Quoted Printable encoding are automatically decoded. For outbound messages, administrators can set defaults.
Because the Internet Mail Connector can also be configured to accept connections only from known IP addresses, it can be used to set up a private messaging network on the Internet.
The Domain Name Service (DNS) Resolver can resolve Internet addresses from a DNS service and route them from the Internet address information. It can query a DNS server and route on the information received. For this reason, the Internet Mail Connector does not require additional computers for routing purposes.
Figure 12. Internet Mail Connector configuration property pages from Microsoft Exchange Server Beta 1
MAPI is a key industry-standard API because it lets Windows-based applications interact with many different messaging services by using a single interface. The MAPI architecture defines the way in which MAPI applications and messaging clients, such as the Microsoft Exchange client, interact with various messaging services such as Microsoft Mail; Microsoft Exchange Server; MSN, The Microsoft Network; CompuServe®; and the Internet. The MAPI architecture is shown in the following figure below:
Figure 13. The MAPI architecture
MAPI divides messaging applications into four components: MAPI applications and messaging clients, MAPI subsystem, MAPI service providers, and messaging services.
MAPI applications and messaging clients communicate with MAPI service providers through MAPI interfaces. MAPI client applications can be divided into three general categories, as follows:
MAPI applications and messaging clients communicate with service providers through the MAPI subsystem. The client interface interacts with the MAPI subsystem to access MAPI-compliant service providers. Through Microsoft's broad publication of its messaging APIs, and because of the robust messaging and groupware functionality defined therein, MAPI has become the de facto industry standard for messaging and groupware clients and providers.
Figure 13 (above) illustrates how MAPI clients and applications span a broad range of messaging and groupware-based applications. As can be inferred from the figure, neither the client nor the service provider must be provided by Microsoft. Because MAPI is an openly defined and distributed standard, any third party can write its own MAPI-compliant client or service provider. The advantage in doing so is obvious. Just as applications that use the Windows printing subsystem do not have to have drivers for each printer on the market, so too can applications access the service provider functionality needed without having to have a specific interface for each provider.
Messaging applications that require messaging services can use any of four MAPI subsystem interfaces: sMAPI (Simple MAPI), common messaging calls (CMC), OLE Messaging (an OLE Automation interface to MAPI), or MAPI itself. Client requests for messaging services are processed by the MAPI subsystem either as function interface calls, as in the case of sMAPI or CMC, or as manipulations of MAPI objects, as in the case of OLE Messaging or MAPI itself, and passed on to the appropriate MAPI-compliant service provider. The MAPI service providers then perform the requested actions for the client and pass back action through the MAPI subsystem to the MAPI client.
Each MAPI subsystem interface has its uses. The sMAPI interface contains 12 Windows-based function calls that let messaging-enabled applications perform basic messaging tasks such as sending e-mail, resolving e-mail names, and so on. The CMC interface is an API layer defined by the X.400 API Association (XAPIA). (With Microsoft Mail 3.2, Microsoft was the first company to support and ship CMC.) This interface provides virtually identical function call interfaces as sMAPI, but has been designed to support cross-platform scenarios. OLE Messaging is an OLE Automation Idispatch interface (object oriented) to MAPI that will allow Visual Basic®, C, or C++ developers to leverage much of the messaging and groupware functionality inherent in MAPI. MAPI itself is an object-oriented C or C++ interface that allows MAPI objects such as messages, forms, and folders to be manipulated. It is designed to be used by more complex messaging-based and groupware applications, such as Microsoft Exchange public folder applications.
MAPI defines three types of service providers:
All service providers share a single Windows-based user interface. For example, the Microsoft Exchange client can receive messages from a fax, a bulletin board system, and an electronic mail system. Messages from all these systems, each with a different transport service provider, can arrive in the Microsoft Exchange universal inbox. Similarly, MAPI selects between message store and transport providers, as necessary, and merges the address books presented to it, so that the client application sees one combined address book interface.
Other vendors can add or replace messaging service providers to enable the Microsoft Exchange client to work with their mail systems, workflow systems, database storage systems, or directory services.
Messaging services have evolved to encompass much more than just electronic mail. Today, messaging services include fax and voice support, Internet mail, rich information sharing applications such as Microsoft Exchange Server and network based information services such as MSN. Through MAPI, MAPI applications and messaging clients can take advantage of the growing number of these messaging services.
When messaging systems are able to communicate and share information with one another, it will be because they were designed to conform with industry standards. In our desire to deliver a powerful, yet manageable corporate messaging system, one of our most important development goals was to ensure that Microsoft Exchange Server would be a great messaging product that adheres closely to industry standards. We have made great strides in these areas with the 1988 X.400 MTA, Internet Mail Connector, X.500-based directory service, and MAPI support, and we have designed the product so that customers can choose which of these standards they want to implement within their organizations. We trust you will find that the Microsoft Exchange Server, with its wide range of standards options, is the right product for your current and future messaging needs.