XUXA is a demonstration cross-platform X.400 User Agent, provided by Isode to help Isode customers demonstrate and test Isode products and APIs. XUXA is a Java GUI, with look and feel modelled on the open source Thunderbird client.

We've built XUXA to demonstrate features of the Isode API and Server products that cannot otherwise be easily shown, the main goals of the product are:

  • To help customers make use of these features in their own applications by providing a good sample application.
  • To help customers set up, evaluate and demonstrate Isode products.
  • To help Isode and Isode customers test Isode products.
  • To help Isode test, document, and better support its client APIs by building an application that uses them.
  • To provide a source code base which Isode customers can purchase from Isode to build specialized applications using some or all of the XUXA code.
  • To showcase a pure “client only” application that holds all data on the server, which it accesses with standard protocols.

The XUXA manual is available for download in PDF format.

XUXA Limitations

Because XUXA is a testbed client and not a saleable product, it has functional limitations which we do not intend to address in future versions. For example XUXA has:

  • No local storage of data
  • No body part viewing or editing capabilities
  • No features that do not directly assist its 'test' goals (e.g., printing)

XUXA Capabilities

XUXA provides access to a range of X.400 capabilities. XUXA has "modes", that provide capabilities for markets that make extensive use of X.400. This description groups features by mode. Some features are specific to the markets (and mode). Others are general purpose X.400 features, of particular interest to the market.

General X.400

XUXA enables:

  • Sending X.400 messages and probes using P7 to an X.400 Message Store
  • Sending X.400 messages and probes using P3 to an X.400 MTA
  • Listing, fetching and deleting messages using X.400 P7.
  • Retrieving messages using X.400 P3. (Note that these are held in memory, and not retained on exit). This is useful for testing M-Switch X.400 without a Message Store.
  • Setting and displaying message priority.
  • Control of delivery reports and IPNs (Inter-personal Notifications) on a per-recipient basis.
  • Display of delivery reports and IPNs.
  • Auto-generation of IPNs on message reception.
  • Generate, Display and Save text encoded body parts (IA5 and General Text (with choice of character set)).
  • Generate and show parameters of FTBP encoded body parts.
  • Recognize G3Fax and Binary body parts
  • Recognize forwarded messages.
  • Control of most X.400 Message Transport Service parameters.

XUXA provides capabilities for testing X.400 systems, including support of multiple profiles so that multiple accounts and servers can be handled from a single point.

General Directory

XUXA’s address book storage is based entirely on directory (no local storage) and it can access general “white pages” information in the directory. Directory editing is done externally by use of Isode’s Sodium (Secure Online Data, Identity and User Management). This demonstrates directory lookup of recipients, and use of directory for recipient capability verification.

Aviation

XUXA's initial goals were to showcase AMHS features in the Isode client APIs, particularly those in support of the extended ATS Message Service (XUXA fully supports both Basic and Extended ATS Message Service). Aviation features of XUXA are:

  • Digital signature of messages using MOAC or Message Token, to provide content integrity, message origin authentication and message sequence integrity. These are standard X.400 capabilities, of particular interest to AMHS users.
  • Transfer of BUFR Messages (a binary meteorological format) using FTBP (File Transfer Body Part).
  • Enable transfer of standard ATS message types (Flight Plans, MET and NOTAMs). Sample flight plans and NOTAMs can be attached from a file. The ATS message type is recognized on message reception, and the text content of the message can be viewed.
  • Display of the three AMHS service features that have two encoding options in AMHS (Filing Time; Message Priority; Originator’s Reference). These can be sent using the Basic ATS Service, that uses AMHS defined protocol in a text body part, or using the Extended ATS Service, that uses standard X.400 protocol features. This can be used to test X.400 infrastructure, and other AMHS Clients for both Basic and Extended ATS Message Service. Differences between the service provided between Extended and Basic mode should be noted:
    • Availability of all CDIN precedence values in Extended encoding.
    • Year, month and second values for filing time available in Extended encoding.
    • Values are in the header rather than a special text body part.
  • Use of the directory to verify whether recipient can handle the extended ATS Message Service, and maximum per recipient message size, and control of message submission based on these parameters.

For more information on Isode's products for the Aviation market, click here.

Security Labels

XUXA can generate and display X.411 Security Labels.

Military

