M-Switch Gateway

M-Switch Gateway uses directory-based configuration, with configuration and user agent information stored in Isode’s M-Vault directory. MConsole, Isode’s management GUI for messaging, connects to the directory using an Isode Bind Profile, shared with Isode GUIs that access the directory. Multiple messaging configurations can be managed from MConsole.

MConsole also provides detailed operational monitoring of multiple M-Switch instances, providing operator functions that are a critical part of a managed messaging service, including message tracking and queue monitoring.

The primary protocol supported by M-Switch is SMTP, which is the standard email message transfer protocol. M-Switch provides comprehensive coverage of SMTP features, including priority handling, security features, and binary data. SMTP can be used for message transfer and authenticated submission.

M-Switch SMTP provides rule-based authorization based on a wide range of parameters. Messages may be archived, and details are recorded in an audit database. This facilitates flexible tracking based on message delivery and receipt. More information on the Audit Database can be found here.

Advanced Message Tracking provides information on messages not delivered. This is described in the white paper “Using Message Acknowledgements for Tracking, Correlation and Fire & Forget“.

The Queue Manager (QMGR) and channel architecture enable a sophisticated scheduling approach, which, combined with the Message Switch’s queue structure, leads to a product that works exceedingly well in demanding operational environments.

The architecture of the Message Switch, the management tools, and directory-based configuration combine to give a very high degree of deployment flexibility. This can be of particular importance in boundary situations, where complex mappings and checks are needed.

M-Switch supports managed distribution lists. Distribution list management is handled by Isode’s Cobalt product, which also handles redirection configuration.

M-Switch has two variants of the distribution list. The baseline list has:

• List membership management.
• Configuration of Security Clearances, to provide access control based on message security label.
• Control of who can send messages to a list.
• Priority handling.
• Maximum message size.

A military variant has support for two features useful for formal military messaging:

• Separation of Action and Information recipients, equivalent to ACP 127 CADs.
• Control of list type (user/role/organization).

M-Switch provides a mechanism to conveniently transfer files, referred to as File Transfer by Email (FTBE). Details are in the Isode white paper “File Transfer by Email“.

M-Switch provides a range of built-in message format conversion capabilities to support mapping between different protocols and for systems with different configurations, such as security label variation. M-Switch will convert messages appropriately.

M-Switch provides flexible alternate routing using an internal routing model referred to as Nexus.   This enables switching of routes. When routing is changed, queued messages can be reprocessed with any necessary message format conversions. Operator control of using diversions is provided with a management UI in MConsole.

M-Switch SMTP can support military messaging over SMTP following a number of open specifications. Including:

• RFC 6477: Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail. The M-Switch Message Profiler operates directly on RFC 6477 messages (as well as STANAG 4406 and ACP127).
• A standard for SMTP Priority (RFC 6710: Simple Mail Transfer Protocol Extension for Message Priorities) and an associated specification to support clients that do not have direct access to an MTA supporting RFC 6710 (RFC 6758: SMTP Priority Tunnelling).

Further details are given in the Isode white paper “Military Messaging over SMTP”.

M-Switch SMTP uses directory-based configuration, with configuration and user agent information stored in Isode’s M-Vault directory. MConsole, Isode’s management GUI for messaging, connects to the directory using an Isode Bind Profile, shared with Isode GUIs that access the directory. Multiple messaging configurations can be managed from MConsole.

MConsole also provides detailed operational monitoring of multiple M-Switch instances, providing operator functions that are a critical part of a managed messaging service, including message tracking and queue monitoring.

User provisioning is handled by Isode’s Cobalt tool. There are a number of military capabilities provided, detailed in the Isode white paper “Provisioning for Military Messaging Handling Systems”.

M-Switch records events using a flexible event logging system.   Events have a priority and an independent alert level. The alert level controls the visual and audio handling of alerts in MConsole.

There is also an alert service, which generates configurable alerts based on M-Switch operational status, such as message queue build-up.

Reputation services provide a mechanism for organizations to originate messages to provide information that enables message recipients to verify that the message comes from its claimed source. Ideally, all email should make use of reputation services. In practice, reputation services can help differentiate in anti-spam checks by making reputation information available as input to the anti-spam checks. M-Switch supports two reputation services.

DKIM

M-Switch provides DKIM (DomainKeys Identified Mail) signing of messages to verify the originating domain and message integrity. This provides a digital signature across message content and selected message headers to provide secure reputation support, which can be used to help protect against phishing attacks and spam.

SPF

SPF (Sender Policy Framework) makes use of DNS (Domain Name Service) configured information. Setting up SPF is part of DNS configuration, independent of M-Switch. M-Switch can perform SPF checks on inbound messages. There are two approaches to handling:

1. Reject messages at the SMTP server when SPF checks fail.
2. Mark the message with a special header, which can be used in subsequent anti-spam checks.

Operationally, the second approach is usually more useful.

The M-Switch Message Profiler is a specialized message distribution capability that sends to recipients based on message content, in particular looking at SICs (Subject Indicator Codes) and keywords.   This is a critical component of military messaging to distribute organizational messages to relevant recipients.

