<< Click to Display Table of Contents >> Navigation:  Event and Object Analysis > Capture Results Filtering > Filtration basics

The key concepts of filtration are:

Match

A logical expression which consists of one or more conditions connected with boolean operators: OR, AND, XOR and NOT, which analyses message contents or metadata and determines whether this specific message falls under the current rule.

Condition

Atomic check condition for the message and/or its metadata. It test one or more fields of the message or its metadata consistently against a certain condition (equation, inequation, template match, etc.).

Action

Description of the action to be performed with the message if it falls under the rule. Possible message actions are detailed in the Actions section.

Rule

Consists of conditions and actions. If conditions are fulfilled for the message, actions are applied to it. There may be no conditions at all, which implies the "all messages" or "any message" match type.

Table

An ordered sequence of rules. A table must have a unique name. There is one system table named "main". It if the entry point for message filtering. Each filter must contain the "main" table. Tables are detailed in the Tables section.

Principles of filtering

All the messages pass through filter tables starting with the "main" table. When a message passes through a table, all the rules from this table are applied to the message in the specified order.

Applying a rule includes:

▪Checking the message (including its metadata) against conditions.

▪Applying the action to the message if the condition is fulfilled.

The action may be a basic operation (a build-it action, such as ACCEPT, DROP, JUMP or RETURN) or a custom operation (setting a label or a tag, modifying the message or its metadata, etc.). Basic operations may be either terminating, i.e. they stop any further message filtering (these are ACCEPT, DROP), or non-terminating, i.e. they do not stop message processing (these are JUMP and RETURN).

The "main" table must always end with a rule that contains the "all messages" match and one of the terminating actions (ACCEPT or DROP). Other tables must always end with a rule that contains the "all messages" match and a terminating action (ACCEPT or DROP) or the RETURN action.

The JUMP action is used to pass the message from the current table to another one. If the RETURN action is applied to the message in that table, the message returns to the original table and goes on through it, starting with the next rule. Table other than the "main" table, and jumping to them, may be required to minimize the number of rules the message has to pass through for the ACCEPT or DROP decision to be made.

It can also be used to combine rules into groups to process messages with some "global" properties in common which cannot be described with matches within a single rule.

Please note:
This means that the main table may not end with the RETURN action rule, as there is nowhere to return to from it. You cannot JUMP to the main table either.

It should be particularly noted that any explicitly or implicitly "cyclical" loops are not allowed. This is verified during the rule compilation. For example, the following scenario will be blocked during the filter compilation: "main" table -> jump -> "boss-messages" table -> "shopping" table -> "spam" table -> "boss-messages" table.