Search the Catalog
Microsoft Exchange Server in a Nutshell

Microsoft Exchange Server in a Nutshell

By Mitch Tulloch
1st Edition April 1999
1-56592-601-3, Order Number: 6013
404 pages, $24.95

Chapter 2
Architecture and Operation

Let's look now at the architecture and operation of Exchange. By architecture I mean the fundamental components that make up an Exchange messaging system. By operation I mean how these components all work together to provide messaging functionality for users. We'll begin by reviewing some of the architecture and operation of the Windows NT Server network operating system on which Exchange runs. Then we'll look at the various components of Exchange and how they work together to provide messaging services to users for progressively more complex mail systems. And along the way, various Exchange concepts are explained as they relate to addressing and routing of messages.

Readers with a Unix background will find much of how Exchange works strange at first. This is probably because Exchange did not evolve from a Unix SMTP environment, but instead is based on the abstract and complex X.400 specifications developed by the International Telecommunications Union (ITU). These specifications define the architecture and operation of a generalized messaging system that is broadly implemented in Europe but relatively new to North America. To the American mind, X.400 may seem to have the flavor of the highly bureaucratic civil service that has pervaded Europe for centuries, with layer upon layer of organization and responsibility. Perhaps Microsoft chose the X.400 model for Exchange because they gave serious consideration to international standards in the area of messaging. More likely it chose the model to advance its marketing inroads in Europe.

In any case, Exchange is quite unlike Unix-based SMTP mail. One could even make the claim today that SMTP and related Internet protocols such as POP3 and IMAP4 have a better claim to being a global messaging standard than does X.400. (Europeans will probably disagree.) But SMTP mail is only one small part of Exchange; it is implemented as an optional component called the Internet Mail Service (IMS) that can be installed to provide an SMTP gateway between your Exchange organization and the Internet. Nevertheless, some consideration will be given in this chapter on how SMTP is implemented in Exchange from an architectural and operational point of view.

Although Exchange is based upon and fundamentally works like an X.400 messaging system, I've relegated an overview of basic X.400 concepts to Appendix A, X.400, so as not to burden the reader with abstract (and unnecessary) terminology in this chapter. Instead, I've chosen to focus on the more familiar Windows terminology such as Windows NT services, Remote Procedure Calls (RPCs), and Microsoft's Messaging Application Programming Interface (MAPI) to explain the function and communication of Exchange components and to highlight the communication between different messaging components using a series of simple flowcharts.

Exchange and Windows NT

The Exchange architecture builds upon the extensible, component-based architecture of the Windows NT network operating system. Windows NT networking is component-based because it consists of a number of core and optional services that can be loaded and unloaded. It is extensible because third-party companies can write their own services to the specifications of the Windows NT application programming interface.

Examples of core Windows NT services include the Alerter Service, Eventlog Service, RPC Locator, and RPC Service. Most Windows NT Server computers will have these services running at all times. To see what services (both core and optional) are currently installed on an NT server, and to start, stop, or pause these services, use the Services utility in the Control Panel. Various dependencies exist between these services so that if you stop one service others may be affected as well.

Examples of optional Windows NT services include networking services such as the Server Service, Workstation Service, DHCP Server Service, and Remote Access Service. These optional services can be installed, removed, and configured using the Network utility in the Control Panel. Some of these services, like the Server and Workstation Services, are installed by default during installation. Others, like the DHCP Server Service, must be manually installed by administrators when they are required.

NOTE:  

Windows NT also has additional services called Executive Services that are not displayed using the Services utility in the Control Panel. These Executive Services include the I/O Manager, Process Manager, Local Procedure Call Facility, and Virtual Memory Manager. Executive Services are essential to the operation of the Windows NT operating system and cannot be stopped, started, or paused. Well, that's not entirely true; if you use the Windows NT Task Manager; you can view all running processes on your servers, including processes running in the Windows NT Executive. You can use Task Manager to kill any process that is running, but if this is done indiscriminately you will likely kill your operating system entirely and be forced to reboot.

Windows NT services are essentially the Microsoft counterpart of daemons in the Unix world. In other words, they are processes that run continually in the background waiting for an application to connect to them and request their services.

To dig a little deeper, the relationship between an application running on an NT server and the underlying services is essentially a client/server one. The application functions as the client and passes its requests to the appropriate subsystem, which acts in a server role toward the application and handles its request. Windows NT includes subsystems for 32-bit Windows, 16-bit Windows, POSIX, and OS/2 applications. These subsystems are components of something called the Windows NT Executive, which is essentially an overarching structure that includes all Windows NT operating system components.

RPCs and LPCs

Messages are passed between applications and Executive components using various interprocess communications (IPC) mechanisms. For example, the Windows NT Executive includes a message-handling component known as the Local Procedure Call (LPC) facility that enables applications running on an NT server to communicate with Windows NT Executive components on that server. Messages called Local Procedure Calls (LPCs) are exchanged between client and server components on the same machine.

To enable communication between Windows NT Executive components on different machines, a similar IPC mechanism called Remote Procedure Calls (RPCs) is used. RPC messages are handled by two Windows NT networking services called the RPC Locator Service and RPC Server Service. These two services make possible distributed applications that run on multiple Windows NT computers and communicate using RPCs.

The original work on RPC facilities was done by Sun Microsystems, and Microsoft's implementation of its RPC facilities is compatible with (but not compliant with, since its code base is different) the Distributed Computing Environment (DCE) standard of the Open Software Foundation (OSF). RPCs enable Microsoft NT-based clients and servers to communicate over the network with DCE-compliant Unix servers such as AIX, Digital Unix, HP-UX, Solaris, and others. Microsoft's RPC facilities can use several different mechanisms for making API function calls and transferring data between two Windows NT machines, including named pipes, NetBIOS, and Windows Sockets.

Let's look a little further into RPCs, since this particular IPC mechanism plays an important role in the operation of Exchange. The idea behind RPCs is the same as the one behind structured programming, in which code can be separated into the program's logic (like a backbone) and various component procedures (like ribs attached to the backbone). Microsoft programming uses dynamic-link libraries (DLLs) to separate the procedures from the backbone code. This way a programmer can upgrade his application by providing users with updated DLLs without the need to modify the backbone portion of the program. With RPCs the backbone and the ribs of an application can be on different machines on the network. To support such a distributed application, the operating system must include components that enable one portion of an application to locate where on the network other components are located, how messages will be passed between components, and so on. The Windows NT RPC Locator and RPC Server services provide these necessary functions.

Essentially, the server portion of a distributed application registers itself with the RPC Locator service. The client portion then queries the RPC Locator service to locate the desired server portion. Once located, the Remote Procedure Stub process packages the function call into an RPC and then uses the RPC Run Time process to send it to the remote machine along with any necessary parameters. At the remote machine, the Application Stub process receives the request, unpackages it, and makes the appropriate function call to the remote procedure, which returns its results using the same mechanisms. As far as the client portion of the application is concerned, it thinks it is making a function call to a local procedure on the same machine.

