Special Case, Set SCL to 0
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.
Example 1
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 1.1.1.1 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.
Example 2
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.
Add the IP of the 3rd party filtering service to the IP allow list in the connection filter. This will safe list all messages coming in to EOP from this device.
Create a rule that sets the SCL to 0 if the recipient is someone that is in the pilot group.
Third have the 3rd party spam filtering solution skip spam filtering for mail destined to a user in the pilot group.
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.
Congratulations
You now understand this special case!
Resources
Check out “Scoping an IP Allow list exception for a specific domain” here.
Comments
- Anonymous
January 01, 2003
Awesome, thanks - Anonymous
August 28, 2014
With my coffee currently in one hand, it would be very useful if I could type with only my other hand - Anonymous
April 21, 2016
great stuff thanks - Anonymous
November 28, 2017
I love this and want to adapt it for our tenant. What are some current header values that are like "X-InternalMessage: True"? I don't see that in our headers.- Anonymous
November 28, 2017
OIC, we create the header in a different transport rule. But is there something else that is already in there that will tell us that?- Anonymous
February 09, 2018
Hi Karen, if you are looking to identify messages coming from on-prem, you could either look at the sending IP, or look for X-MS-Exchange-Organization-AuthAs: Internal, although this header will be on internal Exchange Online to Exchange Online mailboxes as well. I would recommend just adding a header on-prem and then looking for it with a transport rule in Exchange Online.
- Anonymous
- Anonymous