Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Products

Isode M-Switch X.400

M-Switch X.400 is a high performance, highly flexible and robust X.400 Message Transfer Agent (MTA).

 

Deployment Targets

M-Switch X.400 can be deployed in the following ways:

• As a "Backbone MTA", whose role is primarily to connect together other X.400 MTAs, acting as a P1 switch, providing high performance switching and robust message routing.
• As a "Local MTA" (or "Departmental MTA") used to provide X.400 support to end users by use of User Agents. In this situation, M-Switch X.400 will often be used in conjunction with M-Store X.400 to provide mailbox storage for X.400 P7 User Agents.
• As a "Border MTA", to provide connection between different X.400 domains using capabilities such as authorization and anti-virus.
• As a MIXER gateway to convert between X.400 and Internet Mail. This is done by using the M-Switch MIXER product, which is based on M-Switch X.400 and M-Switch SMTP functionality.
• As a special purpose gateway, to integrate with other services, for example AFTN in Aviation markets and ACP 127 in military markets, using one of two X.400 Gateway APIs

This document describes all of the general purpose features of M-Switch X.400, suitable for commercial, EDI, Aviation and Military use. Some specific features for military markets and military conformance are described here.

Further information on deployment targets for M-Switch X.400 is provided in Isode’s solution pages:

• Military. Further details on Isode's Military Messaging Handling Systems (MMHS) solutions are given here.
• Aviation. Further details on Isode's Air Traffic Services Message Handling Systems (AMHS) are given here.
• EDI. Further details in Isode's EDI solutions are given here.
  

Key Benefits of M-Switch X.400

The M-Switch has many functions, which are described below. Reasons why this product may be of particular interest include:

Flexibility

The architecture of the Message Switch, the management tools, and directory based configuration combine to give a very high degree of customer flexibility.

Performance

M-Switch X.400 has very high throughput and low latency.

Excellent scheduling and operational characteristics

The Queue Manager (QMGR) and channel architecture described below enables a sophisticated scheduling approach, which combined with the Message Switch's queue structure leads to a product which works exceedingly well in demanding operational environments. More details are given here.

Rock Solid

M-Switch has exceptional robustness and stability, including support for fail-over clustering and Off Site Hot Standby (Disaster Recovery).

Directory based configuration

The Message Switch uses LDAP/X.500 as its preferred configuration mechanism, which enables sharing of routing and configuration information, and flexible client/server management.

Message distribution statistics displayed by the Message Operator Interface

Management Features

The product has a wide range of management features, including GUI based configuration and operational control, SNMP monitoring, distribution lists, conversion and gateway management, message tracking, and statistics.

Virus Checking of X.400 Messages

Virus checking of X.400 Messages. A flexible approach, which allows use of various different virus checking packages. This is provided by the M-Switch Anti-Virus add-on package.

Full X.400 Support

M-Switch is conformant to the most recent X.400 standards (X.400 (2003)) offering very high functionality, and offering X.400 P3 support as well as X.400 P1.

Security

There are a variety of security features, including support of X.509 PKI based X.400 P1 Strong Authentication, use of SASL authentication and TLS data confidentiality for the Isode management protocols, audit database, and a general purpose message authorization control.

Cross Platform

M-Switch X.400, including all management tools is available on Windows and Unix (Linux; Solaris; HP-UX) platforms as described here.

Message Switch Functionality

Architecture

The overall M-Switch X.400 architecture and the primary processes that comprise M-Switch X.400 are illustrated in the diagram to the right (click on the tumbnail for a larger version), and the following sections summarize how these components work and interact. The event handling system is described later, but not illustrated.

Message Queue

The (on disk) message queue is the centre of M-Switch. Arriving messages are written to the disk and secured, which is central to reliable store and forward messaging. Messages may then be checked and processed locally, before being sent on and removed from the disk. Typically, messages will remain in the queue for a very short while, often less than a second.

Channels

Most M-Switch processes are channels, shown in purple on the diagram above. The exceptions are QMGR (which is special) and three processes associated with the audit database. Channels perform many functions, including bringing messages into M-Switch (e.g., X.400 P1 Channel), delivering or transferring messages out of M-Switch, and processing messages within M-Switch.

Queue Manager (QMGR)

QMGR is the operational core of M-Switch, communicating with channels and with management interfaces. Key QMGR tasks:

• Starting and stopping channel processes.
• Scheduling active processing and delivery of messages.
• Controlling number of connections to the X.400 P1 server and X.400 P3 Client channel.
• Receiving status information from channels, on connections and message transfer status.
• Responding to information and control requests from management processes.

To achieve this, QMGR makes use of three protocols:

• An internal channel communication protocol.
• AgentX to enable SNMP monitoring (not included in R12.0)
• SOM (Switch Operational Management Protocol), which is used by Isode’s management tools and provides strong authentication and data confidentiality using TLS and SASL. SOM Client Libraries are available for use by third party management tools (for example: Sentra)

QMGR is a multi-threaded event driven process that holds an internal representation of the status of all queued messages, channels and connections. By handling all of this with a single process that does not need to look at the queues on disk, very sophisticated scheduling, control and status reporting is available. QMGR is designed to efficiently manage very large message queues (hundreds of thousands of messages). All information held by QMGR and control options are available through the MConsole tool.

Message Submission Library

The Message Submission Library provides a standard internal service for putting messages onto the message queue, which ensures that per message functions such as authentication, routing, and processing calculations are applied consistently and correctly. In older versions of M-Switch, this functionality was provided in a separate process. Key functions provided by the submission library are:

• Sender validation.
• Recipient validation and message routing.
• Determining what internal processing is needed.
• Policy and authorization checks.
• Writing the message to disk.

The Message Submission Library is used in many components of M-Switch, and in particular to handle inbound messages from the X.400 P1 Channel and X.400 P3 Client Channel.

X.400 Protocols

X.400 P1 is provided by the X.400 P1 Channel ("x400p1"). This may be run in two ways:

1. Initiated by QMGR, to connect to remote MTAs to send and receive messages.
2. Initiated by an incoming X.400 P1 connection, through the Isode OSI transport service listener ("iaed"). This will enable a remote MTA to send and receive messages.

X.400 P3 is implemented in two different channels.

1. The P3 Delivery Channel ("p3") is initiated by QMGR, and is used to deliver messages to a server, and in particular to an X.400 Message Store such as M-Store X.400. This uses the "MTS Forced Access" application context.
2. The P3 Client Channel is initiated by incoming X.400 P3 connections through the Isode OSI transport service listener ("iaed"). This will be used by P3 Client applications sending and receiving messages, including applications built on the Isode X.400 Client API. This used the “MTS Access” application context.

M-Switch X.400 operates primarily at the message transport level, and so is independent of message content. Any X.400 content can be transferred, and in particular the X.400 Interpersonal Message format (P2/P22), the Military P772 format and the X.400 EDI Format (Pedi) are supported.
Detailed information on X.400 feature support and conformance is provided here.

M-Switch Configuration

M-Switch X.400 generally uses directory configuration, which has many advantages. Table based configuration is also provided, but is generally not recommended.

The M-Switch GUI for managing directory configuration is EMMA, which is described in M-Switch Configuration Management.

M-Switch configuration is used by all of the M-Switch processes. Logically, configuration information from the directory is used by all processes. As changes to configuration are generally infrequent, this is implemented by QMGR obtaining configuration information from the directory using LDAP, checking for updates, and sharing it with the other processes.

Self Test

In order to optimize performance, the number of channels running, number of each channel type running, number of connections to a single MTA, will vary dependent on many factors, including remote system, network and local hardware performance. Manual optimization is complex, and in any event the optimal configuration is likely to vary over time. For this reason, M-Switch does a sophisticated “self test”, to measure performance and adapts configuration accordingly. This enables M-Switch to adapt its operational parameters to different hardware and network environments.

X.400 Message Routing

X.400 Message routing is configured in the directory using EMMA, based on RFC 1801 “X.400-MHS use of the X.500 Directory to support X.400-MHS Routing”. Routing is primarily done at the time the message is submitted, with directory checks also performed by the X.400 channels.

The routing tree mechanism allows for flexible routing configuration, including alternate routing to support fall-back routing and load balancing. Multiple routing trees may be used, to allow some routing configuration to be shared between MTAs, without requiring each MTA to route in exactly the same manner. Routing can be done on all X.400 address components (down to the mailbox level), including support for wild card routing, with pattern matching on address component values.

Message Priority

