Export (0) Print
Expand All
2 out of 8 rated this helpful - Rate this topic

Understanding Policy Rule Match Options

 

Applies to: Office 365 for enterprises, Live@edu, Forefront Online Protection for Exchange

Topic Last Modified: 2013-04-29

This topic explains various policy rule match expressions or match options that you can use to take action on specific messages in Forefront Online Protection for Exchange (FOPE). For an overview of policy rules and their use, see Policy Rules.

Policy rules can be configured to match expressions within the following parts of an email:

  • E-mail Header: for field name and value.
  • E-mail Senders: for IP addresses, domains, and email addresses.
  • E-mail Recipients: for domains and email addresses.
  • E-mail Attachments: for file names and file extensions.
  • E-mail Subject and Body: for keywords and phrases.
  • Other email message properties (e.g. email size, number of recipients, character sets, and so on.)

The types and capabilities of the policy rules that can be enforced for each email part vary; details are listed below.

noteNote:
  • Some of the tables below list additional match options. These are selections in the FOPE Administration Center that give you more fine-grained control over matching behavior.
  • Policy rule behavior can vary based on differences in how rules match to specific parts of the SMTP envelope and header. Additionally, SMTP message parts can differ between messages. Test rules thoroughly to ensure that they comply with the behavior you intend.

You can match on email header names or values in order to perform specific actions. For a description of each available policy filter action, see Understanding Policy Rule Settings.

 

Email part Match for Syntax Additional match option(s)

Header

Field name

Basic

N/A

Header

Field value

Basic/RegEx

Case sensitive match

Limitations:

  • The combined character limitation for field name and field value is 990 characters
  • Dictionaries are not available for the Header fields

Sample email header rule using Basic syntax:

 

Header: Basic syntax

Name match expression:

Message-ID

Value match expression:

<d1234f1869fb3fb83bfd215319beb77c@www.contoso.com>

Interpretation:

Match when an email header contains "Message-ID: <d1234f1869fb3fb83bfd215319beb77c@www.contoso.com>"

Sample email header rule using RegEx syntax:

 

Header: RegEx syntax

Name match expression:

X-Mailer

Value match expression:

ContosoMailer\s\[version\s1\.73\]|PartnerContosoMailer1234

Interpretation:

Match when an email header contains the header "X-Mailer: ContosoMailer [version 1.73]" including whitespaces OR "X-Mailer: PartnerContosoMailer1234"

Email Sender match options allow you to specify the email addresses, IP addresses, or top-level domains to which the policy rule will apply. If you have many email addresses or domains that you want to use for this match option and do not want to enter them manually, use the Dictionary in the Filters tab to upload a list of email addresses or domains. This Dictionary can be reused for multiple policy rules. For details about how to use the Dictionary option, see Configuring Filters in FOPE.

 

Email part Match for Syntax Additional match option(s)

Sender

IP addresses

Basic/CIDR

Dictionaries

Sender

Domains

Basic/RegEx

Dictionaries

Sender

Email addresses

Basic/RegEx

Dictionaries

Limitations:

  • The combined character limitation for field name and field value is 990 characters.
  • For the Basic syntax, only valid IP addresses, domains and email address formats will be accepted.
  • For IP addresses, Classless Inter-Domain Routing (CIDR) notation of IP addresses is not supported in the same rule with wildcard (*) and question mark (?) metacharacters in Basic syntax. However, the comma as separator is accepted.

Sample email Sender rule using Basic syntax:

 

Sender IP addresses: Basic syntax

Match expression:

88.88.88.?, 99.99.*.1,

Interpretation:

Match the Address Range 88.88.88.0 - 88.88.88.9 OR the Address Range 99.99.0.1 - 99.99.255.1

Sample email Sender rule using CIDR syntax:

 

Sender IP addresses: CIDR syntax

Match expression:

99.99.99.0/24, 88.88.88.88/32

Interpretation:

Matching IP addresses equivalent to the subnet mask 255.255.255.0 resulting in match of 256 hosts for the CIDR Address Range 99.99.99.0 - 99.99.99.255 OR matching the CIDR Address Range 88.88.88.88 - 88.88.88.88 consisting of only one host.

Sample email Sender rule using RegEx syntax:

 

Sender domains: RegEx syntax

Match expression:

^contoso\.com$|test.*\.partner\.contoso\.com|\.info$

Interpretation:

Matching only the domain "contoso.com" (not any sub domains of this domain) OR the sub domain "test" followed by any characters (e.g. "test1"," test1234", "testabcd" and so on) of the domain "partner.contoso.com". OR matching the Top Level Domain (TLD) “.info”

Sample email Sender rule using Basic syntax:

 

Sender email address: Basic syntax

Match expression:

*@contoso.com, *@*.contoso.org

Interpretation:

Any email alias will be matched which have been sent from the domain "contoso.com" OR any email alias sent from the domain "contoso.org" and any sub domain of this domain.

A variety of policy rule actions apply to the Sender match option. You can use Inbound Policy Allow rules to safe-list an IP address, even if it is listed on the Reputation Block Lists (RBLs) that are used by the service. IP address ranges or CIDR formatted IP ranges will not bypass the RBLs, but will still apply for allowing messages from the IP range to bypass spam filtering.

If you have added a Policy Allow rule for an IP and the mail from that IP is still being rejected, the bounce message being sent back to the sending server has instructions that allow them to request or investigate the de-listing of their IPs. If you would like to follow up on their behalf, please have the sender provide you with a copy of the bounce message that they are receiving and contact Technical Support to have the Support Team investigate the reason for the rejection.

To see a chart outlining the various policy rule actions that apply to this match option, see Understanding Policy Rule Settings. For more information about the Basic and RegEx syntax options, see Understanding Policy Rule Syntax.

tipTip:
It is recommended that you use the FOPE connector feature if you want to configure FOPE to skip IP address filtering on inbound email sent from IP addresses specified in a safe list. You can also use this feature to configure FOPE to skip policy and spam filtering, and force TLS encryption on inbound email. For more information, see Inbound Safe Listing Scenario.

Email Recipient match options allow you to specify the email addresses or top-level domains to which the policy rule will apply.

 

Email part Match for Syntax Additional match option(s)

Recipient

Email addresses

Basic/RegEx

  • Dictionaries
  • Enable Opportunistic TLS for unspecified recipients
  • Apply rule even if the email message includes other recipients

Recipient

Domains

Basic/RegEx

  • Dictionaries
  • Enable Opportunistic TLS for unspecified recipients

