QMS Task Details
From GWAVA4
From the Quarantine function tab in the QMS (Quarantine Management System), users may select various messages in the Message List and click on the taskbar buttons to perform tasks.
- Release - the message will be released to that user and appear in their mailbox, as if it had never been blocked. No GWAVA process will block it this time. By default, all users inherit this right from the 'default' group, and it's probably the most common task users perform in the QMS.
- Delete - the message is removed from the the user's ownership. In addition the message may be physically deleted.
- Forward - Just like the release task, the message is released. However, the user may add additional comments, change the subject, from, and recipient field, etc.
- WhiteList - Presents an interface permitting the user to create an source or destination exception in GWAVAMAN.
- BlackList - Presents an interface permitting the user to create a source or destination address block in GWAVAMAN.
Below are specific notes with regards the functionality and interface of each task.
Contents |
Release
Release is straightforward in the basic concept (takes the original message, and lets it be delivered), and there is no interface to complicate matters.
However, release works differently depending on the user's rights. If a user is an administrator, there's no real complication. The user can release all messages and the message will be redelivered to all of the original recipients in the routing envelope.
If however, the user is not an administrator, several restrictions apply:
- The user may only release items that have events listed in the user's Event Scope. If any events fired besides these, the user cannot release the message, and gets an error message to that effect. This is deliberate, to prevent scenarios where users release a virus message or a message which violates policy.
- The message is not released to ALL of the original recipients, only to the user.
Delete
Deleting a message seems straightforward, but really it isn't, because of two things: A message may be "owned" by more than one user, and administrators may/may not want to be able to look at messages after they are orphaned (have no owners).
This leads to ambiguity in the desired results - should the message be removed from all users? Including administrators? What about when the message no longer has "owners"? Should just the physical message files (where the bulk of the disk space is taken) be removed, so searching may still be performed, or should the database records go too? Surely some of this should work differently for administrators?
The Deletion settings under the Global function tab summarize the options, and let you customize them. By default they are all selected on.
This means that for administrative users, a delete completely removes the database records and physical messages - more or less what you'd expect. For a non-administrative user, they have relinquished ownership of the message. In addition the message is completely removed (just as if they were an administrative) if the message is now without "owners".
Forward
Forward is pleasingly simple. The functionality is identical for both administrators and ordinary users. In fact that makes it a bit dangerous, because although forward is similar to a release it is much more powerful:
- not subject to Event Scope
- allows changing of the routing envelope (to, from, subject)
- allows additional comment to be inserted.
When you select one or more messages and click Forward, you receive an interface which looks like the following
You set a subject, and type in a comma delimitted list of recipients. You can also add in additional comments which will appear at the top level of the forwarded message.
NOTE: If the subject and/or recipients are left blank, the original subject and/or recipients are used for each message.
Individual Message settings
It is also possible that you may want to individually change the subject, recipient list on a per message basis. Click the Set Subject and Recipient List individually link, and the interface will change to a tabular list:
Change each row as you will. You can also uncheck a row if you have decided not to forward it after all.
BlackList
BlackListing is currently available only to administrators. In its bare essentials, it is equivalent to adding an address to the source address block or destination address block of the GWAVAMAN interface. Of course, it's nice to be able to click a message in QMS and quickly add to this list.
By design, a BlackList is attached ONLY to the specific Engine that triggered the storage of the message in QMS. If you have both a POA and MTA interfaces installed and they have separate Engine configurations, only one will be affected.
The interface for BlackListing looks like this:
This interface might look a bit overwhelming at first.However, it is highly unlikely that the user desires to create a block for both the Recipients and Sender of each message. The user can quickly eliminate this ambiguity, selecting only the address that he/she desires, and whether they are FROM or TO. The user can also edit an address -- convenient when adding a wildcard blacklist.
WhiteList
WhiteListing is currently available only to administrators. Here is an example of the interface
Similar to BlackListing, this is nearly equivalent to a manual GWAVAMAN function -- adding an address to the source or destination exceptions list. Like BlackListing, a WhiteList is attached ONLY to the specific Engine that triggered the storage of the message in QMS. And also like BlackListing, there are two windows where you can add, edit, and remove address from the TO and FROM column, to create the type of exception(s) you want
However, the WhiteList interface displays additional options, to permit the user to define for which events the exception applies to. It normally would be unwise, for example, to create a virus event exception for a spam message -- it might lead to undesired results!
Furthermore, should the exception be created at the overall event level (e.g. for all attachment filtering), or only at the specific discrete filter level (e.g. *.exe attachment filtering).
When you select multiple messages, the additive sum of all the triggered events is checked off by default for you at the overall event level. So if you had one message with a Fingerprint event, and one message with an Attachment Filename filter, both Attachment filter and Fingerprint will be checked off at the overall event level.
When you select a discrete message, the discrete filters are also displayed so you can make a more granular exception.
