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

Whitepapers

Why use a P7 Message Store?
Getting X.400 messages to and from End Users

Purpose

The goal of this paper is to give an understanding of what an X.400 Message Store, such as Isode’s M-Store X.400 does, and where and how it should be used. In order to do this, the paper looks at general requirements for sending and receiving (X.400) messages, and looks at various approaches that can be taken.

Requirements and Choices for Sending and Receiving X.400 Messages

The following are the basic requirements for sending and receiving (X.400) messages. These requirements distinguish the User (a human or system process) from the User Agent which is the software used by the User to interact with the messaging system.

1. The User needs to compose or construct a new message using the User Agent and send it.
2. The User needs to be able to receive messages.
3. The User may need to change the system running the User Agent, either for mobility reasons (to handle messages in different locations) or for reliability reasons (because the system running the User Agent fails, and an alternate system needs to be used).
4. The User may need to retrieve previously sent or received messages.

This paper looks at four mechanisms to meet these requirements.

1. Use of X.400 P3, which is the basic X.400 protocol for message submission and delivery.
2. Use of X.400 P7, in conjunction with an X.400 Message Store.
3. Gateway to another protocol, and meet the requirements indirectly.
4. Providing Web access to the user as mechanism for interacting with message services. Web access is not a complete solution, and will be used in conjunction with one of the above mechanisms.

X.400 P3 & the X.400 Message Service

Message Transfer Agents (MTAs) are the servers that work together to provide the X.400 Message Transfer Service. MTAs talk to each other using the X.400 P1 protocol. The X.400 Message Transfer Service is provided to User Agents (UAs) using the X.400 P3 protocol that connects a UA directly to an MTA. The core elements of X.400 P3 are:

1. Authentication. There is mutual authentication between the UA and MTA at the start of a P3 association.
2. Message Submission. A message (message content) is provided by the UA, along with envelope information (in particular a list of intended recipients). The MTA accepts this message and returns information on the message to the UA for tracking and correlation.
3. Message Delivery. The MTA sends a message and envelope information to the UA. The key feature of P3 message delivery is that the message is pushed by the MTA to the UA and the UA accepts the message as a one off process.

X.400 P3 meets the first two (core) requirements identified in section on Requirements and Choices. It does not directly address the second two.

X.400 P7 & X.400 Message Store

An X.400 Message Store (MS) is an optional component that sits between an UA and an MTA. The MS interacts with the MTA using X.400 P3 on behalf of the user. The basic model is that the MS is a server process that is "always there" and will take immediate delivery of all messages sent to a UA, and store them in an "In Box". Messages are stored as delivered (i.e., they do not get modified after delivery), and have a status that can have three values: new; listed; processed.

An X.400 Message Store provides four core services to the UA over P7.

1. Authentication between the client and server (both directions).
2. Indirect Submission. This function is identical to P3 Submission from a client perspective, and the MS makes use of the P3 Submission Service to provide indirect submission. At the same time, the MS may keep a copy of the submitted message in an "Out Box".
3. Message Access. This service allows the UA to access messages in either the In Box or the Out Box. The main elements of Message Access are:
   
   1. Summarize. This is used to give summary information on the In Box or Out Box. A common use is to find the number of new messages or number of high priority messages. Many clients do not use this, and go straight to list.
   2. List is a general purpose searching mechanism to identify a set of messages based on a filter, which offers high flexibility to identify messages. It will always return the sequence number of each matched message, and may return attributes associated with the message. Some example common filters:
      
   1. "all new messages", so that incoming messages can be processed.
   2. "date range", to recover messages from archive
   3. Filters based on message priority.

   Some example common usage of information returned:

   1. Just the sequence numbers, which will be used to drive an automatic message fetch.
   2. Attributes such as Message Originator and Subject, to be displayed in a GUI listing, that can be used to select which message to fetch.
   3. Message size and priority, so that high priority messages can be fetched first, and smaller messages can be fetched before larger ones.
   1. Fetch. The complete message or selected parts of a message (identified by sequence number) is fetched. Once all of a message has been fetched, it is changed to state processed.
   2. Delete. The client can delete a message. This is prohibited in some deployments, where deletion is handled by the system administrator. This may be beneficial to ensure that the user always has all messages available or to keep a complete message audit trail.
4. Auto Actions. The client or administrator can configure auto-actions, which are applied to messages when they are delivered. Auto-actions can be controlled by filters, for example to apply an auto-action only to urgent messages. The most important auto-actions are:
   
   1. Auto-alert. This notifies the client of a new message, so that it can be retrieved immediately. This can be used to achieve very low latency message delivery to the desktop, and can optimize overall performance.
   2. Auto-forward. This sends on the message to another recipient. Variants of this are:
      
      1. Keep the local copy too (sometimes referred to as auto-copy).
      2. Delayed auto-forward, which only happens is the message is not fetched in a specified time. This can be used to ensure rapid processing of messages.
         An X.400 Message Store product will also provide a range of operator and administrator management capabilities.

