Cobalt 1.5 – New Capabilities


This release adds new functionality and features to Cobalt, our web based role and user provisioning tool. You can find out more about Cobalt here.

Multiple Cobalt Servers

This enhancement enables multiple Cobalt servers to be run against a single directory. There are two reasons for this.

  1. In a distributed environment it is useful to have multiple Cobalt servers at different locations, each connected to the local node of a multi-master directory.
  2. Where a read only directory is replicated, for example using Sodium Sync to a Mobile Unit, it is useful to run Cobalt (read only) against the replica, to allow local administrators to conveniently view the configuration using Cobalt.

Password Management and Password Policy

This update includes a number of enhancements relating to password management:

  1. Cobalt is now aware of password policy. A key change is that after administrator creation or change of password, when password policy requires user change, Cobalt will mark the password as requiring user change. To be useful in deployment, the applications used also need to be password policy aware.
  2. Cobalt added a user UI to enable password change/reset, to complement Administrator password change.
  3. Administrator option to email new password to user.

Security Management

  1. Directory Access Rights Management. M-Vault Directory Groups enable specification of user rights, to directory and messaging configuration in the directory. This can be configured by Cobalt by domain administrators.
  2. Certificate expiry checking. When managing a directory holding many certificates, it is important to keep them up to date. Cobalt provides a tool which can be run at intervals to determine certificates which have expired and certificates which will expire soon.

User Directory Viewer

Cobalt’s primary purpose is directory administration. This update adds a complementary tool which enables users to access information in the directory managed by Cobalt. This uses anonymous access for user convenience.


  1. Flexible Search. Cobalt administrators have the option to configure search fields available for users. Configuration is per-domain.
  2. Users, Roles and mailing list members now sorted alphabetically.
  3. Base DN can be specified for users for a domain. If specified, Cobalt allows browsing users under this DIT (entry) using subtree search. Add user operation is disabled if this is specified. This allows Cobalt to:
    1. Utilize User provision by other means, for reference from within Cobalt managed components.
    2. To modify the entries, but does not allow addition of new entries.

Red/Black – 2.1 New Capabilities


This release adds important new functionality and adds further device drivers to Red/Black, a management tool that allows you to monitor and control devices and servers across a network, with a particular focus on HF Radio Systems.  A general summary is given in the white paper Red/Black Overview.


Red/Black 2.1 adds a Rules capability that allows rules to be specified in the Lua programming language, which allows flexible control.    Standard rules are provided along with sample rules to help creation of rules useful for a deployment.  There are a number of rule capabilities:

  • A basic rule capability is control based on device parameter values.   Rules can generate alerts, for example to alert at operator at selected severity when a message queue exceeds a certain size.
  • For devices with parameters that clearly show faults or exception status,  standard device type rules are provided that will alert the operator to the fault condition.   This standard rule can be selected for devices of that type.
  • Rules can set parameters on devices, including control of device actions.   For example, this can be used to turn off  a device when a thermometer device records a high temperature.
  • Rules can reference devices connected in the communications chain.  For example a rule can be created to alert an operator if the frequency used on a radio does not match the supported frequency range of a connected antenna.
  • Rules can be used to reconfigure (soft) connectivity, for example to switch in a replacement device when a device fails.


Configuration snapshots can be taken, reflecting the current Red/Black configuration, and Red/Black configuration can be reset to a snapshot. The capability is intended to record standard operational status of a setup to allow convenient reversion after temporary changes.

eLogic/Leonardo Radio Gateway driver

The eLogic/Leonardo Radio Gateway provides conversion between synchronous serial and TCP, with multiple convertors in a single SNMP-managed box.  A key target for this is data connectivity to remote Tx/Rx sites.  The Red/Black driver enables configuration as TCP to Serial and Serial to TCP modes, enabling a Red/Black operator to change selected modem/radios.  

Web (http) Drivers