Figure 2-1 shows a Microsoft Network Monitor capture of network traffic between two Exchange servers in the same site during directory synchronization. The protocol for the selected frame is MSRPC for Microsoft Remote Procedure Call. Notice in the middle portion of the window that RPCs use connection-oriented TCP packets for reliable network communications. The actual data in an RPC packet is often binary and here appears as gobbledygook when converted to ASCII in the bottom-right corner of the window.

Figure 2-1. Network Monitor capture of RPC packets during directory synchronization

 

MAPI

RPCs might be thought of more like envelopes than messages. The actual contents of the envelope are the specific API function calls being performed by the RPC, which in the case of Exchange involve calls to the Messaging Application Programming Interface (MAPI) subsystem. MAPI is a Microsoft Windows technology that provides a layer of programming functionality between messaging applications such as Exchange on the server side or Microsoft Outlook on the client side and an underlying messaging subsystem common to all Windows platforms. MAPI acts like a broker between an application and the Windows messaging subsystem. For example, a client application such as Outlook can use RPCs to pass MAPI function calls to a server application such as Exchange, which returns information the same way (see Figure 2-2).

Figure 2-2. Another Network Monitor capture, this time of the MAPI client Microsoft Outlook using RPCs to access the Administrator's mailbox on the Exchange server Raphael. The client passes the Distinguished Name (DN) of the recipient (Administrator) to the server as clear text (see bottom-right corner).

 

MAPI defines a set of common messaging APIs that developers can use to write frontend or backend messaging applications that will interoperate with each other. MAPI is the foundation of how Exchange works and provides the rich set of programming features that allow Exchange to support complex desktop information management programs like Microsoft Outlook. Outlook is more than just an email client; it also provides a calendar, contacts list, journal, and task organizer. Outlook uses MAPI to provide this broad functionality.

MAPI is more than a set of APIs for messaging; it also defines a messaging subsystem and dynamic link library (mapi.dll ) that is part of the Windows operating system for all current Windows platforms. MAPI provides:

The key thing to note here is that if you want to get the most out of implementing Exchange, your messaging client should be a MAPI-aware client like Microsoft Outlook. POP3 clients like Eudora don't use MAPI and hence lack much of the functionality that can be provided by MAPI-based clients. In for a penny, in for a pound!

RPC Connection Order

One rarely understood issue is the fact that RPC connectivity between MAPI clients and Exchange servers has some configurability. This is because RPCs support a number of different connection methods, as shown in Table 2-1.

Table 2-1: RPC Connection Methods Between MAPI Clients and Exchange
Server (continued)

RPC Connection Method

How a MAPI Client Communicates with Exchange Server

LPC

Used only when MAPI client is on same machine that Exchange Server is installed on

TCP/IP

Uses Windows Sockets (WinSock over TCP/IP) interface

SPX

Uses Windows Sockets (WinSock over SPX) interface

Named Pipes

Uses named pipes

NetBIOS

Uses NetBIOS over the underlying network protocol
(TCP/IP, IPX, or NetBEUI)

VINES IP

Uses VINES IP

For Windows NT or Windows 95/98 clients, the order in which these RPC connections are attempted is as shown in Table 2-1. The order is slightly different for older clients such as Outlook for Windows 3.x or the MS-DOS-based Exchange Client program. The key here is that the RPC connection attempt order can be configured to improve the responsiveness with which the client connects to Exchange. For example, if your server runs only IPX/SPX for its network protocol, while remote clients on your network run both TCP/IP and IPX/SPX, your clients will first try to connect to the server using TCP/IP and will wait until this times out before trying IPX/SPX.

The RPC connection order can significantly impact client connection speeds, and you should be aware that you can configure the RPC connection attempt sequence in two ways:

Exchange Architecture

As mentioned earlier, Exchange has a component-based architecture. The components of Exchange are all implemented as Windows NT services. Exchange components can be classified into two types: core components and optional components.

Core Components

There are four core components to every Exchange server. These components supply services for managing the Exchange directory, storing and forwarding messages, and other essential functions. These core components are:

Directory Service (DS)
Maintains the Exchange directory database (dir.edb), an X.500-compliant database that contains the attributes and configuration settings of recipients, sites, servers, connectors, and gateways. By default, this dir.edb file is located in the \dsadata directory, along with its transaction logs, checkpoint file, reserved log files, and temporary file. See the section "Directory Database" at the beginning of Chapter 3, Directory, for an explanation of these various terms, and refer to Appendix E, Directories, for the directory structure of Exchange.

Every directory object in the Exchange directory database has attributes and stores these attributes in the directory database. For example, personal information concerning a recipient's address, phone number, and company name are stored as attributes of the recipient's mailbox object in the directory. You can access an object's attributes by opening the object's property sheet using the Exchange Administrator program described in Chapter 4, GUI Tools. The various objects in the Exchange directory database are covered alphabetically in Chapter 3.

The Directory Service is also responsible for automatically replicating the directory database to all Exchange servers in a site. Every Exchange server in an organization maintains a complete copy of the Exchange directory database. This is unlike true X.500 directories, in which the directory information can be distributed among multiple directory servers.

The Directory Service also maintains the Global Address List (GAL), which contains information about all the recipients in the Exchange organization. Clients can access the GAL using Microsoft's Messaging Application Programming Interface (MAPI), Lightweight Directory Access Protocol (LDAP), and through Outlook Web Access using HTTP, depending on how Exchange is configured. MAPI is the default method.

Information Store (IS)
Maintains two databases called the Private Information Store (priv.edb) and the Public Information Store (pub.edb). These are located by default in the \mdbdata directory, along with their transaction logs, checkpoint files, reserved log files, and temporary file. See "Directory Database" at the beginning of Chapter 3 for an explanation of these various terms, and refer to Appendix E for the directory structure of Exchange.

The Private Information Store holds the messages and attachments for users whose mailboxes are homed on the Exchange server. The Public Information Store holds the contents of public folder replicas homed on the server. An Exchange server can have one Private Information Store, one Public Information Store, or one of each kind of store.

The Information Store is also involved in transporting messages, as is explained later in this chapter.

Clients can access the Information Store using Microsoft's MAPI or the Internet protocols POP3, IMAP4, and NNTP, depending on how Exchange is configured. MAPI is again the default method.

Message Transfer Agent (MTA)
An X.400-compliant message transfer agent responsible for routing messages and for converting them from the native Microsoft Database Exchange Format (MDBEF) to X.400 format. MDBEF is the format in which messages and attachments are stored in the Information Store. The MTA is involved together with the Information Store in transporting messages. The MTA can route messages to other Exchange MTAs, to MTAs of foreign X.400 mail systems, or to Microsoft Mail Connectors.

System Attendant (SA)
A manager that performs watchdog services for other components. The System Attendant must be running for any other Exchange services to run. Stopping the System Attendant will stop all Exchange services on a machine. Activities of the System Attendant include auto-generation of email addresses when new recipients are created, maintaining the Exchange message routing table (the GWART), maintaining the message tracking logs, and other maintenance and supervisory functions.

Optional Components

