6.5 Understanding Rule Conditions

MailMarshal evaluates rule conditions within each rule. MailMarshal checks rule conditions after any User Matching conditions. In general MailMarshal will only apply the rule actions to a message if all rule conditions evaluate true.

You can choose one or more rule conditions when you create or edit a rule in the Management Console. If the condition includes options, arguments, or variables, you can click a hyperlink in the rule edit panel to open a panel that allows you to specify values.

6.5.1 Rule Conditions for Content Analysis Policy Rules

The following conditions are available for use in Content Analysis Policy rules. They are further explained in the sections following.

•Security

•Where message is detected as spam by SpamEngine

•Where the result of a virus scan is

•Where message is identified as containing malware by Yara Analysis Engine script

•Where message contains suspect URLs

•Where message spoofing analysis is based on criteria

•Where message triggers TextCensor script(s)

•Message Attachments

•Where message attachment is of type

•Where attachment fingerprint is/is not known

•Where message contains attachment(s) named (file names)

•Where attachment parent is of type

•Where the attached image does/does not/may match image category

•Size

•Where message size is

•Where the estimated bandwidth required to deliver this message is

•Where message attachment size is

•Where number of recipients is count

•Where number of attachments is count

•Sender

•Where the sender is/is not in the recipient’s safe senders list

•Where the sender is/is not in the recipient’s blocked senders list

•Where sender's IP address matches address

•Where sender did/did not authenticate successfully

•TLS

•Where message was/was not received via TLS

•Where message was received via TLS versions

•Where the TLS client certificate matches criteria

•Other

•Where the external command is triggered

•Where message contains one or more headers (header match)

•Where message triggers category script(s)

•Where the DKIM verification result is

•Where message was checked with DMARC and a result applied

6.5.1.1 Where message is detected as spam by SpamEngine

This condition allows you to take action on a message based on the result of evaluation by SpamProfiler, SpamBotCensor, and/or SpamCensor. You can use this condition in a rule that is processed early, to quarantine spam with minimal processing load. You can use this condition in combination with user group exclusions or other conditions to fine-tune recognition of spam.

On the rule condition panel, select the anti-spam technologies you want to use.

•If you select SpamProfiler, you can select one or more sub-classifications to check. The SpamProfiler evaluation triggers if any of the sub-classifications triggers.

•You can choose to trigger the condition if all or any of the technologies classifies the message as spam.

For more information, see Help.

6.5.1.2 Where the result of a virus scan is

This condition allows you to select from the virus scanning features available in MailMarshal. Use the rule condition panel to choose the desired virus scanning action and the results to be checked for.

Figure 11: Virus scanning rule condition

You can choose the virus scanners MailMarshal uses when processing this condition.

•All Scanners: MailMarshal uses all configured virus scanners to scan all parts of the message and attachments.

•Specific scanners: To limit the virus scan to specific installed scanners, choose this option then select the desired scanners from the list. MailMarshal uses the scanners you select.

You can choose the scanner results that will cause this condition to trigger. To choose options, select the appropriate boxes on the Select Virus Scanner Results panel.

•Contains Virus: The condition will trigger if any part of the message contains a virus. This is the basic condition.

•...and Name Matches: When you select this item, the condition will only trigger if the name of the virus as returned by the scanner matches the text in the field. You can use this condition to modify the MailMarshal response based on certain virus behaviors. For instance you can choose not to send notifica­tions to the sender address for viruses known to spoof the “from” address. You can use wildcard characters when you enter virus names. For more information, see “Wildcard Characters” and “Regular Expressions”.

•Password Protected: When you select this item, the condition will trigger if the scanner reports the file as password protected.

•File is corrupt: When you select this item, the condition will trigger if the scanner reports the file as corrupt.

•Virus scanner signatures out of date: When you select this item, the condition will trigger if the scanner reports its signature files are out of date.

•Could not fully unpack or analyze file: When you select this item, the condition will trigger if the scanner reports that it could not unpack the file.