Red/Black 2.1 has added an internal Isode framework which allows drivers to manage devices or servers via HTTP(S). This is being used in a number of new drivers, and is Isode’s preferred approach for managing devices. New drivers are:

  1. M-Link.   Allows monitoring of M-Link servers, showing:
    1. Number of connected users.
    2. Number of peer connections.
    3. Number of queued stanzas.
  2. Icon-5066.  Controlling  STANAG 5066 product:
    1. Enable/Disable node
    2. Show STANAG 5066 Address
    3. Show Number connected SIS clients
    4. Show If flow is on or off
  3. Icon-PEP.  Providing:
    1. Enable/Disable service
    2. Show number of TCP connections
    3. Show current transfer rate
  4. Sodium Sync.   Providing:
    1. Number of synchronizations
    2. Last synchronization that made changes
    3. List of synchronizations not working correctly
    4. Alerts for failed synchronizations
  5. Supported Modems.   This replaces drivers working directly with modems included in Icon-5066 3.0.   The new driver talks directly to Proxy Modem or to Icon-5066 where Proxy Modem is not used.  This displays a wide range of modem parameters.   Various modem types can be selected to display appropriate information from the connected device:
    1. Narrowband Modem.
    2. Narrowband Modem with ALE.
    3. Wideband Modem.
    4. Modem/Radio combined variants of the previous three types.


  • Parameter Encryption.   Red/Black can securely store parameters, such as passwords, to prevent exposure as command line arguments to device drivers.
  • Device Ordering.   Devices are now listed in alphabetical order.
  • Alert Source.  Alerts now clearly show where they are generated (Red/Black; Rule; Device Driver; Device).
  • Link to device management.   Where Red/Black monitored devices have Web management, the URL of the Web interface can be configured in Red/Black so that the management UI can be accessed with single click from Red/Black.

M-Link 19.4 Limited Release

M-Link 19.4 provides a very significant update and in particular provides the M-Link User Server product. It also provides M-Link MU Server, M-Link MU Gateway and M-Link Edge.   It does not provide M-Link IRC Gateway, which remains M-Link 17.0 only.

M-Link 19.4 Limited Release is provided ahead of the full M-Link 19.4 release. M-Link 19.4 Limited Release is fully supported by Isode for production deployment. There is one significant difference with a standard Isode release:

  • Updates to M-Link 19.4 Limited Release will include additional functionality. This contrasts to standard Isode releases where updates are “bug fix only”. There will be a series of updates which will culminate in the full M-Link 19.4 release.


There are three reasons that this approach is being taken:

  1. To provide a preview for those interested to look at the new capabilities of M-Link 19.4.
  2. To enable production deployment of M-Link 19.4 ahead of full release for customers who do not need all of the features of the full M-Link 19.4 release.  M-Link 19.4 limited release provides ample functionality for a baseline XMPP user service.
  3. To enable customer review of what will be in M-Link 19.4 full release. We are planning to not provide all M-Link 17.0 capabilities in M-Link 19.4 full release. A list is provided below of the current plan. Based on feedback, we may bring more functionality into M-Link 19.4 full release. There is a trade-off between functionality and shipping date, which we will review with customers.



M-Link 19.4 User Server and M-Link 19.4 MU Server offer significant benefits over M-Link 17.0:

  • M-Link 19.4 is fully Web managed, and M-Link Console is no longer used. This is the most visible difference relative to M-Link 17.0.  This enables management without installing anything on the management client.  It is helpful for deployments also using Web management in M-Link  Edge  and M-Link  MU Gateway (using either 19.3 or 19.4 versions).
  • Flexible link handling, as provided previously in M-Link 19.3
  1. Multiple links may be established with a peer.  These links may be prioritized, so that for example a SATCOM link will be used by default with fall back to HF in the event of primary link failure.  Fall forward is also supported, so that the SATCOM link is monitored and traffic will revert when it becomes available again. 
  2. Automatic closure of idle remote peer sessions after configurable period.
  3. Support for inbound only links, primarily to support Icon-Topo.
  4. “Whitespace pings” to X2X (XEP-0361) sessions to improve failover after connectivity failures.
  • M-Link MU Server allows the HF Radio improvements of M-Link 19.3 MU Gateway to be used in a single server, rather than deploying M-Link 19.3 MU Gateway plus M-Link 17.0 User Server
  • The session monitoring improvements previously provided in M-Link 19.3
  1. Shows sessions of each type (S2S, X2X (XEP-0361), GCXP (M-Link Edge), and XEP-0365 (SLEP)) with information on direction and authentication
  2. Enable monitoring for selected sessions to show traffic, including ability to monitor session initialization.
  3. Statistics for sessions, including volume of data, and number of stanzas.
  4. Peer statistics, providing summary information and number of sessions for each peer.
  5. Statistics for the whole server, giving session information for the whole server.
  • Use of the capabilities previously provided in M-Link 19.3 to provide metrics on activity to enable us to feed them into a Prometheus database using the statsd protocol. Prometheus is a widely used time series database used to store metrics: Grafana is a graphing front end often used with Prometheus:  Grafana provides dashboards to present information.  Isode will make available sample Grafana dashboards on request to evaluators and customers.  Metrics that can be presented include:
  1. Stanza count and rate for each peer
  2. Number of bytes sent and received for each link
  3. Number of sessions (C2S; S2S; GCXP; X2X; and XEP-0365 (SLEP))
  4. Message queue size for peers – important for low bandwidth links
  5. Message latency for each peer – important for high latency links
  • Provides HTTP Upload (XEP-0363) that enables a client to upload a file to the M-Link server and then share using URL.  This is supported by Swift 6.0 to provide file sharing.
  • Enhanced FMUC (XEP-0289 Federated MUC) capabilities
    • Use of the fallback capabilities of M-Link 19.4 to provide improved resilience
    • Improved detection of failed communication between links, using (lack of) XEP-0198 acknowledgements to determine link failure and sending regular pings so that failure is detected when there is no user traffic.