Message profiler can work on SMTP messages or an STANAG 4406 (X.400) messages, using the forwarded message structure to communicate profiler actions.

M-Switch Profiler is described in more detail in the Isode white paper “Military Messaging: Distribution and Profiling”

Profiles are configured using Cobalt, Isode’s provisioning tool.

STANAG 4406 is the NATO standard for Military Messaging based on X.400. STANAG 4406 defines a number of functional and security features to support formal military messaging. It is particularly important for High Grade Messaging, where features of X.400 to support high reliability are used.

The core X.400 capabilities of M-Switch Gateway are specified on the M-Switch X.400 page. Most STANAG 4406 extensions operate at the client level and are transparent to M-Switch. One key change is that STANAG 4406 specifies 6 priorities, extending the three X.400 priorities.

Military messaging can be used over SMTP, providing all of the functionality of STANAG 4406.  This is provided as a core capability of M-Switch Gateway.   Details provided in the Isode white paper “Military Messaging over SMTP”

M-Switch provides two options for ACP 127.

1. “ACP 127”. This is a baseline option suitable for point-to-point ACP 127 and for Mobile Units receiving ACP 127 broadcast.
2. “ACP 127 Broadcast”. This is an additional option for the M-Switch Gateway for use on shore to support ACP 127 broadcast and associated protocols.

ACP 127 Protocols

The M-Switch baseline ACP 127 protocol is ACP 127G, which is the most recent NATO specification of ACP 127.

ACP 127 has a multitude of variant standardized protocols and national variants. In addition to the ACP 127G baseline, M-Switch provides support for the related ACP126, ACP128, JANAP128, and DOI103S protocols, along with some national variants.

ACP 127 Conversion with  SMTP/STANAG 4406

M-Switch Gateway provides conversion between ACP 127 and STANAG 4406 or SMTP. SMTP is supported with extensions for military messaging as described in the whitepaper [Military Messaging (MMHS) over SMTP]. Conversion to STANAG 4406 (the NATO standard for organizational messaging) follows the specifications set out in STANAG 4406 Annex D. Conversion to SMTP is aligned to this.

ACP 127 Routing in M-Switch

M-Switch has native support for SMTP and X.400 with core routing based on Directory Configuration and DNS.   This routing can be used to direct traffic to specific ACP 127 circuits.   However, the usual approach is to utilize routing within the ACP 127 channel based on the Routing Indicator (RI) and RI prefix.

ACP 127 RI Routing enables flexible routing of messages to ACP 127 circuits and supports ACP 127 relay. It also enables support of CADs and AIGs described below. ACP 127 RI routing can also use security clearance to control routing based on a security label.

When ACP 127 routing determines that a recipient has a local RI, it will look up the RI and Plain Language Address (PLA) in the directory to determine the recipient address (X.400 or SMTP).

ACP127 End User Support with Harrier

M-Switch ACP 127 support provides connectivity to peer ACP 127 systems, but does not support local ACP 127 clients.   To support local users, protocol conversion to SMTP is provided, which enables local users to use Harrier.

Harrier is Isode’s Military Messaging client, which is native SMTP. It is aware of ACP 127 and can be configured in ACP 127 mode so that only ACP 127-compatible messages are generated. Harrier provides all of the capabilities needed in ACP127, including user addresses in ACP127 format (Routing Indicator (RI) and Plain Language Address (PLA)), as well as a choice of IA5 and ITA2 character sets.

ACP127 Relay

Added to an M-Switch gateway, the add-on can be configured as an ACP127 relay. Routing between ACP127 peers is configured to use the Routing Indicator (RI) prefix. This allows for completely flexible routing, with the prefix approach allowing for succinct specification of routing in common relay setups. Protocol conversion (e.g., between ACP127 and ACP128) can be performed.

BRASS/BRE1TA/BRIPES

M-Switch may be used in support of NATO BRASS (Broadcast and Ship to Shore) and BRE1TA (BRASS Enhancement 1 Technical Architecture) deployments as provided using M-Switch Gateway in the NATO BRIPES software package (BRASS IP Enhanced Services).  This capability includes RECAP Messages, OTAM (Off The Air Monitoring), FAB (Frequency Assignment Broadcast), and other elements important for these deployments. A detailed description is given in the whitepaper [Isode’s Solution for BRASS (Broadcast and Ship to Shore)].

FAB shore-side capability provides an option for Red/Black separation using M-Guard.

The shore side of this package requires the ACP 127 Broadcast option for the M-Switch Gateway in addition to the ACP 127 option. Mobile Unit support for these capabilities is provided in the ACP 127 option.

Capabilities

Message Transport

Support is provided for the three primary approaches used for connecting ACP127 systems: Serial Line, HF Radio, and TCP.

ACP127 was initially designed for operation over serial lines to communicate with teletypes, and operation directly over serial ports is still important for many deployments, including direct operation over HF Radio modems without the use of STANAG 5066 ARQ. The following serial interfaces are supported:

