Incoming content filter - ESA

[pbabu6001]

I have created a content filter and having few questions. Also, please find the attachment for reference.

1. How to make it as case insensitive.

2. I have tested this content filter by using "Trace" option in GUI. But, I am unable to see the Action of this content filter (Delivered to recipient4@internal.com). Can you help on this?

3. Provide the script to create this content filter in Message filter.

4. For this redirection filter, Message filter is recommended or Content filter?

Many thanks in advance.

[Robert Sherwin]

Are content filters and message filters case insensitive?

Both content filters and message filters allow you to apply actions to the messages you specify. Typically, filter rules and actions use regular expressions that are case sensitive.  Case insensitive matching can be applied to both types of filters. In either case,  the regular expression token ( (?i) ) is used.

For content filters, simply add the token via the GUI:

For message filters

if(body-contains("(?i)lottery")) {
   drop();
}

Note: The regular expressions for the mail-from and rcpt-to  filter rules are case insensitive by default.

For message filter - best to consult the User Guide for the full methods/actions used...

CHAPTER 9-1 User Guide for AsyncOS 10.0.1 fo r Cisco Email Security Appliances 9 Using Message Filters to Enforce Email Policies

And, I will also provide you this:

Differences Between Message Filters and Content Filters

Message Filters and Content Filters use the same scripting language and regular-expression matching.

Content Filters

Content Filters support a subset of the rules and actions used by Message Filters. Content Filters include all of the rules and actions needed in order to identify and act upon the content of a message, and they are easy to configure in the GUI.

Message Filters

Message Filters are more flexible and give access to the metadata of a message, such as the receiving listener, the sender IP, the SenderBase reputation score of the sender, the number of recipients in the message, the size of the message or attachments. A subset of the metadata is available in Content Filters as well. Message Filters are applied as the first Policy processing step in the ESA email pipeline. When a Message Filter is applied, its actions apply to all recipients of the message. This means that, if the action is Drop, then no recipient receives the message, even if the rule that matched the message matched only one recipient.

Actions for All Recipients

Content Filters are applied as the last Policy processing step in the email pipeline, after messages have been splintered into separate copies depending on the Mail Policies (and therefore different recipient groups) defined in your configuration.  Because of this, Content Filters can be applied to a more finely-grained group of senders or recipients. If you perform an action on all recipients, it is therefore more efficient to do so in a Message Filter before message splintering takes place. This is especially true in the case of content scanning (body-contains or attachment-contains rule), or if the action is to drop or bounce a message, which would then avoid anti-spam and anti-virus scanning on a message destined for non-delivery.

[pbabu6001]

Could you please confirm whether the attached condition correct or not?

[pbabu6001]

Please find the attachment and let me know on can we create that filter more effectively?

[exMSW4319]

PBabu, in More Effective.PNG you've chopped off whether those rules are an AND or an OR. I have a sneaking suspicion that "Only if all conditions match" won't do what you want.
For efficiency, you might try: if(attachment-filename == "(?)\\.(suffix1|suffix2|suffix3))

Looking back to Content filter.PNG, presuming that in your actual configuration the recipients will be a bit more haphazard you may want to put their addresses in a dictionary instead. This will still accept partial addresses as long as you are careful about possible mismatches:
if(mail-from-dictionary-match("purpose_dictionary",1) {action;}

In general, filters are more efficient than rules. They're also harder to learn, fussier to write and less self-documenting than rules even before you start on all the extra things that filters can do.

I've never tested to see if it makes a major difference, but I nest my filters where possible to execute the cheap conditions first and the more expensive ones deeper in, so in theory they only run if the cheap test says so.

The same principle goes for the sequence in which filters and then rules are run. Use the final actions to avoid later tests, and remember that a final filter action doesn't necessarily cut out subsequent rule evaluation.