•Unexpected scanner error: When you select this item, the condition will trigger if the scanner reports an unknown error or the code returned is unknown.

6.5.1.3 Where message is identified as containing malware by Yara Analysis Engine

This condition allows you to take action on a message based on the result of evaluation by the proprietary Yara Analysis Engine (YAE). This technology provides an additional layer of protection against malware and other spam messages.

You can use this condition in combination with other conditions to fine-tune recognition of malware. The rule condition panel allows you to select a specific Yara Analysis Engine script for use in this condition.

6.5.1.4 Where message contains suspect URLs

This condition extracts URLs from the message and checks them against a list of suspect URLs maintained by Trustwave and constantly updated from a variety of trusted sources.

6.5.1.5 Where message spoofing analysis is based on criteria

This condition allows you to define when MailMarshal should consider a message to be spoofed. A spoofed message did not originate within the domain of the claimed sender email address. MailMarshal can check spoofing based on local domain servers, authenticated connections, and/or Sender ID.

In the rule condition panel, select any of the detailed criteria for this condition.

Figure 12: Message spoofing analysis rule condition

MailMarshal evaluates the first two criteria, if selected, when the sender address (“From:” header or SMTP “Mail From:” address) of a message is within a Local Domain, as specified in the System Configuration > Local Domains item in the Management Console. These criteria do not apply for messages with From addresses in other domains.

The originating IP address:

Select this condition to check for spoofing based on the IP address of the computer which originated the message. Choose one of the following options to determine how MailMarshal checks the IP address:

• Is not considered local as defined by the anti-relaying settings: When you select this option, MailMarshal considers email with a local sender address “spoofed” if it does not originate from a com­puter allowed to relay. The list of computers allowed to relay is determined by the IP address ranges in the MailMarshal Relaying Table that is effective from this server. This option is useful if you allow multiple servers and workstations in the local network to route email directly through MailMarshal.

•Does not match the IP address for that specific local domain: When you select this option, MailMarshal considers email with a local sender address “spoofed” if it is not delivered to MailMarshal from the correct Local Domain email server. The Local Domain server is the computer to which MailMarshal delivers messages for the specific SMTP domain of the “From:” address.

The originating system did not use ESMTP authentication:

Select this option to check for spoofing based on the login given by the system that delivered the mes­sage to MailMarshal. Use this condition (and not an IP address based condition) if you allow roving users to send email through MailMarshal using the Authentication feature. For more information about this feature see “Authentication by Account”.

MailMarshal evaluates the following criterion, if selected, for all messages.

The Sender-ID evaluation fails:

Select this option to evaluate the message using the Sender ID Framework. Click Change Settings to see additional settings that allows you to configure detailed Sender ID criteria.

6.5.1.6 Where message triggers TextCensor script(s)

This condition checks textual content in some or all parts of the message and its attachments, depending on the settings defined in the specific scripts.

In the rule condition panel, you can select one or more TextCensor scripts to be used in evaluating the message. You can add a script or edit an existing script. For detailed information about Scripts, see “Identifying Email Text Content Using TextCensor Scripts”.

6.5.1.7 Where message attachment is of type

MailMarshal checks the structure of all attached files to determine their type. MailMarshal can recognize over 175 types as of this writing.

The rule condition panel provides a listing of file types organized by category. To select an entire category, select the check box associated with the category. To select individual types within a category, expand the category and select the check boxes associated with each type.

6.5.1.8 Where attachment fingerprint is/is not known

The “fingerprint” identifies a specific file (such as a particular image). The rule condition panel allows you to choose to base the condition on fingerprints which are known or unknown.

To add a file to the list of “known” files, use the “add to valid fingerprints” rule action, or the “add fingerprints” option in the Console when releasing a message.

To delete a file from the list of “known” files, locate the file. It will be present on one or more of the MailMarshal email processing servers in the ValidFingerprints sub folder of the MailMarshal installation folder. Delete the file from this location on all servers then commit the MailMarshal configuration.