• Windows COM Port /Linux TTY.
• RRC 2217 interface over TCP to devices such as Digiport TS Server, Asynchronous serial hub.

ACP127 is widely deployed over HF Radio using STANAG 5066, particularly in Naval environments. This is done using the Character-Oriented (COSS) protocol defined in Annex P of STANAG 5066. COSS support is included in the M-Switch ACP127 channel, which can be selected by configuring a circuit to use a STANAG 5066 server such as Isode’s Icon 5066.

ACP 127 circuits can be configured to operate over TCP with sender rate control based on the configurable underlying modem speed.

Address Mapping

The preferred approach for address mapping between ACP127 and SMTP and/or STANAG 4406 is to have a directory entry for each user supported at the gateway. This can be configured with Isode’s Cobalt provisioning product. The directory entry will include:

• ACP127 Plain Language Address (PLA).
• ACP127 Routing Indicator (RI).
• SMTP address and/or X.400 O/R Address.

Directory search can then be used to identify the entry and map between addresses at the gateway. A Directory entry is essential for any SMTP or X.400 user communicating with ACP127, as there is no mechanism to encode SMTP and X.400 addressing information in ACP127.

For ACP127 users communicating across the gateway, the use of a mapping entry is recommended. This enables ACP127 users to have “clean” addresses for use in SMTP or STANAG 4406 systems.   An alternative “encoded” mechanism is also provided to encode ACP 127 addresses on the SMTP/STANAG 4406 side.

Collation of Large Messages

ACP127 messages are small and do not have attachments. A typical M-Switch ACP127 configuration will use authorization to prevent messages with attachments or very large messages from being sent over ACP127 (and an appropriate error message sent to the sender).

Some variants of ACP127 (e.g., DOI-103S) have a mechanism for splitting large messages into small messages, which M-Switch supports. M-Switch will also reassemble such messages so that message splitting is transparent to SMTP and STANAG 4406 users.

In most situations, they will provide a reliable service for sending large messages, and the use of service messages to request retransmission (based on channel sequence number) will ensure no message loss. In the event of a message being received with missing fragments and the missing fragments not arriving in response to a service message request, the message will be sent with clearly marked “gaps” at a timeout interval configurable according to message priority. For very high precedence, only minimal time can be waited for collation, so they will typically be sent as fragments without collation.

Security Labels and Access Control

ACP127 provides two security label mechanisms. A few basic labels are in the core ACP127 protocol, and extended labels may be used in FL12A. This enables security label-based access control for inbound ACP127 messages and flexible security label mappings, for example, to facilitate integration with ACP145 gateways.  Details provided in the Isode white paper “Security Label Capabilities in M-Switch Products”.

ACP127 Service Messages & Reliability

ACP127 sends messages over a TCP connection, serial line, or HF Radio. There is no protocol acknowledgement, and there are no end-to-end delivery reports as in X.400 and SMTP.

ACP127 achieves reliability by sequentially numbering each message sent to a peer, which enables the receiver to detect if any messages are missing. ACP127 can send a special service message to request retransmission of any missing messages. M-Switch will detect missing ACP127 messages and request retransmission. The ACP127 sending channel holds all recently sent messages in a local database in order to facilitate this automatic transmission.

M-Switch also provides a configuration option to use ZIC/ZID service messages at intervals to automatically verify that a link is correctly working in both directions. ACP127 also defines special reliability options for FLASH messages, which have a special acknowledgement protocol. This can be selected for circuits where this is needed.

CAD / AIG

ACP 127 has two mechanisms to support distribution list type capabilities:  Collective Address Designators (CADs) and Address Indicating Groups (AIGs).  CADs and AIGs are centrally managed and expanded in a distributed manner. M-Switch ACP 127 supports AIGs and CADs, with configuration held in the directory using the ACP 133 schema.

Management

Cobalt provides provisioning of users, including ACP 127 capabilities and addressing.

Full GUI management for ACP127 is provided in the MConsole management GUI. Three views are relevant:

1. Configuration view, to manage the ACP 127 circuit and link configuration.
2. ACP 127 Addresses view that provides:
   1. View of PLAs, RIs, and ACP 127 circuits to show routing.
   2. Management of AIGs and CADs
3. ACP 127 view, which provides operator support for selected circuits:
   1. Message queue monitoring
   2. Options to send custom messages (e.g., RATT)
   3. Options to send service messages
   4. Queue management:
      1. Deletion (vetting off)
      2. Re-ordering
      3. Message hold
      4. Control of manual/automatic operation
      5. OTAM monitoring (broadcast)
      6. RECAP list (broadcast)
      7. Message Repair (broadcast, receive, and other unreliable links)
      8. FAB Control (broadcast)
      9. FAB Monitoring (ship side of ship-to-shore circuit)
      10. FAB Status Control and History (shore side of ship-to-shore channel)
      11. Message review/accept (shore side of non-ARQ ship-to-shore channel)
      12. Tracking (messages sent and received)
      13. Transmit and receive logs