There are a number of optional components that can be installed on Exchange servers. These optional components, which are also implemented as Windows NT services, provide support for enterprise-level Exchange implementations, advanced security, legacy mail systems, and connectivity with foreign mail systems. Listed here are some of these additional components with a brief description of their functions. Further information on these components can be found in Chapter 3.

Site Connector and Directory Replication Connector
Connects Exchange sites together into an enterprise-level messaging system
Dynamic RAS Connector
Connects Exchange sites together using an asynchronous dial-up connection
Internet Mail Service
Connects Exchange sites together using the Internet's SMTP mail system as a backbone or connects Exchange organizations to the Internet's SMTP mail system itself
Internet News Service
Connects Exchange to the Internet's Usenet news system using the NNTP Internet protocol
MS Mail Connector and Directory Synchronization
Provides messaging and directory synchronization with legacy Microsoft Mail 3.x mail systems
Microsoft Schedule+ Free/Busy Connector
Provides scheduling capability for legacy Microsoft Schedule+ clients
X.400 Connector
Connects Exchange sites together over dedicated low-bandwidth connections or connects Exchange sites to X.400-based foreign mail systems
Connector for cc:Mail
Connects Exchange sites to Lotus cc:Mail foreign mail systems

Exchange Operation

By Exchange operation, I am referring here to several things:

To simplify things, we will start with a simple messaging system involving one Exchange server and various clients and then enlarge this to include more complexity.

Single-Server Scenario

When you have only one Exchange server deployed, communication between Exchange core components on that server are performed using Local Procedure Calls (LPCs). Communication with Exchange clients such as Microsoft Outlook on different machines is accomplished using Remote Procedure Calls (RPCs).

The communications between the Exchange core components on a single server are illustrated in Figure 2-3.

Figure 2-3. Communication between core Exchange components in a single-server scenario

 

Here is the description of these various interactions between core components, keyed to the numbers in Figure 2-3. Note that these numbers simply identify the various interactions, and in this diagram they do not indicate a series of sequential steps. The abbreviations used are:

DS = Directory Service
IS = Information Store
MTA = Message Transfer Agent
SA = System Attendant
  1. DS <--> IS

    2. The DS initiates communication with the IS during directory replication with other sites. Directory replication between sites is performed using email messages; directory synchronization within a site is accomplished using RPCs.

    The IS initiates communication with the DS to:

  2. MTA --> DS

    3. The MTA initiates communication with the DS to look up addresses in the GAL.

  3. SA --> DS

    4. The SA initiates communication with the DS to:

  4. IS <--> MTA

    5. The IS initiates communication with the MTA to:

    The MTA initiates communication with the IS to:

  5. IS <--> SA

    6. The IS initiates communication with the SA to create log entries when message tracking is enabled on the IS.

    The SA initiates communication with the IS to send or receive notifications for Link Monitors that are running.

  6. MTA -->SA

    7. The MTA initiates communication with the SA to create log-file entries when message tracking is enabled on the MTA.

Single-Server with Connectors

If connectors or gateways are installed on a lone Exchange server to provide messaging interoperability with foreign mail systems, the communication between components becomes slightly more interesting (see Figure 2-4).

Figure 2-4. Communication between core Exchange components and a connector or gateway in a single-server scenario

 

Here is the description of the additional interactions occurring between components, keyed to the numbers in Figure 2-4. Note that these numbers simply identify the various interactions, and in this diagram they do not indicate a series of sequential steps:

  1. Connector --> DS

    2. Connectors initiate communication with the DS to look up addresses in the GAL. For example, the Internet Mail System communicates with the DS to look up the SMTP address of a message addressed to a Custom Recipient on the Internet. Custom Recipients are recipients in the GAL who do not match any users in your organization, but instead match users on external mail systems such as the Internet's global SMTP mail system. You create Custom Recipients in your GAL for external users whom your own users frequently send mail to.

  2. Connector <--> IS

    3. The IS initiates communication with the connector to announce that there is a message waiting to be routed through the connector to the foreign mail system.

    Connectors initiate communication with the IS to process and deliver messages send from foreign mail systems to recipients on your Exchange server (or to other Exchange sites within your organization).

  3. MTA --> Connector

    4. The MTA initiates communication with the connector to deliver a message to the connector for routing to the foreign mail system.

Exchange Server and the Exchange Administrator Program

If the Exchange Administrator program is installed on an Exchange server to enable management of that server, the program communicates with the Exchange components using LPCs. If the Administrator program is installed on a different machine, it communicates with the server using RPCs. Figure 2-5 shows the interaction between the Exchange Administrator program and the core Exchange components.

Figure 2-5. Communication between the Exchange Administrator program and core Exchange components

 

Here is the description of the interactions occurring between the Administrator program and the core Exchange components, keyed to the numbers in Figure 2-5. Note that these numbers simply identify the various interactions, and in this diagram they do not indicate a series of sequential steps:

  1. Exchange Administrator --> DS

    2. The Exchange Administrator program initiates communication with the DS to:

  2. Exchange Administrator --> IS

    3. The Exchange Administrator program initiates communication with the IS to:

  3. Exchange Administrator --> MTA

    4. The Exchange Administrator program initiates communication with the MTA to view, re-order, and delete messages in MTA queues.

  4. Exchange Administrator --> SA

    5. The Exchange Administrator program initiates communication with the SA to:

Exchange Server and Client Programs

Exchange supports six kinds of messaging clients:

The communication between the core components on an Exchange server and each kind of client is illustrated in Figure 2-6.

Figure 2-6. Communication between Exchange core components and various clients

 

Here is the description of the interaction between the core Exchange components and various kinds of client programs, keyed to the numbers in Figure 2-6. Note that these numbers simply identify the various interactions, and in this diagram they do not indicate a series of sequential steps:

  1. MAPI client --> DS

    2. MAPI clients initiate communication with the DS to:

  2. MAPI client --> IS

    3. MAPI clients initiate communication with the IS to:

  3. POP3 client --> IS

    4. POP3 clients initiate communication with the IS to:

  4. IMAP4 client --> IS

    5. IMAP4 clients initiate communication with the IS to:

  5. LDAP client --> DS

    6. LDAP clients initiate communication with the DS to:

  6. HTTP client --> DS

    7. HTTP clients initiate communication with the DS to:

  7. HTTP client --> IS

    8. HTTP clients initiate communication with the IS to:

Single-Server MAPI Message Flow

If you only have one Exchange server, both the recipient sending a message and the recipient receiving it are homed on the same server. By homed we mean that this server is their home server. A recipient's home server is the Exchange server in whose Information Store database the recipient's messages and attachments are stored.

Figure 2-7 shows the interaction between clients and a lone Exchange server when a message is sent. Note that the MTA is not involved in this process; the MTA is used when moving messages between servers, however.

Figure 2-7. Message flow between a client and a single Exchange server

 

