Assured: The Isode Blog

Isode R14.4: M-Switch MIXER - Per Address Mappings

This is the ninth in a series of messages describing new features in Isode R14.4, scheduled to ship in April 2009. You can see all of the messages on this blog relating to R14.4 by clicking on this link

MIXER is a standardized mapping between X.400 and Internet mail specified in RFC 2156. Addresses are mapped algorithmically, with MIXER mappings relating part or all of the domain of an Internet email address to O, OUs, ADMD, PRMD and Country of X.400 OR Addresses. This provides a convenient way to algorithmically map addresses, usually resulting in addresses that are reasonable for human users.

This mapping can be configured in the directory according to RFC 1838. M-Switch MIXER supports this, and provides GUI configuration of the MIXER mappings. A typical MIXER gateway will define a small number of these mappings.

R14.4 extends this core mapping to provide mappings for individual user addresses configured in the directory. A directory entry will hold both Internet and X.400 addresses for a user, and will map between these. This has the benefit of providing a completely flexible mapping for a community of users, and can also utilize information that is already configured in the directory where users have access to both Internet mail and to X.400.

There is flexible configuration for mapping in both directions. It is possible to use multiple directories, each handling different parts of the mail address space. The attributes used for the mappings are also configurable. This is important where a MIXER gateway supports multiple organizations, and there are existing directories for each organization holding the relevant information.

We believe that this will be a useful option for many organizations deploying MIXER gateways.

Another Aviation Messaging (AMHS) win for Isode partner Radiocom Inc

Paraguay's new aviation messaging system, supplied by Isode partner Radiocom, has now gone live.

Supplying components for the new Air traffic service Message Handling Systems (AMHS) is something that Isode have developed a specialization in over the last few years. As with many of our markets, we supply components to partners who in turn supply and install the complete solution for the end user, in this case national Aviation Authorities.

Our partners have been doing a fantastic job of winning bids with solutions that include Isode components. Of 38 countries that have so far decided on an AMHS system, 31 have them have bought systems from Isode partners, incorporating Isode components.

Radiocom have had a great many successes in supplying AMHS systems, particularly in South America, where country after country are opting for Radiocom as their preferred supplier. Hopefully we'll be seeing many more AMHS wins like this in the near future.

Follow the links for more information on Isode's components for Aviation Messaging and Aviation Directory.

Isode Partner Boldon James wins MMHS contract

Isode Partner Boldon James have announced that they've won a large Military Messaging Handling System (MMHS) contract that includes components from Isode.

Our Military Messaging components are something that we've put a lot of work into and it's nice to be able to semi-publicly acknowledge a sale in a market that is understandably reticent about releasing details of sensitive contracts. Although even with this contract we're not allowed to say which 'European Ministry of Defence' the contract is for.

The details of the contract, which is being delivered via Hewlett Packard can be found on the Boldon James website here.

Our congratulations go to Boldon James, together with our hopes for many more successes of this type.

XUXA (X.400 Demo UA) Updates in Isode R14.0

We've continued to update our demo UA, XUXA, and a new version is included in R14.0. Updated source code is also available.

Changes of particular note:

1. XUXA makes use of the new M-Store X.400 capability to store messages on submission. It can be used to show and retrieve submitted messages.

1. Submitted messages ('Sent Messages') can be copied to the 'Outbox' of XUXA, and then sent again with a single operation. This is useful for load testing, making it easy to send many messages at once.

More information on XUXA is available here, more information on R14 is available here.

Getting X.400 messages to and from end users

A reasonable chunk of Isode's business comes from X.400 messaging systems, a popular protocol in military, aviation and EDI markets. In a new whitepaper published today we take a look at 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 the various approaches that can be taken.

The whitepaper which, like all Isode whitepapers, is free and can be reached without registration can be found here.

New Whitepaper: X.400 Bridgehead for Microsoft Exchange

X.400 Bridgehead for Microsoft Exchange is a new product from Isode partner Boldon James, produced in collaboration with Isode. It's primary goal is to provide X.400 protocol connectivity for Microsoft Exchange 2007; this capability was provided as a part of Exchange 2003 and earlier versions, but is not included with Exchange 2007.

In a new whitepaper now available from the Isode website, X.400 Bridgehead for Microsoft Exchange - Technical Architecture and Back-end Features, we describe the architecture of X.400 Bridgehead, and summarize it's key features. It is particularly oriented towards understanding the capabilities of X.400 Bridgehead in the context of older versions of Exchange and full X.400 Message Transfer Agents (MTAs).

The whitepaper which, like all Isode whitepapers, is free and can be viewed without registration, is available here.

New Whitepaper: How AMHS users benefit from directory