The central protocol to Isode’s constrained communication solution is ACP 142, sometimes known as ‘P_Mul’. ACP 142 provides reliable multicast, which is an essential base service. ACP 142 is implemented as a channel in M-Switch products. M-Switch products use channels for each of the various protocols that they support. The ACP 142 channel runs as a server to process incoming requests.

M-Switch provides extended EMCON extensions to support broadcast-only networks (e.g., NATO BRASS (Broadcast and Ship to Shore)) and extended outages. The two-mode model of ACP 142 EMCON is extended to four modes, and the option is added to treat a message as delivered after a configurable number of transmissions.

Two network mappings are provided for ACP 142 protocols. The first is to use IP, which is widely supported and ideal for some underlying networks, and in particular for Satcom. ACP 142 uses UDP to map onto IP, and CO ACP 142 uses TCP. ACP 142 utilizes IP multicast addressing.

The second mapping is to use the STANAG 5066 protocol. The ACP 142 channel accesses a STANAG 5066 server using the STANAG 5066 SIS (Subnet Interface Service) protocol. Isode’s own STANAG 5066 Server, Icon 5066, is a modem-independent STANAG 5066 server, enabling applications to work efficiently over HF Modems/Radios and allowing multiple applications to work simultaneously.

Further details on ACP 142 are provided in the Isode white paper “ACP 142: SMTP & STANAG 4406 Messaging for Constrained Networks”

MConsole provides two views for ACP 142 management:

• Configuration View. This enables the configuration of ACP 142 channels.
• ACP 142 View. This provides an operator view of ACP 142 messages, enabling:
  • Monitoring of queues
  • Message control, including abort and prioritization

CFTP (Compressed File Transfer Protocol) is specified in STANAG 5066 annex V. It is used for email over HF. It is supported as an option in M-Switch.

STANAG 5066 Edition 5 Annex W specifies the SIS Layer Extension protocol, which defines an efficient point-to-point message transfer protocol using a Reliable Datagram option. M-Switch provides a prototype implementation of this protocol.

There are a number of protocols that can be used for messaging transfer over HF supported by M-Switch.  Two Isode white papers provide further detailed information:

• “Messaging Protocols for HF Radio” describes various options.
• “Measuring Performance of Messaging Protocols for HF Radio” provides performance measurements.

MConsole is a desktop management tool that can connect to multiple M-Switch servers. MConsole also connects to the Audit Database (described below in the message acknowledgment and tracking section) and to the M-Vault directory for managing M-Switch configurations. This section lists the various views provided by MConsole to give an overview of the functionality provided.

• Operational Views
  • Summary View: Provides a simple operator status summary view of multiple M-Switch services.
  • Switch View: Detailed operator view to monitor and control multiple M-Switch services, described in detail below.
  • Vetting View: M-Switch can configure selected traffic for operator vetting (approval) prior to being sent. This view provides an operator UI to vet messages.
  • ACP 127 View: This provides an operator view for ACP 127 circuits, featuring a wide range of monitoring and control functions necessary for operating ACP 127. These functions are described in the ACP 127 section.
  • ACP 142 View: This view is for monitoring ACP 142 multicast channels and for controlling queued traffic.
  • Channel Monitor View: This view can be used with any point-to-point channel. It is intended to monitor and control slow channels such as CFTP, which is used for HF Radio.
  • Diversions View: M-Switch can configure multiple routes to a given peer. The diversion view allows an operator to switch routes.
  • 400 Message Store Operations: Monitoring and Control of M-Store, described in more detail below.
• Configuration Views
  • Switch Configuration Management View: Provides full configuration of M-Switch and message routing.
  • 400 Mailbox Management: Configuration of X.400 mailboxes, described below.
  • Gateway Users View: Configuration of mappings for M-Switch MIXER.
  • ACP 127 Addresses View: Shows ACP 127 routing and enables configuration of ACP 127 AIGs and CADs.
• Audit Database Views
  • Message History View: Provides a simple view of recently transferred messages.
  • Message Tracking View: Provides comprehensive message tracking, described below.
  • Acknowledgement Tracking View: Provides information on message acknowledgements, described below.
  • Statistics View: Provides various statistical graphs.
• Miscellaneous Views
  • Welcome view: Shown on startup, to facilitate initial M-Switch configuration or to connect MConsole to existing M-Switch servers.
  • Event Viewer: Look at event and audit logs on local and remote M-Switches.
  • Alerts: Display of events with alert severity configured. Enables the operator to see operational issues.
  • User Agent: Simple tool to submit SMTP and X.400 test messages.
  • Options View: Configuration of MConsole options.

Cobalt provides a Web interface to provision users and other M-Switch capabilities. The key functions provided by Cobalt are:

• User Provisioning with a range of information
  • SMTP email address as primary key
  • White pages information
  • 400 and ACP 127 addresses
  • Capabilities:
    • Attachments allowed
    • Maximum Size
    • ACP 127 constraints for ACP 127 users
  • Certificate/Identity for S/MIME signing and decryption
  • Security Clearance
• Redirects
  • An alias mechanism
• Role Provisioning
  • Primarily for military messaging
  • Options for Users
  • List of users allowed to occupy the role