Here is the description of the interaction between the core Exchange components and a MAPI client such as Microsoft Outlook, keyed to the numbers in Figure 2-7. Note that in this diagram, the numbers do refer to a series of sequential steps that take place as the various components interact:

  1. MAPI client (sending) --> IS

    2. The MAPI client sending the message initiates communication with the IS and submits the message to the IS. In this case, the distinguished name (DN) of the destination recipient is used to route the message.

  2. IS --> DS

    3. The IS initiates communication with the DS to locate the home server of the message recipient.

  3. DS --> IS

    4. The DS responds to the request from the IS by indicating that the message recipient is on this Exchange server (since we are considering a single-server scenario here).

  4. IS --> MAPI client (receiving)

    5. If the message recipient has his MAPI client running, the IS initiates a connection with the receiving MAPI client and notifies the client that a new message has arrived. If the message recipient does not have his MAPI client running, the IS will initiate a connection as soon as the receiving client is started.

    NOTE:  

    Distinguished name (DN) is the native addressing format for Exchange recipients. Every object in the Exchange directory database is identified by a unique DN, including recipients such as Mailboxes, Distribution Lists, and Custom Recipients. DNs are part of the X.500 directory recommendation and consist of a hierarchical set of attributes starting with the name of the organization, then the name of the organizational unit (site), then names of any containers, and finally the internal name of the directory object itself. For example, the recipient Bob Smith with mailbox BobS homed on a server in the site Toronto in the organization SampleCorp would have the distinguished name:

    Here we have:

    o for Organization

    ou for Organizational Unit (site)

    cn for Common Name (anything else)

    Exchange recipients also have other addresses besides DNs. These are discussed later in this chapter.

Single-Server SMTP Message Flow

This scenario expands on the previous one by considering single-server message flow when the Internet Mail Service is installed on the server to provide a gateway to other SMTP hosts on the Internet. Figure 2-8 outlines the process involved when an Exchange recipient uses a MAPI client such as Outlook to send an SMTP message to someone on the Internet.

NOTE:  

Another note on terminology. What others might consider a gateway, Exchange refers to as a connector. The Internet Mail Service is an example of an Exchange connector because it provides messaging connectivity with SMTP hosts on the Internet. But it can also be thought of as a gateway between the Exchange mail system and the Internet SMTP mail system. Unfortunately Exchange uses the term "gateway" to refer to a connector from a third-party company, which causes some confusion.

Figure 2-8. Message flow between a MAPI client and an Internet SMTP recipient in a single-server scenario

 

Here is the description of the interaction between the sending MAPI client, the core Exchange components, and the Internet Mail Service (IMS), keyed to the numbers in Figure 2-8. Note that in this diagram, the numbers do refer to a series of sequential steps that take place as the various components interact:

  1. MAPI client (sending) --> IS

    2. The sending MAPI client initiates communication with the IS and submits the message to the IS.

  2. IS --> MTA

    3. The IS recognizes that the message is not addressed to a user on the Exchange server (actually, by communicating with the DS), so it initiates communication with the MTA. The MTA is notified whenever a message is addressed to a recipient that is not homed on the sender's home server. The MTA recognizes the destination address as being of type SMTP, determines from the Exchange message routing table (GWART) that there is only one IMS and that it is on the same server, and checks the address space of the IMS to see if it is capable of routing the message to its destination. If it can't route the message, it returns a non-delivery receipt (NDR) to the sender, since there is only one connector to try. If it can route the message, it places the message in the folder MTS-OUT. This folder is not a physical folder you can find using Windows Explorer; it is a virtual folder within the Private Information Store on the Exchange server where outgoing messages are queued until the MTA can process them.

  3. IS --> IMS

    4. The IS then initiates communication with the IMS to inform it of the queued message. The IMS then requests that the IS convert the message format to SMTP and retrieves the message from the MTS-OUT queue in the IS.

  4. IMS --> \imcdata\out

    5. The IMS then places the retrieved message in another queue, this time a physical folder with the path \imcdata\out representing the outgoing queue for the Internet Mail Service.

    NOTE:  

    An address space is a collection of partial addresses for a connector that specifies which destination addresses the connector is capable of routing. In practical terms, what this means is that a connector's address space specifies the possible messaging paths through the connector or the possible destination addresses that the connector can handle. The address space of a connector must be specified when the connector is installed and is usually a partial email address that identifies the possible range of destinations the connector can route messages to. For the Internet Mail Service, which uses SMTP addresses, some examples of possible address spaces might be:

    "*" which means that the connector can be used to route any SMTP mail (the asterisk is a wildcard). This is the usual choice for SMTP messaging to provide full connectivity with the Internet.

    ".com" which means that the connector can route messages to any .com domain. In other words, if a message is addressed to then the Internet Mail Service would not be able to route this message to its destination.

    "anycorp.com" which means that the connector can only be used to route SMTP messages addressed to any recipient in the SMTP domain anycorp.com. In other words, it can route a message to user@anycorp.com but cannot be used to send mail to user@anothercorp.com.

  5. MTA <--> DS

    6. Meanwhile, the MTA initiates communication with the DS to get the SMTP address of the destination recipient. If the destination recipient is a Custom Recipient within the Exchange directory, the SMTP address of this custom address is obtained. For example, if the message is addressed to BobS, a Custom Recipient on the server that has an SMTP address of , then this step of the process resolves BobS into . If the SMTP address of the destination recipient was manually typed into the "To:" field on the client program, the DS cannot resolve the destination and encapsulates it as an SMTP address.

  6. IMS <--> Internet DNS server

    7. The message is now ready to be routed to the Internet, but first the IMS queries a DNS server for an MX record to obtain the IP address of the destination SMTP host.

  7. IMS --> Internet SMTP Host

    8. The IMS now uses TCP/IP to establish a connection with the destination SMTP host (or a relay host if this is configured) and delivers the message.

The single-server SMTP message flow for a message coming from the Internet to a recipient homed on an Exchange server is the reverse process, with MTS-IN substituted for MTS-OUT and \imcdata\in for \imcdata\out.

NOTE:

POP3 and IMAP4 clients such as Microsoft Outlook Express, Eudora Pro, and Netscape Communicator interact with Exchange in essentially the same way that MAPI clients do as described. Microsoft has integrated POP3 and IMAP4 functionality directly into the Information Store at an API level similar to MAPI. This allows POP3 and IMAP4 clients to use the same security features that MAPI clients use. For example, POP3 and IMAP4 clients can use Windows NT Challenge/Response (NTLM) for secure authentication, if they support it.

The sole difference is that when a POP3 or IMAP4 client retrieves a message from the Information Store, the Information Store converts it to an appropriate format for that client. MAPI clients can access messages in the native format in which they are stored in the Information Store, namely the Message Database Encapsulated Format (MDBEF). POP3 and IMAP4 clients cannot understand this format, so the Information Store must convert it to an appropriate format for that client, such as MIME, Uuencode, or BinHex.

To send messages, POP3 and IMAP4 clients use SMTP to connect to the Internet Mail Service (IMS) on port 25, and the IMS forwards the message to the Information Store after which it is processed just as in Figure 2-8 starting with step 6.

Single-Site Scenario