Limitations:

  • The character limitation for any field is 9,000 characters.
  • For the Basic syntax, only valid domain and email address formats will be accepted.
  • Dictionaries: If you have many recipients and/or email addresses that you want to use for this match option and do not want to enter them manually, use the Dictionary option to upload a list. For details about how to use the Dictionary option, see Configuring Filters in FOPE.
  • Apply rule even if the e-mail message includes other recipients: If an email message contains other recipients besides the ones specified in the policy rule, then the policy rule will not be applied to that message at all; the policy rule will be skipped. However, if this check box is selected, the following actions will be performed:
    • This rule is automatically applied to all inbound messages. When an inbound rule is configured to match on recipients, the rule will match when the recipient is in the recipient list, even if there are other recipients for the message and the action will apply to the entire conversation. The Apply even if other recipients check box does not affect behavior for the rule. In this case, the rule is applied to inbound messages, even when there are other recipients and the check box is not enabled.
    • For Outbound Policy Rules, messages will not be bifurcated (except for the Force TLS or Opportunistic TLS option) and the policy rule action will be applied for all recipients of a message.
    • For Outbound Policy Rules, messages will be bifurcated if the FOPE policy rule is configured with the Force TLS action and Apply even if the email includes other recipients is selected. Force TLS is required only for domains specified in the rule.

     

    Policy Rule Apply rule even if the email message includes other recipients Email containing recipients
    noteNote:
    Example domains contoso.com and alpha.com are domains of the company, but acquisition.com is not.
    Rule Behavior

    Traffic Scope: Inbound
    Domain Scope: All domains
    Action: Reject
    Recipient e-mail address: a@contoso.com

    Not selected

    a@contoso.com

    Rule will be applied; message will be rejected.

    Traffic Scope: Inbound
    Domain Scope: All domains
    Action: Reject
    Recipient e-mail address: a@contoso.com

    Not selected

    a@contoso.com; b@contoso.com

    Rule will be skipped; all recipients will get the message.

    Traffic Scope: Inbound
    Domain Scope: All domains
    Action: Reject
    Recipient e-mail address: a@contoso.com

    Selected

    a@contoso.com; e@acquisition.com

    Rule will reject message to: a@contoso.com

    Traffic Scope: Inbound
    Domain Scope: All domains
    Action: Reject
    Recipient e-mail address: a@contoso.com

    Selected

    a@contoso.com;b@contoso.com;c@alpha.com ;e@acquisition.com

    Rule will reject messages to:a@contoso.com;b@contoso.comsince b@contoso.com belongs to the domain specified in the policy rule.

    Traffic Scope: Outbound
    Domain Scope: All domains
    Action: Reject
    Recipient e-mail address: e@acquisition.com

    Not selected

    e@acquisition.com

    Rule will be applied; message will be rejected.

    Traffic Scope: Outbound
    Domain Scope: All domains
    Action: Reject
    Recipient e-mail address: e@acquisition.com

    Not selected

    e@acquisition.com; b@contoso.com

    Rule will be skipped; all recipients will get the message.

    Traffic Scope: Outbound
    Domain Scope: All domains
    Action: Reject
    Recipient e-mail address: e@acquisition.com

    Selected

    e@acquisition.com; a@contoso.com; b@contoso.com; c@alpha.com

    Rule will be applied; message to all recipients will be rejected.

  • Enable Opportunistic TLS for unspecified recipients: If the box is unchecked, then outbound messages will not be bifurcated. This means that authenticated Transport Layer Security (TLS) will be enforced for the delivery of all recipients on the message, where any of the recipients match the Policy Filter rule and the recipient mail transfer agent (MTA) is configured to accepting TLS-based connections (including valid public certificates). If one of the recipients has an MTA that does not supporting TLS connections, then the message to this recipient will be rejected. Checking this box will still enforce authenticated TLS on the recipient who matches the rule, but also allows all other recipients to be transmitted using Opportunistic TLS if all attempts to enforce TLS fail. The Forefront Online Protection for Exchange service will always use the highest level of encryption available for transmission of the messages and if not available step down.
    Examples:

     

    Policy Rule Apply Opportunistic TLS for unspecified recipients Message Containing Recipients
    noteNote:
    Example domain acquisition.com supports TLS connections, and alpha.com does not.
    Rule Behavior

    Traffic Scope: Outbound
    Domain Scope: contoso.com
    Action: Force TLS
    Sender domain: acquisition.com

    Not selected

    c@acquisition.com; d@alpha.com

    Message to c@acquisition.com will be transmitted via TLS; message to d@alpha.com will be rejected, since alpha.com does not support TLS connections (or does not have a valid public certificate)

    Traffic Scope: Outbound
    Domain Scope: contoso.com
    Action: Force TLS
    Recipient domain: acquisition.com

    Selected

    c@acquisition.com;d@alpha.com

    Message to c@acquisition.com will be transmitted via TLS; message to d@alpha.com will be transmitted via SMTP (unencrypted channel)

To see a chart outlining all the policy rule actions that apply to this match option, see Understanding Policy Rule Settings. For more information about the Basic and RegEx syntax options, see Understanding Policy Rule Syntax.

