X.400 clients (User Agents) use the X.400 P7 protocol to access a Message Store. Isode’s M-Store X.400 is an X.400 Message Store that supports X.400 P7, and also uses X.400 P3 to connect to an MTA (Message Transfer Agent) such as M-Switch X.400. It serves as an intermediary between User Agents and the Message Transfer Agent, accepting delivery of messages on the user’s behalf and storing them for subsequent retrieval.
The Message Store provides facilities for searching and listing messages, to optimize retrieval. Messages may be deleted or retained online in the Message Store. Messages are submitted from a P7 client to the MTA through the message store (indirect submission) and M-Store X.400 can be configured to store these messages in an “out box” for subsequent client access. Message Store and client configuration management is integrated into the messaging infrastructure using the LDAP/X.500 directory.
Key Features
Robust and High-Performance
M-Store is a robust product that uses the underlying file store to ensure message and database integrity. Online backup of both submitted and delivered messages is supported. It includes support for failover clustering and Off Site Hot Standby and Disaster Recovery.
M-Store provides fast message access to mailboxes that may contain hundreds of thousands of messages and high throughput message submission and delivery with low latency.
Performance Optimization
X.400 P7 is a complex and flexible protocol that can be used in many ways. While M-Store X.400 supports a wide range of usage, it is optimized for certain types of use, as described here. Isode’s X.400 Client API is designed so that calls will use M-Store X.400 in an efficient manner. Key optimizations:
- Full message fetch. Few clients make use of the P7 capabilities to retrieve selected parts of messages.
- Empty mailbox. Many systems operate with a “fetch message; process message; delete message” model.
- Large mailboxes, that may contain hundreds of thousands of messages, with most fetched and cached. A common model (for both In Box and Out Box) is that messages are archived, often for a fixed period (e.g., 30 days). At the same time, new messages are fetched quickly, so only new messages are active. There are various optimizations in support of this model, including
- Listing of new messages (to efficiently determine new messages in a large mailbox).
- Systematic fetching of all messages in a large mailbox, to enable restore on local In Box and Out Box messages on a client.
- Searching by message priority (precedence) and message size, which is useful for clients to control order of processing.
- Delivery to clients using auto-alert and immediate fetch.
It is recommended to consider this information when configuring or designing clients to use M-Store X.400.
Message Auto Actions
Auto actions are an important feature of an X.400 Message Store. An auto action may be applied to all messages or to selected ones (e.g., to all high priority messages). M-Store supports the following auto actions:
- Auto Alert. This sends an alert to the P7 client that a message has been delivered to the store, enabling the client to immediately fetch the new message.
- Auto Forward. Message is forwarded on to another recipient, and the message originator notified with an Inter Personal Notification. A copy may be kept for the local user, and this variant is sometimes referred to as Auto Copy.
- Delayed Auto Forward. Message is auto-forwarded if it is not fetched within a configured period. This mechanism can be useful to ensure that messages get processed promptly.
Message Precedence/Priority
M-Store is aware of message priority, including six level STANAG 4406 priority (precedence). Many actions are event driven, and so there is no “ordered queue” to precedence sorted. Clients can search for messages based on priority, and thus order their work to retrieve higher precedence messages first. For message delivery, M-Switch X.400’s precedence ordered queuing will ensure that high precedence messages get delivered ahead of lower precedence messages.
Message Ageing
Both In Box and Out Box stores can be configured to delete messages after a certain period of time. This is useful as a mechanism to automatically clear out messages, and also in support of mandatory online archiving requirements, such as the ICAO (Aviation) requirements for two and thirty day archiving.
Management
M-Store uses directory based configuration, which means that configuration and user agent information is stored in Isode’s M-Vault directory. Use of directory for message store configuration gives a highly flexible approach, integrated with the configuration of the M-Switch X.400. This allows for client/server configuration management and sharing of configuration information between servers.
Isode’s M-Console management GUI is used for both configuration management and operational management of M-Store.
Backup & Disaster Recovery
Because M-Store uses the file store to hold messages (and not a special database), standard backup techniques may be used on M-Store, including the message index.
M-Store provides a restore capability that will synchronize an index server to the message database, removing index entries not needed and creating missing ones. This will deal with the situation where the message and index backups are not aligned.
M-Store also provides built in backup and restore commands, which can be driven using the SOM protocol described below with a scripting interface. This backs up all or selected mailboxes to a specified file store location. Backup and restore can also be requested from the MConsole GUI.
M-Store X.400 provides and off site disaster recover capability that can be used as part of a full X.400 disaster recovery capability.
The diagram below illustrates the architecture of the Isode X.400 Message Store and its relationship to P7 client and to its associated X.400 MTA using X.400 P3. An X.400 Message Store is associated with a single X.400 user. M-Store X.400 uses a single process to support multiple X.400 clients, retaining separate databases for each X.400 client (UA).
There are two databases (of the same format) for each Message Store client; an “In Box” that holds messages delivered to the user and an “Out Box” for messages sent by the X.400 client. Each message is held as a single file on disk that contains:
- Message Content.
- Message Envelope Information.
- Message Store Sequence Number and Child Sequence Number information.
- Cached index attribute values
This file is written once on message delivery (or submission), and not changed subsequently. The files are named by the parent sequence number, which is the primary index to the message in the P7 protocol, plus a ‘state’ character, indicating whether the message is New, Listed or Processed. As a message progresses through these states it is renamed appropriately.
By use of the file store, the indexing and integrity mechanisms of the file store are utilized by M-Store X.400. There is no complex database, and so problems associated with database corruption are avoided. Some operations, such as fetch based on sequence number can operate very efficiently using just this database structure.
In order to support efficient searching and listing of messages, M-Store X.400 maintains an optimized message index.
Note that authoritative message information is held in the message databases. The message index can be completely rebuilt from the message database, and the presence of prebuilt index attribute values stored in message files means that a full decode of messages is not required during this process.
The M-Store X.400 server is a single process, comprising a number of modules. The P7 server module supports P7 connections initiated by multiple P7 clients and will:
- Support Summarize, List, Fetch, Register (auto action) and Delete operations using the In Box or Out Box database.
- Pass Indirect Submission operations to the P3 Submission module.
- Send auto-alerts to the P7 client, as requested by the P3 delivery module.
The P3 submission module will initiate a connection to an MTA for indirect message submission. After the message is submitted, a copy may be stored in the Out Box database.
The P3 delivery module accepts messages being delivered by an MTA. Delivered messages will be stored in the In Box database, and then registered auto actions are processed. Auto-forwarded messages are handled through the P3 Submission module. Auto alerts are passed to the client through the P7 server module.
After a message is delivered into the In Box database for a user, the most recent message for that user is cached in memory. In a typical high performance system, the P7 client will have a registered auto alert and will fetch the message immediately and thus make use of the memory cached copy. Clients will generally cache message copies, and in this case the only further message change will be when it is deleted. Thus the only disk i/o is that needed to write the message, and rename the message file to reflect the change in its status. The message database format is chosen to be efficiently generated from a P3 delivery. This approach provides for very high volume and low latency delivery.
The message index is held in memory within the M-Store X.400 server. It is periodically flushed to disk, and is also written out on a clean shutdown, so that it can be quickly reloaded when M-Store X.400 is restarted. On restart, M-Store X.400 runs an index check routine to ensure that the reloaded index for each mailbox is consistent with the set of message files present in the mailbox (since inconsistency could arise if M-Store X.400 has been shut down uncleanly). This check runs as a background process; while it is running, messages can be submitted and delivered as normal.
The base X.400 standards and ISPs (International Standard Profiles) are set by two bodies.
- The ITU (International Telecommunications Union) as a series of documents collectively referred to as X.400. There are a number of documents in this series (e.g., X.400, X.402, X.420).
- ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) as MOTIS (Message Oriented Text Interchange Systems) and the ISO/IEC 10021 series. These documents are equivalent (e.g., ISO/IEC 10021-7 is equivalent to X.420).
The ITU and ISO documents are technically aligned. There are some small differences because the ITU documents relate only to interconnection with public services, whereas the ISO/IEC documents also cover “local” issues. Isode supports these differences, which relate to different deployment situations, and do not affect interoperability. Conformance to X.400 base standards is listed below.
| ITU X.400 | Message Handling System: System and Service Overview. ISO/IEC 10021-1, 1999 |
|---|---|
| ITU X.411 | Message Handling Systems (MHS): Message Transfer System: Abstract Service Definition and Procedures. ISO/IEC 10021-4, 1999 |
| ITU X.413 | Message Store: Abstract Service Definition. ISO/IEC 10021-5, 1999 (Note the MS service is supported, but not the MS(94) service) |
| ITU X.420 | Message Handling Systems (MHS): Interpersonal Messaging System. ISO/IEC 10021-7, 1996 |
There are two ITU/ISO Protocol Implementation and Conformance Statement (PICS) documents for M-Store X.400, that give a detailed specification of the X.400 services and protocol elements supported:
- Common Messaging: MS Access (P7) – AMH13. This specifies the core capabilities, common to all types of message content.
- IPM: Requirements for enhanced MS Access (P7) – AMH24. This specifies features specific to InterPersonal Messaging
Military Conformance
M-Store also conform the the following standards for military messaging. ACPs (Allied Communications Publications) are issued by the CCEB (Combined Communications Electronics Board). STANAG documents are NATO standardization agreements.
| ACP 123 | Message Handling System: System and Service Overview. ISO/IEC 10021-1, 1999 |
|---|---|
| STANAG 4406 Edition 1, Version 3 | Military Message Handling System. March1999 |
| STANAG 4406 Edition 2 | Military Message Handling System. March1999
|
Management Conformance
| RFC 1801 | MHS use of the X.500 Directory to support X.400 MHS Routin. S. Kille, June 1995 |
|---|---|
| RFC 2294 | Representing the O/R Address hierarchy in the X.500 Directory Information Tree. S. Kille, March 1998 |
| RFC 2788 | Network Services Monitoring MIB. S. Kille, N. Freed, March 2000 |
| ITU X.500 | The Directory: Overview of concepts, models and services. ISO/IEC 9594-1, 2001 |
Ready to request an Evaluation?
Thankyou for considering Isode’s software products. To request an evaluation, please select the product(s) you are interested in, then fill out the enquiry form.