Isode's R18.0 release is a Fully Supported Isode release (see the Supported Releases page for more details). Note that R19.2 is the current release for M-Link Edge, R17.0 is the current release for all other products in the M-Link family, and R18.1 for all products in the M-Vault family.

Read on for the major changes that R18.0 introduced.


New features in R18.0 have been broken down into the following sections:

  1. M-Vault Product Family
  2. M-Switch Product Family
  3. Harrier Email Client

Note that there are no new features for M-Store or M-Box in R18.0. Additionally M-Link is not being included in R18.0, M-Link users should continue to use M-Link R17.0, with M-Vault R17.0 if needed. The release page for R17.0 can be consulted for the latest R17.0 changes to these products.

M-Vault Product Family

M-Vault has undergone some significant internal changes, which are the reason for making a new major release. Care has been taken to preserve current management interfaces, and it is anticipated that the changes will be transparent to most customers. A one-time upgrade is necessary to move to use or R18 M-Vault. Changes include:

  • Standard Schema representation. M-Vault now stores schema in the directory using standard LDAP/X.500 format – this format could previously be generated. This facilitates standard management and means that schema can be replicated with data. The old schema format can be read, so there is no configuration change required on upgrade.
    • Schema can be replicated with multi-master and failover.
  • Dynamic schema editing.
  • Upper and Lower bounds control of attributes.
  • MemberOf attribute, which allows efficient group support.
  • Extensible match following section 4.5.1.7.7 of RFC-4511.
    • Provide matching rules that can support match based on partial attribute, for example: DirectoryStringFirstComponentMatch.
  • Paged Results and Server Side Sorting can be used together.
  • EntryDN support following RFC-5020.
  • LDAP Transactions (RFC-5805) can now be used in multi-master configuration
  • Reduced Memory usage.
  • Reduced startup time.
  • Faster performance.

M-Switch Product Family

Profiler

A profiler enables messages to be delivered to recipients based on message content. Profilers are often used as part of military messaging solutions. This is a high functionality profiler intended to address NATO and other high-end profiler requirement sets.

NOTE: The R18.0 M-Switch Profiler is full product capability, but there is no configuration GUI. A configuration GUI will be provided in 2021 and M-Switch Profiler will be marketed once this is available. The profiler can be configured by editing a JSON configuration file.

Key capabilities:

  • Multi-Protocol; Profiler operates directly on the three standard military messaging protocols:
    • SMTP with RFC 6477.
    • STANAG 4406.
    • ACP 127.
  • Operator Web UI that may be used to profile messages which are not automatically profiled.
  • Separate Action and Info addressing for recipients of profiled messages. This uses forwarded message for STANAG 4406 and SMTP. SMTP may also use Resent-* headers. No special support needed for ACP 127.
  • Flexible rules to identify sets of message recipients.
  • Time of day handling, for example to give different night-time processing.
  • Switch-able plans (e.g., War and Peace).
  • Processing based on keywords in message subject and content.
  • Selection based on message attributes, including SICs, SIC pattern, originator, Message Type and associated parameters (e.g., Exercise), message priority, message security label/classification, and message instructions.

Operator Management

Although many M-Switch deployments can operate with minimal operator oversight, deployments in mission critical environments, particularly those with constrained or degraded networks need continual operator oversight. ACP 127 always needs operator cover, as a consequence of the basic nature of the protocols, and MConsole ACP 127 view provides this to give a wide range of operator monitoring and control. ACP 142 is usually used on constrained networks and has an MConsole ACP 142 view to support Operator management. R18.0 MConsole adds two new views for Operators:

  • Channel Monitor View. This allows for monitoring of any outbound channel to show queued messages, including SMTP and X.400. Message transmission progress is shown for CFTP and SLEP channels. Message content can be viewed and messages deleted or held (to allow other messages to pass). This is to help manage congested channels.
  • Summary View. Currently Switch Operations view gives the best summary, but it is a complex view that is oriented towards advances system administrators. Switch Operations view is retained for advanced use. The summary view provides a concise summary of queued messages, with information based on message priority. It also gives information on messages queued for vetting or correction and provides red/amber/green health warnings. Multiple M-Switch servers can be monitored, with one tab per switch with health status on the tab. This view is designed to give an operator summary status view and could be used on a heads-up display.

Shaper Channel Configuration

M-Switch shaper channel provides configuration for a range of protocol conversion, boundary and cross domain functions. This includes: Security Label Mapping; Message Signing and Encryption; Body Part conversion. Configuration uses XML files. A new GUI is introduced in R18.0 to enable configuration of this complex capability.

SMTP Bilateral Agreements

SMTP bilateral agreements are introduced, analogous to the capability currently supported for X.400 and other channels. This enables configuration of information that is specific to the SMTP peer. This includes:

  • Security Clearance. This enables message routing based on security label.
  • TLS options and configuration.