The Attachment match option gives you the ability to specify email file extensions and names to which the desired policy rule action will apply. If you want to specify multiple file extensions or names for this option and do not want to enter them manually, use the Dictionary option to upload a list. For details about how to use the Dictionary option, see Configuring Filters in FOPE. Policy Rules shows an example of a policy rule that is based on an attachment match option.

 

Email part Match for Syntax Additional match option(s)

Attachment

File name (and extension)

Basic/RegEx

  • Dictionaries
  • Search files in compressed attachments

Attachment

File extension (only)

Basic/RegEx

Dictionaries

Limitations:

  • The character limitation for any field is 9,000 characters.
  • File extensions are not accepted with periods (.) in the Basic syntax match expressions.

Sample email Attachment rule using Basic syntax:

 

Attachment file extensions: Basic syntax

Match expression:

exe, bat, *gz

Interpretation:

All files in email attachments with the extension exe OR bat, OR all files whose extension ends with gz (e.g. gz OR tar.gz) will be matched.

Sample email Attachment rule using RegEx syntax:

 

Attachment file name: RegEx syntax

Match expression:

test.*\.tar\.gz

Interpretation:

All files in email attachments with the name and extension test.tar,gz OR test123.tar.gz OR testXXXXXX.tar.gz, and so on will be matched.

noteNote:
This field can match file name and field extensions.

Search files in compressed attachments: When you select this option, the Hosted Filtering service scans for specific extensions that may be located in a compressed file that is not password-protected. The service scans the following compressed extensions: amg, arc, arj, ark, b64, bhx, cab, gbz, gz, gzip, ha, jar, lbr, lha, lzh, lzw, pkzip, rar, tar, tgz, uu, z, zip, zlib.

noteNote:
This option does not apply to password-encrypted files. Password-protected zip files can be blocked or quarantined by adding zip+ to the list of file extensions to be filtered. Password-encrypted files will continue to come through unless you have inserted zip+ in the file extension filtering field to block password-protected zip files.

To see a chart outlining the various policy rule actions that apply to this match option, see Understanding Policy Rule Settings. For more information about the Basic and RegEx syntax options, see Understanding Policy Rule Syntax.

This match option allows you to match for words, phrases, patterns of letters or numbers in the message subject or message body. If you want to specify multiple words/phrases for this option and do not want to enter them manually, use the Dictionary option to upload a list. For details about how to use the Dictionary option, see Configuring Filters in FOPE. Policy Rules shows an example of a policy rule that is based on a message-subject match.

 

Match for Syntax Additional match option(s)

Subject

Basic/RegEx

  • Dictionaries
  • Exact match
  • Case sensitive match
  • Not match

Body

Basic/RegEx

  • Dictionaries
  • Exact match
  • Case sensitive match

Limitations:

  • The character limitation for any field is 9,000 characters.
  • The Not match exception option is only available for outbound encryption policy actions.
  • Outbound Allow rules are not supported for either Message Subject or Message Body.
  • Inbound Allow rules are not supported for words or phrases in Message Body.

Sample email Message Subject rule using Basic syntax

 

Message Subject: Basic syntax

Match expression:

casino, free, pill*, vi?gra

Interpretation:

All subject lines containing any of the words “casino” OR “free” OR “pill”, “pills”, “pills4free” and so on, OR the word “viagra”, “vi@gra”, and so on, will be matched.

Sample email Message Subject rule using RegEx syntax

 

Message Subject: RegEx syntax

Match expression:

\d\d\d\-\d\d\-\d\d\d\d|\d\d\d\s\d\d\s\d\d\d\d

\d\d\d\d\s\d\d\d\d\s\d\d\d\d\s\d\d\d\d|\d\d\d\d\s\d\d\d\d\d\d\s\d\d

Interpretation:

This will match 3 digits, a dash, 2 digits, a dash, and 4 digits. This will also match 3 digits, a space, 2 digits, a space, and 4 digits. These could be social security number patterns.