M-Link 19.4 (Limited Release) Update Plan

This section sets out the plan for providing updates to M-Link 19.4 (Limited Release)

The current release is Update 1, which added FMUC capabilities among other functionality. Please note that the update number is distinct from the release version number. The first software version of update 1 is “19.4v4”.

The following updates are planned:

Update 2: Archive Administration

The initial archive capability is fully functional. Administration adds a number of functions, including the ability to export, back up and truncate the archive. These capabilities are seen as important for operational deployment of archiving.

Update 3: CSR Generation

Management of PKI identities and certificates in R19.4 is done with PEM files, which is pragmatic.  Use of PKCS#10 Certificate Signing Requests is a more elegant approach that enables operational integration with deployed Certification Authorities.

Update 4: Clustering

Clustering is the largest piece of work and the most significant omission from the limited release. It is expected to take a number of months work to complete this, based on core work already done. 

Update 5: Miscellaneous

There are a number of smaller tasks that are seen as essential for R19.4 final release, which will likely be provided incrementally. If any are seen as high priority for the limited release, it would be possible to address prior to the clustering update.

  • Server-side XEP-0346 Form Discovery and Publishing (FDP). This will enable third-party clients to use FDP.
  • Certificate checking using CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol).
  • Complete implementation of XEP-0163 Personal Eventing Protocol (PEP). This is mostly complete in the initial limited release.
  • Administration. The limited release supports single administrator with password managed by M-Link.
    • Option for multiple administrators
    • Option for administrators specified and authenticated by LDAP
    • Administrators with per-domain administration rights
  • XEP-0198 Stream Management  support for C2S (limited release supports it in S2S and XEP-0361)
  • Web monitoring of C2S connections
  • XEP-0237 Roster versioning
  • C2S SASL EXTERNAL to provide client strong authentication
  • SASL GSSAPI support to enable client authentication using Windows SSO
  • Provide transformations for C2S connections, for example to prevent negotiation of in-band bytestreams

Update 6: Upgrade

To provide an upgrade from M-Link 17.0. This capability is best developed last.

Note that M-Link 19.4 limited release will automatically upgrade from M-Link 19.2/19.3 Edge and from M-Link 19.3 MU Gateway.

Items Under Consideration for M-Link 19.4 Final Release

There is a trade-off between functionality included and ship date. The following capabilities supported in in 17.0 are under consideration for inclusion in M-Link 19.4. We ask for customer review of these items.

Unless we get clear feedback requesting inclusion of these features, we will not include them in 19.4 and will consider them as desirable features for a subsequent release.

  • XEP-0114 Jabber Component Protocol that allows use of third party components.
  • Archiving PubSub events (on user and pubsub domains)
  • Configuring what to archive per domain (R17 supports: nothing, events only (create, destroy, join, etc), events and messages)
  • Providing a clean user interface for assigning MUC affiliations to groups, to simplify MUC rights administration. This can currently be achieved but the UI is limited
  • XEP-0227 configuration support to facilitate server migration
  • “Send Announcement” to broadcast information to all users
  • PDF/A archiving to provide a simple and stable long term archive

