Content dictionaries are groups of words or entries that work in conjunction with the Body Scanning feature on the appliance and are available to both content and message filters. Use the dictionaries you define to scan messages, message headers, and message attachments for terms included in the dictionary in order to take appropriate action in accordance with your corporate policies. For example, you could create a list of confidential or profane words, and, using a filter rule to scan messages that contain words in the list, drop, archive, or quarantine the message.

The AsyncOS operating system includes the ability to define a total of 100 content dictionaries using the GUI (Mail Policies > Dictionaries) or the CLI’s dictionaryconfig command. You can create, delete, and view dictionaries; add and delete entries from a dictionary; and import and export entire dictionaries.

You can use content dictionaries to scan messages against message or content filters in order to take appropriate action in accordance with your corporate policies. You can create, delete, and view dictionaries; add and delete entries from a dictionary; and import and export entire dictionaries. You can also determine case sensitivity and word boundary detection for each dictionary. For example, you could create a list of confidential or profane words, and, using a filter rule to scan messages for words in the list, drop or archive messages containing matching words. And you can add a “weight” terms in a dictionary so that certain terms trigger a filter action more easily.

Dictionaries can contain non-ASCII characters.

Note that, for efficient processing, the following content dictionary entries are treated as words:

• Entries containing only alphanumeric characters
• Email addresses containing the following characters: 0-9, A-Z, a-z, dot, underscore, hyphen, and at symbol
• Domain names containing the following characters: 0-9, A-Z, a-z, dot, underscore, hyphen, and at symbol

If you want the appliance to treat such a word as a regular expression, enclose the word in parenthesis, for example, (user@example.com) .

Text resources are text objects, such as disclaimers, notification templates, and anti-virus templates. You can create new objects for use in various components of AsyncOS. You can import and export text resources.

Message disclaimer stamping allows you to add a disclaimer text resource to messages. For example, you could append a copyright statement, promotional message, or disclaimer to every message sent from within your enterprise.

Words in dictionaries are created with one text string per line, and entries can be in plain text or in the form of regular expressions. Dictionaries can also contain non-ASCII characters. Defining dictionaries of regular expressions can provide more flexibility in matching terms, but doing so requires you to understand how to delimit words properly. For a more detailed discussion of Python style regular expressions, consult the Python Regular Expression HOWTO, accessible from

http://www.python.org/doc/howto/

Note	To use the special character # at the beginning of a dictionary entry, you can use a character class [#] to prevent it being treated as a comment.

For each term, you specify a “weight,” so that certain terms can trigger filter conditions more easily. When AsyncOS scans messages for the content dictionary terms, it “scores” the message by multiplying the number of term instances by the weight of term. Two instances of a term with a weight of three would result in a score of six. AsyncOS then compares this score with a threshold value associated with the content or message filter to determine if the message should trigger the filter action.

You can also add smart identifiers to a content dictionary. Smart identifiers are algorithms that search for patterns in data that correspond to common numeric patterns, such as social security numbers and ABA routing numbers. These identifiers can useful for policy enforcement. For more information about regular expressions, see “Regular Expressions in Rules” in the “Using Message Filters to Enforce Email Policies” chapter. For more information about smart identifiers, see “Smart Identifiers” in the “Using Message Filters to Enforce Email Policies” chapter.

Note

Dictionaries containing non-ASCII characters may or may not display properly in the CLI on your terminal. The best way to view and change dictionaries that contain non-ASCII characters is to export the dictionary to a text file, edit that text file, and then import the new file back into the appliance. For more information, see Importing and Exporting Dictionaries as Text Files.

The content dictionary feature also includes, by default, the following text files located in the configuration directory of the appliance:

• config.dtd
• profanity.txt
• proprietary_content.txt
• sexual_content.txt

These text files are intended to be used in conjunction with the content dictionaries feature to aid you in creating new dictionaries. These content dictionaries are weighted and use smart identifiers to better detect patterns in data and trigger filters when the patterns indicate compliance issues.

Note	Importing and exporting dictionaries does not preserve the Match Whole Words and Case Sensitive settings. This settings are only preserved in the configuration file.

See FTP, SSH, and SCP Access for more information accessing on the configuration directory.

You can also create your own dictionary files and import them onto the appliance. The best way to add non-ASCII characters to dictionaries is to add the terms into the dictionary in a text file off the appliance, move that file onto the appliance, and then import that file as a new dictionary. For more information about importing dictionaries, see Importing Dictionaries. For information about exporting dictionaries, see Exporting Dictionaries.