The following Military features are supported:

  • In military mode. XUXA encodes Inter-Personal Messages as P772 according to STANAG 4406. This enables testing that an X.400 messaging infrastructure correctly supports P772 message transfer.
  • Six level military message priority (deferred; routine; immediate; priority; flash; override) can be used.
  • One P772 X.400 Heading Extension (Message Type) can be used. Other P772 features are supported in the underlying API but not currently exposed in XUXA.
  • Security Labels (both X.411 and CMS (STANAG 4406 ed 2).
  • STANAG 4406 ed 2 message signing and verification.

For more information on Isode's products for the Military market, click here.

EDI

XUXA supports two standard X.400 features of specific interest to EDI customers:

  • Display of general text body parts, as well as IA5.
  • Setting general text to: "West European", "East European", "Cyrillic", "Arabic", "Greek", "Hebrew", "Other Latin-using languages".
  • Support of FTBP (file transfer body part), and the ability to send arbitrary named files, such as Word documents.

Performance Testing

XUXA is intended to help measure the client view of X.400 infrastructure performance. Features provided:

  • Reports the time taken to submit each message sent.
  • Messages can be copied from the Sent Folder (M-Store X.400 submitted messages) to the outbox and sent in a single batch.

M-Store X.400 Capability Testing

XUXA provides a tool for external testing of M-Store X.400. As well as general submission and access to messages, it enables testing of specific capabilities:

  • Generation of IPN on auto-forward. To do this set up a recipient to auto-forward messages using MConsole's "X.400 Message Stores" view.
  • Generation of IPN on message discard. To test this, delete a message using MConsole's "X.400 Message Stores" view before it is fetched by the recipient.
  • Storage of messages on submission, and retrieval over P7 using XUXA’s “Sent Messages” folder.
  • Testing very large mailboxes by fetching messages on demand.
  • Use of auto-alert to fetch new messages.

M-Switch X.400 Capability Testing

XUXA can be used for capability testing and demonstration of M-Switch X.400, using MTS and other features shown below.

Response to Probes can be tested by a send option.

The following M-Switch capabilities can be tested using the addressing settings:

  • Generation of delivery and non-delivery reports in normal operation to good and bad addresses.
  • Generation of delivery reports on operator actions, such as message timeout and deletion.
  • Alternate recipient. This gives an alternate address to use, if the primary one fails (either by being invalid, or if delivery is not possible in an appropriate time frame). It can be tested by using an invalid primary address and setting an alternate recipient.

The following M-Switch capabilities can be tested using the X.400 MTA Parameter settings:

  • DL Expansion Prohibition. Will give DR if message is sent to a distribution list.
  • Alternate Recipient Allowed. If set, the MTS may send the message to an alternate recipient (specified on the receiving system), in the event that the originator specified address is invalid. This can be demonstrated by setting “Admin Alt. Recipient” in M-Switch.
  • Recipient Re-assignment Prohibition. This prevents the message from being sent to another recipient by use of a redirect. This can be demonstrated by use of a redirected address.
  • Conversion with loss prohibited. This prohibits message conversion that will lead to information loss. None of the standard M-Switch channels performs a “lossy” conversion. However, any M-Switch conversion channel can be configured to say that it loses information. This can be used to demonstrate this flag.
  • (Implicit) Conversion Prohibited. This prohibits all conversion. It can be tested by sending a message to a recipient behind a gateway, such as a MIXER gateway, which will be rejected with this parameter set.
  • Recipient Disclosure. This allows the message recipient to see all the MTS recipients. This cannot be demonstrated with the current XUXA version, as other MTS recipients are not shown.
  • Latest Delivery Time. This can be used to set the latest time at which a message may be delivered. It can be tested by stopping M-Store X.400 to prevent message delivery. It can also be tested by setting the Final UTC Time to the current time, you do this by
    not adding any delay in hours, minutes or seconds. Then wait a few seconds and send the message.
  • Deferred Delivery. The capability to defer delivery of a message can be demonstrated easily.
  • Content Return Request. This requests that the original message is returned with negative delivery reports. Although the current version of XUXA does not display returned content, the capability can be demonstrated by requesting content return on a large message to a bad address. Content return can be inferred from the substantial increase in size of the delivery report.
  • Content Identifier. This can be set to arbitrary values in a message, and viewed in associated DRs.
  • Original EITs (Encoded Information Types). XUXA sets this when sending a message. On reception, this can be viewed, to see both body part types, and character set types used in general text. FTBP content types are not shown in the current version of XUXA. 

Support and Availability

XUXA is provided only on an "as is" basis, along with the Isode API and Server products. Xuxa is available on Windows and Linux. More details on supported platforms and versions can be found here.

XUXA is not a supported Isode product. However, we are keen to ensure that XUXA works well with the Isode product set, and that X.400 protocol interoperability is good. Please report any problems or issues to Isode support.

Source code is available to XUXA, as an Eclipse Project, to enable users of the Isode client APIs to see how the product works. This is of particular interest to users of the Java client APIs, but may also be of interest to 'C' developers. Isode charges a nominal fee for this (£100), to bind customers to a legal agreement available here (100K pdf). The purpose of this is to prevent XUXA being used operationally or being sold as a product.