Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Products

Messaging Operational Management: MConsole

MConsole (Message Console) is Isode's central tool for M-Switch Operational management, giving detailed monitoring information and a wide range of controls.

It connects using the SOM (Switch Operational Management) protocol to one or more M-Switch instances. It also connects to an audit database for tracking and archive information. In general, a set of MTAs will use a single audit database, so that messages can be tracked from one point.

MConsole GUI Framework

MConsole provides a structure for multiple views onto one or more local or remote instances of M-Switch. MConsole may have multiple windows open and multiple tabs in each window. Tabs provide various views, including: M-Switch; Message Tracking; Message Content; Errors. Tabs can be dragged between windows. Isode plans to add additional capabilities and views to MConsole.

MConsole M-Switch Monitoring Capabilities

MConsole's core 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.

Click images for more detail
Viewing Message Content	Viewing Message Channels	Viewing Events

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

• Overall queue status, including number and volume of messages in the queue, and processing totals.
• Information on message priority (civil or military values).
• 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 number of the channel processes currently running.
• There may be one or more "peer MTAs" (Message Transfer Agents) associated with a channel. A peer MTA will have one or more messages queued for transfer to the remote system.
• There may be one or more messages associated with each peer MTA, and information is available on each message.
• For each message, information is displayed on each message recipient for which M-Switch is responsible for transfer or delivery.
• Information on each quarantined message can be displayed including sender, recipient and spam score. Actions can be performed on quarantined messages.
• Display the content of messages that are in the queue and additional envelope information read from the message queue.
• For each monitored entity (overall switch, channel, MTA group, peer MTA, message, recipient), MConsole has a configurable definition of "badness", which is recorded for each entity. This is displayed graphically, so that an entity with zero badness is green and an entity that has reached the defined threshold is shown red. Intermediate levels have an intermediate color, to give a clear graphical image of components with varying levels of problem.
• Graphical display of key M-Switch parameters, such as number of messages and number of channels running.
• Show inbound and outbound connections associated with peer MTAs, including permanent and scheduled connections.
• Show information on partially received messages. (This capability is generic, but currently only supported by the STANAG 4406 Annexe E/ACP142 channel.
• Show percentage of data transferred or received.
• Configuration storage on connection information for M-Switch instances that are regularly monitored.
• Authentication of MConsole users, with differing monitor and control rights.
• Automatic refresh.

Click images for more detail
Message Control Actions	Monitor Inbound Connections

M-Switch Operational Control: MConsole

As well as monitoring M-Switch, MConsole 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. Disabled status, including disabling in on direction only is clearly displayed.
• Add (or clear) a configurable for all components (Channels, peer MTAs, messages, recipients).
• Request immediate processing (i.e., over-ride normal scheduling) for channels, peer MTAs, and messages.
• Request reprocessing of a message (or all messages for a peer MTA). This causes a complete new routing calculation to be performed. This is used when routing changes have been made, typically to deal with operational requirements, in order to apply these changes to messages in the queue. Note that some routing changes, and in particular alternate MTA and forced alternate MTA are automatically picked up without a requirement for this reprocessing.
• 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 reason code selected by the operator. M-Switch will then non-deliver the message.
• Limit the priority of message that is 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 military "minimize" condition.

Click images for more detail
Message Details	Message Properties	Message Switch Status

 

Tracking and Archive Access

MConsole provides a three tracking views, that access the audit database. The first view is a general purpose tracking view. This provides:

• Flexible searching for messages (using information in the audit database), based on time period, message parameters such as originator and message id, and message handling stated (delivered, transferred, quarantined, deleted etc.).
• Searching for messages on a single MTA or on all MTAs handled by the audit database.
• Display of key parameters of each message matched.
• Identification of delivery reports for each message matched.
• Display of Message Content, retrieved from the online archive.
• Forwarding of message to any recipient, with operator comment. This provides a flexible mechanism to retrieve and manage archived messages
• Calling for separate view with message details with all associated information about transfers, checking etc.
• Calling for separate view with delivery reports associated with selected message.
• Automatic refresh at operator defined intervals, to enable new delivery reports to be identified.
• Forward X.400 messages stored in archive using simplified user agent view

 

Click images for more detail
Message Tracking	Quarantine Tracking	Delivery Tracking

 

The second view is specifically for quarantine management. This offers:

• Optimized view to display only messages associated with quarantine (having one of quarantine states).
• Automatic refresh at operator defined intervals, to enable new delivery reports to be identified.
• Flexible searching for messages in quarantine (analogous to this one in general view) and all options known from general message tracking view.
• Options to release/delete messages from quarantine.

The third view is specifically for tracking delivery reports. This offers:

• View based on negative, positive, or all delivery reports. Negative reports is the default, and expected to be the primary use.
• Automatic refresh at operator defined intervals, to enable new delivery reports to be identified.
• Operator alert for new delivery reports.
• View message content of message that is being reported on.
• Forward the message that is being reported on to any recipient.

A key goal of the delivery report tracking is to enable an operator to watch for messages that get rejected locally, perhaps because of an typographic error in the message recipient. In the event that the message is relevant it may be forwarded to an appropriate recipient.

Switch Operational Management (SOM) Framework

Isode's approach to operational management is client server, as described in the white paper "The Isode Management Architecture: Client/Server and Directory". This is implemented in M-Switch using the Switch Operational Management Architecture (SOMA), as illustrated below.

Access to and control of M-Switch operational information is provided using the SOM protocol to the M-Switch QMGR (Queue Manager). These services are accessed by management tools, built over the SOMClient API. The central capabilities provided by SOM are:

• Authenticated client access, using SASL, including X.509 based strong authentication using SASL EXTERNAL.
• Optional anonymous access.
• Optional data confidentiality using TLS.
• Authorization, with per user controls on services available (e.g., access to message content and envelope information).
• Log access, monitoring and searching.
• Queue status information and control at various levels:
  • Overall queue
  • Channel (inbound and outbound)
  • Peer MTA and Peer MTA Group
  • Recipient
  • Association (inbound and outbound)
  • Partially received message object
• Access to messages in the M-Switch queue.
• Deletion, redirection and other control operations on messages in the M-Switch queue.
• Access to messages in the message archive.
• Access to messages in the quarantine store, and ability to release messages.

SOM provides the framework for implementing Isode tools, including MConsole, the Event Viewer, and Quarantine message resubmission.

SOM is also intended for integration with third party tools. Isode provides a 'C' version of the SOM Client API to enable this and Pure Java version is planned.

Availability

The Isode messaging management tools are available on Solaris, Windows, Linux and HP-UX. More details on supported platforms and versions can be found here.