This chapter provides a review of mail system terminology and key concepts. This general material applies to all mail systems, including Exchange. The remaining chapters of this guide assume that you understand the basic material presented here when the chapters describe how to implement these general concepts specifically for Exchange.
Take a few moments to skim this chapter. It covers a broad range of topics, beginning with fundamental definitions and ending with an overview of network communication, data replication, and other issues involved in interconnecting mail systems. If a term or topic is not familiar, read the explanation before you continue.
In Chapter 1, "Overview of Exchange," I defined Exchange as the entire system and the Exchange client and Exchange server as those specific parts of the system. The following are some other terms used consistently throughout this guide:
There are several important terms that describe the high-level administrative structure of the mail system itself.
Figure 2.1 shows a schematic diagram of a general mail system to help you put these terms in context. The high-level administrative structure generally reflects the geographic structure of an organization. When you plan your own system, you will develop a similar high-level diagram, starting top downfrom the organization, to the sites, and then to the server or servers that make up each site.
Figure 2.1. A mail system serves your entire organization, linking servers and sites.
Of course, for many companies, the organization is located at a single site and served by a single mail server. But it doesn't hurt to think big. Exchange is beautifully designed to scale from the smallest company to the largest, so your choice of a new mail system will never be a limit to growth.
As shown in Figure 2.2, the high-level functional structure of a mail system is fairly simple. There are a handful of major components. On the server side, there is a centrally shared directory of possible recipients and storage space for the messages themselves. On the client side, there is mailbox software that lets users compose and send messages as well as receive and read them.
Figure 2.2. Functionally, a mail system consists of a central directory and message storage space plus client mailbox software for handling messages.
Communication between server and client (and server to server) is handled by interface components called messaging protocols and Application Program Interfaces (APIs). A wide range of public messaging standards have been developed to promote open communications between mail systems. Messaging standards simplify the job of interconnecting mail systems and give users greater control at the desktop.
Fortunately or not, the practical implementation of these simple ideas is sufficiently complicated and messy enough to support huge businesses and legions of programmers.
The following sections discuss the basic components of a mail system in a bit more detail.
The mail system creates and maintains an internal directory of every mailbox in the organization. This information is made available to mailbox owners in a more abstract, useful form called an address book. An address book lists possible message recipients. I defined two common kinds of recipients at the beginning of this chapter: individual mailboxes identified by owner name and distribution lists. Exchange and most other mail systems support two additional types of recipients:
Although custom recipients and public folders are commonly found on most mail systems, these terms are specific to Exchange. For example, Lotus cc:Mail calls public folders "bulletin boards." This guide adopts the Exchange terminology for consistency.
There are two kinds of address books:
An individual's mailbox is identified by the Display Name of the owner. The Display Name can be anything the owner wants the Exchange world to see, such as the owner's first and last name. It could also be something like "The Lead Administrator for Acme Corp." For convenience, names are often given a short form for internal use in the mail system. The short form is the primary entry in the address book and is quicker to type and easier to remember. The short form of a full name is also called an alias.
There are several conventional ways to generate an alias from a full name. For example, Pat B. Green can be shortened to patg, pgreen, or pbg. When you add a new user to a system, Exchange can create an alias automatically using the first name plus the last initial, the first initial plus the last name, or initials only. No aliasusing the full name, in other wordsis also an option.
Note that an alias is not limited to shortened variations of a full name. Most mail systems allow just about anything.
Ideally, an alias uniquely identifies the mailbox owner. This isn't always possible, of course. For example, the first name/last initial method yields ambiguous results for Pat Green and Pat Gordon. If you try to use PatG for both names, Exchange will force the second one to be unique, such as PatG2.
Unlike phone numbers or postal addresses, there is no universal scheme or central authority to assign e-mail addresses or enforce consistency. The administrator is the central authority for the organization.
When Exchange is implemented, you might adopt a format for generating an alias as well as a plan for ensuring uniqueness. However, aliases are not absolutely necessary because users don't actually require them. In fact, many companies do not use alias names; they use Display Names exclusively. You will probably spend a fair amount of time policing consistency, especially if your organization has more than one site.
Microsoft's solution to avoid ambiguous aliases is to use the first name plus as much of the last name as needed for uniqueness. People with the shortest aliases are either early hires or have uncommon first names.
For example, you-know-who is billg. Bill Green, hired later, is billgr. Bill Graham, coming later still, is billgra, and so on. On the other hand, Epiphany Schwartz will probably never have any competition for the alias epiphanys.
In addition to an alias, if a mail system is connected to the outside world, each mailbox owner usually has an e-mail address. Unlike an alias, this is for external useit identifies the mailbox owner to a foreign mail system such as the Internet. This is the address a mailbox owner gives publicly so an outsider can send mail. Of course, an appropriate gateway must exist to receive messages from a foreign mail system.
Fortunately, widely used messaging standards enforce a certain level of consistency in e-mail addresses. The following are the most commonly encountered address standards:
The Internet address format is quickly becoming a globally accepted standard. There are many other messaging standards in addition to SMTP and X.400. Thankfully, most mail system can handle either or both of these e-mail address formats.
Physically, a message store is one or more files located on a disk drive accessible to the mail server. In Exchange and in most other mail systems, storage is logically organized into private and public areas.
Message technology has an interesting way of staying in step with disk drive technology. Back when messages were mostly simple text, drives were small. Now that gigabyte drives are commonplace, so are megabyte messages. No matter how big the mail system drives are, they probably won't be big enough.
For this reason, Exchange and most other mail systems let users take personal control of message storage. In a personal message store, messages are transferred from the server-controlled message store into files controlled by the mailbox owner. This action is generally initiated by the mailbox owner. Usually, a personal message store is physically located on the local drive of the mailbox owner's personal computer. Although this can be a beneficial way of reducing the amount of storage required on the server, after a message is transferred to a personal store it is no longer accessible to the server. This can cause problems for some users. For example, if a user signs onto the mail system remotely from a terminal outside the office, messages stored in the personal store won't be accessible.
The message store terminology used in Exchange is confusing on two counts. First, Exchange uses the terms "message store," "information store," and "folders" interchangeably. For example, the personal message store is also called the "personal information store" and "personal folders." Please be aware that the usage varies in the printed documentation, in the online documentation, and in the user interface.
Also, "personal" is a synonym for "private," but Exchange uses these terms to distinguish between messages stored centrally on the server (private message store) and individually by the client (personal message store). However, you can think of it this way: private folders can be shared by granting permissions to others. So they are private to the owner and to whomever has been granted permissions. On the other hand, personal folders cannot be shared with anyone; they are strictly personal. "Personal" and "public" add to the confusion because the terms seem to distinguish between client and server, but public really refers only to the shared part of the server store.
To avoid confusion, this guide always calls the server message store the information store and refers to the shared, public part of the server store as public folders.
Mail system support of published messaging standards has become critically important as acceptance and dependence upon e-mail has grown. Standards have made it possible to interconnect a wide range of private and publicly maintained mail systems in an increasingly effective global network. Improved standards have even made it possible to build a mail system from a mix of server and client components provided by different manufacturers.
Messaging standards operate at a range of levels. On the simplest level, protocols define formats for addresses and messages that permit uniform data transfer between mail systems. Implementation details are left to the creator of the software. On the highest level, ambitious APIs support tight functional integration between mail system components and mail-aware applications. An API exposes software functionality directly to other programs. Think of a protocol as something like the operating voltage specification for a table lamp, and an API as the definition of physical details that make it possible to screw a bulb into the socket, flick a switch, and have light
Despite the obvious benefits of messaging standards, in theory at least, their practical implementation is fraught with problems. There are many different standards efforts conducted by alternately cooperating and competing academics, standards organizations, industry committees, and mail system manufacturers. As a result, standards often overlap. Various groups adopt chunks of competing specs in an effort to claim the title of "most complete" or "most compatible." Well-intentioned efforts take a baseline specification and enhance it in mutually incompatible directions.
As a result of all this activity, most messaging standards are now enormously huge and enormously complex. As administrator, you can't avoid these things if you want your mail system to connect to the outside world. Gateway software does a reasonable job of hiding complexity, but there are many unavoidable, annoying details.
Don't despair. The following is a capsule summary of the alphabet soup of messaging standards you're likely to encounter, arranged by culprit.
The Internetin the beginning, at leastwas largely a creation of academics: research scientists, graduate students, and professors. Therefore, the original standards have been proposed and driven by the academic community.
As such, the hallmark of the Internet is simplicity. It's not that academics don't love complexityit's just that they usually get stuck with a hodgepodge of second-hand equipment. So a lowest-common-denominator approach demands simplicity.
Simplicity and the exploding interest in the Internet driven by the World Wide Web have positioned SMTP as the de facto standard for addressing and sending text-based messages. Internet mail access is required for most businesses, and this is likely to be the first Exchange connector (gateway) you set up. The following are the important Internet-related acronyms:
Whereas the Internet was born out of the world of academia, X.400 was born out of the world of standards organizations. One such organization is the ISOInternational Standards Organizationwhich is a worldwide federation of national standards bodies from nearly 100 countries. Another is the CCITTa French acronym that stands for International Consultative Committee for Telegraphy and Telephonybased in Geneva.
The X.400 series of protocols was jointly developed by ISO and CCITT, and X.400 is the CCITT version of the joint standard.
As you can imagine, getting more than 100 different countries to agree on anything is a challenge. The X.400 address format is a shining example of the dangers of design by committee. Here are some other ISO messaging standards that you are likely to encounter:
The messaging standards discussed so far are protocols rather than APIs. APIs provide the muscle of a commercial implementation over the skeleton of a messaging standard specification. With a defined API in place, software manufacturers can build products to support a standard interface. Individual mail systems can interoperate, and server and client components can be plugged together to build complete systems.
Recognizing the need for API-level support, several groups formed to define APIs to wrap around the various pieces of the ISO MHS specifications. The best of these efforts produced the Common Messaging Calls (CMC) API. CMC was created by the X.400 API Association (XAPIA), a consortium of leading mail-system manufacturers, telecommunications companies, and large-end users.
CMC has been expanded to include direct support for SMTP/MIME as well as X.400. There are actually two CMC APIs: Simple CMC and Full CMC. Simple CMC is designed to support mail-enabled applications. Full CMC is designed to support an entire mail system. Simple CMC support is available today in several products, including Microsoft Mail. In addition, Lotus and Novell selected Full CMC implementation as the primary messaging API in their next-generation, client-server mail systems (Notes 4.0 and Groupwise XTD, respectively).
CMC is developing largely in parallel to Microsoft's Messaging API, or MAPI, which is covered in detail in the next section. Even though Microsoft has been a key participant in the XAPIA, CMC has taken on the flavor of an "everybody else against Microsoft" effort.
With characteristic zeal, Microsoft chose to define its own messaging standard and develop the API to support it. Called MAPI, it is an integral part not just of Exchange, but also of the various Windows operating systems such as Microsoft Word and Excel. The key is support at the operating system level. Because Microsoft provides the operating system for more than 90 percent of the desktop clients, the company can provide a fundamentally greater degree of integration with a MAPI-compliant mail system. Interestingly, Microsoft was originally a strong supporter of CMC, and participated in developing the original specification. As Microsoft engineers began to develop the specification for Exchange however, they found that CMC could not provide the desired degree of operating system integration. Thus, MAPI was born.
Like CMC, MAPI exists in two versions. The first, called Simple MAPI, is nearly identical to Simple CMC. This is the result of Microsoft's early support for CMC. In fact, Microsoft defined support for CMC version 1.0 as an integral part of Simple MAPI.
The second version, called Extended MAPI, is much more than a protocol for communication between different manufacturers' mail systems. In fact, about the only thing the simple and extended versions have in common are the name MAPI.
With Extended MAPI (or simply, "MAPI" from here on), Microsoft has created an entirely new messaging architecture to support Exchange and other mail systems. Exchange itself is possible only because of MAPI. Discussed in detail in Chapter 3, "Server Components," the MAPI architecture provides a structure that gives all mail systems equal treatment.
Lotus, Novell, and others have pledged support for MAPI; for example, the next version of Lotus cc:Mail is supposed to be MAPI based. Microsoft has not announced support for Full CMC in MAPI. As an Exchange user, you are committing to MAPI, and it is unlikely that CMC support will be an issue.
As the Exchange administrator, network issues are an important part of your job. After all, the biggest difference between e-mail and snail mail is the data network.
Networks connect client to server, server to server, site to site, and site to outside services such as the Internet. Here is a quick review of important network issues and terms:
You will need to estimate capacity requirements in order to size your organization's wide area network support for remote sites and clients. Here are the issues you need to consider:
The point-to-point data connections that make up a wide area network are usually supplied by telephone companies. Physical connections are made through a hardware device that connects the organization's data network on one side to phone lines on the other. The hardware device can be a conventional analog modem, an ISDN (Integrated Service Digital Network) modem, or more specialized device. There are two kinds of connections:
You will encounter the following communications protocol terminology:
With multiple servers, all directories and message stores must be updated when changes are made on individual servers. For example, if a new recipient is added to the Seattle office, directories on servers in the Houston and Atlanta offices must show the change as well. Of course, the speed at which information is updated between sites depends on the configuration of the organization's wide area network resources. There are two kinds of update strategies:
This chapter provided an overview of the general terminology and key concepts of mail systems. Armed with an understanding of the terminology, it is time to look at the specifics of how Exchange is a complete client-server mail system. In Chapter 3, "Server Components" and Chapter 4, "Client Components," you learn about the architecture of Exchange and are introduced to the various pieces of software that provide core mail system functionality.