Let's now look at the situation where several Exchange servers are installed to form a single site. Exchange servers within the same site communicate with each other using Remote Procedure Calls (RPCs). It is therefore essential that servers in the same site have RPC connectivity. In practice this means having a LAN or dedicated, high-bandwidth, permanent WAN connection between all servers in the site and running an RPC-supporting protocol such as TCP/IP or NWLink IPS/SPX Compatible Protocol. The network connectivity between servers in the same site requires high bandwidth because every server in a site opens an RPC connection to every other server in the site. This makes bandwidth increase rapidly with each new added server. (Actually, it increases as n(n+1) where n is the number of servers in the site.)

Since all recipients in the single-site scenario are contained within the Exchange directory, the distinguished name of the destination recipient is used to route the message.

The communications between the Exchange core components on two servers in the same site are illustrated in Figure 2-9.

Figure 2-9. Communication between core Exchange components in a single-site scenario

 

For simplicity, let's consider a site consisting of only two servers. This scales easily with no significant changes to larger numbers of servers. Here is the description of these various interactions between core components on the two servers, keyed to the numbers in Figure 2-9. Note that these numbers simply identify the various interactions, and in this diagram they do not indicate a series of sequential steps. The abbreviations used are:

DS1 and DS2 = Directory Service on servers 1 and 2

IS1 and IS2 = Information Store on servers 1 and 2<

MTA1 and MTA2 = Message Transfer Agent on servers 1 and 2

SA1 and SA2 = System Attendant on servers 1 and 2

  1. DS1 <--> DS2

    2. The DS on one server communicates with the DS on the other server to perform directory replication. This allows all Exchange servers in the site to have a full copy of the directory database, which provides fault-tolerance and reduces network traffic during directory lookups. The process works as follows:

    Let's say a change is made to the DS1 directory, such as adding or deleting a directory object or modifying the attributes of an object. DS1 then waits 300 seconds (the replication latency interval) in case additional changes are made; this allows changes to be batched if possible. After the replication latency interval expires, DS1 sends a notification to DS2. If there were other servers, DS1 would pause 30 seconds before notifying the next server. DS2 receives the notification and checks its update sequence number (USN) to see when it last received a directory update. USNs are used by the Directory Server to prevent duplication of updates. DS2 then responds to DS1 by requesting (pulling) any updates that DS1 has. DS1 connects to DS2 using RPCs and transfers the updates, and DS2 then processes the updates to ensure its directory database is complete and current.

    NOTE:  

    When you create a new recipient (mailbox, custom recipient, distribution list, or even a public folder), Exchange automatically creates several different kinds of addresses for that recipient. These include:

    • Distinguished Name (DN), also known as type EX, the native, internal address of the recipient in the Exchange X.500 directory system.

    • An X.400 Originator/Recipient (O/R) address, also known as type X400, which serves as a backup address type in case the DN is corrupt or unavailable. X400 addresses are also used for connectivity with foreign X.400 mail systems, which are common in Europe.

    • An Internet or type SMTP address, used for connectivity with the Internet system of SMTP hosts.

    • A Microsoft Mail 3.x address, known as type MS, used for connectivity with legacy Microsoft Mail networks.

    • Other types of addresses may also be generated when a recipient is created. For example, if the Connector for cc:Mail is installed in a site, new recipients will also have a type "CCMAIL" address created for them.

    These various types of addresses are covered in more detail in Chapter 3 in the context of directory objects where they are relevant.

  2. MTA1 <--> MTA2

    3. All other communication between two Exchange servers in the same site (and messages destined for a connector on another server) take place through the MTAs on the initiating and receiving servers. While the DSs exchange directory replication information in direct binary form, the MTAs always exchange information in the form of email messages using the distinguished name (DN) or Originator/Recipient (O/R) address of the destination recipient or service for addressing purposes. The kinds of messages exchanged between MTAs can be:

    and so on. Messages can be submitted to an MTA by a user, a connector, a service, or another MTA. The general process by which the MTA on one server communicates with the MTA on another server in the same site is as follows:

    If the data handed to MTA1 for delivery is not in the form of an email message, MTA1 converts it to this form. MTA1 then looks up the destination recipient or service in DS1 to find out how to route the message to its destination. Let's say that it determines that the destination recipient or service is on server 2. MTA1 then opens an RPC connection (called an association) to MTA2 using the site service account as the security context. More than one association can be opened if there are a large number of messages to be delivered. MTA1 then delivers the message to MTA2 using RPCs. MTA1 keeps the association open for 300 seconds in case more messages need to be delivered either way. MTA2 consults DS2 to see if the message is to be delivered to a recipient or service on server 2 or routed to another site or foreign mail system and then delivers the message accordingly.

    NOTE:

    By default, 50 messages must be queued in the MTA before it opens a second association for sending messages. If your network connection is poor or you are having RPC connection problems, try lowering the association threshold value on the Messaging Defaults tab of the MTA Site Configuration property sheet.

    The MTA can deliver messages to both recipients and services because both recipients and Exchange services have unique email addresses. For example, a message addressed to the Directory Service on server Raphael in site Toronto of organization SampleCorp would be, in SMTP format:

    The System Attendant has a hidden mailbox called RAPHAEL-DSA within the Private Information Store on server Raphael for receiving messages from other services on the Exchange server and from Exchange components on other servers in the organization. Some of the services that use the MTA for delivering messages include the Information Store, the System Attendant, the MS Mail Directory Synchronization object, and various Exchange connectors.

Let's look some more at the MTA routing process. When a message is submitted to MTA1, it communicates with DS1 and goes through the following steps:

  1. It checks the DN or O/R address or the destination recipient or service to see if the site portion of the address is the local site. If this is not the case, it uses the Exchange message routing table (GWART) to route the message to the appropriate connector. This is described later in this chapter.
  2. Since the site portion of the address is the local site, it checks whether the address is a valid one. If invalid, an NDR is returned to the originating recipient or service.
  3. If the address is valid and it is the recipient is a distribution list (DL), it expands the DL and then delivers the message to each member of the DL.
  4. If the address is a custom recipient, it obtains the DN of the destination recipient from DS1 and starts the routing process over again.
  5. If the address is on the local server (the home server of the sending recipient), it delivers the message directly to IS1.
  6. Otherwise, the destination recipient or service is on another server in the site (e.g., server 2), so MTA1 uses the process previously described to transfer the message to MTA2. If this can't be done (perhaps server 2 is down), the MTA retries at intervals until it succeeds or times out. The default timeout is 24 hours.

Single-Site Message Flow

Figure 2-10 shows the interaction between two Exchange servers in the same site when a message is sent from a recipient homed on server 1 to a recipient homed on server 2. This should be fairly obvious by now.

Figure 2-10. Message flow between two Exchange servers in the same site