M-Switch handles messages based on priority, which is available for all protocols (not just X.400). This includes standard X.400 three level priority and military six level priority. Isode GUIs can display using standard X.400 or military priority names. Message priority is set by the originating application, and may be modified by distribution list processing. M-Switch scheduling will always send higher priority messages first. Some or all channels may be set, using MConsole, to only send messages above a certain priority for a specified period.

Permanent (Scheduled) Associations

Connections to peer MTAs can be configured to be "permanent", so that they are always open. This will reduce message latency, by avoiding the need to open a connection to transfer a message. Permanent associations can be open all the time, or occur at scheduled times.

Permanent associations may have an associated message priority, for example to hold an open connection only for use by high priority messages. This can be used in conjunction with scheduling, to prevent lower priority messages from being transferred at scheduled times. Priority scheduling may be given a start and stop time, so that transfer of lower priority messages can be disabled for a (one off) period.

For more on Intervals, Schedules, Precedence & Permanent Associations, click here.

Event Handling

M-Switch uses the Isode event handling system. Multiple event streams can be configured, with event access using Isode’s Event View, Unix Syslog, or Windows Event Manager. Isode events are documented with description and severity.

More details on the event system are given in this whitepaper on Operational Monitoring.

Audit Logging & Audit Database

Detailed information on messages handled and processing status are recorded in an audit log. This audit log is processed by the Message Audit Service which is stored in an audit database. The audit database may be local or remote and used by one or more M-Switch servers.

The Audit Database is accessed by MConsole and the Message Operator Interface (MOI) which use this information to provide:

• Statistics and reports on M-Switch usage and performance.
• Message Tracking.
• Message Archive Retrieval.

Further details are given in Message Operator Interface Overview.

Anti-Virus Channel

Detailed information on anti-virus capabilities are given under M-Switch Anti-Virus. This section summarizes how these capabilities are provided in M-Switch.

The Anti-Virus channel operates by breaking out body parts of an X.400 IPM (including military P772) and passing them to a third party AV checker. Messages are deleted, and warning messages may be sent to message originator and recipients. It is straightforward to use most AV checkers in conjunction with M-Switch.

Message Archive

Messages may be archived at the same time as they are placed into the M-Switch message queue. Messages are archived in a single file per message, in a file system directory. The archive directory is named using date/time, and changes at configurable intervals. This enables the archive directory to remain a reasonable size and to facilitate offline backup. The archive file name is audit logged along with other standard message audit information.

Message Tracking from MOI or MConsole can use information in the audit database to locate messages, and then use the SOM protocol to retrieve archived messages via the QMGR (which directly accesses the identified file in the archive), and display or forward them. Similarly, these tools can also view messages in the queue and quarantine.

Housekeeper Channel

A number of general functions are handled by a special Housekeeper Channel, including:

• Processing Delayed Messages. During message submission, DNS and LDAP are used to determine routing and processing of messages. In the event of a timeout on one of these services, the message is “delayed” and message submission is completed later by the Housekeeper Channel.
• Message Warning and Timeout. When a message has been in the queue for a configurable period, it will be timed out, and a delivery status notification sent to the sender. At intermediate times, messages warning of delay may also be sent.
• Operator requested Message Deletion and Non-Delivery. In normal processing, message deletion is handled by the last channel doing work on the message. The operator may request message deletion or non-delivery using MConsole, which will be done by the Housekeeper Channel.
• Message Redirect. The operator may request redirection of a message recipient to a new recipient using MConsole, which is done by Housekeeper Channel.
• Message Reprocessing. Routing configuration for M-Switch may change in a way that would cause different routing for a message. The operator may request that a message or groups of messages are “reprocessed”, so that the updated routing calculation is applied. This is particularly important if a routing change is made to enable queue messages to take an alternate route.

Authorization & Routing Policy

M-Switch provides a comprehensive authorization framework, for controlling which messages can be sent. This includes controls for individual senders and recipients. Controls are often applied on the basis of channel. So far channels have been described in functional terms. Multiple logical channels can be created using the same protocol. For example to create “P1 Internal” and “P1 External” channels, each with a group of associated MTAs. This logical grouping can be used to set up authorization policy, which will enable appropriate message relaying and block other types of access.

Security and Authentication