Features post 19.4

After 19.4 Final Release is made, future releases will be provided on the normal Isode model of major and minor releases with updates as bug fix only.

Customer feedback is requested to help us set priorities for these subsequent releases.

M-Link IRC Gateway

M-Link IRC gateway is the only M-Link product not provided in M-Link 19.4. M-Link 17.0 IRC Gateway works well as an independent product.

When we do a new version, we plan to provide important new functionality and not simply move the 17.0 functionality into a new release.

New Capabilities

The R19.4 User Server focus has been to deliver functionality equivalent to 17.0 on the R19.3 base. After 19.4 we are considering adding new features. Customers are invited to provide requirements and to comment on the priority of identified potential new capabilities set out here:

  • FMUC Clustering.  M-Link 19.4 (and 17.0) FMUC nodes cannot be clustered.
  • FMUC use with M-Link IRC Gateway. Currently, IRC cannot be used with FMUC. This would be helpful for IRC deployment.
  • STANAG 4774/4778 Confidentiality Labels.
  • RFC 7395 Websocket support as an alternative to BOSH.
  • OAuth (RFC 6749) support
  • Support of PKCS#11 Hardware Security Modules

M-Link 17.0 User Server Features not in R19.4

This section sets out a number of 17.0 features that are not planned for R19.4. If there is a clear customer requirement, we could include in R19.4. We are interested in customer input on priority of these features relative to each other and to other potential work.

The following capabilities are seen to have clear benefit and Isode expects to add them.

  • Security Label and related configuration for individual MUC Rooms.  In 19.4 this can be configured per MUC domain, so an equivalent capability can be obtained by using a MUC domain for each security setting required,
  • XEP-0012 Last Activity
  • Option to limit the number of concurrent sessions for a user
  • XMPPS (port 5223) has clear security benefits. The 17.0 implementation has limited management which means that it is not generally useful in practice.

The following capabilities are potentially desirable.  Customer feedback is sought.

  • XEP-0346 Form Discovery and Publishing (FDP)
    • WebApp viewer.  We believe this would be better done in a client (e.g., Swift).
    • Gateway Java app, which converted new FDP forms to text and submitted to MUC.
    • Administration of FDP data on Server.   
  • Per-Domain Search Settings, so that users can be constrained as to which domains can be searched
  • Internal Access Control Lists, for example to permit M-Link Administrators to edit user rosters.
  • Generic PubSub administration

Features in M-Link 17.0 that Isode plans to drop

There are a number of features provided in M-Link 17.0 that Isode has no current plans to provide going forward, either because they are provided by other mechanisms or they are not seen to add value. These are listed here  primarily to validate that no customers need these functions.

  • Schematron blocking rules
    • These have been replaced with XSLT transform rules
  • IQ delegation that enables selected stanzas sent to users to be instead processed by a component
  • XEP-50 user preferences
    • This ad-hoc allowed users to set preferences overriding server defaults to indicate which types of stanzas they wanted to store in offline storage and whether to auto-accept or auto-subscribe presence.
  • Management of XEP-0191 block lists by XEP-0050 ad hoc
    • Management of block lists, where desired, is expected to be performed by XEP-0191
  • XEP-114 Component permissions
  • Pubsub presence, apart from that provided by PEP
  • XEP-78 (non-SASL authentication)
    • This is obsolete
  • Some internal APIs that are not longer needed
  • Support for a security label protocol (reverse engineered by Isode) used in the obsolete CDCIE product
  • Security Checklist
    • M-Link Console had a security checklist which checked the configuration to see if there was anything insecure
    • This does not make sense in context of the Web interface which aims to flag security issues in appropriate part of UI
  • Conversion of file based archive to Wabac
    • M-Link Console had an option to “Convert and import file-based archive…” in the “Archive” menu
    • This was needed to support archive migration from older versions of M-Link
  • Pubsub-based statistics. M-Link 17.0 recorded statistics using PubSub. M-Link 19.4 does this using Prometheus, which can be integrated with Grafana dashboards.
  • XMPP-based group discovery – the ability to use XMPP discovery on an object  and get a list of groups back.
  • XML-file archives
    • This was a write-only archive format used by older versions of M-Link before introduction of the current archive database. M-Link 17.0 continued to support this option.

