With my coffee currently in one hand, it would be very useful if I could type with only my other hand. Alas I cannot, so I’ll be typing this article with both hands while my coffee waits for me. With none of this at all being relevant to this blog, let’s dig in to this week’s EOP article.

We recently made a change to the behavior that takes place when a transport rule set the SCL on an inbound message. This behavior change is especially important to be aware of if you are setting the SCL with a transport rule in your own tenant. First off, let’s review EOP spam actions (trust me, this is relevant).

Spam Actions

In the EOP Content Filter, you can decide what happens to messages marked as Spam or High confidence spam.

If the content filter scans a message and assigns an SCL of 5 or 6, EOP will take the Spam action on the message. If the content filter scans a message and assigns an SCL of 9, EOP will take the High confidence spam action. All possible values are documented here.

With this understanding, let’s look at what’s changed.

What’s changed?

Previously, if a transport rule set the SCL of a message, the content filter WOULD NOT take the corresponding spam action (ie. If a transport rule set an SCL of 9 and the High confidence spam action was to move a message to the quarantine, the message would not be moved to the quarantine). Instead, as long as the SCL which was set by the transport rule was greater than your SCLJunkThreshold level, the message would be moved to the junk mail folder, regardless of what the EOP Spam or High confidence spam action was set to.

Note: For the action, Move message to Junk Email folder, to work with on-premises mailboxes, two rules need to be added to the on-premises mail environment.

With the new change that rolled out over the last couple of weeks, setting the SCL in a transport rule WILL cause the content filter to take the appropriate spam action. Personally, I think this is much more intuitive then how it previously worked. Setting the following SCL values in a transport rule will now take the noted actions.

• Bypass spam filtering – This sets the SCL to -1, which means that content filtering will not be performed.
  
  
• 0 to 4 – When you set the SCL to one of these values, the message will be passed along to the content filter for additional processing. See my previous article on this, Special Case – Set SCL to 0.
  
  
• 5, 6 – When you set the SCL to one of these values, the action specified for Spam in the content filter will be performed.
  
  
• 7 to 9 – When you set the SCL to one of these values, the action specified for High confidence spam in the content filter will be performed.
  
  

Bonus behavior

The above change also comes with a great bonus feature. Previously, when a transport rule was set to Deliver the message to the hosted quarantine, only admins could release these messages from the quarantine. These quarantined messages would not appear in End-user Spam Notifications nor would they appear in an end users online quarantine view. This meant that end users could never release messages on their own which had been quarantined by a transport rule. We can now get around this limitation!

If your Spam action or High confidence spam action is set to move a message to the quarantine, setting an SCL in a transport rule (to a value which will trigger either spam or high confidence spam) will cause the content filter to move the message to the quarantine. Messages moved to the quarantine this way will appear in End-user Spam Notifications as well as in the end users online Quarantine view. Sweet!

To quickly tell which messages in the quarantine will be viewable to end users, look at the Type property. Spam indicates that the message will be viewable in the end users online quarantine view and ESN which will allow them to release it. Whereas Transport rule indicates that the message won’t appear in an end users online quarantine view nor in an ESN and will only be releasable by an administrator.

Example

The following indicates that the quarantined message can only be released by administrators.

 

The following indicates that the quarantined message can be released by end users.

Resources

Spam confidence levels
Create a transport rule to identify mail as spam or not spam by setting the SCL
Create on-premises transport rules for Junk Email Folder to work
Special Case, Set SCL to 0
Release quarantined messages as an end user

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.

1. 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.
   
   
2. Create a rule that sets the SCL to 0 if the recipient is someone that is in the pilot group.
   
   
3. 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.

I just dropped my van off for some maintenance at the dealership and am currently waiting for a shuttle to take me to the office. As I sit here I’m thinking about EOP and PowerShell and have come up with a great idea for this week’s article. I don’t always think about EOP outside of work, but when I do, watch out! Already, let's dive in.

In my role I work with customers that are brand new to Exchange Online Protection and assist them in implementing and troubleshooting the service. Typically customers come from a 3rd party spam filtering service and have existing safe and block lists in place which they want to migrate over to EOP. If these lists are long, the process of adding them to EOP through the online portal can be very agonizing. Luckily, there’s an easier and quicker way to do this, PowerShell to the rescue! This article is going to focus on lists that are comprised of sender domains, but this script can easily be modified for specific senders.