X.400 P1 can use simple authentication (password based) or strong authentication based on X.509 PKI (Public Key Infrastructure). Strong authentication increases security, and reduces management complexity as it does not need password administration. P1 Strong Authentication is based on Isode's Strong Authentication Infrastructure.

X.400 P3 uses simple authentication. Strong authentication is planned for a future release.

Isode uses Transport Layer Security (TLS) for data confidentiality and Simple Authentication and Security Layer (SASL) for authentication in Isode's SOM protocols, so that secure management from MConsole is possible.

Header and Message Content Processing

For X.400 Inter-Personal Messages (including P772), M-Switch has an "exploded" format, that represents the message as a directory hierarchy, with a file for each message header and body part, and subdirectory for forwarded messages. This format enables other programs to easily manipulate parts of a message. Conversion between the single file and exploded format is referred to as "exploding" and "flattening" and is done by a p2explode and p2flatten channel.

Individual body parts can be converted from one to another using conversion filters. Typically this is used for converting a text body part from one character set to another: for example, from T.61 (teletex) to IA5 (International Alphabet 5, similar to ASCII) as specified in X.408. Such conversions are often necessary as part of content-type conversion. The necessary conversions are calculated when a message is first submitted and they may be re-evaluated when a message is 'exploded'.

It is often desirable to rewrite header information in particular to 'normalize' addresses by rewriting the address in some canonical form, rather than one of the multiple addresses that can be used to reach a specific recipient. Channels for the header normalization of Internet message headers are provided. This capability can be used to provide a coherent view of addresses for local users, or to manage addresses to give an external view in a firewall type configuration.

Content Checking

M-Switch provides a Content Checking Channel ("P2Check") that operates on exploded messages, and can check for words to block on. It is extensible to integrate in different types of content checking.

X.400 Distribution List (DL) Processing

Expansion of distribution lists is provided by a list channels which uses the LDAP/X.500 Directory to provide X.400 conformant distribution list expansion. Setup of X.400 DLs is done using EMMA. Management of X.400 DL membership, priority control and submit permissions can be done either by EMMA or by Sodium (Isode’s Directory administration tool).

X.400 (1984) and X.400 Downgrade

Versions of X.400 after 1988 are compatible, primarily due to extensibility mechanisms added in X.400 (1988). M-Switch supports X.400 (1984), which is not compatible.

The X.400 channel performs downgrading of P1-1988 to P1-1984 when sending using mts-transfer-protocol-1984. O/R Address downgrading can be configured to conform to ISO/IEC DISP 10611-1 Annex D (Message Handling Systems - Common Messaging - Part 1: MHS Service Support). A message will be non-delivered if downgrading fails (according to the rules of X.411, Annex B).

There is also support for content downgrade as defined in RFC 1328. Downgrading of P22 to P2 follows ISO/IEC DISP 12062-1 (Message Handling Systems - Interpersonal Messaging: Part 1: IPM MHS Support) Annex C.

MIXER

MIXER is conversion between Internet Mail and X.400 is provided by M-Switch MIXER. M-Switch MIXER includes all of the functionality of M-Switch X.400 and M-Switch SMTP, and includes additional channels to map between exploded X.400 messages and exploded Internet messages.

P1 File

M-Switch X.400 supports delivery to an X.400 format known as "P1 File" using a P1 File Channel. This format is a de facto industry standard, and can be used to integrate M-Switch X.400 with a number of third party gateway products.

X.400 Gateway APIs

Isode supports two X.400 Gateway APIs.

These APIs enable integration of X.400 messaging services with other messaging or telematic services. For example:

• Integration of a military X.400 system with ACP 127 Messaging.
• Integration of an air traffic messaging system with AFTN Messaging.
• Integration of a messaging system with facsimile or telex services.

The above diagram illustrates how both gateway APIs allow Isode customers to build channels. These channels will operate as independent processes (i.e., the channel is not invoked by the QMGR, although they are monitored and controlled by the QMGR). These gateway channels use the Isode library code to submit messages and to retrieve messages from the M-Switch queue. It can be seen that the gateways are a tightly coupled part of M-Switch X.400.

Conformance

M-Switch X.400 Conformance, including conformance for aviation markets is set out here.

Additional M-Switch X.400 Conformance for military markets is set out here.

Availability

M-Switch X.400 is available on Solaris, Windows, Linux and HP-UX. More details on supported platforms and versions can be found here.