Icon-PEP 2.0 – New Capabilities

Icon-PEP supports operation of IP applications over HF networks using STANAG 5066 Link Layer

Listed below are the changes brought in with 2.0.

Web Management

A web interface is provided which includes:

  • Full configuration of Icon-PEP
  • TLS (HTTPS) access and configuration including bootstrap with self signed certificate and identity management.
  • Control interface to enable or disable Icon-PEP
  • Monitoring to include:
    • Access to all logging metrics
    • Monitoring GRE traffic with peered routers
    • Monitoring IP Client traffic to STANAG 5066
    • Monitoring DNS traffic
    • Monitoring TCP traffic with details of HTTP queries and responses

Authentication and Authorization

OAuth support added to control access to monitoring and configuration.

NAT Mode

A NAT (Network Address Translation) mode is introduced which supports Mobile Unit mobility for traffic initiated by Mobile Unit.   Inbound IP or SLEP (TCP) traffic will have address mapped so that traffic on shore side appears to come from the local node.  This avoids the need for complex IP routing to support traffic to Mobile Units not using fixed IP routing.

Other Features

  • Product Activation, including control of the number of Units
  • Filtering (previously IP client only) extended to SLEP/TCP

Cobalt 1.4 – New Capabilities

Cobalt provides a web interface for provisioning users and roles in an LDAP directory. It enables the easy deployment of XMPP, Email and Military Messaging systems.

Listed below are the changes brought in with 1.4.

HSM Support

Cobalt is Isode’s tool for managing PKCS#11 Hardware Security Modules (HSM) which may be used to provide improved server security by protecting PKI private keys.

  • Cobalt provides a generic capability to initialize  HSMs and view keys
    • Multiple HSMs can be configured and one set to active
    • Tested with Nitrokey, Yubikey, SoftHSM and Gemalto networked HSM
  • Enables key pair generation and Certificate Signing Request (CSR) interaction with Certificate Authority (CA)
  • Support for S/MIME signing and encryption
    • User identities for email
    • Organization and Role identities for military messaging
  • Server identities that can be used for TLS with Isode servers

Isode Servers 

A new tab for Isode servers is added that:

  • Enables HSM identities to be provisioned
  • Enables a password to be set, which is needed for Isode servers that bind to directory to obtain authorization, authentication and other information
  • Facilitates adding Isode servers to a special directory access control group, that enables passwords (usually SCRAM hashed) to be read, to enable SCRAM and other SASL mechanisms to be used by the application

Profiler Enhancement

  • Extend the SIC rule so that multiple SICs or SIC patterns can be set in a single rule

Icon-Topo 2.0 – New Capabilities

Icon-Topo supports Mobile Unit (MU) mobility between HF Networks, enabling application communications over a wider area than can be achieved with a single ground station. It provides a way to schedule the movement from one HF network to another, ensuring that as an MU goes about its deployment the communications network is kept up and running.

The below is the list of changes brought in with version 2.0:

ACP 127 Support

Mobile Units (MUs) can be configured as “ACP 127 only” with routing over M-Switch ACP 127 broadcast circuits.  ACP 127 MUs can be moved between broadcast on different HFAPs using Icon-Topo schedules.  When messages are routed between HFAPs following routing change,  ACP 127 will be used to transfer messages between HFAPs if an ACP 127 circuit is configured.  Otherwise the message will be protocol-converted to SMTP or X.400 (and converted back to ACP 127 on the new HFAP).

This capability allows flexible MU movement between HFAPs.   Note that MU ACP 127 configuration must be done manually.

XMPP Support

Icon-Topo now supports configuration of M-Link XMPP routing for MU, HFAP and FAREP.  This requires M-Link 19.3 Edge (FAREP)  or M-Link 19.3 MU Gateway (HFAP and MU).  This provides full MU mobility for XMPP services.


Four important new features are provided:

  1. HTTPS (HTTP over TLS) access is provided for Icon-Topo configuration server.   Self signed certificate will be generated.  A standard certificate can be configured.
  2. Directory access using LDAP from configuration and update servers may be configured to use TLS
  3. M-Switch access from update server may be configured to use TLS.
  4. Isode Product Activation now controls both configuration and update servers.

M-Guard 1.5 – New Capabilities

