Analyze the To headers in the message. To analyze all message recipients, including Cc and Bcc recipients, use the Recipient's address test.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Do not analyze the message. This test is always true. The action is performed regardless of the message characteristics.
Analyze the Content-Type and Content-Disposition headers and, when using true file type identification, the contents of the files themselves. This test determines the filename of each message attachment. Expands the %%ATTACHMENT_NAMES%% template variable.
The Arguments button exposes the following options:
Use true file type identification for filename extensions: Modifies the test to use true file type detection for filename extensions. The files themselves are examined, as well as the filenames shown in the Content-Type and Content-Disposition headers. Archives are automatically expanded, so that files within other files can be tested. PureMessage will search as many levels as necessary (up to a configured maximum) to find specified file types. The maximum recursion depth is set in /opt/pmx/etc/tft.conf.
Tests for document types should use the application-specific file extension (such as .doc or .xls). To view a list of extensions that PureMessage supports, run:
pmx-list-true-filetypes --verbose
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Analyze the size of each message attachment. This test applies to any MIME attachment, including text/plain and text/html message body parts. Expands the %%ATTACHMENT_NAMES%% template variable.
Scan the content of message attachments, including archived attachments such as .zip and .tgz files. Archives are automatically expanded so that files within other files can be tested. PureMessage searches as many levels as necessary (up to a configured maximum) to find specified file types. The maximum recursion depth is set in opt/pmx/etc/tft.conf. Expands the %%ATTACHMENT_NAMES%% template variable.
The advantage of using this test instead of similar tests (Attachment type and Attachment name) is that the action is not performed on a message unless the file type is a true match for one that is specified in this test. For example, the Attachment type test will perform the action if there is a file type match in the message's Content-Type header, even if that does not represent the true identity of the file. So, it could be that a message appears to contain a Microsoft Word attachment, but the file extension has been falsified, and the message actually contains a .jpeg file instead.
This test can be used to detect specific file types or groups of file types. To view a list of supported file groupings, run:
pmx-list-true-filetypes
To view the specific file extensions within those groupings, run:
pmx-list-true-filetypes --verbose
The Arguments button exposes the following options:
Analyze the Content-Type and Content-Disposition headers and, when using true file type identification, the contents of the files themselves. This test determines the type of each message attachment. Expands the %%ATTACHMENT_NAMES%% template variable.
The Arguments button exposes the following options:
Use true file type identification for file type: Modifies the test to use true file type detection. The file itself is examined in addition to the declared Content-Type and Content-Disposition headers. Archives are automatically expanded, so that files within other files can be tested. PureMessage searches as many levels as necessary (up to a configured maximum) to find specified file types. The maximum recursion depth is set in /opt/pmx/etc/tft.conf.
Tests for attachment types should use the Mime file type. For a complete list of the Mime types that PureMessage supports, run:
pmx-list-true-filetypes --verbose
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Analyze the Envelope From value in the message.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Analyze the Sender or Recipient(s) Group(s), depending on the message's direction, and match them against the specified group.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Analyze the Envelope To value in the message. Specify individual recipients or lists of recipients. However, if a message addressed to a number of recipients tests true, specified actions are performed for all recipients. If, for example, a message with an attachment is addressed to five recipients, two of which match a list specified in the "Envelope to" test, and an "Drop attachment" action is also specified, none of the five recipients receive the attachment.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Check the header for a specified word or phrase.
The Arguments button exposes the following options:
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Check for the occurrence of a specific header.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Analyze the size of the message header.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Scan the message for numeric sequences that are common to major credit cards. This test is based on the Luhn algorithm, a checksum formula that performs the validation. Supported credit cards are American Express, MasterCard, Visa, Visa Electron, Discover Card, Diners Club, and China Union Pay.
The creditcard_number_limit setting in /opt/pmx/etc/creditcard.conf determines how many numeric sections PureMessage will scan in a given message. By default, PureMessage scans nine separate sections of numbers that might contain credit card numbers before proceeding to the next stage of processing.
You can configure the scan failure actions for this test in /opt/pmx/etc/scanlimit.d/phrase.conf.
The Arguments button exposes the following options:
Check message attachments for filenames or file extensions specified in the Suspect Attachment Names list and check Content-Type and Content-Disposition headers for attachment types specified in the Suspect Attachment Types list.
The Arguments button exposes the following options:
Use true file type identification: The files themselves are examined in addition to the declared Content-Type and Content-Disposition headers. Archives are automatically expanded, so that files within other files can be tested. PureMessage will search as many levels as necessary (up to a configured maximum) to find specified file types. The maximum recursion depth is set in /opt/pmx/etc/tft.conf.
Most common archive formats are supported. If you are creating a new rule that tests for suspect attachments, it is recommended that you specify this argument instead of the deprecated "Inspect archives" argument described below.
Analyze the stated virus names; automatically runs the "Message contains a virus" test.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Returns true if virus scanning for a message fails, and no viruses were found in the message. This test only works if it is preceded by the test "Message contains a virus." It is used to differentiate between messages that cannot be scanned for some reason (for example, encryption), and messages that contain viruses (either instance causes the test to return true).
Specify the types of unscannable content that PureMessage will allow or deny by editing the cantscan.conf file.
Only the "contains" and "Matches regex" Operators are recommended for this test. The "is" and "matches" tests compare against the entire text of the message, which is usually not desirable when looking for a particular phrase.
The Arguments button exposes the following options:
You can set the maximum attachment size and the maximum time per message scanned in /opt/pmx/etc/phrase.conf.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Returns true if a message could not be scanned. This test is only available for use within the following content tests: Attachment name, Attachment true filetype, Attachment type, Message contains credit card number, Message contains word or phrase, or Message contains suspicious attachments.
This test is mainly used to differentiate between messages that cannot be scanned for some reason (e.g., an unrecognized file type), and messages that contain undesired content, since both will cause the various content tests to return true. The kinds of unscannable content that PureMessage should allow or deny can be specified by editing the files in /opt/pmx/etc/scanlimit.d/. To configure unscannable content options for the Message contains word or phrase and Message contains credit card number tests, use /opt/pmx/etc/scanlimit.d/phrase.conf. For the attachment tests, use /opt/pmx/etc/scanlimit.d/tft.conf>.
Analyze the visible text in a message; compare it to the contents of the Offensive Words List. This test decodes base64/quoted-printable encoded text and strips out HTML markup before looking for a match.
Analyzes the message to determine if it is some form of Non Delivery Report/Receipt message.
The Arguments button exposes the Use BATV to detect valid bounces option. When it is selected, PureMessage performs the specified action(s) on legitimate bounce messages only. Messages using Bounce Address Tag Validation (BATV) are passed on to the next stage of processing.
This test is performed on mail sent from external hosts, and it must be used in conjunction with the "Apply BATV watermark" action. This action is configured in the "Mail from internal hosts section" of the policy, and it adds a private signature to each outgoing message.
When this test and action are both configured, PureMessage can then detect if this signature is included in incoming messages. This allows PureMessage to distinguish between legitimate bounce messages and backscatter spam. For more about backscatter, see the Knowledgebase on the Sophos website.
Checks the sender's IP address against IP blocklist data from SophosLabs. IP addresses defined in the IP Blocking Exception, Trusted Relay IPs and Internal Hosts lists are exempted.
This test is a policy-level alternative to MTA-level IP blocking. It is only effective if the IP Blocker Service is running. Using this test in the policy allows more flexibility in handling messages from blocked IP addresses, but it is not as efficient as rejecting the messages at the MTA level.
Even if you choose to block IP addresses at the policy level, it is still recommended that you enable the expanded IP-blocking functionality described in "Enabling or Disabling MTA IP Blocking" in the Local Services Tab section of the Manager Reference.
Do not analyze the message. This test is always false. The action is performed regardless of the message characteristics.
Analyze the total number of 8 bit (non-ASCII) characters in the message body. Use to check whether a message is 7 bit-clean (pure ASCII).
Analyze the To, Cc and Bcc headers in the message.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Analyze the hostname or IP address of the server that passed the message to the local domain.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Analyze the Reply-to headers in the message.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Analyze the From headers in the message.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Calculate the message's spam probability. If a message passes through several Spam probability tests, the message is only scanned once for its spam probability; its score is saved. This makes it possible to have different actions based on different spam probability ranges without having to scan the message multiple times.
Analyze the names of spam rules violated by the message; automatically performs the Spam probability test. Refer to the Anti-Spam Rules page for a list of configured rules.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
Analyze the contents of the message subject.
(Supports Multiple Test Expressions. For more information, see "Test Expressions")
DomainKeys Identified Mail (DKIM) is an authentication framework used to sign and validate a message, based on the domain of the sender. This test performs the validation by verifying the origin of the sending address. To configure PureMessage to add a DKIM signature to some or all outgoing messages, see Sign message with DKIM header in the "Actions Defined" section. DKIM verification depends on access to public keys stored on an available DNS server. This must also be configured for the test to take affect. For general information, see www.dkim.org.
The test analyzes the message header for DKIM signatures. It allows PureMessage to verify the origin of messages that bear a DKIM signature. This test returns true if the message matches the value specified.
Create multiple tests to allow for the various possibilties described in the values below.
Configurable Values:
When using this test with match operators such as Contains and Matches, type one of the following four values in the adjacent text box.
If you plan to quarantine messages based on certain test results, you may want to create a quarantine digest informing end users that messages have been quarantined for this reason. For more information, see "Managing Quarantine Digest Rules" in the Quarantine Tab section of the Manager Reference.