Whitepapers Messaging

X.400 Bridgehead for Microsoft Exchange: Technical Architecture and Back-end Features

X.400 Bridgehead for Microsoft Exchange (“X.400 Bridgehead”) is a product from Boldon James, produced in collaboration with Isode. It’s primary goal is to provide X.400 protocol connectivity for Microsoft Exchange 2007 and future versions of Microsoft Exchange, as this capability was provided as a part of Exchange 2003 and earlier versions, but is not included with subsequent versions of Exchange. This paper describes the architecture of X.400 Bridgehead, and summarizes it’s key features. It is particularly oriented towards understanding the capabilities of X.400 Bridgehead in the context of older versions of Exchange and full X.400 Message Transfer Agents (MTAs).

X.400 Bridgehead Overview

X.400 Bridgehead Goals

The top level goals of X.400 Bridgehead are:

  1. To provide all of the functionality of the X.400 Connector in Exchange 2003, so that users of Exchange 2003 can migrate to use Exchange 2007 and keep all desired X.400 functionality. This goal is the primary driver for the product.
  2. To provide easy to use GUIs that will be familiar to Exchange administrators and enable X.400 management in a natural manner.
  3. To enable connection between a Microsoft Exchange server, and X.400 Servers using the X.400 P1 protocol.
  4. To provide fully featured X.400 capabilities, based on a modern X.400 implementation.
  5. To fully support STANAG 4406, the military version of X.400.
  6. To provide features in support of high reliability and precedence handling oriented towards military X.400 deployments and others with stringent reliability requirements.

X.400 Bridgehead Architecture


The above diagram illustrates the architecture of Exchange X.400 Bridgehead. Key features:

  1. The core X.400 functionality is provided by Isode’s M-Switch X.400, which is a market-leading X.400 Message Transfer Agent (MTA).
  2. Integration between Exchange and M-Switch X.400 uses Isode’s X.400 Gateway API on one side and standard Microsoft Exchange APIs on the other. This gives a clean and simple coupling between the two components.
  3. Configuration information is held in Microsoft Active Directory, which the M-Switch X.400 component accesses using the Internet Standard LDAP (Lightweight Directory Access Protocol).
  4. There is integrated GUI management, that accesses all components of the system to provide a single administrator view including:
    • Access to Exchange configuration relevant to X.400 connectivity.
    • Configuration of integration options.
    • Configuration of M-Switch X.400 (via Active Directory).
    • Operational monitoring of M-Switch X.400 using Isode SOM (Switch Operations and Management) protocol and API.

The back end architecture provided by points 1-3 gives a high functionality product making maximum use of COTS products and APIs. The GUI front end gives a seamless administrator view.

X.400 Bridgehead & M-Switch X.400

Although X.400 Bridgehead makes use of M-Switch X.400, they are different products with different scope. This is illustrated below.


M-Switch X.400 is a full X.400 MTA, with a primary role of switching messages using X.400 P1. It can also deliver messages to an X.400 Message Store, such as Isode’s M-Store X.400. It provides native X.400 message switching, and can also be used as the basis for gateways to third party systems, or MIXER gateways to SMTP.

The Boldon James Safemail.mil outlook based client can be used with both Exchange and M-Store X.400.

X.400 Bridgehead provides connectivity from an Exchange server using X.400 P1. The primary goal is “connector” functionality, to move messages to and from Exchange using X.400 P1. Some more specific differences arising from these architectural differences:


Feature M-Switch X.400 X.400 Bridgehead
Primary Goal X.400 Message Switching Connecting Exchange to X.400
Management Goal General Purpose Support of X.400 Connector Role
GUIs Isode GUIs, providing access to all M-Switch functionality. Exchange-integrated GUIs, focused on X.400 Connector functionality. (Isode GUIs are not used or provided).
Server Functionality Comprehensive functionality Subset of M-Switch X.400 functionality, needed for X.400 Connector role.
Directory normally used Isode M-Vault Active Directory


Functionality of X.400 Bridgehead is targeted at the connector role, which means that many aspects of M-Switch X.400 functionality are intentionally not made available. This will make operations straightforward for the administrator. If requirements arise for elements of functionality available in M-Switch X.400, it will generally be straightforward to incrementally add these to X.400 Bridgehead.
It will also make sense in many situations to use X.400 Bridgehead to connect to M-Switch X.400, and then use general purpose features within M-Switch X.400.