This will match 4 digits, a space, 4 digits, a space, 4 digits, a space, and 4 digits. This will also match 4 digits, a space, 6 digits, a space, and 2 digits. These could be credit card number patterns.

Sample email Body rule using RegEx syntax

 

Message Body: RegEx syntax

Match expression:

Starting.*Satisfaction.*Guaranteed

Interpretation:

This will match “Starting” AND “Satisfaction” AND “Guaranteed” in this exact order within the body of an email. All words needs to be present in an email in order to match. This will match, for example, the following body text: “Watches Starting at $15. Satisfaction Guaranteed” but will not match “Guaranteed Satisfaction, Watches Starting at $15.”

noteNote:
You can achieve the same effect with the Basic syntax by using the wildcard meta character.
  1. Case sensitive match: The policy rule engine will perform a case-sensitive match on emails based on the match expression specified in a policy rule.
    Example: “cAseSensitivE” will not match "CASESENSITIVE" if the Case sensitive match option was selected for this match expression. If Case sensitive match is de-selected, the match expression "cAseSensitivE" will match "CASESENSITIVE".
  2. Exact match: The policy filter will match expressions at its boundaries.
    Example: “This is a test” will not match “This is a test1234” OR “This is a perfect test” OR “123This is a test”. It will match exactly the phrase specified, but will not treat this expression as case-sensitive. In order to achieve this, both Exact match and Case sensitive match need to be selected.

To see a chart outlining the various policy rule actions that apply to this match option, see Understanding Policy Rule Settings. For more information about the Basic and RegEx syntax options, see Understanding Policy Rule Syntax.

Match criteria options for the message properties include the following options:

  • Executable content
  • Class ID extensions
  • Maximum number of recipients
  • Maximum size
  • Character sets

The Executable content check box blocks any file attachment that contains executable content (e.g. exe), regardless of file name or file type (e.g. if a .com file has renamed to .jpg). The file is analyzed by the virus filtering service to determine whether it is a binary executable type of content or is simply relying on the extension. If this option is selected, no binary executable files of any type will be allowed through the system if those files contain any active content that can be executed.

The Class ID extensions check box is recommended as a virus precaution. The Class ID (CLSID) tag is an extended HTML element that is used to describe the class of a viewable or downloadable document. It typically looks like the following: CLS ID: ABCD1234-AB12-12AB-AB12-ABCDEF123456. When used legitimately, it assists the browser in determining which plug-in, active component, or helper application should be used to handle a data object that is accessed over the Web. Some attachments can include a CLSID as all or part of the file-name extension and not show the full extension of the file when they are saved and viewed with Windows Explorer. This characteristic of the CLSID extension can be subject to misuse and can allow dangerous file types to look like simple, harmless files (such as JPG or WAV files) that do not need to be blocked. Using the CLSID extension for attachments may also circumvent attachment checking in some email policy filtering solutions that rely only on file-name extensions.

The Maximum number of recipients option specifies the maximum number of recipients to which inbound email messages can be sent. This number must be between 2 and 499. Currently, the network-wide recipient limitation for inbound or outbound email is 499 addresses.

The Maximum size option blocks sending and receiving messages over the specified number of megabytes (MB). The current network-wide size limitation on inbound and outbound messages is 150 MB. Therefore, any message that is 150 MB or greater is blocked by default. The overall message size is being managed by the rule, and not just the attachment size. Messages may be larger than expected when received because of encoding or large message bodies. Values should be entered in Kilobinary Bytes (KiB). For example, the setting to block messages larger than 20 MB is entered as 20,480 KiB. You can see an example of a policy rule that blocks messages over a specified size at Policy Rules.

The Character sets option matches character sets other than English. By matching a character set such as Cyrillic, the filter will match any messages sent to your domain that contains Cyrillic characters. If you create a policy rule to block a character set, this will affect all email sent that includes the specified character set, not just spam email. By default, all available character sets are allowed. You can see an example of a policy rule that shows how to block a non-English character set at Policy Rules.

 
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.