X.400 Message Switch

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. 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. Two options are provided:
   • singled threaded process initiated through the Isode OSI transport service listener (“iaed”).
   • A multi-threaded process. This is preferred for systems with large numbers of P3 connections.

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.

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

In order to deal with the specification of an X.400 system, there is a series of ISPs (International Standard Profiles) published in conjunction with the base X.400 specifications. “ISO/IEC 10611-1: Common Messaging Part 1: MHS Service Support (1999)” sets out a core framework for the X.400 ISPs. In particular, it defines a set of functional groups to which an implementation can claim conformance. The following table lists all of the X.400 functional groups and which ones are supported by M-Switch X.400.

An MTA must support Message Transfer, using the X.400 P1 protocol. M-Switch is conformant to the core ISP requirements for the 1984, 1988, 1996, 1999, and 2003 versions of X.400. Detailed specification of the Message Transfer Conformance of M-Switch X.400 is provided in two PICS statements:

• Common Messaging: Message Transfer (P1) – AMH11 (based on ISP 10611 – 3/AMH11)
• IPM: Requirements for Message Transfer (P1) – (based on ISP 12062 – 3/AMH22)

Message Access refers to submission and delivery using the X.400 P3 protocol. There are two versions of the X.400 P3 protocol:

• P3 (1988), with conformance defined in AMH12 (MTS Access) and AMH 23 (IPM Requirements for MTS Access).
• P3 (1994), with conformance defined in AMH14 (MTS94 Access) and AMH 25 (IPM Requirements for MTS94 Access). This defines additional end-user management and control functions.

Extensions from X.400(1994) and X.400(1999) can be used with both of these protocols. Isode supports P3(1988) only. Details of M-Switch X.400 P3 conformance are defined in “AMH12 and AMH14 – MTS Access (P3) and MTS 94 Access (P3)” ISO/IEC ISP 10611-4. This is aligned to ITU X.483 “P3 PICS”. Isode is conformant to the mandatory elements of the ISP for P3(1988), with two exceptions:

• DeliveryControl operation is not supported. M-Switch X.400 achieves the functions of this operation by use of its own configuration management tools. This allows access to controls by P7 users and administrators, which increases flexibility.
• For the MTS Forced Access protocol, M-Switch X.400 supports only delivery (and not submission). This reflects the use of MTS Forced Access to deliver messages from M-Switch to a Message Store, where submission is not needed. P3 Clients can submit and deliver messages using MTS Access.

Lower Layers: X.400 & RTSE

The X.400 channels support the 1984, 1988, and 1992 recommendations, including the mts-transfer (P1-1988, RTSE normal-mode), mts-transfer-protocol (P1-1988, RTSE X.410(1984)-mode), and mts-transfer-protocol-1984 (P1-1984, RTSE X.410(1984)-mode) application contexts.

Full RTSE recovery is supported for both inbound and outbound transfers. There is full support for Two-Way Alternate. All three application contexts can be supported by a receiving channel on a single Session address.