Files can also be “made known” by placing them in the ValidFingerprints sub-folder of the Quarantine folder on any email processing server. MailMarshal loads these fingerprints every 5 minutes, and when configuration is committed. For further information about this process, see Trustwave Knowledge Base article Q10543.

6.5.1.9 Where message contains attachments named

Use this condition to block files by extension, by specific file name, or by a wildcard pattern of the file name.

You can enter a list of file names in the rule condition panel. When you enter information, you can use the wildcard characters asterisk (*) and question mark (?). For example, the following are valid entries: *.SHS;*.VBS;*.DO?

You can use this condition to quickly block dangerous file types such as VBS, or known virus attachments such as “creative.exe”. However, the condition checks only the file name and not the contents of the file. Use the condition “Where message attachment is of type” to check files by structure.

6.5.1.10 Where attachment parent is of type

This condition is intended to be used with the condition “Where message triggers TextCensor script(s).” When this condition is selected, MailMarshal considers the file type of the immediate parent container as well as that of the attachment. For instance, you can check whether an image is contained in a MS Word document.

The rule condition panel provides a listing of available parent types organized by category. To select an entire category, select the check box associated with the category. To select individual types within a category, expand the category and select the check boxes associated with each type. You can also choose to apply the condition to types in or out of the selected list. For instance, you can check that an image is not contained in a Word document.

6.5.1.11 Where the attached image does/does not/may match image category

This condition allows you to take action on a message based on the result of analysis of attached images by Image Analyzer (an optional component licensed separately).

MailMarshal passes the following types of files that it unpacks from a message to Image Analyzer for analysis:

•Files MailMarshal recognizes as IMAGE types

•Binary files of unknown type.

Image Analyzer actually scans files of the following types: BMP, DIB, JPEG, JPG, JPE, J2K, JBG, JPC, PNG, PBM, PGM, PPM, SR, RAS, TIFF, TIF, GIF, TGA, WMF, PGX, PNM, RAS. For more information see Trustwave Knowledge Base article Q11622.

MailMarshal does not request image analysis for very small images (by default, images smaller than 75x75 pixels). You can adjust this setting. See Trustwave Knowledge Base article Q14960.

In the rule condition panel, select the detailed criteria for this condition.

Figure 13: Image analysis rule condition

The attached image matches selected category:

Specifies that the condition will trigger if Image Analyzer returned a score higher than the "matches above" value.

The attached image does not match selected category:

Specifies that the condition will trigger if Image Analyzer returned a score below the "does not match below" value.

The attached image may match selected category

Specifies that the condition will trigger if Image Analyzer returned a score between the "matches above" and the "does not match below" values.

Category selection

Specifies a single Image Analyzer category to be checked in this rule condition. The Description field shows the intended purpose of the selected category. To check for additional categories, use one rule per category.

In the Detection section you can configure advanced settings for Image Analyzer.

You can choose from the following basic detection settings:

Normal:

Specifies that the default Image Analyzer triggering levels should be used.

High:

Specifies that high sensitivity Image Analyzer triggering levels should be used. This setting detects more objectionable content, but also produces more false positive results.

Custom:

Allows you to set the Image Analyzer triggering levels using the slider controls.

•Matches above: Specifies the minimum Image Analyzer return value that causes an image to be classified as matching the selected category, for example, likely to be pornographic. Default value: 75 for "normal" setting; 60 for "high" setting.

•Does not match below: Specifies the maximum Image Analyzer return value that causes an image to be classified as not matching the selected category. Default value: 49.

6.5.1.12 Where message size is

MailMarshal uses the size of the entire message, before unpacking, in this condition. The rule condition panel allows you to choose a size and matching method (greater than a given size, less than a given size, between two sizes, not between two sizes, equal to or not equal to a size). If you choose to match between two sizes the matching is inclusive.

6.5.1.13 Where the estimated bandwidth required to deliver this message is