Here is the description of the interaction between the core Exchange components on the two servers, keyed to the numbers in Figure 2-10. Note that in this diagram, the numbers do refer to a series of sequential steps that take place as the various components interact:

  1. Client 1 --> IS1

    2. Client 1 initiates communication with IS1 and submits the message to IS1.

  2. IS1 --> MTA1

    3. IS1 recognizes that the message is not addressed to a user on the Exchange server (actually, by communicating with DS1), so it initiates communication with MTA1.

  3. MTA1 <--> DS1

    4. MTA1 consults DS1 to determine whether the message is destined for the local site or a remote site. Since it is the local site, it checks the validity of the destination address. If the address is invalid, an NDR is returned.

  4. MTA1 --> MTA2

    5. MTA1 opens an association with MTA2 using RPCs, if there is currently no association open between them. MTA1 transfers the message to MTA2.

  5. MTA2 <--> DS2

    6. MTA2 consults DS2 to see if the message is addressed to the local server or to another server.

  6. MTA2 --> IS2

    7. MTA2 puts the message into the incoming queue and notifies IS2 of its arrival. IS2 then retrieves the message from MTA2 and places it in the MTS-IN virtual queue in the Private Information Store on server 2.

  7. IS2 --> Client 2

    8. If client 2 is currently logged on (has Outlook running), IS2 notifies client 2 of the arrival of a new message.

Summary of Single-Site Communications

Table 2-2 shows the various kinds of data that are typically transferred between Exchange servers in the same site and the Exchange services responsible for generating the data. Between two Exchange servers in the same site, all data is actually transferred by either the Directory Service (directory synchronization traffic only) or the Message Transfer Agent (all other forms of messaging traffic, whether initiated by users or Exchange services).

Table 2-2: Types of Exchange Inter-Server Traffic and Services Responsible

Service Generating Data

Kind of Data

Directory Service

Directory replication information

Information Store (private)

Mail messages sent by users

Information Store (public)

Public folder hierarchy information

 

Public folder contents

Table 2-3 presents a rather more complex look at how services on different servers in the same site communicate with each other. Dirsync refers to directory replication between an Exchange site and a legacy Microsoft Mail 3.x network. All communications between two services on different servers take place through the two servers' MTAs, except for communication between their Directory Services which takes place directly using RPCs. Again, DS1 refers to the Directory Service on server 1, DS2 for server 2, and so on.

Table 2-3: Amplification of Detail in Table 2-2.

Initiating Service

Receiving Service

Type of Communication

DS1

DS2

Directory synchronization updates

IS1priv

IS2priv

User-initiated messages

 

IS2pub

User-initiated messages

 

connector

User-initiated messages

IS1pub

IS2priv

User-initiated messages

 

IS2pub

Public folder replication

 

connector

User-initiated messages

SA1

IS2priv

User-initiated messages

 

IS2pub

User-initiated messages

 

SA2

Link Monitor (between two sites)

Dirsync

MS Mail system

Directory synchronization updates

Multi-Site Scenario

There are various reasons for setting up multiple sites in an Exchange organization:

Whatever the reasons, having multiple sites in your Exchange organization raises issues about site connectivity, message delivery, and routing. Exchange uses connectors to provide messaging connectivity between different sites. There are two kinds of connectors that can be installed:

Messaging connectors
These connectors enable email messages to be moved from one site to another. The four kinds of messaging connectors that can be used to provide message transfer capabilities between Exchange sites are:

Directory replication connector
This connector is responsible for exchanging directory updates between Exchange sites and requires that messaging connectivity be established first using one of the four messaging connectors described here.
NOTE:

The X.400 Connector and Internet Mail Service (why didn't they call it the SMTP Connector?) can both be used for a different function, to provide a messaging gateway between your Exchange organization and external mail systems such as the Internet or a foreign X.400 mail system. There are also other connectors that can perform gateway functions but cannot be used for linking together Exchange sites. These include:

  • MS Mail Connector (also PROFS and SNADS)
  • Connectors for cc:Mail and Lotus Notes

As far as message delivery and routing is concerned, Exchange servers in different sites communicate in much the same way as servers in the same site do, with one exception: all transfers of information between servers in different sites, including directory updates, take place in the form of email messages and are handled by the message transfer agent (MTA). The role of the MTA in message transport, routing, and connector selection is crucial in understanding a multi-site Exchange scenario. The MTA can route messages to:

The MTA holds the central position in delivering messages between servers in a multi-site scenario. The MTA makes its decision about which connector to route a message through based upon several factors, including:

Address space

The MTA compares the destination address of the message with the list of all possible address spaces. Each connector installed in an Exchange organization has one or more address spaces defined for it, which are possible messaging paths along which the connector can route messages. By comparing these address spaces with the destination address, the MTA can determine which connectors are capable of routing the message to its destination and which are not.

NOTE:

Note that when we refer here to the MTA of a site, we really mean the MTAs of the servers in that site. For simplicity, you can think of each site consisting of only one Exchange server for the remainder of this chapter, since we are now focusing on inter-site traffic rather than intra-site traffic.

Routing cost

Each address space for a connector has a cost value assigned to it by the administrator using the connector's Address Space property page. The cost value can range from 1 to 100, with preference being given to paths with lower cost. If two connectors can provide message routing to a given site, messages are always sent over the connector whose address space has the lowest cost. Routing costs are cumulative, so that if several connectors must be traversed to reach a given destination, the cost values of each connector along the way must be added together to determine the routing cost for each possible routing pathway.

NOTE:  

To confuse things, there is another kind of cost value associated with Exchange: connected site cost. This kind of cost only applies to a connector when it is being used to connect Exchange sites together, and is configured using the Connected Sites property page of that connector. The X.400 Connector, for example, uses this cost value to select between different bridgehead servers if more than one is available. The connected site cost can range between 1 to 100.

Even more confusing, the online documentation for the X.400 Connector indicates that routing costs can range from 0 to 100 instead of from 1 to 100. A routing cost of zero is said to indicate that the selected route will always be tried and other routes will only be attempted if this route fails. However, this clashes with the concept of cumulative routing costs described earlier. The inconsistency is with the documentation.

Figure 2-11 shows an example of an organization consisting of three sites. Site A is connected to Sites B and C using Site Connectors over T1 lines. Sites B and C are connected using a Dynamic RAS Connector over a dial-up ISDN connection. If a recipient in site A wants to send a message to a recipient in site B, the MTA in site A first looks at the possible address spaces to see which connectors it can use to route the message. The Site Connector and Dynamic RAS Connector can use either a recipient's distinguished name (DN) or O/R address to route messages, and we'll assume that address spaces for all connectors are configured to allow routing of messages anywhere within the organization. The MTA in site A next looks at the total cost of the messaging paths to site B. These costs are:

Since the direct path has the lower cost, messages sent from A to B will always be routed through the Site Connector joining sites A and B.

Figure 2-11. Routing costs in a multi-site scenario

 

Note that if a recipient in site B sends a message to a recipient in site C, the indirect route BAC will be used instead of the direct route BC because of its lower cost. In that case, why install the Dynamic RAS Connector at all if it isn't used for message routing? The obvious reason is to provide a backup messaging path in case the T1 line between sites A and B goes down. In complex scenarios, cost values need to be chosen carefully with consideration given to organization topology and WAN link bandwidth to ensure that messages are routed as efficiently as possible and to provide fault-tolerance to your messaging system.

Cost values can also provide load balancing of messaging traffic. If two connectors are used to join two sites together and these connectors both have the same cost, Exchange will randomly choose between them each time they are used to route messages.

Scope

Sometimes you may want to prevent messages from being routed to a specific connector. In Figure 2-12 we have two sites, A and B, connected by a Site Connector over a high-speed permanent WAN link. Each site is also connected to the Internet using the Internet Mail Service (IMS) because users in the organization frequently need to communicate with external users on the Internet using SMTP mail. The administrator in site A wants to ensure that when a recipient in site A sends SMTP mail it will be routed directly to the Internet using the IMS A connector and not indirectly via the Site Connector followed by IMS B connector. Cost values can assist in accomplishing this, but another method is to restrict the scope of the address space for the IMS A connector to users belonging only to site A. This is accomplished by specifying an address space restriction for the connector. The MTA checks the originator of each SMTP message sent by users in site A and only allows messages originating with users in this site to be routed through the IMS A connector. SMTP messages sent by users in site B are not permitted to be routed through IMS A.

Figure 2-12. Defining address space restrictions can prevent messages from being routed to specific connectors

 

The possible address space restrictions that can be applied to an address space are:

Organization
Messages sent from anyone in the Exchange organization can be routed through this connector.
This Site
Only messages originating from recipients in this site can be routed through this connector.
This Location
Only messages originating from recipients homed on servers in this location can be routed through this connector.

NOTE:  

Locations are a method of grouping one or more servers together within a site, that is, forming "subsites." Locations can be used in message routing as described later in this chapter. The location of a server can be specified as:

  • "<None>" which is the default value (i.e., no locations are defined in the site)

  • A specific text string such as "Headquarters" or "Downtown"

  • "*" which enables servers in this location to have access to and be accessed from all servers in all locations

Re-Routing

Because large Exchange organizations can have quite complex site topologies, some mechanism must be provided to prevent messages from endlessly looping. Furthermore, if a connector or gateway stops functioning, there must be some way of re-routing messages to use alternate paths if available. To this end, the MTA tracks which connectors a message uses in trying to reach its destination.

As an example, consider Figure 2-11 again. A message is sent from a recipient in site B to a recipient in site C. Since the indirect route BAC has a lower cost than the direct route BC, the MTA in site B will route the message through the Site Connector to the MTA in site A. Now suppose the MTA in site A receives the message destined for site C and determines that the Site Connector between A and C is down. The MTA in site A then determines that the next lowest cost route to its destination site C is back through site B and then using the Dynamic RAS Connector to site C. So the MTA in site A re-routes the message back to the MTA in site B. The MTA in site B determines that the indirect route through A has already been attempted; if it didn't recognize this, it might send the message back to site A and have it endlessly loop. Having determined this, the MTA in site B then re-routes the message directly to site C.

Multi-Site Message Flow

The process by which the MTA determines which connector or gateway to route a given message through is really a two-step process called Routing and Selection:

Routing Process
MTA determines which connectors can be used to route the message.

Selection Process
MTA determines which connector should be attempted to route the message when the Routing Process gives more than one possibility.

In the final two sections of this chapter, we will examine the details of these processes and bring to a conclusion our look at the operation of Exchange.

Routing

The first thing the MTA must do when it is handed a message by the Information Store, Directory Services, System Attendant, or another MTA is determine whether the message is destined for the MTA's local server, a server in the local site, a server in a different site, or a foreign mail system such as the Internet. We will consider here only the last two options, since we have already dealt with local delivery earlier.

The MTA receives a message; this message needs to be forwarded to the appropriate connector. The routing process is the determination of which connectors can route the message towards its destination. The key here is address spaces, discussed earlier. Each connector in an organization has one or more address spaces, that is, paths over which it is capable of routing messages. Address space information is replicated between all servers in an organization by directory synchronization (within a site) and directory replication (between sites). The System Attendant and the MTA on each server use this information to create a local message routing table called the Gateway Address Routing Table or GWART. Each server keeps a copy of the GWART in its directory and updates it as connectors are installed, removed, or reconfigured in the organization.

Besides the address spaces of connectors in the GWART, the MTA also considers address space restrictions and server locations in determining which connectors can route the message. Combining these three possible values for locations with the three possible scopes for address space restrictions lets administrators have a great deal of control over how messages are routed. Table 2-4 shows the "equivalent restriction" of combining a location with an address space restriction.

Table 2-4: The "Equivalent Restriction" Formed by Combining Locations with Address Space Restrictions

Location

Address Space Restriction

Organization

Site

Location

<None>

Organization

Site

Site

Specific Location

Organization

Site

Specific Location

*

Organization

Site

Site

Exchange also maintains a text-file version of the GWART in the \mtadata folder with the filename Gwart0.mta. Whenever the GWART is updated, the old version is renamed Gwart1.mta and the new GWART is saved as Gwart0.mta. You can print these files for reference or troubleshooting purposes. This text-file version of the GWART is not used in the routing process.

Figure 2-13 shows a sample GWART for the organization SampleCorp, whose current messaging topology is displayed in Figure 2-14.

Figure 2-13. The GWART for SampleCorp, as displayed using the Site Add ressing object for the Toronto site

 

Figure 2-14. The messaging topology for SampleCorp when the GWART for Figure 2-13 was displayed

 

From Figure 2-14 we see that:

The GWART is divided into three sections:

  1. Distinguished Name (DN)

    2. Address spaces of type EX use the native Exchange addressing format, Distinguished Names.

  2. Domain Defined Attribute (DDA)

    3. These are address spaces used for Custom Recipients, that is, recipients defined in the Exchange directory that represent users of external mail systems. Exchange automatically generates MS Mail (type MS) and Internet (type SMTP) addresses for each recipient you create, but other DDA addresses can be created using third-party gateways.

  3. Originator/Recipient (O/R)

    4. Address spaces of type X400 use the native X.400 addressing format.

Each line in the GWART represents a messaging path that can be used by the MTA for routing messages within the organization and to foreign mail systems. The Details button provides additional information for each address space, including the associated connectors used by that address space.

NOTE:

The GWART will look a little different depending on the site in which it is being viewed. This is because the Site Addressing object in Figure 2-13 displays how the GWART can be used to route messages from the local site (Toronto) to other sites and foreign mail systems.

If we look at this GWART line by line, it says the following concerning the MTAs in the Toronto site:

EX /O=SAMPLECORP/OU=VANCOUVER; 1 Site Connector (Vancouver)
Messages can be routed directly to the Vancouver site using the Site Connector (Vancouver). The distinguished name of the destination recipient can be used to route the message. The cost of this routing path is 1.

EX /O=SAMPLECORP/OU=WINNIPEG; 2 X.400 Connector (Winnipeg)
Messages can be routed indirectly to the Winnipeg site using the X.400 Connector (Winnipeg). The distinguished name of the destination recipient can be used to route the message. The cost of this routing path is 2 because the message would have to first traverse the Site Connector (Vancouver) to the Vancouver site and then traverse the X.400 Connector (Winnipeg) to the Winnipeg site. Note that routing costs are cumulative costs.

MS DOMAIN44/DEGAS; 1 MS Mail Connector (RAPHAEL)
Messages can be routed directly to the legacy Microsoft Mail server Degas using the MS Mail Connector (Raphael). The MS Mail address of the destination recipient can be used to route the message. The cost of this routing path is 1.

MS DOMAIN44/DEGAS; 2 MS Mail Connector (VANGOGH)
Messages can be routed indirectly to the legacy Microsoft Mail server Degas using the MS Mail Connector (Vangogh). The MS Mail address of the destination recipient can be used to route the message. The cost of this routing path is 2 because the message would have to first traverse the Site Connector (Vancouver) to the Vancouver site and then traverse the MS Mail Connector (Vangogh) to server Degas.

SMTP *; 2 Internet Mail Service (VANGOGH)
Messages can be routed indirectly to the Internet using the Internet Mail Service (Vangogh). The SMTP address of the destination recipient can be used to route the message. The "*" indicates that SMTP mail can be sent to any recipient on the Internet, that is, to any SMTP domain. The cost of this routing path is 2 because the message would have to first traverse the Site Connector (Vancouver) to the Vancouver site, and then traverse the Internet Mail Service (Vangogh) to an SMTP host on the Internet.

X400 c=US;a= ;p=OTHERCORP;o=EDMONTON; 1 X.400 Connector (OtherCorp)
Messages can be routed directly to the remote X.400 MTA of OtherCorp using the X.400 Connector (OtherCorp). The O/R address of the destination recipient can be used to route the message. The cost of this routing path is 1.

NOTE:  

In this example, OtherCorp is another Exchange organization and has the same country code and Administrative Management Domain (ADMD) in its O/R Address. If OtherCorp were a foreign X.400 mail system, then its O/R Address might read something like:

C=US;a=ATT;p=OTHERCORP;o=EDMONTON;

where American Telephone and Telegraph (AT&T) is the ADMD for the Private Management Domain (PRMD) OtherCorp. For more information on ADMDs and PRMDs see the entry "X.400 Connector" in Chapter 3.

X400 c=US;a= ;p=SAMPLECORP;o=VANCOUVER; 1 Site Connector (Vancouver)
Messages can be routed directly to the Vancouver site using the Site Connector (Vancouver). The O/R address of the destination recipient can be used to route the message. The cost of this routing path is 1.

X400 c=US;a= ;p=SAMPLECORP;o=WINNIPEG; 2 X.400 Connector (Winnipeg)
Messages can be routed indirectly to the Winnipeg site using the X.400 Connector (Winnipeg). The O/R address of the destination recipient can be used to route the message. The cost of this routing path is 2 because the message would have to first traverse the Site Connector (Vancouver) to the Vancouver site and then traverse the X.400 Connector (Winnipeg) to the Winnipeg site.
NOTE:

Two things to note here:

There are two address spaces for the Site Connector (Vancouver) and the X.400 Connector (Winnipeg), a distinguished name (DN) address space of type EX, and an Originator/Recipient (O/R) address space of type X400. These connectors may use either address space for routing messages.

The O/R addresses specify the country attribute as c=US, even though all of SampleCorp's sites are located in Canadian cities. Perhaps this indicates that SampleCorp has been acquired by a U.S. conglomerate!

Selection

Once the MTA has used the GWART to determine all possible routing paths that can be used to route the message, the next step for the MTA is to determine which is the best route to use. This process differs depending on which of these scenarios is true:

When the local MTA wants to connect to a remote MTA in another site through an available connector, there are 10 different criteria the MTA uses to determine the most efficient routing path to select. The MTA processes these criteria sequentially; each connector that passes one criterion is tested for the next criterion, until at the end a single connector is selected. Here are the steps followed by the MTA for selecting a connector to deliver a message, making the selection from the list of possible connectors that resulted from the earlier Routing process:

  1. Was the message previously delivered to the local MTA by any connectors? If so, eliminate those connectors from consideration; otherwise, the message may loop endlessly.

  2. Do any connectors have Retry Count equal to Max Open Retries? Retry Count is included with each message and indicates how many attempts the MTA has made to route the message through the connector. Max Open Retries can be configured specifically for an X.400 Connector or Dynamic RAS Connector or globally for all connectors using the Site MTA Configuration object.

  3. Do any connectors have delivery restrictions or message size limits that apply to this message? If so, eliminate those connectors. This does not apply to messages containing directory replication updates.

  4. Try active connectors first. If that fails, try scheduled connectors, and if that fails, try remote initiated connectors. Some connectors, such as the Site Connector, Internet Mail Service, and Microsoft Mail Connector, are always on (active). Other connectors, such as the X.400 Connector and Dynamic RAS Connector, have several possible activation states as shown in Table 2-5.

    5. Table 2-5: Possible Activation States for Connectors

    Activation State

    Description

    Always

    This connector is currently active.

    Schedule Time

    This connector is scheduled to become active at some future time.

    Remote Initiated

    This connector is activated only when its remote partner contacts it.

    Never

    This connector is turned off.

  5. Which connectors have the lowest Retry Counts? These will be given preference in routing attempts.

  6. Which connectors are currently in a Retry State and are attempting to retry delivery? Eliminate these. This step applies only to connectors on the local server.

  7. Which connectors have the lowest cost values? These will be given preference in routing attempts.

  8. Which connectors are local and which are remote? A local connector is capable of sending a message directly to the destination site. For example, a connector on a messaging bridgehead server would be considered local. To use a remote connector, the MTA must first send the message to a messaging bridgehead server where the connector is installed. Local connectors are given preference.

  9. If there is still more than one possible connector selected after all these steps, a connector is selected randomly to load balance the connection.

  10. If, however, all possible connectors are in a Retry State, the connector with the lowest Retry Counter value is selected so that the message can be routed as soon as possible.

Re-Routing

Finally, if the local MTA routes a message over a connector and the message cannot reach its destination, the MTA tries to reroute the message by a different connector. By default, it does this by going through the entire Selection process all over again. You may also choose to disable this behavior by restricting the MTA to use least-cost routing to route messages. This has to be done for each server by configuring the Message Transfer Agent for that server object accordingly. This streamlines the routing process by eliminating steps 5, 6, and 10 from the Selection process, and by performing step 2 after step 9 instead of near the beginning.

If the MTA has delivered a message to a connector with an activation state of Remote Initiated, it waits until the connector is activated before it considers whether to reroute a message that cannot be delivered.

If the MTA attempts to deliver a message to a foreign mail system such as the Internet through a connector or gateway such as the Internet Mail Service, there is no re-routing possible. As far as the MTA is concerned, once the message has been turned over to the connector, it has reached its destination. It will be the responsibility of the foreign mail system to issue a non-delivery receipt (NDR) to indicate to the message originator that the message failed to reach its intended destination.

oreilly.com Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
 International | About O'Reilly | Affiliated Companies | Privacy Policy

© 2001, O'Reilly & Associates, Inc.