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

Whitepapers

X.400 Technology for Internet Service Providers

Purpose

Isode markets its X.400 and Internet messaging solutions as different products. However, Isode's core M-Switch product is the same for both X.400 and Internet deployments, with some modules specific to Internet and X.400 deployments. This white paper looks at features which are present in Isode's products primarily to address X.400 markets, but can add significant value to ISP messaging deployments.

What is X.400 Anyway?

Most ISPs have limited knowledge of X.400, and those that do would typically attach views like "It's a Dinosaur" or "Didn't X.400 die with the Arc?". X.400 is a set of messaging protocols developed by CCITT and ISO, which were originally intended to provide a global messaging infrastructure. This did not happen, and most people now use Internet email for their messaging. However, X.400 is still alive and well in certain specialized markets that typically have strong security and management requirements.

Isode has separated out its X.400 and Internet Email product descriptions, so that capabilities are laid out separately in order to set out the solutions clearly for target markets. M-Switch has a single manual, and the multi-protocol nature of the product becomes clear when you start to look closely (although Internet Mail configurations will not show any X.400 functionality or information to users or operators). We tried to separate out the manual (for R10.2), but this proved to be unmaintainable due to the high level of functionality that was a part of the core product. We noted that much functionality developed for X.400 customers was also available to Internet mail users. This led to the question "How could this functionality be useful to Internet users?". The result is this paper, which looks at how functionality in the Isode products which was developed primarily for X.400 markets can be useful for Internet customers.

Customer Management Philosophy: X.400 vs Internet

A typical X.400 operator has a very different underlying message management philosophy to a typical Internet mail service provider. Consider the case of a failed connection to transfer a message. A typical ISP or Enterprise will just regard this as an event that will go un-noticed. The ISP will want to monitor for major failures, but a transient failure of this nature will either sort out, or result in a timed out message. A typical X.400 operator will want to know immediately about such failures, and would consider what corrective action to take (e.g., calling the operator of the remote MTA or re-routing the message). This may seem unduly paranoid, until you consider that a typical X.400 infrastructure is supporting services such as Military formal messaging, EDI, and ground to ground Aviation scheduling. Where messages are dealing with things such as scheduling of aircraft flights, you need to take a pro-active operational approach to managing the messaging infrastructure, and operators need to be pro-active when messages are delayed or not read by recipients.

Most Internet environments do not need this level of management. However, many customers have a growing expectation of the reliability and quality of email service, and many of the capabilities described here will be useful for Internet Email Service Providers to improve their operations and to provide a higher level of managed service to their customers.

The Central Role of Message Switching

In many Internet email systems, management is primarily associated with the handling of stored messages, dealing with functions including quota management, mailbox migration and archiving. Often, the SMTP message switching is a simple subsystem with very minimal management capabilities. In a managed messaging infrastructure, where it is critical to ensure that messages are reliably and rapidly delivered, management of the message switching infrastructure is the highest priority. M-Switch, Isode's SMTP and X.400 Message Switch, is a core Isode product with strong management features.

M-Switch Architecture

M-Switch is sold with variants to support SMTP, Anti-Spam, X.400, and MIXER (X.400/Internet Email Conversion). There is a single underlying product, which is a multi-protocol message switch. Although the architecture is multi-protocol, in practice is has been developed to support two protocols: X.400 and Internet Email. Where practical, functionality is implemented in an abstract manner, so capabilities are provided as generic services and not constrained to a single protocol. Protocol specific functionality is provided by "channels" which means that the core system is not protocol specific. This is a very powerful architecture, and means that most M-Switch management features are available in the context of both protocols.

Message Priorities and Scheduling

X.400 has the concept of Message Priority, and Isode has implemented this in M-Switch, including:

• Always working to send high priority messages first, while still optimizing processing (by avoiding stopping and starting processes) and network usage (by maximizing use of open connections to remote MTAs).
• Not starting connections for lower priority messages, when there are higher priority messages in the queue.
• Reserving channel slots for high priority messages, so that there is always spare capacity to process them.