MailMarshal calculates the bandwidth required to deliver a message by multiplying the message size by the number of unique domains to which it is addressed. The rule condition panel allows you to choose a total bandwidth and matching method (greater than a given size, less than a given size, between two sizes, not between two sizes, equal to or not equal to a size). If you choose to match “between” two sizes the matching is inclusive.

One use of this criterion is to move high-bandwidth messages to a “parking” folder for delivery outside peak hours. Another use is to reject high-bandwidth messages.

6.5.1.14 Where message attachment size is

This condition checks the size of each attachment separately after all unpacking and decompression is complete. The size of an attachment can be greater than the size of the original message, due to decompression of archive files. The rule condition panel allows you to choose a size and matching method (greater than a given size, less than a given size, between two sizes, not between two sizes, equal to or not equal to a size). If you choose to match “between” two sizes the matching is inclusive.

6.5.1.15 Where number of recipients is count

This condition checks the number of SMTP recipient addresses in a message. It is typically used to block messages with large recipient lists as suspected spam. The rule condition panel allows you to choose a number and matching method (greater than a given number, less than a given number, between two numbers, not between two numbers, equal to or not equal to a number). If you choose to match “between” two numbers the matching is inclusive.

6.5.1.16 Where number of attachments is count

This condition is typically used to block messages with large numbers of attachments. The number of attachments can be counted using top level attachments only, or top level attachments to email messages including any attached messages, or all attachments at all levels.

The rule condition panel allows you to choose a number and matching method (greater than a given number, less than a given number, between two numbers, not between two numbers, equal to or not equal to a number). If you choose to match “between” two numbers the matching is inclusive.

6.5.1.17 Where the sender is/is not in the recipient’s safe senders list

This condition allows you to take action on a message based on the list of “safe senders” maintained by a local message recipient through the Spam Quarantine Management Website. A typical use of this action is to create an exception to Spam rules, using the rule action “Pass the message to rule.” The default rules provided with new installations of MailMarshal include a rule to perform this function.

The user can enter an individual email address, or a wildcard pattern using the asterisk (*) wildcard character.

In the rule condition panel, choose whether to apply the condition if the sender is, or is not, in the recipient’s safe senders list.

6.5.1.18 Where the sender is/is not in the recipient’s blocked senders list

This condition allows you to take action on a message based on the list of “blocked senders” maintained by a local message recipient through the Spam Quarantine Management Website. A typical use of this action is to create a rule that quarantines all email from addresses in the user’s blocked list. The default rules provided with new installations of MailMarshal include a rule to perform this function.

The user can enter an individual email address, or a wildcard pattern using the asterisk (*) wildcard character.

In the rule condition panel, choose whether to apply the condition if the sender is, or is not, in the recipient’s blocked senders list.

6.5.1.19 Where sender's IP address matches address

This condition can be used to take action on messages from one or more ranges of IP addresses.

MailMarshal shows the configured ranges in the rule condition panel. To add a range to the list, click New to open the Match IP Address panel. To modify an existing address, highlight it, and then click Edit. To delete an existing address from the list, highlight it, and then click Delete.

Add or modify an address or range using the rule condition panel. Select one of the three choices using the option buttons:

•An IP Address: Enter a single IPv4 or IPv6 address. For instance, enter “10.2.0.4” or “::1”.

•A range of IP addresses: Enter the starting and ending IP addresses for an inclusive range. For instance, enter “10.2.1.4” and “10.2.1.37”

•An entire network range: Enter an IP address and a network mask in CIDR notation. For instance, enter “10.2.1.4” and “24” to match the entire 10.2.1.0 subnet. Enter “fe80::” and “10” to match IPv6 link-local addresses.

The check box at the bottom of the panel controls whether this address or range will be included or excluded from the condition match.

•To include the address or range, select the check box.

•To exclude the address or range, clear the check box.

6.5.1.20 Where sender did/did not authenticate successfully

This condition can be used to check whether MailMarshal authenticated the remote system using an account and password. For more information about setting up accounts for authentication see “Setting Up Accounts”.