X.400 Bridgehead & Native X.400 Support in Exchange

It is also useful to understand X.400 Bridgehead in relation to the X.400 Connectors supplied in Exchange 2003 and earlier versions.

Exchange 2003 X.400 Connector

The underlying architecture of the Exchange 2003 X.400 Connector is very similar to X.400 Bridgehead. It is based on an X.400 MTA, but with restricted GUI functionality oriented towards the Connector role. X.400 Bridgehead can be considered as a re-implementation of the older connector using:

  • A new X.400 MTA.
  • A new GUI.
  • Externally published Microsoft APIs (as opposed to internal ones).

How Exchange 2007 Supports X.400

Exchange 2007 does not support connections using X.400 P1; X.400 Bridgehead is needed for this. However, Exchange 2007 does have extensive X.400 support comprising:

  • Support for the core X.400 information framework and elements of service.
  • Representation of X.400 information in MAPI attributes in the Exchange Store.
  • Access to this X.400 information using MAPI, which is how Boldon James Safemail works.
  • X.400 addressing of Exchange users.
  • Core X.400 address support, to enable X.400 based routing to connectors (native or third party such as X.400 Bridgehead).

This core X.400 service can be shared between Exchange 2007 SP1 servers using the SMTP connector in the following way:

  • X.400 and other messaging information carried in TNEF format, which is a Microsoft format.
  • Use of Microsoft SMTP extensions to carry X.400 elements of service such as Originator Requested Alternate Recipient.
  • Encoding X.400 OR Names into SMTP addresses, using a Microsoft format based on the MIXER standard.
  • Three queues for high/normal/low priority messages.

This is a good mechanism to interconnect Exchange 2007 servers to provide X.400 services, but is not suitable for connecting to third party systems.

Use of X.400 Bridgehead to Interconnect Exchange Servers

X.400 Bridgehead can be used to interconnect two Exchange 2007 SP1 servers, as an alternative to the native Exchange mechanism. While use of the native mechanism will generally be more convenient, benefits of using X.400 Bridgehead include:

  1. Use of an open standard (X.400 P1) for the interconnection. This could be for policy reasons, or to facilitate changing one of the servers at a later date.
  2. Because of functionality offered by X.400 Bridgehead that is not available with the native Exchange connector.

X.400 Bridgehead Server Features

This section considers the major features of X.400 Bridgehead.

Note: This list is provisional, and may vary in first and subsequent X.400 Bridgehead product versions.

Connectors and Configuration

Exchange’s model of connection to peer MTAs is by use of connectors. X.400 Bridgehead will follow this model. The basic architecture is that there is a single M-Switch X.400 server for each Exchange server (and not one per connector).

The X.400 Bridgehead UI will present a familiar connector model. Under the UI, this will control two things:

  1. Each connector definition will cause appropriate messages to be routed from Exchange to the integrated M-Switch X.400 server.
  2. Each connector definition will be associated with a peer X.400 MTA connection in the M-Switch X.400 configuration.
  3. The connector definition will ensure correct M-Switch X.400 internal routing to the associated X.400 MTA.

This provides a connector model, using the general purpose configuration capabilities of Exchange and M-Switch X.400.

Resilience and Redundancy

X.400 is generally used in environments with high reliability requirements. X.400 Bridgehead has a number of features that are oriented towards this environment. These include:

  • Fail-over routing. When one peer MTA is not available, another one will be used in order to avoid delay.
  • Load balancing. A variant on fail-over routing, where traffic is shared over multiple links.
  • Fail-over clustering support, to deal with CPU and associated system failures.

Precedence Handling

Precedence is critical for military systems, M-Switch X.400 has comprehensive support for precedence handling.

Many of these features are included in X.400 Bridgehead, and in particular efficient scheduling based on the six military precedence levels to ensure that high precedence messages get sent first. It also includes capacity reservation for higher precedence messages.


This paper has given an overview of the capabilities of Exchange X.400 Bridgehead, and shows how it provides a high reliability X.400 P1 connection capability for Exchange.