Assured: The Isode Blog

Mobile Messaging

Our CEO, Steve Kille, has been guest-posting on the Ferris Research Weblog on a subject close to our hearts, Open Standards in mobile messaging.

The main point of the post we've stated publicly before (and here on this blog) but bears repeating as often and as loudly as possible, that proprietary protocols for mobile messaging should be challenged and are being challenged by emerging Open Standards.

Product Release time.

We started to distribute Release 11 (R11) of our Email and Directory server set today. A number of new monitoring and integration features in this release are particularly relevant to our strategy of providing high-assurance messaging solutions to markets such as Aviation, Military and Intelligence.

We've included in R11:

• A new operator console, DConsole, for monitoring directories,
• A new tool, XMSConsole, to support the management of multiple X.400 servers,
• A complete revision of the Logging system, and
• A Directory Client API, enabling applications to access a directory to perform authentication and obtain configuration information.

R11 also includes the first market-specific Directory Client API, the ATN(Air Traffic Network Directory) Directory API, for the Air Traffic industry.

We've talked about DConsole and XMSConsole in previous blog entries and you can read about all of the key R11 features in the press release on our website.

The benefits of an audit database and spam scores

Our audit database is holding an increasing amount of information on messages passing through our system.  We've done a lot of work on this for R11, and it is becoming an increasingly central part of our messaging management.   The tracking and quarantine interfaces are product release.  I thought it would be useful to show some of the things that can be done, and to give a hint of the direction we are taking this.   We record spam scores.   This graph is generated against a database of a million or so messages, showing score profile.   

Steve

SMTP and POP3 Support for Aviation

We've been seeing (through our partners) a number of requests for AFTN and AMHS solutions that also request support for SMTP/POP3, typically as a single bullet point without detailed explanation.

Isode's M-Switch product is available in three basic setups:

1. M-Switch X.400: An X.400 MTA.
2. M-Switch SMTP: An Internet Message Switch.
3. M-Switch MIXER: Supports both 1 and 2, and conversion between X.400 according to the Internet MIXER standards.

Thus, M-Switch can be used to support SMTP switching, and with our new M-Box product can be used for Internet Mesage Delivery and Access (both POP3 and IMAP).

To support reading of AMHS messages from an Internet Mailbox,  we recommend that delivery is made to an AMHS mailbox, and then the messages is rendered in HTML and sent as a nicely formatted Internet message to the recipient.  This is described in more detail in the Isode White paper:  Delivering the ATS Message Service to the End User using AMHS

An alternative approach is to use the mapping between X.400 and Internet Mail provided by M-Switch MIXER.   This will enable basic connectivity with core services. Some service elements, particularly those of the Extended ATS Message Service will be lost in the mapping.   The messages will also not be particularly convenient for the end user.   However, this mechanism is available and will work.

Regards

Steve

Isode propose Open Standards approach to challenges of mobile messaging.

With mobile messaging demand continuing to grow and proprietary solutions making most of the running in supplying that demand, Isode CEO Steve Kille, in a talk to EEMA's Annual Conference in Leuven, Belgium yesterday and in a whitepaper released on the Isode website (Open Standards: The best approach for Mobile Messaging) makes the case for an Open Standards approach to mobile messaging.

Isode believes that solutions based on Open Standards deliver increased flexibility and lower costs compared to their proprietary counterparts and that Open Standards can produce a solution as good as or better than proprietary protocols. A technically robust and commercially viable service can be achieved with Open Standards.

A key step in enabling Open Standards based alternatives to such proprietary protocols/services as Blackberry are the proposals of the IETF's LEMONADE ("License to Enhanced Mobile Oriented And Diverse Endpoints") working group, set up to propose messaging standard extensions in support of smart phones, set-top boxes, other memory/processor limited devices and bandwidth/latency challenged networks.

Isode's soon to be released IMAP server, M-Box, has support for some of the key LEMONADE specifications and Isode will be demonstrating M-Box and expanding on the Open Standards messaging approach at the Inbox/Outbox exhibition being held in London on 22/23 June.

InfoSec 2005 Pt2

It's rare that an exhibition takes place that fits in with our specialised markets so attending InfoSec this year was quite a departure from normal Isode marketing and sales activities. But in this case we had a good reason to attend, supporting an Isode Partner (Appliansys) who were launching their new product, RelayBox, an appliance server that uses our M-Switch Anti-Spam product.

We'll post more on RelayBox as the product details become more widely available but in the meantime we'd like to thank the ApplianSys exhibition team (below) for being such excellent hosts to our Business Development Manager, Mark Timberlake.

P3 and P7 Client APIs diverging

One of the goals of our P3/P7 client API was to provide a single API that gave the same API to both services, so that a client product could be easily built to use either protocol.   As applications are being developed to these APIs, we are finding some requirements to diverge (although still keeping the common core API).   There are two interesting changes in R11.

1.  In X.400 P7, a client access a server to retrieve a message, which may subsequently be deleted from the server.   In P3, a message is delivered from MTA to the P3 client and removed from the MTA as part of the delivery.   When the "get message" operation is used with P3, a message could be lost if the client crashes before the message is secured.  Therefore, we've provided a two stage API for P3, so that a P3 client can get the message, store it securely, and then complete the P3 operation reliably.

2.  We've extended our API to provide access to the P7 list operation.  This means that an application using P7 can get a list of messages that are held in the store.   This will help more sophisticated P7 Client applications.

So, while we still have a common core API, we are introducing some protocols specific features, which sophisticated applications will want to take advantage of

Steve