6.5.1.21 Where message was/was not received via TLS

This condition allows you to take action on messages depending on whether they were received with TLS (Transport Layer Security). For more information about setting up TLS in MailMarshal, see “Securing Email Communications”.

6.5.1.22 Where message was received via TLS versions

This condition allows you to take action on messages depending on the version of TLS used to secure the connection. For more information about setting up TLS in MailMarshal, see “Securing Email Communications”.

6.5.1.23 Where the TLS client certificate matches criteria

This condition allows you to take action on messages depending on the specific features of the SSL certificate that was used to secure the connection. You can check the date, trust, revocation status, and other features. For full details of the available options, see Help. For more information about setting up TLS in MailMarshal, see “Securing Email Communications”.

6.5.1.24 Where the external command is triggered

This option allows you to select one or more external commands MailMarshal uses to test the message. External commands can be executable programs or batch files. In the rule condition panel, specify the commands. If more than one command is specified, all commands must be triggered for this condition to be triggered. For more information about external commands see “Extending Functionality Using External Commands”.

6.5.1.25 Where message contains one or more headers

This condition can be used to check for the presence, absence, or content of any message header, including custom headers. You can use this condition to check for blank or missing headers, or to reroute email.

Within the rule condition panel, click Add to create a new header match rule. For more information about creating header match rules, see “Using Rules to Find Headers”.

You can check more than one header match in a single condition. If you check more than one match, all matches must be true for the condition to be true (logical “and”). To match any of several header conditions (logical “or”), include more than one rule with one condition per rule.

To edit any Header Match condition (or view its details), highlight it, and then click Edit. To delete a Header Match condition, highlight it, and then click Delete.

6.5.1.26 Where message triggers category script(s)

This condition allows action to be taken on messages that trigger a category script. Select one or more categories using the rule condition panel.

If you select more than one script, you can choose to take action if all scripts trigger, or if any of the scripts trigger.

Figure 14: Category script rule condition

MailMarshal can automatically download updates to category scripts.

You can create and customize your own category scripts. Some example category scripts are provided with MailMarshal. For more information, see the technical reference “MailMarshal Anti-Spam Configuration,” available from the MailMarshal support page on the Trustwave website.

6.5.1.27 Where the DKIM verification result is

This condition allows you to take action on messages depending on the results of DKIM (DomainKeys Identified Mail) validation. You can choose to take action on messages that pass or fail validation, on messages where the required information could not be retrieved, or on messages where the DKIM header was not present.

6.5.1.28 Where message was checked with DMARC and a result applied

This condition allows you to take action on messages depending on the results of DMARC (Domain-based Message Authentication, Reporting & Conformance) validation. You can choose to take action on messages that pass validation, messages that could not be evaluated, and messages that fail validation. For messages that fail DMARC validation, you can base the action on the DMARC policy of the sending domain. For full details of the available options, see Help.

6.5.2 Rule Conditions for Connection Policy Rules

The following conditions are available for use in Connection Policy rules.

•General

•Where message is of a particular size

•Where the SPF evaluation result is

•Sender

•Where sender’s HELO name is/is not criteria

•Where sender's IP address matches address

•Where sender has authenticated

•Where sender's IP address is listed by Reputation Service

•TLS

•Where message was/was not received via TLS

•Where message was received via TLS versions

•Where the TLS client certificate matches criteria

6.5.2.1 Where message is of a particular size

This condition is normally used with a “refuse message” action to refuse large messages. The rule condition panel allows you to choose a size and matching method (greater than a given size, less than a given size, between two sizes, not between two sizes, equal to or not equal to a size). If you choose to match “between” two sizes the matching is inclusive

6.5.2.2 Where the SPF evaluation result is

This condition directs MailMarshal to check the message source using the Sender Policy Framework (SPF). Select the SPF results that trigger the condition using the option buttons.

To select a custom triggering value, and to configure advanced options, select Custom and then click Change Settings. 

See Help for definitions of the options.

6.5.2.3 Where sender's HELO name is/is not criteria