M-Guard is an XML guard that is used at a network boundary to control traffic. An M-Guard instance is an application level data diode, with traffic flowing in one direction only. Commonly, M-Guard instances will be deployed in pairs, one controlling flow in each direction. The following is a list of the new capabilties introduced in version 1.5.

M-Guard Certificate Authority

M-Guard uses X.509 certificates to verify peers. It does not use CRL checking or OCSP to check for certificate revocation as the network connections to do this would lead to an unacceptable security risk. This means that in the event of certificate compromise the whole PKI needs to be replaced. This essentially means that each M-Guard instance needs its own PKI.   

M-Guard product has added a product-specific certificate authority (CA) to manage certificates used to authenticate GCXP peers. This provides a convenient way to manage the PKI for each M-Guard deployment.

The M-Guard CA functionality is provided in M-Guard Console. 

Guard Isolation Support

Guard instances are now isolated from each other and other processes on the M-Guard Appliance. This is built on the FreeBSD “Jail” capability. It increases the protection of each guard instance.  Each guard now has independent IP addressing.

System Integrity Verification 

The M-Guard Appliance system software now includes a manifest of system files with cryptographic hashes for each file. M-Guard Appliance verifies the current system against this manifest at boot and at regular intervals (hourly by default) to provide notice of any detected changes to the system files.

M-Guard Console can be used to verify system integrity of an M-Guard Appliance against a separately distributed, signed manifest, which enables regular and more robust checking for changes to system files. Customers may implement additional checks against this signed manifest.

Release Artifact Signatures and Signature Verification 

All M-Guard release artifacts are digitally signed. These include:

  • M-Guard Appliance full and update images;
  • M-Guard Appliance manifest, release information, and release notes;
  • M-Guard Console image;
  • M-Guard Console release information and release notes; and
  • M-Guard Admin Guide.

M-Guard Console supports verification of release artifact signatures to ensure their integrity.

Harrier 3.3 – New Capabilities

Harrier is our Military Messaging client. It provides a modern, secure web UI that supports SMTP, STANAG 4406 and ACP 127. Harrier allows authorised users to access role-based mailboxes and respond as a role within an organisation rather than as an individual.

Harrier Inbox view (behind) showing Military Messaging security label and priority parameters; and Message view (in front).
Harrier Inbox view (behind) showing Military Messaging security label and priority
parameters; and Message view (in front).

The following changes have been made with the 3.3 release:

Integration with IRIS WebForms

Harrier’s generic support for MTF (Message Text Format) has been extended by provision of a close integration with  Systematic IRIS WebForms. This provides convenient creation and display of MTFs using the IRIS WebForms UI within Harrier.

IRIS Forms message attachment in Harrier Military Messaging Client
IRIS Forms message attachment

Further examples and an in-depth description can be found in the Isode white paper  C2 Systems using MTF and Messaging.

Browser Support Enhancements

New session handling, which allows a users to open multiple sessions per browser and multiple views.  This enables a user to easily access multiple mailboxes at the same time.

PKCS#11 HSM Support

PKCS#11 HSM (Hardware Security Module) support is added. This has been tested with HSMs from Nitrokey, Yubico, Gemalto and the SoftHSM software. This provides two capabilities, which can be managed using Cobalt 1.4.

  1. The private key for the server, protecting HTTPS access.
  2. Private keys for Users, Roles and Organizations. supporting message signing and encryption.

Other Enhancements

  • Audit logging when user prints a message
  • Option to enforce security label access control checks.  By default, these are advisory, with enforcement generally provided by M-Switch.
  • Default security label in forward and reply to the label of the message being replied to or forwarded.  
  • Option to configure backup servers for IMAP, SMTP and LDAP to provide resilience in event of primary server failing.
  • Option to use local timezone instead of Zulu for DTG, Filing Time and Scan Listing.
  • When using Zulu timezone, show local time in tool tip.

Messaging Products Update – 19.0 Capabilities

The below is a list of the new capabilities brought to our Messaging products for the 19.0 release. 19.0 adds a lot of extra functionality across the board for our messaging products, along with a complete rewrite of the codebase so that future releases and bug fixes can be developed more quickly. For the full release notes please check the individual product updates, available from the customer portal and evaluation sections of our website.


Cobalt (version 1.3 or later) is needed to manage various capabilities in M-Switch 19.0. HSM management depends on Cobalt version 1.4 or later.