A new, free, whitepaper has been published on the Isode website today.

The paper looks at how an AMHS end application, such as an AMHS Terminal sending and receiving flight plans, will utilize and benefit from the directory. The paper assumes a very basic understanding of AMHS and ATN Directory.

For those unfamiliar with AMHS and ATN directory, a simple introduction is given in the Isode introduction to the Aviation industry. A simple explanation of the nature of the ATN Directory and its deployment in support of AMHS is given in the Isode White Paper Deploying the ATN Directory with AMHS: What you can do now.

Radiocom update

Our partner Radiocom have recently installed Latin America's first operational AMHS (Air Traffic Service Message Handling System) deployment, incorporating Isode servers. The contract was awarded to Radiocom by the International Civil Aviation Authority after an international tender and involves installing 160 terminals at 73 Argentinian airports.

Radiocom have now sent us through an updated description of their AMHS User Agent, Tau which we've added to our list of AMHS terminals produced by Isode partners.

You can read more about Radiocom and their Argentinian project on their site here, or the press release on the isode site here.

Auto-action management features

Auto-actions are an excellent feature of an X.400 message store, and have been a core part of M-Store X.400. We've added a range of management features around auto-actions, which will enable Isode customers to make effective use of this feature.

Auto-actions are a feature of the service provided by an X.400 Message Store to clients through the P7 protocol. Clients can create and manage auto-actions through the P7 protocol (using the RegisterMS operation). Each auto-action has an associated filter, which can match all messages or selected messages based on a large number envelope parameters (e.g., message size, priority, or originator) or on header parameters (e.g. subject). When a message is delivered into the store, it is matched against the filter for each registered auto action, and all matching auto-actions are applied to the message. There are three useful auto-actions supported by M-Store X.400:

1. Auto-forward. The auto-forward action forwards a delivered message to one or more recipients specified in the auto-action, and marks the message as auto-forwarded (an X.400 feature). It may be set to include a cover note. There is an option in auto-forward to delete the message after it is auto-forwarded. Auto-forwarding is useful to ensure that messages get processed when a user is away for a period. It can also be helpful to distribute messages to multiple recipients (essentially an alternate approach to using distribution lists, which allows more user control. This will be desirable for some AMHS users, as this model reflects the way that a lot of AFTN systems operate.
2. Delayed auto-forward. A variant of auto-forward, which was defined for the US Defense Messaging System, is to perform the auto-forward in the event that the message has not been fetched from the message store after a defined period (i.e., has not been read by the intended recipient). This mechanism can be used to help ensure that messages get read promptly. The filter mechanism can be useful here, for example to have a shorter auto-forward delay for urgent messages.
3. Auto-alert. Most P7 operations are client initiated, and normal P7 operation is for the client to poll the server at intervals to check for new messages. The auto-alert auto-action causes an alert operation to be sent from the server to the client, which provides information on a newly arrived message. Use of auto-alert allows a client to get new messages more quickly, and improve efficiency by reducing the frequency of polling the store.

The first changes we've made in support of auto-actions is to the P7 support in our X.400 Client API product. We've added in the RegisterMS operation, so that users of the API can register auto-actions. We've also changed how the X400msWait operation works, so that it will return when an alert operation comes in, and so that the polling frequency can be specified by the API user. This enables an API user to take advantage of the auto-alert capabilities. The auto-action protocol support is designed for the client (end user) to manage auto-actions. This is very useful, but in many situations it is also useful to configure and manage auto-actions centrally. This is particularly true where sophisticated use is made of the capability, and for more formal messaging structures where the configuration and flow is centrally managed. Isode has extended its management console to provide GUI management of autoactions, including sophisticated setup of filters.  This will enable an operator to view and modify setup for each user.

We've also added a related management feature that enables the manager to forward a message from any mailbox (including a cover note). This is in support of our reliable message transport approach. We already provide capability to monitor mailboxes, and in particular to monitor messages that have not been fetched (i.e., not read by the intended recipient). This capability allows the operator to forward such messages to a new recipient. This will help a service to guarantee processing of all messages in a timely manner.

XMSConsole - Monitoring for M-Store X.400 and High Assurance Messaging

We introduced XMSConsole quietly in R10.6, and have done quite a bit more work for the version which ships in R11.  XMS Console allows you to monitor M-Store X.400 (our X.400 P7 Message Store), and provides management features such as backup/restore and mailbox management.

A key new feature of monitoring unread messages is shown below.

 

For some messaging applications, this feature might seem   strange.  However if you are managning messages that need urgent action, such as in Aviation or Military situations, it is important for the operator to know about unread messages, so that actions can be taken to get them processed.  See our white paper on High Assurance Messaging.

Steve