This condition allows action to be taken based on the HELO name provided by the remote email server. Choose from the following options:

•Where sender’s HELO name is: The condition will be true if the HELO name matches the criteria you select below.

•Where sender’s HELO name is not: The condition will be true if the HELO name does not match the criteria you select below.

•A specific string: Check this box and enter a character string to base the condition on an exact string (for example, AKLMAIL1)

•An IP address: Check this box to base the condition on HELO strings that are IP addresses (not text names). Check the additional box “Correctly enclosed in brackets” to require brackets around the IP address.

•A fully qualified domain name: Check this box to base the condition on HELO strings that are fully qualified domain names (FQDNs). For instance, AKLMAIL1.EXAMPLE.COM is a FQDN.

6.5.2.4 Where sender's IP address matches address

This condition can be used to permit relaying, or to refuse messages, from one or more ranges of IP addresses. MailMarshal shows the configured ranges in the rule condition panel. To add a range to the list, click New to open the Match IP Address panel. To modify an existing address, highlight it, and then click Edit. To delete an existing address from the list, highlight it, and then click Delete.

Add or modify an address or range using the rule condition panel. Select one of the three choices using the option buttons:

•An IP Address: Enter a single IPv4 or IPv6 address. For instance, enter “10.2.0.4” or “::1”.

•A range of IP addresses: Enter the starting and ending IP addresses for an inclusive range. For instance, enter “10.2.1.4” and “10.2.1.37”

•An entire network range: Enter an IP address and a network mask in CIDR notation. For instance, enter “10.2.1.4” and “24” to match the entire 10.2.1.0 subnet. Enter “fe80::” and “10” to match IPv6 link-local addresses.

The check box at the bottom of the panel controls whether this address or range will be included or excluded from the condition match.

•To include the address or range, select the check box.

•To exclude the address or range, clear the check box.

6.5.2.5 Where sender has authenticated

This condition is normally used with the “Accept message” action to allow relaying by specific users. This condition will trigger if MailMarshal authenticated the remote system using an account and password. For more information about setting up accounts for authentication see “Setting Up Accounts”.

6.5.2.6 Where sender's IP address is listed by Reputation Service

This condition allows Reputation Service tests (DNS Blocklists) to be applied. Choose the services to be used from the list in the Reputation Services panel.

The panel shows a list of all configured services. Select the check box for each service you want to use. Clear the check box for any service you do not want to use in this Condition. For information about how to configure reputation services, see “Reputation Services and DNS Blocklists”.

6.5.2.7 Where message was/was not received via TLS

This condition allows you to take action on messages depending on whether they were received with TLS (Transport Layer Security). For more information about setting up TLS in MailMarshal, see “Securing Email Communications”.

6.5.2.8 Where message was received via TLS versions

This condition allows you to take action on messages depending on the version of TLS used to secure the connection. For more information about setting up TLS in MailMarshal, see “Securing Email Communications”.

6.5.2.9 Where the TLS client certificate matches criteria

This condition allows you to take action on messages depending on the specific features of the SSL certificate that was used to secure the connection. You can check the date, trust, revocation status, and other features. For full details of the available options, see Help. For more information about setting up TLS in MailMarshal, see “Securing Email Communications”.

6.5.3 Rule Conditions for Dead Letter Policy Rules

The following conditions are available for use in Dead Letter Policy rules:

•Where the dead letter reason contains

•Where message is detected as spam by SpamProfiler

6.5.3.1 Where the Dead Letter reason contains

This condition allows you to enter text that MailMarshal will match in the Dead Letter Reason field of a deadlettered message. You can choose to allow a deadlettered message to be passed through to recipients. For a list of the reason codes, see Trustwave Knowledge Base article Q14226.

6.5.3.2 Where message is detected as spam by SpamProfiler

This condition allows you to take action on a deadlettered message based on the result of evaluation by SpamProfiler. You can use this condition to classify deadlettered messages as spam, or move them to the deadletter spam folder.