Sign Up Follow Join Read

M-Switch (X.400) Server

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

Deployment Targets

 

X.400 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, security label handling 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.
  • In support of communication over constrained links such as HF Radio or Satcom. Follow the link for more information on M-Switch's capabilities for constrained networks.
  • As an ACP 145 gateway, providing STANAG 4406 message signing and verification.

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:

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.

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 (1999)) 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.

Security Labels

M-Switch handles security labels in X.400 messages, including control of routing delivery based on Access Control using Security Clearance.

Constrained Network Support

M-Switch provides optimized support for constrained networks such as HF Radio and Satcom, supporting both point to point and multicast communication and EMCON (Emission Control)/Radio silence. Click for more on M-Switch constrained network support.

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 below (click to show/hide a larger version), and the following sections summarize how these components work and interact. The event handling system is described later, but not illustrated below.

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.
  • 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. 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.

IPv6

The X.400 protocols run over ISO Transport, which usually runs over TCP using ITOT (ISO Transport over TCP). This can operate over IPv4 or IPv6. Configuration is supported using the encoding defined in X.519(2009) which also enables configuration using Internet domains with resolution to IPv4 or IPv6 addresses at run time.

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 MConsole.

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 MConsole, 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.

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 (envelope and subject from heading), delivery reports and IPNs (InterPersonal Notifications) 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. Isode supports Norman, Sophos and CLAM AV packages. Other packages may be supported in the future.

Content Checking

M-Switch provides a Content Checking Channel that can check for words to block on, for example to block messages with “dirty words”. It is extensible to integrate in different types of content checking.

File Transfer by Email

M-Switch provides infrastructure to transfer files by email, which is designed to support applications such as directory and database replication. It could also be used to support user file transfer.

There is a file transfer by email server that watches configured directories, and transfers files to one or more email recipients associated with each directory originating from an email address associated with the directory. Files are used with naming conventions to indicate message submission and successful or failed delivery to each recipient (using X.400 delivery reports). There is a matching file transfer by email channel that delivers messages and reports.

More information is given in the Isode white paper [File Transfer by Email], and information on its use for Directory Replication is described in the whitepaper  [Directory Replication by Email and over 'Air Gap'].

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 the Message Operator Interface Web Application 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.

Archived messages are designed to be reviewed from an online M-Switch server using SOM and QMGR to read archived messages and pass to an Isode GUI. Isode also provides a function, licensed as part of the X.400 Client API, to parse archived messages so that archived message files can be handled in a customer developed application.

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 has a rule based authorization system, including GUI configuration in MConsole. Capabilities include:

  • Routing and checking configuration
  • Archiving control
  • Configuration of groups of users and hosts
  • Closed User Group
  • Channel and message controls based on message size
  • Control of checking and conversion
  • X.400 per user delivery capability checking (size, content, EITs)
  • Priority based routing

Boundary Acknowledgement

M-Switch can be configured to generate acknowledgements for messages being relayed both read receipts (X.400 IPNs and SMTP MDNs) and delivery reports (X.400 DRs and SMTP DSNs). This is to support end systems which do not generate acknowledgements and security boundaries (e.g., Data Diode) where acknowledgements cannot be returned. There is an option to configure acknowledgement generation where they are not requested, and to control relayed acknowledgement requests. This works for M-Switch X.400, M-Switch SMTP and M-Switch MIXER.

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.509 certificates with MTA subjectAltName needed for this can be generated by Sodium CA.

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.

Security Label Support

M-Switch X.400 recognizes X.411 (message envelope) Security Labels. Support for STANAG 4406 (content) security labels is planned. M-Switch X.400 supports FLOT (First Line of Text) labels, and can map between FLOT and X.411 labels.

M-Switch provides Security Label based checking, with Security Policy Based Access controls against Security Clearance, with clearance configurable for Channel, Peer MTA, or User. This also includes digital signature checking and support for setting and enforcing signatures and labels when using File Transfer by Email.

For more information see [Security Label Capabilities in M-Switch].

Header and Message Content Processing

For X.400 Inter-Personal Messages (including P772), M-Switch can perform a range of conversion activities using a 'shaper' 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.

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. Management of X.400 DL membership, priority control and submit permissions is handled in MConsole.

M-Switch also provides an option to have an entity that is a hybrid between a User Agent and Distribution List to enable a configuration where a User Agent can effectively send as a Distribution List. This is primarily for Aviation (AMHS) deployments.

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 X.400 messages and Internet messages.


ACP 145

M-Switch can be used to provide STANAG 4406 conversion with message signing and verification according to ACP 145. For more details see our M-Switch X.400 Military Messaging page.

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.

X.400 Gateway APIs

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.