This flexibility is possible because of the Queue Manager architecture, where there is a process that manages scheduling of all messages based on a range of parameters, rather than simply a series of linear queues.

Internet Mail (SMTP) does not have the concept of priority. Because the M-Switch queuing mechanism is common to X.400 and SMTP, priority is available for Internet messaging. This is easily accessed by use of an Internet Message header "Priority:", which can be set to "normal", "urgent", or "non-urgent". This field is defined in RFC 2156 as part of the MIXER specifications, supported by M-Switch, for mapping between Internet mail and X.400.

This priority handling can be useful for Internet mail systems that carry a mix of urgent business critical traffic, and less urgent information.

Active Monitoring and Control

M-Switch has an MConsole tool, illustrated above, which provides monitoring and control functions for M-Switch. MConsole provides a graphical display, which shows a history of the loading of the message switch, and gives status of the various "channels" of the message switch, highlighting any problem queues or messages. It has sophisticated, configurable heuristics for classifying multiple levels of warning condition. It also allows control of the queue, and capabilities such as resubmitting and deleting messages. M-Switch may also be monitored using SNMP (Simple Network Management Protocol).

For a typical X.400 deployment, the ability to carefully monitor message switching is a top priority. Many Internet messaging systems, have relatively crude tools for monitoring. Isode's monitoring facilities are standard for Internet mail.

Dealing with Delayed Messages

Isode's monitoring enables an operator to determine when a message is not being delivered. The operator's first step is likely to be to determine if the cause of non-delivery can be rectified (e.g., by telephoning the operator of a failed server). M-Switch provides other options to the local operator:

• Reroute the message to an different MTA, in order to bypass a failed link.
• Resubmission of the message, to a different recipient.
• Non-deliver the message, so that the originator can be alerted to a failure which cannot be rectified quickly.
• Automatically send the message to an alternate recipient after a configurable period of time. For X.400, this can be a sender specified alternate recipient. This is not possible for Internet mail, as this cannot be set. For both protocols, it is possible to have an alternate recipient associated with the message recipient or a default alternate recipient associated with the system.

These capabilities will help manage messages in environments where it is critical to ensure communication.

Store and Forward Routing

Email uses a store and forward approach, with messages being held at a sequence of MTAs (Message Transfer Agents) en route from originator to recipient. X.400 deployments often use complex store and forward routing topologies, and X.400 MTAs need to be configurable to achieve this. Isode uses an approach of "Message Routing Trees", which was originally defined in RFC 1801 to enable routing information to be shared by different MTAs in a directory, while allowing MTAs to have appropriate routing configurations, dependent on their location in the routing topology.

Internet Email has an approach of direct delivery, and use of the DNS (Domain Name Service) allows an MTA to determine the correct MTA for delivery to a given domain (e.g., delivery to "isode.com"). This approach is very effective in many situations. However, it becomes problematic when when a more complex topology is needed. Often MTAs inside an organization need to route differently to those outside. This can be awkward to configure.

Isode's implementation of Message Routing Trees works for both Internet Email and for X.400, and for Internet Email can be mixed with standard DNS routing. This means that it is straightforward to build more complex store and forward configurations using M-Switch, while still making use of DNS as appropriate and sharing routing configuration between multiple MTAs using the directory. Routing trees can also be used to configure redundant routing, to enable routing to work when individual MTAs fail.

Fail-Over Clustering

In situations requiring high reliability, message switches are generally configured with redundant storage (RAID), so that they are not at risk from failure of a single storage component. In the event of a processor or other system component failing, a typical solution is to have the switch stop working. Messages in transit at the time of failure are then processed when the system component is restored. The message delays caused by this approach are not acceptable in many environments. In order to avoid this, Isode's products all support fail-over clustering. This approach is useful for X.400 and Internet messaging.

Conclusions

This paper has looked at a number of management technologies which are a part of X.400, or are commonly associated with X.400. These are available to those using M-Switch for Internet messaging, and will allow service providers to delivery a higher standard of managed messaging service than with a typical Internet only product.