Events and Services
From GWAVA4
A pair of concepts central to GWAVA administration are Events and Services
Contents |
Events
An Event occurs when a message being processed is flagged by GWAVA as containing content that the administrator of the mail system has found undesirable, or worthy of notice.
How can a message trigger an event? Here are just a few examples...
- The message contains a virus, and the antivirus event system is enabled.
- The message contains spam, and the antispam event system is enabled
- The message contains inappropriate content and the text filter event system is enabled.
- The message originates from an undesired address and the source address event system is enabled.
In each case, the administrator has turned on a specific event system (virus, spam, RBL, attachment filename filtering, etc), and set particular criteria (such as the word "dog" in the text filtering system) that the message has triggered.
A message may trigger multiple events of the same type -- for example two viruses in the same message -- or multiple events of the different types (a virus plus spam in the same message).
Services
A Service defines what should happen when a particular event is triggered. For example, you probably want to block messages containing a virus, and perhaps send a message to the administrator. Or you might want to quarantine a spam message within a certain score threshold, and let the user later decide if they want to release the message.
If a message triggers multiple events the services are overlayed additively to determine the final disposition of the message. There are, however, ways to override this behavior, discussed later on.
Events may have Exceptions attached to them for specific users, in which case these users will not be affected by the services. For example, you might want to add an exception to the *.EXE attachment blocking event for joe@yourcompany.com so Joe could receive EXE attachments.
An event by itself without any services attached to it doesn't do anything other than record that the event occurred in the logs.
Core Services
Block: Do not allow this message to pass through.
Notify Administrator - Send an e-mail to the administrator about the message. The specific contents of the e-mail are based upon a template configured in the Notification Options
Notify Originator - Send an e-mail to the sender of the message. The specific contents of the e-mail are based upon a template configured in the Notification Options
Notify Recipient - Send an e-mail to recipient of the message. (Often this only makes sense in conjunction with a Block). The specific contents of the e-mail are based upon a template configured in the Notification Options
Notify Defined Addresses - Send an e-mail to one or more defined addresses. The specific contents of the e-mail are based upon a template configured in |the Notification Options. This option is currently hidden for antivirus, spam, and oversized message events, but available elsewhere.
Quarantine - Store the message in the GWAVA Quarantine Management System (QMS). Users with accounts in the QMS will be able to access these messages, and possibly release or forward them, depending on the configured rights. These messages will also be subject to being compiled into an digest notification e-mailed to users, if the QMS administrator has turned the digest function on.
Using Defined Addresses to Monitor E-mail
Consider an example. You are a company considering acquisition of Widget Inc, whose primary product is Gooshas.
In GWAVA 4, you can go to the Text filtering section, add "gooshas" and "widget" as filters, and activate the Defined Addresses services for each filter. Then you could enter the e-mail addresses of the Human Resources officer (or other appropriate authorities) as the defined addresses. Optionally, you could also notify the administrator and/or block the message.
Because GWAVA 4 lets you attach the Defined Address service to almost any individual filter criteria in the system, you can easily monitor e-mail.
The BCC Service
The BCC Service is similar to the Notify Defined Address Service, but sends a copy of the original message to the specified e-mail address or to the Administrator. See Blind Carbon Copy Service for additional details.
Special Antispam Services
Some services only available in the anti-spam event system are:
- Spam auto-learn, Ham auto-learn - you can instruct GWAVA to automatically feed the Antispam engine messages which trigger certain events. For example, you might want to add a text filter with the words "Toner Cartridges". If you then activated the Spam auto-learn service for this event, all messages containing "Toner Cartridges" would be learned as spam.
- Flag the message as 'Junk' for client handling - Adds X-Spam-Status: Yes or X-Spam-Status: No to the header of the e-mail message, allowing filtering by mail servers on this content. For example GWIA can automatically route such messages to junk mail folders if /xspam is added to gwia.cfg
- Rewrite Subject To - Allows you change the subject of the message, optionally embedding the original subject and spam score. Useful for filtering purposes.
MultiState Services
By default, all services, with exception of those linked to Antivirus events are displayed in the user interface as "two-state" services -- ON or OFF. The concept is straightforward and usually all an administrator needs under normal circumstances.
If multiple event occur, the "sum" of the services are activated. For example, if the administrator blocks oversized messages, and the administrator quarantines filenames ending in EXE, and a message passes through the scanner that contains an oversized EXE attachment, the message will be both blocked and quarantined.
In many cases, such additive behavior is fine, and doesn't cause any difficulties. But there are cases where you want to FORCE a service to be on or off, regardless of other events. In these instances, 4 states can be assigned to a service - ON, OFF, FORCE ON, and FORCE OFF. FORCE ON and FORCE OFF take priority over ordinary ON and OFF service states.
A solid example is perhaps helpful. Say you want to block viruses. So you probably turned the block service ON under the Antivirus event system. Let's assume you also tend to block messages containing EXE attachment, but because not all EXE attachments are 100% "evil", you want to block and quarantine EXE attachments, so if necessary these files can be released from the Quarantine Management System (QMS). Both of these services are also in the ON state
What happens depends on the message:
- Scenario I: A message is not infected, and doesn't contain EXE attachments. Nothing occurs (at least because of these settings.
- Scenario II: A message is infected, and doesn't contain EXE attachments. The message is BLOCKED.
- Scenario III: A message is not infected, and contains EXE attachments. The message is BLOCKED and QUARANTINED.
- Scenario IV: A message is both infected and contains EXE attachments. The message is BLOCKED and QUARANTINED.
It is Scenario IV that is potentially problematic. The administrator might well have wanted this message to be simply BLOCKED (since it contains a virus), and not quarantined at all. It is scenarios like this one where FORCE ON and FORCE OFF are useful.
If the administrator had set the Quarantine service for the antivirus event to FORCE OFF, then Quarantining would not occur, even if the message had an EXE attachment.
As the above example illustrates, one of the most useful places for 4-state services is the Antivirus event system, and this is the only event for which 4-state services are enabled by default. Take a moment to click repeatedly on a service in the Antivirus event system and you'll see that the display cycles between 4 states, with the locked padlock indicating a FORCED state.
Now that we've covered the basics of the padlock states, we can look at an additional complexity that makes this system very powerful. Often when blocking attachment types such as EXE attachments, there's an exception to this. For instance, the IT department may need to be excepted from EXE blocks. In doing this we've exposed a new scenario that could cause problems:
- Scenario V: A message is both infected, contains EXE attachments AND a user has an exception for EXE attachments.
What will happen here? The FORCE ON state of a service overrides exceptions, so in this scenario, even though the user would usually have their EXE attachments bypass the scanner, it will not do so if viruses cause the block service to be forced. This allows guaranteed prevention of unwanted data without worrying about what effect adding exceptions might cause the system.
If desired, administrators can enable multistate events nearly everywhere, by changing their Preferences. See Managing User Accounts in GWAVAMAN