Example

We have a list of domains we want to safe list in EOP. We may have an existing rule that we would like to append domains to, or we may need to create a new rule from scratch.

First off, create a .csv file containing all of the domains (one per line) that should be added to the safe list. Here’s what mine looks like.

Once this is created we can jump into PowerShell.

1. If there isn’t an existing transport rule then we’ll need to create one. Since we’re talking about PowerShell let’s use a cmdlet to accomplish this. If you already have a safe list transport rule then go straight to step #2.
   
   New-TransportRule –name SafeDomains –SetSCL -1
   
   The above will set the SCL to -1 (Bypass spam filtering) for messages that trigger this rule.
   
   
2. Now we need to add the domains that we want to safe list to this rule. The following script will work both for brand new rules and for existing rules. If you have an existing safe list rule, this script will append the new entries to those that already exist in the rule.
   
   $csvImport=Import-Csv .\SafeDomains.csv -header domains
   $rule = Get-TransportRule SafeDomains
   
   #create safeDomains as an array
   $safeDomains = @()
   
   if ($rule.SenderDomainIs -ne $null)
   {
   $safeDomains = $rule.SenderDomainIs
   }
   
   foreach($v in $csvImport.domains)
   {
   $safedomains += $v
   }
   
   set-TransportRule SafeDomains -SenderDomainIs $safeDomains

That’s it! Here’s how my rule looks in the portal.

 
To create a block list, change the action above to how you would like EOP to handle messages that are received from the blocked domains (ex. delete message, move to quarantine, set a high SCL, etc…).

Connecting to PowerShell is quite easy, but often people need just a little push in the right direction with a sample script to get really moving on their own. It reminds me of this saying.

Give a person a fish and you feed them for a day. Teach a person to fish and you feed them for a lifetime.

Happy scripting!

Resources

Exchange Online PowerShell
Exchange Online Protection PowerShell

Note: If you have Exchange Online licenses (which include EOP), use the first link. If you have Exchange Online Protection licenses, use the second link.

Before I start I would like to call out that I think this is the best blog title that I have come up with to date. Surprisingly, or maybe not, I thought of this title and article while I was playing Ultimate Frisbee. My mind was obviously not in the game, and we did lose... anyways, let’s move on and figure out what I’m talking about with the title.

When your domains are added to Office 365 you will be presented with the MX record that will need to be set for them in DNS. Each domain will be given a slightly different and unique MX record. For example, if we added contoso.com to our tenant, Office 365 would probably (but not necessarily) give us the following MX record to add to the DNS for this domain.

contoso-com.mail.protection.outlook.com

Now let’s consider the situation where a lot of domains have been added to Office 365. Again, each of these domains will have been given a unique MX record by Office 365. You can get these unique records either one at a time through the Office 365 Portal, or you can pull them all at once using PowerShell. Once you have obtained all the unique MX records, you then will need to set each in DNS and hope you don’t make a typo.

To make things easier, you can use a single MX record for every single one of the domains that you have added to your Office 365 tenant! Great!!

Now, what is this one MX to rule them all? It can actually be the MX that is provided for any one of your domains. Continuing on with my above example, I have my Office 365 tenant and I have added both contoso.com and tailspintoys.com. Office 365 has indicated that the MX for contoso.com should be set to the following.

contoso-com.mail.protection.outlook.com

I can use this MX record for tailspintoys.com, even though Office 365 will have provided this domain its own unique MX record. Any additional domains I add to my tenant can also be configured with this same MX record.

The important part is that you are using a single Office 365 tenant. The MX record that you obtain needs to be from a domain that in in the same Office 365 tenant as all the other domains that will use this same MX.

Warning

In the above example, if you ever remove contoso.com from your tenant, the contoso-com.mail.protection.outlook.com MX record will stop working. So, if you want to use one MX for all your domains, use the MX from a domain that you will never delete from your tenant. Or better yet, use the MX from your default <InsertName>.onmicrosoft.com domain.

With the example above, the default domain was contoso.onmicrosoft.com. Perform an MX lookup on this and it currently returns the following.

contoso.mail.protection.outlook.com

This FQDN, contoso.mail.protection.outlook.com, can be used as the MX record for every domain that is added to this Office 365 tenant. If this tenant also has an on-premises mail environment that is smart hosting outbound mail to EOP, this same FQDN can be used as the smart host.