• Organization Provisioning
  • For military messaging
  • Options for Users
  • Roles with sending and draft, and release rights
• Profile Configuration
  • For use with content-based list expansions, provided by M-Switch Profiler
• Distribution Lists
  • Members
  • Action/Info member (military variant only)
  • List type – users/roles/organization (military variant only)
  • 400 and ACP 127 addressing
  • Security Clearance
  • List expansion policy
• File Transfer by Email configuration. More details available here
• Hardware Security Module (HSM) support
  • For M-Switch and S/MIME identities

MConsole is a GUI management tool with multiple views that connects to one or more M-Switch servers.

MConsole’s Switch-view mode provides a monitoring-oriented view of one or more M-Switch instances, with a hierarchical view of objects in the left-hand window, and information on a selected object in the right-hand window.

MConsole provides a graphical display that gives a structured overview of one or more M-Switch servers. Monitoring features of MConsole include:

• Information on each M-Switch channel. Channels are a logical grouping of messages for different protocol, delivery, conversion, and management functions. For example, one or more channels may be associated with SMTP email transfer. This will include the number of messages, message delay, and the number of channel processes currently running.
• Access to configuration information about MTAs, channels, and permanently connected MTAs.
• Show inbound and outbound connections associated with peer MTAs, including permanent and scheduled connections.
• Overall queue status, including number and volume of messages in the queue, and processing totals.
• Graphical display of important operational information, such as the number of messages and the number of channels running.
• Information on messages, including:
  • The content of messages that are in the queue and additional envelope information is read from the message queue.
  • The security label associated with a message.
  • priority (civil or military values).
  • Information on each message recipient for which M-Switch is responsible for transfer or delivery.
  • Quarantined message information (sender, recipient, and spam score), actions can be performed on quarantined messages.

As well as monitoring M-Switch, the MConsole Switches view can be used to control the queue and provide operator functions, which are a critical part of a managed messaging service. Control features provided by MConsole include:

• Disabling channels and peer MTAs for inbound and/or outbound connections.
• Add (or clear) a configurable option for all components (Channels, peer MTAs, messages, recipients).
• Request immediate processing (i.e., override normal scheduling) for channels, peer MTAs, and messages.
• Request reprocessing of a message (or all messages for a peer MTA).
• Delete messages or individual recipients from the queue (no other actions).
• Redirect a message or selected recipients to another address.
• Forward a message (message content) to any recipient.
• Time-out messages or individual recipients. M-Switch will behave as if the message had timed out and send appropriate delivery reports.
• Non-deliver messages or individual recipients, with a reason code selected by the operator. M-Switch will then not deliver the message.
• Limit the priority of messages that are processed by a channel or the whole MTA (all channels). This is useful in periods of high activity to restrict message processing to higher priority messages, and in support of the military “minimize” condition.

M-Switch writes audit logs that record information on messages transferred and the location where each message is archived (so that management tools can access message content). These logs are processed into an audit database. Details of the Audit database are provided here.

MConsole provides tracking/management views that access the audit database. The general purpose tracking view provides:

• Flexible searching for messages (using information in the audit database), based on time, message parameters such as originator and message ID, and message handling status (delivered, transferred, quarantined, deleted, etc.).
• Searching for messages on a single MTA or all MTAs handled by the audit database.
• Display of key parameters of each message matched.
• Display of SMTP and X.400 Message Content, retrieved from the online archive via SOM access to M-Switch.
• View of the delivery reports (X.400 DRs and/or SMTP DSNs) and read receipts (X.400 IPNs and SMTP MDNs) associated with each message.
• Forward SMTP and X.400 messages stored in the archive to any recipient, with operator comment using a user agent view.

An acknowledgement view enables tracking of delivery reports (SMTP DSNs and X.400 DRs) and read receipts (SMTP MDSs and X.400 IPNs). This has two primary goals:

• To track errors, in particular, delivery reports. This will give the operator immediate information about problems and enable them to take proactive action, such as forwarding a mis-addressed message.
• To warn about a delay in the delivery report or read receipt. This can facilitate detecting operational problems and ensure that messages are correctly delivered and processed.

The acknowledgement view can provide an automatic refresh to facilitate the directory operator tracking of problems. Further information is provided in the whitepaper  “Using Message Acknowledgements for Tracking, Correlation and Fire & Forget“.

Some remote systems will not provide reliable acknowledgements, and so it makes sense to exclude them from message correlation. Information on “Alertable Missing Acknowledgements” is stored in the Audit Database using a flexible rules-based approach and can be managed with MConsole.

MConsole’s X.400 Message Stores view connects to one or more message stores, showing both mailboxes and open P3 and P7 connections. MConsole also enables:

• Manage mailbox backup.
• Configure auto-actions, such as auto-forward. These are managed through the message store, like that of a P7 client.
• Mailbox monitoring, to show unread messages and to help deal with messages that have not been read.
• Shows information on a specific message.
• Show information on a specific connection to the Message Store.

MConsole’s X.400 Mailbox management view enables:

• Easy setup and management of mailboxes (P3, P7, and Remote)
• Configuration of advanced mailbox and routing parameters
• Easy handling of the mailbox and directory white pages relationship, including flexible management of white pages data
• Configuration of redirects, aliases, and synonyms
• Creation and management of X.400 Distribution Lists (DLs)
• Aviation (AMHS) support, including templates for standard XF and CAAS format addresses, and the capability to handle a hybrid UA/DL

Where mailboxes are provided by a local X.400 Message store, the X.400 Message Stores view allows detailed management of the local mailboxes, including backup/restore, connection monitoring, message management and forwarding, auto-action management, and monitoring unread messages.

When an error in message transfer occurs, the normal action is to send a delivery report to the message sender, indicating the error. An alternative approach, often used in military “fire and forget” scenarios, is to have errors handled by an M-Switch operator. M-Switch supports a “correction” capability, so that when messages fail, they are queued on a corrections channel. M-Switch provides a Web corrections interface, so that operators can deal with failed messages and take actions such as address correction to enable successful delivery.

M-Switch Profiler distributes messages based on content. Distribution is usually automatic, but there are situations where operator intervention is required, for example, for AAA SICs or if no rules are matched. This situation is handled by a Web user interface that allows an operator to direct messages that the profiler determines need manual handling.

S/MIME (Secure MIME) is a widely used standard (RFC 5751) for providing end-to-end message digital signature based on X.509 PKI and message encryption. S/MIME signing is a core M-Switch capability. S/MIME encryption is offered as part of the encryption option

M-Switch products can check S/MIME signatures on message submission to validate message integrity and origination. These checks are integrated with the authorization system, so messages can be controlled based on signature presence and validity.

S/MIME headers may be signed following the S/MIME procedures. When this is done, M-Switch marks the S/MIME signed headers following “Considerations for protecting Email header with S/MIME“. This enables correct reverse mapping by M-Switch when header signing is used. There is also an option to not sign the message header, which gives better interoperability but poorer security.

M-Switch content conversion can strip S/MIME signatures and can add an S/MIME signature. So M-Switch can be used to add S/MIME signatures at a boundary, or to add signatures where clients cannot do this, to provide onward message integrity services. This content conversion works without restriction on messages that are signed but not encrypted.

For triple-wrap encrypted messages, M-Switch can validate and convert the outer S/MIME signed wrapper. Isode’s Harrier product can generate S/MIME triple wrap. However, M-Switch cannot decrypt or generate triple wrap S/MIME. Triple wrap may be added in a future version of M-Switch.

M-Switch products use Transport Layer Security (TLS) for data confidentiality and Simple Authentication and Security Layer (SASL) for authentication. SASL is also used to map simple identifiers onto directory names for authentication. M-Switch management prefers the use of the SCRAM mechanism with SASL described in the Isode white paper  “SCRAM: A New Protocol for Password Authentication”.

M-Switch provides authentication for both configuration and operation. Users are authenticated against the directory. Isode’s recommended model is that (human) users authenticate as themselves, and that each user is given appropriate rights. The benefit of this approach is that all actions can be audit logged according to the user (not the role), which improves accountability when activity is analysed.

Configuration is held in the directory, and so the operator will authenticate to the directory. Directory access control is used to grant users full rights, read-only access, or no access at all. Operator rights for a range of management functions in MConsole are configured using MConsole.

M-Switch products include a comprehensive authorization mechanism based on rules configured in M-Switch for controlling which messages can be sent and how they are sent. Capabilities include controls based on:

• Sender and recipient, including address pattern matching.
• The destination channel, which enables the control of protocols and options used.
• Message size and message priority.
• S/MIME signatures and security labels.
• Submitting the IP address and sub-network, and on submitting the host and authentication.
• Subject Indicator Code (SIC) count.
• Security classification.

M-Switch products provide an authorization-controlled mechanism to add additional recipients to a message. This is implemented as an extension to the Archive Capability, so that inbound messages may be “archived” by sending an email to a configured recipient. This can be used for archiving, but also provides a mechanism to get selected messages sent to additional recipients. The recipient addition capability can also be used for a variety of purposes, including:

• Sending select messages to an additional backup address.
• Monitoring traffic to or from selected local users or remote destinations.

M-Switch provides support for Security Labels in several formats:

• ESS Labels using the standard RFC 2634 encoding in S/MIME.
• ESS Labels, base64 encoded in a configurable X-Header
• Text encoded labels, represented in X-Header, Subject for First Line of Text (FLOT).

M-Switch can convert between label formats, using a Security Policy (SPIF) based approach to map between the various supported label formats. This conversion can also use configured equivalent labels to map between different Security Policies.

M-Switch can make authorization decisions based on the presence and validity of a security label. It can also make Access Control decisions (checking against Security Clearance in the context of a governing Security Policy) based on destination channel, MTA, and user. For more information, see the whitepaper “Security Label Capabilities in M-Switch“.

M-Switch can perform message encryption and decryption. This is provided as an additional option to the core M-Switch.

The encryption option supports S/MIME Enveloped encryption for SMTP usage and STANAG 4406 triple wrap encryption for STANAG 4406 usage. Messages can be decrypted and re-encrypted in boundary configurations.