CFTP Channel

Compressed File Transfer Protocol (CFTP) is a simple protocol to transfer SMTP messages over HF Radio, specified in STANAG 5066. It is also know as Battleforce Email (BFEM).

SLEP Channel

SIS Layer Extension Protocol (SLEP) is defined in S5066-APP3 as framework for application communication over HF. It specifies a protocol for transferring SMTP Multicast Email (MULE) format messages defined in RFC 8494 over HF. It addresses a number of deficiencies of CFTP and gives superior performance to ACP 142 over point to point Automatic Link Establishment (ALE) networks.

Limit by Priority

A capability is provided to limit messages by military or X.400 civilian priority. This provides a generic mechanism to reduce network traffic under high load or MINIMIZE conditions. This is of primary interest for constrained networks and is supported for ACP 142 channels and ACP 127 channels. For ACP 127, priority control of peer systems can be controlled by use of ZAN service messages.

Military Address Lists

A new channel is provided to support military address lists. List members are configured as directory entries following ACP 133 schema. Message expansion use SMTP format messages, but list members can have SMTP or X.400 addresses. There is support for exempted recipients, and duplicates are eliminated for nested lists. The unique capability of this list is the recipients can be designated as Action or Info. When a list is expanded, two messages will be sent if needed. Action/Info status is shown in an extended header, so that a military client can determine if it is an Action or Info recipient of the message.

TLS Configuration

Improved GUI for TLS setup for SMTP and other purposes. Includes Certificate Signing Request (CSR) generation.

Other New M-Switch Capabilities

The following additional capabilities have been added in R18.0:

  • Improvements to the MConsole Vetting view, to improve operator vetting of all or selected inbound messages.
  • Configuration of authorization blocking rules to generate specific SMTP error codes.
  • Configuration of SMTP Delivery Status Notifications to include custom text, based on SMTP error code.
  • Tool to measure message throughput, designed for measuring protocol performance constrained links.
  • Protocol independent operator alert of FLASH messages.
  • GUI configuration of available ciphers.
  • UI to validate DNS Records: MX, A, SPF; DKIM; STS; DMARC.
  • UI and scripts X.400 User integrity Script. Tools to validate internal messaging configuration directory references.
  • Improved UI for sending ACP 127 service messages, including priority selection.

Harrier Email Client

After the release of R18.0, Harrier became a product in its own right (Harrier 3.0). The current Harrier release is R3.1

Security Label Support

Harrier's primary security label selection is a drop-down list taken from personal and system label catalogs. R18.0 adds the capability to add any security label, with the UI driven by the Security Policy Information File (SPIF) for Harrier. New labels can be used just once or added to the personal label catalog. There is also UI to manage the personal catalog.

Capability Checking

Harrier provides capability checking to ensure messages match recipient capabilities. This includes maximum message size, and ACP 127 character set and line length limits. R18.0 adds a check against message recipient Security Clearance, to ensure that sender does not send a message to an inappropriate recipient.

STANAG 4774 / STANAG 4778 (Preview)

NATO has standardized a new security labels in STANAG 4774 "CONFIDENTIALITY METADATA LABEL SYNTAX" and STANAG 4778 "METADATA BINDING MECHANISM". Use of these labels with SMTP is specified in NATO Technical Note TN-1491 Edition 3 "PROFILES FOR BINDING METADATA TO A DATA OBJECT".

Harrier 18.0 provides a preview implementation of these standards that includes the core label and binding support, along with basic label succession handling.

S/MIME

Harrier 18.0 extends S/MIME capability for message signing (including header signing) and encryption to include Triple Wrap and CRL checking (LDAP, HTTP, and OCSP).

Draft & Review

The core Draft & Release process is extended to include message review. A message may have multiple (sequential) reviewers and releasers. The review process is selected for each message by drafter, and may be updated as message progresses. Message Reviewers and Releasers can edit the message or pass comments back.

Other Capabilities

Harrier adds other capabilities, including:

  • Message Printing. This includes military message headers and includes security label in print header and footer.
  • Show time to process message, based on per-priority configured target handling times. Overdue messages are clearly marked.
  • Message Organization (From) can be selected from multiple options.
  • Internationalization. Harrier UI can now be in multiple languages. Two demonstration languages are available.
  • Option to send Message Delivery Notification (MDN) sent if message is deleted without being read.
  • Watching two folders for changes (currently selected folder + "INBOX").
  • Support for replying to HTML-only email messages.
  • Sanitize HTML before display, in particular to warn about EFAIL attack.
  • Automatic re-establishment of authenticated sessions if browser is reloaded.
  • Harrier uses cookies and can be configured to inform users of cookie usage.