https://bugzilla.balabit.com/show_bug.cgi?id=148 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |FIXED Status|NEW |RESOLVED --- Comment #3 from Balazs Scheidler <bazsi@balabit.hu> 2011-11-29 16:16:06 --- (In reply to comment #2)
In the 3.3.3 users guid docuemntation, in "Example 13.3. Using classification results for filtering messages"
there is a sentence that states
"Filtering on the unknown class selects messages that did not match any rule of the pattern database. Routing these messages into a separate file allows you to periodically review new or unknown messages."
----------- That was what I was trying to do.
True enough, the original idea was to check ".classifier.rule_id" which is not a tag, but like I've said this was a sensible addition, so I implemented it in the patch below. It is important to note that if there are multiple db-parser() instances processing the same message, then the result of the _last_ match will control the presence of the ".classifier.unknown" tag. commit cd059eab18b483685fd83675d39fb54bcbedfe8c Author: Balazs Scheidler <bazsi@balabit.hu> Date: Tue Nov 29 16:13:52 2011 +0100 db-parser(): set .classifier.unknown tag if a message doesn't match Whenever a message doesn't match the patterns, automatically set the tag '.classifier.unknown'. Likewise if it does, clear this tag. The rationale is to make it easier to use tags to detect if a message actually matched while processing with the last db-parser(). We're clearing the same tag in case of a match so that if there are multiple db-parser() instances, the check against .classifier.unknown would work, even if the first one matched and the 2nd doesn't. Reported-By: Evan Rempel <erempel@uvic.ca> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.