Update (August 28, 2014) - Setting the SCL with a transport rule to anything from 0 to 4 will cause the behavior that is described in this article.
This is a scenario I’ve wanted to write about for some time now as it isn’t very intuitive. When a transport rule has an action to set the SCL to 0, this is actually a special case where the outcome is probably not what you would think. Setting the SCL to 0 with a transport rule will cause EOP to scan the message with the spam filter, even if the message was safe listed earlier on in the processing (i.e. By the connection filter). This rule action is not required very often, but in certain scenarios this functionality is extremely useful.
First off, let’s take a look at what one of these rules looks like. The action will be Modify the message properties --> set the spam confidence level (SCL).
Next we choose “0” for the SCL level.
Great, we have now created a rule to set the SCL to 0! Now, when this rule triggers it will cause EOP to scan a message with the spam filter, even if the message was safe listed earlier on in the processing. Let’s look at some scenarios where you would want to create a rule like this.
We have a hybrid mail environment where mailboxes exist both in the cloud and on-premises. The MX record is pointing towards on-premises and mail is relayed to the cloud from on-premises if that is where the mailbox exists. This hybrid setup does not have rich co-existence and incoming mail flow looks as follows.
There are two scenarios here for incoming mail and we want EOP to behave differently for each. For messages that originate from the Internet and are destined for a cloud mailbox, we want EOP to scan these messages for spam. However, when an internal mailbox on-premises sends to an internal mailbox in the cloud, we do not need EOP to scan these for spam as there is a chance one of these messages could be falsely marked as spam.
A common way to do this would be to safe list the on-premises IP in EOP. This is done through the connection filter.
This will cause all messages that route through on-premises to skip spam filtering in EOP (VERY IMPORTANT NOTE: this is because the connection filter only evaluates the connecting IP and not the originating IP). However, we only want messages that originate from an on-premises mailbox which are destined to a cloud mailbox to skip spam filtering.
There are a few things we can do here, but consider this. Have the on-premises environment tag all messages that originate from an on-premises mailbox with an X-Header, for this example let’s use X-InternalMessage: True. Now we can create the following rule in EOP.
Let’s take a step back and look at what we’ve done. All messages routing through or originating from the on-premises mail environment which are destined to the cloud will be safe listed by our connection filter (remember we added 188.8.131.52 to the connection filter and remember that the connection filter only evaluates the connecting IP when mail is received). The above rule will set the SCL to 0 for all messages unless they have been stamped on-premises with the X-InternalMessage: True header. This means that all messages that originate from the Internet will have their SCL re-set from -1 to 0 which will cause them to be scanned by the spam filter. Whereas messages that originate on-premises will retain the SCL of -1 from the connection filter and skip the spam filtering.
One last example where I see this used is with organizations that have an existing 3rd party spam filtering service and want to trial EOP for a pilot group of users. Here is what incoming mail flow will typically look like in these setups.
Internet --> 3rd party spam filtering solution --> EOP --> On-premises mailbox
In this scenario the organization will want their 3rd party solution active and EOP to act as a pass through, unless mail is destined for a user in the pilot group. In which case the 3rd party system would act like a pass through and EOP would be active.
Keep in mind that in this scenario you won’t see the full picture of EOP. This is because you miss out on IP based edge blocks because EOP only evaluates the connecting IP, and here EOP will only ever see the IP of the 3rd party spam filtering solution. You also cannot turn off the malware scanning in EOP. With that being said, this is often enough for a company to trial EOP with the understanding that they won’t be seeing the full picture.
You now understand this special case!
Check out “Scoping an IP Allow list exception for a specific domain” here.