An X.400 Message Store product will also provide a range of operator and administrator management capabilities.

X.400 P7 vs X.400 P3

The most visible difference between P3 and P7 is that P3 provides submission and delivery only, whereas a P7 Message Store holds copy of delivered and submitted message in an In Box and an Out Box. This storage has a number of potential uses and benefits:

• Messages can be accessed when the client wants, and not just once on delivery.
• Messages can be stored for a longer (possibly fixed) period to enable:
  
  • Client recovery of lost messages
  • A client searchable archive (using P7)
  • A formal online archive, that may be used for audit and general recovery purposes

In order to support stored messages effectively, P7 provides a range of functions that can be used in a simple or sophisticated manner.

A related architectural difference is that message management options are available to ensure that messages get to the end user. Delayed auto-forwarding is an example of a built in capability.

Another example is the Isode M-Store X.400 management capability to monitor unread messages. This enables an operator to detect that a message is unread, and to take appropriate action. Use of an MS enables a higher level of management.

One implementation consideration relates to the nature of P3, which is ideal for delivery to server processes such as an X.400 Message Store. Essentially, P3 delivery works by sending out a stream of messages, which the client must reliably store. Care needs to be taken with the client implementation to ensure that there is no possibility of message loss. In contrast the P7 model is based on client access which, as well as providing additional functionality, is more natural and straightforward for the implementer.

Supporting Unreliable Clients

If a decision is being made between using P3 and P7 to provide send/receive of X.400 messages, a key question to consider is client reliability, and in particular the approach to hardware failure. There are two basic models:

1. Reliable Client. Here the model is to provide hardware redundancy and backup systems appropriate to the service being provided, and to ensure that once messages get to the client that they are not lost.
2. Unreliable Client. Here the model is that the client hardware can be thrown away and replaced with a new one from store. Message reliability is handled server side.

If the second model is chosen, P7 is the right protocol as storing messages on the server is necessary to achieve reliability. Both P3 and P7 are suitable for supporting the reliable client model.

Conversion to another Protocol

An alternative to using an X.400 protocol to send/receive X.400 messages is to convert the message in some way, so that another access protocol can be used. This can include conversion to a standardized protocol such as SMTP (using a product such as Isode’s M-Switch MIXER) or AFTN (Aeronautical Fixed Telecommunication Network) or conversion to a proprietary protocol or format.

Protocol conversion is often necessary to allow interconnection of different systems, and there are many situations where it is a sensible choice.

However, where the primary goal is to send and receive messages over an X.400 infrastructure, this approach is almost always a bad one. Reasons:

• Adding in protocol conversion puts another piece into the system, which will increase complexity and most likely reduce performance.
• Loss or degradation of information and functionality is likely:
  
  • X.400 is feature rich, and it is likely that a mapped protocol will be less rich. In particular use of SMTP or AFTN leads to substantial functionality loss.
  • Digital signatures and other security features rely on protocol and cannot in general be mapped.

Message Filing

An X.400 P7 Message Store provides a sophisticated In Box/Out Box service. This is the functionality needed by most X.400 messaging deployments. The X.400 P7 specification supports message folders using the message group mechanism, but this does not include folder sharing with other users. This mechanism is not widely implemented in P7 clients or servers.

Where client/server message filing is required, Isode recommends the use of IMAP (Internet Message Access Protocol) which is the Internet Standard for messaging filing, and supported by Isode's M-Box product. Filing X.400 messages using IMAP is straightforward, as X.400 messages can be encoded within an Internet Message using the X400WRAP Internet Standard specified in RFC 3855.

Web Access

A variant on the architectures described before is to use Web access from the user's desktop. This choice is an important part of the overall access design. In general Web access will be used in conjunction with one of the approaches descrisbed earlier. The diagrams above show how Web UIs can be integrated with either P3 or P7.

There are many general considerations on usability and deployment for choosing between Web and GUI, and these are not considered here. For many users and applications, Web is ideal for occasionally used functions, whereas a GUI is preferable for high volume work.

A choice may need to be made between a Web UI and a P7 GUI. Some technical observations can be made:

1. P7 will require significantly lower data volumes than HTML (Web) and so will be more suitable for low bandwidth links.
2. P7 will generally be implemented as a background task in a GUI, which will make it better for low bandwidth and/or high latency links.
3. In the event of network failure, a P7 Client can continue to work on messages that have been previously fetched and to prepare new messages. This characteristic would make P7 preferable for unreliable links.
4. Message digital signature needs the binary version of the message to create a message signature, and so cannot be done on the desktop. This leads to improved security characteristics of a P7 GUI.

There are clear situations where both P7 GUI and Web UI are preferable. Fortunately, it is quite sensible and reasonable to support both options.

Conclusions

This paper has looked at architectural choices for sending and receiving X.400 messages, and when different options are appropriate. Use of an X.400 P7 Message Store has particular benefits where there are requirements to:

• Provide management post delivery to ensure that messages are read.
• Provide an online archive of sent and received messages.
• To support "unreliable" clients, by providing all necessary reliability features on the server.