M-Switch, M-Store and M-Box depend on M-Vault 19.0.   All of these products are a part of R19.0 with common libraries and so are commonly installed together.

Product Activation 

All of the messaging products now use the new product activation.  Products activation is managed with the Messaging Activation Server (MAS) which provides a Web interface to facilitate managing activation of messaging and other Isode products.   MAS is provided as a tool, but installed as an independent component.   


Product Activation

There are a number of M-Switch features arising from the new product activation:

  • Various product options are encoded in the activation, restricting functionality to M-Switch options purchased.   The options available and any activation time limits are displayed by MConsole.
  • MConsole will correctly display the product name of the M-Switch being used (e.g., M-Switch MIXER, M-Switch Gateway etc).
  • MConsole views are restricted so that only ones relevant to the activated options are shown (e.g,, ACP 127 views will not be shown unless ACP 127 is activated).

Use of Cobalt

A number of functions have been moved from MConsole to Cobalt, which provides a Web general administrator interface.   MConsole is being more focused on M-Switch server configuration and operation.   Capabilities provided by Cobalt in support of M-Switch:

  • User and Role provisioning (replacing Internet Mail View)
  • Special function mailboxes
  • Redirections
  • Standard SMTP distribution lists
  • Military Distribution Lists
  • Profiler Configuration
  • File Transfer by Email (FTBE) account provisioning

Directory and Authentication

A number of enhancements have been made to improve security of authentication.   New configurations will require this improved security and upgrades are expected to switch.

  • Configuration of default M-Vault configuration directory is simplified.
  • Option provided to use a different M-Vault directory for users/operators, defaulting to the configuration directory.
  • M-Switch access to configuration and user directories will always authenticate using SASL SCRAM-SHA-1.  This is particularly important for deployments not using TLS, as it will ensure plain passwords are not sent over a link, while still using hashed passwords in M-Vault.
  • M-Vault directories created by MConsole will always have TLS enabled (where the product activation option allows).
  • Connections from M-Switch to M-Vault will use TLS by default.
  • Three modes can be configured for SMTP and SOM (MConsole) access to M-Switch
    • SCRAM-SHA-1.  This is the default and is a secure option suitable for most configurations.
    • PLAIN.  This option is needed if authentication is done using pass through to Active directory.   This should only be used on systems with TLS.
    • ANY.  When this option is used, SOM/MConsole will use SCRAM-SHA-1.   It is needed for SMTP setups that want to offer additional SASL mechanisms such as CRAM-MD5, which will need plain passwords to be stored in M-Vault.

ACP 127

An extensive set of enhancements had been provided to ACP 127.

  • Extend circuit control from enabled/disable to Enabled (Rx/Tx) / Rx Only / Disabled
  • Enhanced OPSIG support for BRIPES following agreed doc:
    • QRT/QRV.   Supports remote enable/disable, including control from top level of circuit management UI
    • ZES2 automatic handling on receive
    • Service message option to send INT ZBZ
    • Configurable option for reliable circuit to send ZBZ5 to acknowledge receipt of identified message
    • Limiting priority UI use two letter codes, but will still recognize single letter
    • Add CHANNEL CHECK generation and response
  • Option to use “Y” for emergency messages
  • Support for Community Variables (CV) which is a BRASS mechanism to use multiple crypto keys
    • Configuration of CVs available for each destination
    • Display of CVs for queued messages
    • CV Audit Logging
  • Scheduled Broadcasts to support MUs with constrained availability (e.g., Submarines)
    • Periodic Mode with GUI configuration
    • UI to show which messages will be transmitted in which period based on estimated transmission times
    • Scheduled periods at same time each day
    • Explicitly scheduled fixed intervals on specific day
  • Extension to Routing Tree configuration to specify specific channel.   This makes it easier to utilize the ACP 127 RI routing, which is needed in many ACP 127 configurations
  • Improved mapping of CAD/AIG to SMTP
  • Option to turn off message reassembly
  • Improvements to monitoring of circuits using serial links

FAB (Frequency Assignment Broadcast)