Caution

These text files contain terms that some persons may consider obscene, indecent or offensive. If you import terms from these files into your content dictionaries, the terms will be displayed when you later view the content dictionaries you have configured on the appliance.

The message filter rule named dictionary-match(< dictionary_name >) (and its counterparts) evaluates to true if the message body contains any of the regular expressions in the content dictionary named dictionary_name . If that dictionary does not exist, the rule evaluates to false.

Note that the dictionary-match() rule functions similarly to the body-contains() body scanning rule: it only scans the body and attachments of messages, and not the headers.

For scanning headers, you can use the appropriate *-dictionary-match() -type rule (there are rules for specific headers, such as subject-dictionary-match() and a more generic rule, header-dictionary-match() , in which you can specify any header including custom headers). See “Dictionary Rules” in the “Using Message Filters to Enforce Email Policies” chapter for more information about dictionary matching.

dictionary-match
(<dictionary_name>)

In the following example, a new message filter using the dictionary-match() rule is created to blind carbon copy the administrator when the appliance scans a message that contains any words within the dictionary named “secret_words” (created in the previous example). Note that because of the settings, only messages that contain the whole word “ codename ” matching the case exactly will evaluate to true for this filter.

bcc_codenames:

if (dictionary-match ('secret_words'))

{

bcc('administrator@example.com');

}

In this example, we send the message to the Policy quarantine:

quarantine_codenames:

if (dictionary-match ('secret_words'))

{

quarantine('Policy');


}

You must have access to the configuration directory on the appliance. Imported text files must be present in the configuration directory on the appliance. Exported text files are placed in the configuration directory.

See FTP, SSH, and SCP Access for more information on accessing the configuration directory.

To add non-ASCII characters to text resources, add the terms into the text resource in a text file off the appliance, move that file onto the appliance, and then import that file as a new text resource. For more information about importing text resources, see Importing Text Resources. For information about exporting text resources, see Exporting Text Resources.

You can create some text resources with both HTML-based and plain text messages, such as Disclaimers. When a text resource containing both HTML-based and plain text messages is applied to an email message, the HTML-based text resource message is applied to the text/html part of the email message, and the plain text message is applied to the text/plain part of the email message.

When you add or edit an HTML-based text resource, the GUI includes a rich text edit that allows you to enter rich text without having to manually write HTML code.

Consider the following information when adding and editing an HTML-based text resource:

• You can choose to have the plain text version of the message to be automatically generated based on the HTML version, or you can define the plain text version independently.
• You can switch between the rich text editor and HTML code by clicking the Code View button.
• To enter HTML code that is not supported in the rich text editor in the GUI, switch to code view and manually enter HTML code. For example, you might want to do this to insert a reference to an image file located on an external server using the <img src> HTML tag.

The appliance can add a default disclaimer above or below the text (heading or footer) for some or all messages received by a listener. You can add disclaimers to messages on the appliance using the following methods:

• Via a listener, using the GUI or the listenerconfig command (see Adding Disclaimer Text via a Listener).
• Using the content filter action, Add Disclaimer Text (see Content Filter Actions).
• Using the message filter action, add-footer() (see the “Using Message Filters to Enforce Email Policies” chapter).
• Using a data loss prevention profile (see Data Loss Prevention).
• Using message modification for Outbreak Filters to alert the user that the message may be an attempt at phishing or malware distribution (see Modifying Messages). Disclaimers added for this type of notification are added above the text.

For example, you can append a copyright statement, promotional message, or disclaimer to every message sent from within your enterprise.

Prior to using disclaimer text you have to create the disclaimer template. Use the Text Resources page in the GUI (see Adding Text Resources) or the textconfig command (see the CLI Reference Guide for AsyncOS for Cisco Email Security Appliances) to create and manage a set of text strings to be used.

AsyncOS includes a setting used to modify the way disclaimer stamping with different character encodings works. By default, AsyncOS attempts to place the disclaimers it attaches within the body part of an email message. You can use a setting configured within the localeconfig command to configure the behavior if the encodings of the body part and the disclaimer are different. To understand this setting, it is helpful to view an email message as consisting of several parts:

The message body after the first blank line may contain many MIME parts. The second and following parts are often called “attachments,” while the first is often called the “body” or “text.”

A disclaimer can be included in an email as either an attachment (above) or as part of the body

