
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.