Further information on the Encryption option is provided here.

In order to deal with specification of an X.400 system, there are a series of ISPs (International Standard Profiles) published in conjunction with the base X.400 specifications. “ISO/IEC 10611-1: Common Messaging Part 1: MHS Service Support (1999)” sets out a core framework for the X.400 ISPs. In particular it defines a set of functional groups, to which an implementation can claim conformance. The following table lists all of the X.400 functional groups, and which ones are supported by M-Switch X.400.

An MTA must support Message Transfer, using the X.400 P1 protocol. M-Switch is conformant to the core ISP requirements for the 1984, 1988, and 1996, 1999 and 2003 versions of X.400. Detailed specification of the Message Transfer Conformance of M-Switch X.400 is provided in two PICS statements:

• Common Messaging: Message Transfer (P1) – AMH11 (based on ISP 10611 – 3/AMH11)
• IPM: Requirements for Message Transfer (P1) – (based on ISP 12062 – 3/AMH22)

Message Access refers to submission and delivery using the X.400 P3 protocol. There are two versions of the X.400 P3 protocol:

• P3 (1988), with conformance defined in AMH12 (MTS Access) and AMH 23 (IPM Requirements for MTS Access).
• P3 (1994), with conformance defined in AMH14 (MTS94 Access) and AMH 25 (IPM Requirements for MTS94 Access). This defines additional end user management and control functions.

Extensions from X.400(1994) and X.400(1999) can be used with both of these protocols. Isode supports P3(1988) only. Details of M-Switch X.400 P3 conformance is defined in “AMH12 and AMH14 – MTS Access (P3) and MTS 94 Access (P3)” ISO/IEC ISP 10611-4. This is aligned to ITU X.483 “P3 PICS”. Isode is conformant to the mandatory elements of the ISP for P3(1988), with two exceptions:

• DeliveryControl operation is not supported. M-Switch X.400 achieves the functions of this operation by use of its own configuration management tools. This allows access to controls by P7 users and administrators, which increases flexibility.
• For the MTS Forced Access protocol, M-Switch X.400 supports only delivery (and not submission). This reflects use of MTS Forced Access to deliver messages from M-Switch to a Message Store, where submission is not needed. P3 Clients can submit and deliver messages using MTS Access.

Lower Layers: X.400 & RTSE

The X.400 channels support the 1984, 1988 and 1992 recommendations including the mts-transfer (P1-1988, RTSE normal-mode), mts-transfer-protocol (P1-1988, RTSE X.410(1984)-mode) and mts-transfer-protocol-1984 (P1-1984, RTSE X.410(1984)-mode) application contexts.

Full RTSE recovery is supported for both inbound and outbound transfers. There is full support for Two Way Alternate. All three application contexts can be supported by a receiving channel on a single Session address.

In addition to the open standards supported by M-Switch SMTP and M-Switch X.400, M-Switch MIXER conforms to the following Open Standards.

The (on disk) message queue is the centre of M-Switch. Arriving messages are written to the disk and secured, using fsync() to ensure no possibility of message loss, which is central to reliable store and forward messaging. Messages may then be checked and processed locally before being sent on and removed from the disk. Typically, messages will remain in the queue for a very short while, often for just a few milliseconds.

Most M-Switch processes are channels. The exceptions are QMGR (see below) and three processes associated with the audit database. Channels perform many functions, including bringing messages into M-Switch, delivering or transferring messages out of M-Switch, and processing messages within M-Switch.

The core of any message switch is the set of messages that it holds on disk. M-Switch products have a general queue format that allows for efficient processing of messages in transit and provides a highly flexible manipulation of the messages for protocol and format conversion.

The message queue is managed by a Queue Manager (QMGR) process, which is responsible for scheduling the various channels, taking into account the resource management requirements of the Message Switch. Other processes provide the information needed by the QMGR to build and update its queue, and so the QMGR never needs to read files on disk. This approach means that the QMGR is extremely fast. The structure allows sophisticated cross-linking of information about queued messages, and thus enables the whole product to provide a very powerful scheduling mechanism that takes many factors into account.

The QMGR controls the dynamic operation of the whole product, scheduling other processes to run, and maintaining an overall view of the status of the message queue.

X.400 P1 is provided by the X.400 P1 Channel (“x400p1”). This may be run in two ways:

1. Initiated by QMGR to connect to remote MTAs to send and receive messages.
2. Initiated by an incoming X.400 P1 connection, through the Isode OSI transport service listener (“iaed”). This will enable a remote MTA to send and receive messages.

X.400 P3 is implemented in two different channels.

1. The P3 Delivery Channel (“p3”) is initiated by QMGR, and is used to deliver messages to a server, and in particular to an X.400 Message Store such as M-Store X.400. This uses the “MTS Forced Access” application context.
2. The P3 Client Channel is initiated by incoming X.400 P3 connections. This will be used by P3 Client applications sending and receiving messages, including applications built on the Isode X.400 Client API. This used the “MTS Access” application context. Two options are provided:
   • singled threaded process initiated through the Isode OSI transport service listener (“iaed”).
   • A multi-threaded process. This is preferred for systems with large numbers of P3 connections.