Typically, when there is an encoding mismatch between the message body and a disclaimer, AsyncOS attempts to encode the entire message in the same encoding as the message body so that the disclaimer will be included in the body (“inline”) and not included as a separate attachment. In other words, the disclaimer will be included inline if the encoding of the disclaimer matches that of the body, or if the text in the disclaimer contains characters that can be displayed inline (in the body). For example, it is possible to have a ISO-8859-1 encoded disclaimer that only contains US-ASCII characters; consequently, this will display “inline” without problems.

However, if the disclaimer cannot be combined with the body, you can use the localeconfig command to configure AsyncOS to attempt to promote, or convert, the body text to match the encoding of the disclaimer so that the disclaimer can be included in the body of the message:

example.com> localeconfig

Behavior when modifying headers: Use encoding of message body

Behavior for untagged non-ASCII headers: Impose encoding of message body

Behavior for mismatched footer or heading encoding: Only try encoding from
message body



Choose the operation you want to perform:

- SETUP - Configure multi-lingual settings.

[]> setup



If a header is modified, encode the new header in the same encoding as

the message body? (Some MUAs incorrectly handle headers encoded in a

different encoding than the body. However, encoding a modified header

in the same encoding as the message body may cause certain characters in the modified

header to be lost.) [Y]>



If a non-ASCII header is not properly tagged with a character set and

is being used or modified, impose the encoding of the body on the

header during processing and final representation of the message?

(Many MUAs create non-RFC-compliant headers that are then handled in

an undefined way. Some MUAs handle headers encoded in character sets

that differ from that of the main body in an incorrect way. Imposing the encoding of the

body on the header may encode

the header more precisely. This will be used to interpret the content of headers for

processing, it will not modify or rewrite the header

unless that is done explicitly as part of the processing.) [Y]>



Footers or headings are added in-line with the message body whenever

possible. However, if the footer or heading is encoded differently

than the message body, and if imposing a single encoding will cause

loss of characters, it will be added as an attachment. The system will

always try to use the message body's encoding for the footer or

heading. If that fails, and if the message body's encoding is USASCII,

the system can try to edit the message body to use the footer's

or heading's encoding. Should the system try to impose the footer's

or headings's encoding on the message body? [N]> y



Behavior when modifying headers: Use encoding of message body

Behavior for untagged non-ASCII headers: Impose encoding of message

body. Behavior for mismatched footer or heading encoding: Try both

body and footer or heading encodings



Choose the operation you want to perform:

- SETUP - Configure multi-lingual settings.

For more information about the localeconfig command, see the “Configuring the Appliance to Receive Mail” chapter.

Notification templates are used with the notify() and notify-copy() filter actions. Notification templates may contain non-ascii text and action variables (see “Action Variables” in the “Using Message Filters to Enforce Email Policies” chapter), including the anti-virus-related variables used by anti-virus notifications. For example, you could use the $Allheaders action variable to include the headers from the original message. You can configure the From: address for notifications, see Configuring the Return Address for Appliance Generated Messages.

Once you have created a notification template, you can refer to it in content and message filters. The following figure shows a content filter where the notify-copy() filter action is set to send the “grape_text” notification to “grapewatchers@example.com:”

Figure 1. Notify Example in a Content Filter

There are two types of anti-virus notification templates:

• anti-virus notification template. The anti-virus notification template is used when the original message is not attached to the virus notification.
• anti-virus container template. The container template is used when the original message is sent as an attachment.

Anti-virus notification templates are used in basically the same way as notification templates except that they are used with the anti-virus engine instead of filters. You can specify a custom notification to send while editing a mail policy. You can configure the From: address for anti-virus notifications. For information, see Configuring the Return Address for Appliance Generated Messages.

Bounce and encryption failure notification templates are used in basically the same way as notification templates except that they are used with bounce notifications and message encryption failure notifications. You can specify a custom bounce notification to send while editing a bounce profile and a custom message encryption failure notification while editing an encryption profile.

The following figure shows a bounce notification template specified in a bounce profile.

Figure 3. Bounce Notification Example in a Bounce Profile

Note	You must use RFC-1891 DSNs to use custom templates.

The following figure shows an encryption failure template specified in an encryption profile.

Figure 4. Encryption Failure Notification Example in an Encryption Profile

Encryption notification templates are used when you configure Cisco Email Encryption to encrypt outbound email. The notification informs recipients that they have received an encrypted message and provides instructions for reading it. You can specify a custom encryption notification to send with encrypted messages. You specify both an HTML and a text encryption notification when you create an encryption profile. Therefore, if you want to create a custom profile, you should create both text and HTML notifications.