Assured: The Isode Blog

Argentina adopts AMHS supplied by Isode partner Radiocom Inc.

Argentina leads the way in AMHS ground-to-ground messaging by deploying a system provided by Isode partner Radiocom Inc.

By passing its Factory Acceptance Test (FAT) and Provisional Site Acceptance Tests (PSAT) the aviation messaging system now being rolled out in Argentina has become one of the first deployed systems based on the new ICAO standard for ground to ground messaging, AMHS.

The new system was supplied by Radiocom Inc. of Miami, Florida and based on components developed by Radiocom and UK software house Isode Ltd.

You can find out more about this ground breaking deployment on our website.

R11.2 M-Box

R11.2 will be the second release of our new M-Box product.  As you might expect, a lot of work has gone into hardening the product, and adding desirable functionality that we left out of the first release.   We've also put a lot of work into tuning performance, to get the results shown in the benchmarks we released recently. 

R11.2 adds supports for Quota control, so that disk space usage can be controlled for each user, and the manager can monitor usage.   It also adds TLS (Transport Layer Security) support for IMAP, to add data confidentiality to message retrieval. We've also provided a mechanism to manage SIEVE using the Internet Draft "A Protocol for Remotely Managing Sieve Scripts" (managesieve) Alexey Melnikov of Isode is a co-editor of this specification).   

SIEVE (RFC 3028) is a language that specifies control of mail filtering, to handle things such as vacation notifications, mail forwarding and automatic email filing. These can be controlled based on parameters such as message size, and regular expression matches on email headers (e.g., "Subject:").

Because SIEVE is a language, a server implementing SIEVE needs to decide where to store SIEVE scripts and how to manage them.   M-Box stores them in files on the server. For a future release we plan to store SIEVE scripts in the directory, so they could be managed by a special purpose DUA, or have custom scripts built from information managed in a provisioning system.

Managesieve provides a mechanism to create and update scripts using a simple protocol. This allows for better integration with email clients. Cool IMAP clients such as Mulberry and Polymer support managesieve.   Unfortunately the mainstream clients do not (yet).   

Isode recommends proving Webmail in conjunction with M-Box using the excellent open source IMP that provides a Webmail front end to IMAP.   One of the tools associated with IMP is Ingo, which is a Web interface to manage SIEVE scripts using managesieve.  This has good functionality, is easy to use (particularly for common functions such as vacation notices), and works well with M-Box. Its suitable for use both with IMP and as a Web interface for other users to manage SIEVE scripts.

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.

Directory Client API now support LDAP and X.500 DAP

The directory client API which we added in R11.0 has been extended for R11.2.   An important change is that this API now supports both X.500 DAP (Directory Access Protocol) and the Internet Standard LDAP (Lightweight DAP).

This is done in a way so that a single application can mix LDAP and DAP calls, and that exactly the same API is used for both.  The only difference is how calls are initiated.  A directory connection is opened by specifying a string.   A different format is used for DAP (RFC 1278 format) and LDAP (RFC 2255 format), and the appropriate type of connection is opened.   For example ‘"X500"/Internet=dsa.example.com’ would get DAP and ‘ldap://ldap.example.com’ would get LDAP.

We believe that this is a useful and simple API that is good for developing both LDAP and DAP applications. It will be particularly important in markets where there are conformance requirements for DAP (such as military or aviation).   This will give application developers the ability to develop applications that are conformant, but may also be used with LDAP.

We’ve also extended the API to allow applications to update the directory (Add, Delete, Modify).   This means that the API can be used for a wider range of applications.

X.400 Features for Military Messaging and AMHS

We've been working on a number of enhancements to EMMA for R11.2. One of these is described here.

M-Switch X.400 has flexible control of both X.400 content, and body part types within messages. Channels can be set up so that only supported content and body parts are transferred.

The X.400 protocols have built in definitions for a number of content types and body parts with integer values. EMMA has built in support for these, using convenient string representations (for example to conjure the X.435 (Pedi) protocol). They are also extensible, so that the infrastructure can be used for transfer of user defined types.

There are a relatively small number of object identifiers representing content types and body parts in common X.400 usage. We've enabled easy use for some of these (the ones that we believe will be useful for Isode customers) by providing convenient string representations and straightforward setup option.

Military messaging uses three main content types. These are:

• P772 (The military messaging format, defined in STANAG 4406)
• Protecting Content Type (PCT) (Usage defined in STANAG 4406 ed 1 v3 and in ed 2, using CMS (Cryptographic Message Syntax) to carry P772)
• A variant of PCT defined in RFC 3855 and used in STANAG 4406 ed 2, where the PCT is wrapped in MIME.

