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

This section describes techniques you can use to debug and test filters.

Timestamps

Timestamps (<action name="datetime" value="label-name">) can be used not only at the start and at the end of message processing, but in each rule to specify when it was processed relative to the start of the entire message filtering process. For this purpose, you can specify the datetime action directly before the terminating action.

For example:

<rule name="rule2" enabled="1">
 <match>
   <c name="attach-exist"/>
 </match>
 <action name="datetime" value="rule2-end" />
 <action name="accept" />
</rule>

In this example, the "rule2-end"label will be added to the message after it is processed by the rule in order to specify the time when the message was accepted (ACCEPT) by this rule.

Certain actions can take a significant time to perform (such as resolution of DNS names, message inspection by external antivirus software, etc.). All these actions are performed successively, so you can measure the time required to perform a long action by enclosing it with datetime actions.

For example:

<rule name="rule2" enabled="1">
 <match>
   <c name="attach-exist"/>
 </match>
 <action name="datetime" value="rule2-dns-start" />
 <action name="dns" />
 <action name="datetime" value="rule2-dns-end" />
</rule>

In this example, you can compare the values of the "rule2-dns-start" and "rule2-dns-end" labels after the rule finishes processing to find out the time required by the dns operation.

Rule tags

You can use the tag setting action in any rule with the tag name identical to the action name. This allows you to record the "history" of rules applied to the message while it passes through the filter. This can be useful to test filters and track filtering "routes" when the filter is complex and contains multiple rules and tables.

For example:

<rule name="rule-attach" enabled="1">
 <match>
   <c name="attach-exist"/>
 </match>
 <action name="tag" value="rule-attach" />
</rule>
 
<rule name="rule-bad-words" enabled="1">
 <match>
   <c name="text" op="all" value="tel, respect" />
 </match>
 <action name="tag" value=" rule-bad-words" />
</rule>
 
<rule name="rule-only-for-dns" enabled="1">
 <action name="dns" />
 <action name="tag" value=" rule-only-for-dns" />
</rule>
 
<rule name="accept-all" enabled="1">
 <action name="tag" value="accept-all" />
 <action name="accept" />
</rule>

You can do the same with timestamps to record not only the rules applied but also the time of application.

"From simple to complex"

Certain actions can take a significant time to perform (such as resolution of DNS names, message inspection by external antiviruses, etc.). Place such actions as close as possible to the end of the processing route in order to minimize situations when a long operation is performed, and then the DROP action is applied due to failed verification of the FROM field. You may want to check FROM first and drop some messages, and then perform dns or other long operations like antivirus inspection.