M-Switch X.400 operates primarily at the message transport level, and so is independent of message content. Any X.400 content can be transferred, and in particular, the X.400 Interpersonal Message format (P2/P22), the Military P772 format, and the X.400 EDI Format (Pedi) are supported.

The Message Submission Library provides a standard internal service for putting messages onto the message queue, which ensures that per-message functions such as authentication, routing, and processing calculations are applied consistently and correctly. Key functions provided by the submission library are:

• Sender validation.
• Recipient validation and message routing.
• Determining what internal processing is needed.
• Policy and authorization checks.
• Writing the message to disk.

M-Switch generally uses directory configuration. Table-based configuration is also provided, as it is useful for some specialized deployments, particularly where a very simple static configuration is needed. The M-Switch GUI for managing directory configuration is MConsole. Table-based configurations are managed by editing text files.

M-Switch configuration is used by all of the M-Switch processes. Logically, configuration information from the directory is used by all processes. As configuration changes are generally infrequent, this is implemented by QMGR obtaining configuration information from the directory using LDAP, checking for updates, and sharing it with the other processes.

In order to optimize performance, the number of channels running, the number of each channel type running, number of connections to a single MTA will vary depending on many factors, including remote system, network, and local hardware performance. Manual optimization is complex, and in any event, the optimal configuration is likely to vary over time. For this reason, M-Switch does a sophisticated “self-test” to measure performance and adapts the configuration accordingly. This enables M-Switch to adapt its operational parameters to different hardware and network environments.

X.400 Message routing is configured in the directory using MConsole, based on RFC 1801 “X.400-MHS use of the X.500 Directory to support X.400-MHS Routing”. Routing is primarily done at the time the message is submitted, with directory checks also performed by the X.400 channels.

The routing tree mechanism allows for flexible routing configuration, including alternate routing to support fall-back routing and load balancing. Multiple routing trees may be used to allow some routing configuration to be shared between MTAs, without requiring each MTA to route in the same manner. Routing can be done on all X.400 address components (down to the mailbox level), including support for wild card routing, with pattern matching on address component values.

Internet messages are structured according to the MIME (Multipurpose Internet Message Extensions) Standard defined in RFC 2045. M-Switch has a mimeshaper channel that understands MIME format and can perform conversion on messages and components within messages.

Individual body parts can be converted from one to another using conversion filters. Typically, this is used for converting a text body part from one character set to another. The necessary conversions are calculated when a message is first submitted, and they may be re-evaluated when a message is ‘exploded’.

It is often desirable to rewrite header information – in particular, to ‘normalize’ addresses by rewriting the address in some canonical form, rather than one of the multiple addresses that can be used to reach a specific recipient. Mimeshaper provides options for the normalization of Internet message headers. This capability can be used to provide a coherent view of addresses for local users, or to manage addresses to give an external view in a boundary messaging configuration.

M-Switch provides anti-virus checks on some or all messages being handled, using third-party anti-virus packages. The following anti-virus packages are supported:

• Sophos, a commercial product that is optimized for this type of checking. This can be purchased directly from Sophos.
• ClamAV is an open-source anti-virus checker that is specifically designed to target email-borne viruses and malware.

The setup of M-Switch to use the anti-virus package of your choice is straightforward.

What does M-Switch do to support Anti-Virus checking?

The basic function of M-Switch to handle viruses is very simple. It takes an inbound stream of messages, separates out the message content to hand to a virus checker, and then sends the messages onward (once they have passed the virus check). M-Switch can be easily inserted into a message stream to add anti-virus capability. The more detailed process is:

• M-Switch has the concept of “channels,” which perform specific functions on messages in the internal queue. A content checking channel drives the anti-virus capabilities, which M-Switch uses. This is programmable, so different content checking channels may be invoked (by the same instance of M-Switch) with different parameters in different situations, or even with different virus checkers.
• M-Switch can be configured to invoke the anti-virus checking on all messages, or on selected messages (e.g., “all inbound”, “all outbound”, “all messages from organization X”, “all messages to user X”).
• M-Switch can control virus checking by size. In particular, virus checking can be skipped for very small messages (which are common and will be too small to carry a virus).
• The virus checking can do various things on detecting a virus, including one or more of:
  • Sending a customizable message back to the sender
  • Sending a customizable message to the intended recipient (example below)
  • Removing the infected body part, and then replacing it with another body part (typically one that says “there was a virus-infected thing here”)
  • If the virus checker can clean up the virus, the channel can replace the infected body part with a clean one
  • Generate a non-delivery report to the originator of the message
• The virus checks audit logs for all activity, which can be processed into management reports as needed.
• Anti-virus statistics can be displayed in MConsole when the audit database is used.
• The virus channel has a framework that can be used with any virus checker that provides an API or command line interface. Integration is straightforward. While the virus checker is usually run on the same machine as M-Switch, it can also be set up to run remotely.