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

Information 

Note: In a single rule, an AND relationship exists between multiple conditions. If a single rule includes multiple conditions, they must all evaluate true for the rule action to be taken. To match any of several conditions, place each one in its own rule. To create OR relationships between conditions, create a separate rule for each condition.

 

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.

Information 

Note: You can also choose to reject messages at the Receiver based on SpamProfiler evaluation. For more information, see “Configuring SpamProfiler”.

To use SpamBotCensor you must ensure that MailMarshal processing nodes are directly connected to the Internet (with no other gateway or firewall forwarding incoming messages to MailMarshal).

 

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

 config-spamengine.png

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

rule-condition-virus.png 

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.

Information 

Note: The detailed failure results depend on return codes provided by the individual scanner vendors.

With the exception of Contains Virus and Unexpected scanner error, the virus scanning features listed on the rule condition panel can only be used with DLL based scanners. If you attempt to select options that are not supported by the scanners you have selected, MailMarshal will not allow you to save your selections.

Use the option “Unexpected scanner error” to specify an action MailMarshal should take when the code returned by the scanner is not known to MailMarshal. If this option is not selected in a rule condition, an unexpected return code will result in the message being dead lettered. For command line scanners, configure the list of return codes in the virus scanner properties. For more information about virus scanner properties, see “Using Virus Scanning”.

 

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.

Information 

Note: MailMarshal includes a default rule to check messages and attachments using a YAE script that is provided by the Trustwave SpiderLabs Email Security team and automatically updated (AMAX.yae). Advanced administrators can create custom YAE scripts. For more information, see the document “Using Yara Analysis Engine Scripts”, available from the MailMarshal support page on the Trustwave website.

 

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.

Information 

Note: To improve overall performance, place rules that use this criterion after spam blocking rules, and before rules that rewrite URLs for Blended Threat analysis.

 

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

rule-condition-spoofed.png 

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.

Information 

Note: This is the more restrictive option. It requires all email originating within the organization to have been routed to MailMarshal from a trusted internal email server. Only messages accepted by the internal email server will be accepted by MailMarshal. This option can stop local users from “spoofing” addresses within the local domains.

 

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.

Information 

Note: For more information about Sender ID, see Trustwave Knowledge Base article Q11559.

 

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”.

Information 

Note: You can include more than one TextCensor script in this condition by selecting multiple boxes in the rule condition panel. By default if you select more than one script, all the scripts you select must trigger for the condition to be true (logical AND). You can choose to make the condition true if ANY script triggers (logical OR).

 

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.

Information 

Note: You can enter additional custom types by entering signature information in a configuration file. For information about the required procedures and structure of the file, see Trustwave Knowledge Base article Q10199.

 

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.

Tip 

Tip: The attachment fingerprint ability is intended to be used for a small number of images. If you add large numbers of files, MailMarshal performance will be affected.

This option can be useful to exclude certain images, such as corporate logos or signatures, from triggering quarantine rules. It is not intended as an anti-spam option.

For example to take action only on images that are not in the list of known images, use the following conditions:

When a message arrives
Where message attachment is of type IMAGE
And where attachment fingerprint is not known

 

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.

Tip 

Tip: You can check for well-known attachments, such as signature images in documents, using the condition “Where attachment fingerprint is/is not known.”

 

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).

Information 

Note: You cannot select this rule condition if Image Analyzer is not licensed.

If the Image Analyzer license expires while this condition is selected, images will not be scanned by Image Analyzer. In this case the MailMarshal Engine log will show that Image Analyzer has not been used because it is not licensed.

 

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

rcia.PNG 

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.

Information 

Notes:

MailMarshal versions prior to 10.1 used only the “Pornography” category. Any rules upgraded from those earlier versions use this category.

Some earlier product versions included additional sensitivity settings. These settings are no longer required.

 

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.

Information 

Note: MailMarshal checks the size of the received message in its encoded format. This is typically 33% larger than the size reported by an email client.

 

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.

Tip 

Tip: This condition is evaluated based on the RCPT TO list specified when the message was received. It does not check the content of email headers such as To:, CC:, or BCC:.

 

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.

Information 

Note: “Top level attachments” are the files explicitly attached by name to an email message. Other files, such as the contents of a zip archive or images within a MS Word document, may be contained within the top-level attachments.

 

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.

Information 

Note: If the Safe Senders list is disabled (from the Administrator section of the SQM website), this condition has no effect.

 

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.

Information 

Note: If the Blocked Senders list is disabled (from the Administrator section of the SQM website), this condition has no effect.

 

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.

Information 

Note: This condition is also available in Connection Policy rules. To save resources and improve security, you should use this condition in a Connection Policy rule where possible.

 

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”.

Information 

Note: You can also check for authentication using the Connection Policy rule condition “Where sender has authenticated.” To save resources and improve security, you should use the Connection Policy condition where possible. Using a Content Analysis policy rule allows more actions and combinations of conditions.

 

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.

Information 

Note: You can only use Header Match conditions within the rule where you create them. To use the same condition in more than one rule, create it in each rule.

 

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

rule-condition-category.png 

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.

Information 

Note: DKIM validation of the message is performed when the message is received. To use this condition, you must enable DKIM validation (in System Configuration, see MailMarshal Properties > Array Properties > Receiver Properties > DKIM).

 

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

Information 

Note: The MailMarshal Receiver can only process this condition if the outside server has made an ESMTP connection and reported the message size. In order to check the size of all messages, you should repeat this condition in a Content Analysis Policy rule to include messages received from sources that do not support ESMTP. See also Trustwave Knowledge Base article Q10602.

 

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.

Information 

Note: For more information about SPF, see Trustwave Knowledge Base article Q11560.

 

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.

Information 

Note: You can check one or more of the boxes.

Matching of a specific string supports wildcards. For more information, see “Wildcard Characters”.

 

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”.

Information 

Note: You can also check for authentication using the Connection Policy rule condition “Where sender did/did not authenticate successfully.” To save resources and improve security, you should use the Connection Policy condition where possible. Using a Content Analysis policy rule allows more actions and combinations of conditions.

 

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”.

Information 

Note: Reputation Services results are based on the IP address of a server, and currently provide information about IPv4 addresses only.

 

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.

Information 

Note: The SpamCensor and SpamBotCensor engines cannot be used to evaluate deadlettered items because they can only evaluate a fully unpacked message.

 

Trustwave MailMarshal 10.2.5 User Guide August 2024
< Previous Section   |   Next Section >
Full document: see MailMarshal Documentation.