A subsystem is provided to support FAB, which is needed for older BRASS systems that do not support ALE. The M-Switch FAB architecture is described in The key points are listed below:

  • A new FAB Server component is provided to run black side and generate the FAB data stream(s).
  • Red/Black separation can be provided by M-Guard
  • The FAB Server can monitor a remote modem for link quality using a new SNR monitoring protocol provided by Icon-5066 3.0.
  • Circuits to support FAB use a new “anonymous” type, reflecting that they are not associated with a specific peer.
  • Support is provided for ARQ (STANAG 5066 COSS) circuits which operate automatically shore side and for direct to modem circuits which require a shore side operator.
  • There is an operator UI for each circuit that enables setting FAB status and controlling acceptance of messages

Profiler and Corrector

  1. Support of TLS for Corrector UI and Manual Profiler
  2. Improved message display, including Security Label
  3. Profile configuration read from directory, which enables Cobalt configuration of Profiler rules

Icon-Topo Support

Isode’s Icon-Topo product automatically updates M-Switch configuration in support of MU Mobility.  M-Switch enhancements made in support of this:

  • Show clearly in MConsole when External MTAs, Routing Tree Entries and Nexus are created by Icon-Topo.
  • Enhance Nexus and Diversion UI to better display Icon-Topo created information.

PKCS#11 HSM Support

PKCS#11 HSM (Hardware Security Module) support is added. This has been tested with HSMs from Nitrokey, Yubico, Gemalto and the SoftHSM software.  HSM support can be enabled and PKCS#11 identities created by Cobalt can be configured and used for all TLS and S/MIME functions in M-Switch.


  • Configure Warning Time based on Message Priority.
  • Tool to facilitate log and archive clear out


No new features for R19.0.


Improved Searching

Message searching is extended with three new capabilities that are exposed in Harrier.

  • Choice to search based on SIC (Subject Indicator Code) which can be used on its own or in conjunction with options to search other parts of the message.
  • Option to filter search based on a choice of one or more message precedences, matching against the action or info precedence as appropriate for the logged in user.
  • Option to filter search based on selected security label.

PKCS#11 HSM Support

PKCS#11 HSM (Hardware Security Module) support is added. This has been tested with HSMs from Nitrokey, Yubico, Gemalto and the SoftHSM software.  This can be used to protect TLS access to M-Box using server identity created by Cobalt.

Directory Products Update – 19.0 Capabilities

The below is a list of the new capabilities brought to our Directory products for the 19.0 release. 19.0 adds a lot of extra functionality across the board for our messaging products, along with a complete rewrite of the codebase so that future releases and bug fixes can be developed more quickly. For the full release notes please check the individual product updates, available from the customer portal and evaluation sections of our website.


Use of several new 19.0 features depend on Cobalt 1.3 or later.


Product Activation 

M-Vault uses the new product activation.  Product activation is managed with the Messaging Activation Server (MAS) which provides a Web interface to facilitate managing activation of messaging and other Isode products. MAS is provided as a tool, but installed as an independent component.   

Headless Setup

M-Vault, in conjunction with Cobalt, provides a mechanism to set up a server remotely with a Web interface only. This complements setup on the server using the M-Vault Console GUI.

Password Storage

Password storage format defaults to SCRAM-SHA-1 (hashed). This hash format is preferred as it enables use of SASL SCRAM-SHA-1 authentication which avoids sending plain passwords. Storage of passwords in the plain (previous default) is still allowed but discouraged.

LDAP/AD Passthrough

An LDAP Passthrough mechanism is added so that M-Vault users can be authenticated over LDAP against an entry in another directory. The key target for this mechanism is where there is a need to manage information in M-Vault, but to authenticate users with password against users provisioned in Microsoft Active Directory.  This is particularly important for Isode applications such as M-Switch, M-Link, and Harrier which utilize directory information not generally held in Active Directory.

Cobalt provides capabilities to manage accounts utilizing LDAP Passthrough.

OAuth Enhancements

A number of enhancements to OAuth, which was introduced in R18.1

  • OAUTH service has been integrated  into the core M-Vault server, which simplifies configuration and improves security,
  • Operation without Client Secret, validating OAUTH Client using TLS Client Authentication.  This improves security and resilience.
  • Allow client authentication using Windows SSO, so that Windows SSO can work for OAUTH Clients.  This enables SSO to be used for Isode’s applications using OAuth.

Sodium Sync

  • Some enhancements to Sodium Sync to improve operation on Windows Server.
  • Option that will improve performance for any remote server with a large round-trip-time.