R11.2 provides a military messaging setup option, to allow all of these Content types. It is straightforward to support only a subset of these. We've also extended our X.400 APIs, to make it easy to handle military messages.

AMHS (aviation) specifications define a set of body part types, and text character repertoires within those that are allowed by an AMHS/AFTN Gateway (MTCU). R11.2 provides a setup option so that M-Switch X.400 can be configured to prevent messages not conforming to these restrictions from being passed to the MTCU.

Steve

LDAP Configuration of Internet Messaging

One of the key developments in R11.2 is improvements to our directory configuration for Internet messaging. There have been changes to each of our three Internet servers.

In a previous blog, I talked about the LASER routing changes to M-Switch, as a new approach to local routing configuration. From an overall Internet messaging perspective, this change brings the advantage that M-Box and M-Switch can share a common per-user configuration (a single directory entry for each account).

We've also implemented 'LDAP Proxied Authorization Control' (Proxy Auth) in M-Vault. This is not yet a standard, but we anticipate that it will be standardized:

http://www.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-13.txt

Proxy auth is used where a server wishes to perform directory operations on behalf of another user. The feature of proxy auth that is important for Isode Internet messaging is that the "other user" is specified as "user@domain". This "other user" name is mapped onto a directory distinguished name, using one of the same options available with the Isode SASL support:

• Using an Active Directory compatible mapping
• Use a single search (for mailbox)
• Use a two stage search (first domain, and then user within the identified subtree from the first search)

M-Box can use this mechanism to get information on IMAP and POP users. It will use the account name provided (either directly or via SASL), and use the proxy auth mechanism to map to a distinguished name and to retrieve information from this entry. This gives flexibility, as the name mapping is not handled by M-Box, and is the same as used for SASL verification.

We've also extended M-Box's user and server configuration options using LDAP, to include information such as user quota. It is also possible enable/disable POP and/or IMAP services on a per user basis.

Steve

 

 

 

New Whitepaper on the Isode site

Much discussion on ATN Directory has set out a big vision as to how directories can interconnect globally and solve a wide range of problems. We set out such a picture in an earlier whitepaper  'ATN Directory Vision' (http://www.isode.com/whitepapers/atn-directory.html).

A new whitepaper on the Isode site sets out a much more pragmatic and short term view and looks at:

• What products and systems an ANSP (Air Navigation Service Provider) can purchase and deploy today.
• The directory infrastructure that would result in supporting such products, and in particular how the DIT (Directory Information Tree) might be laid out.
• What products are expected to become available soon (over the next six months) that could be used with such an infrastructure.
• Consideration as to how such an infrastructure could interconnect with other similar directories and short term deployment choices that will facilitate such future interconnection.

The whitepaper is available at http://www.isode.com/whitepapers/atn-directory-now.html.

X.400 Wildcard Routing

R11.2, scheduled for end of November, has a lot of new and exciting functionality.

We've extended our X.400 routing, to enable use of Wildcards. These changes are reflected in M-Switch X.400, and in GUI extensions to EMMA to manage these conveniently.

The core of M-Switch X.400's routing specification is defined in RFC 1801 (MHS use of the X.500 Directory to support MHS Routing). One part of this that we've not implemented until now is wildcard routing. This enables an MTA to match part of an O/R Address, to control where a message is routed to.  Matching is done by use of a string based regular expression on an O/R Address component. For example, you could configure routing to make use of Surnmame=^K to define routing for surnames starting with K. Multiple weighted filters can be used with a single routing node. This can be done as preferred routing or as a fallback if other matches fail.

We've also extended the routing to allow delivery based on a wild card match. This is done by a wild card redirect (using the X.400 Message Redirect capability). So a match could be made on CN=Kille$ to redirect all addresses with Common Name ending in Kille to a specific recipient O/R Address.

So why have we chosen to implement this now?

AMHS O/R addressing makes use of components that contain part or all of the eight digit AFTN addresses. While these are address components in X.400 terms, in structural terms, they often contain information that is useful to route on. Wild card routing will enable AMHS configurations to make use of this. For example, an address such as /C=XX/A=ICAO/P=ED/O=AFTN/OU=EDDEZTZX/ (XF Form) could be routed by a match of OU=^EDDE (first four letters).

Current AFTN systems often choose to deliver AFTN address ranges or mismatches to a specific recipient. The wild card redirect allows this same capability to be supported in X.400. For example, an address such as /C=XX/A=ICAO/P=Aena/O=LECS/OU=LEMG/CN=LEMGZPZX/ (CAAS form) could be matched with wild card redirect of CN=^LEMGZP.

We suspect that there will be uses for this capability beyond AMHS.

Steve