Daisy Chaining with EOP

Update Dec 23, 2014 – I’ve revised this article to make a couple of points clearer. On the mail flow side there are no issues with daisy chaining. However, if the intent is to evaluate the effectiveness of EOP filtering, having a service sit in front of EOP will not allow EOP to show it's full abilities.

Daisy chaining filtering services is something I often see as a temporary configuration when an organization is transitioning from a previous filtering solution to Exchange Online Protection. I also see this when customers are testing EOP and don’t want to take their previous filtering solution out of the mail loop. Here’s what mail flow looks like in these situations.

Daisy chaining services with EOP in this manner is a fine, however there are some important behavioral changes with EOP that you’ll need to be aware of. On the mail flow side this setup is fine, however if the intent is to test EOPs Spam filtering abilities, you won’t get the full picture of EOPs abilities unless your MX is pointed directly towards EOP.

Why you ask? Great question, and in the next section we will dive into the technical reasons behind this.

How Daisy Chaining Effects EOPs Filtering Abilities

EOP evaluates the connecting IP of all messages that are received. The IP is evaluated against the IPs in the tenants Connection Filter along with IPs that are on Microsoft’s safe and block lists.

Here’s the important part, EOP will only evaluate the connecting IP for these checks. For example, you have added 1.1.1.1 to the Blocked List in the IP Connection Filter. A message is inbound from 1.1.1.1 and first arrives at the Third Party Filtering Service, this service then relays the message to EOP. EOP will only see the IP of the Third Party Filter Service because this is the connecting IP. EOP will not see the originating IP of the message and so won’t block it based on entry of 1.1.1.1 in the blocked list in the connection filter.

Another scenario where this is impacted

Consider the following mail flow.

This is typical for customers that have an on-premises spam filtering solution, but are slowly moving mailboxes to Exchange Online. In this scenario, the end goal is to have their MX record pointing towards Exchange Online, but initially this is usually what mail flow looks like. For inbound mail, if the recipient mailbox in on-premises it’s delivered directly, and if it’s in the cloud, on-premises will relay it to the cloud.

In this scenario, on-premises mailboxes are obviously not protected by EOP, but cloud based mailboxes are. For Exchange Online mailboxes, you still lose EOPs IP based edge blocks. In this scenario, EOP will only ever see the connecting IP, which is the IP of the on-premises mail environment, so any IP based evaluations, EOP will be evaluating the on-premises IP and not the originating IP.

Edge Blocking Stats

Even for customers that don’t populate the Connection Filter, EOP identifies a large amount of spam based on the connecting IP, and when you put a hop in front of EOP, you lose out on this ability. EOP maintains an IP block list that will always apply at our edge (unless you have white listed the IP in the connection filter). This IP block list is a combination of a list that we maintain, along with third party lists that we subscribe to.

Consider the following slide which I showed in my EOP presentation at TechEd North America this year.

The numbers in this slide are only averages and change month to month. However, you can see that EOP does a large amount of spam identification based on the originating IP. When you introduce a hop in front of EOP, you lose out on this IP based spam detection. Hence, unless your MX is pointed directly towards EOP, you won’t be seeing the full power of the service.

Real world example

I worked with a customer that had the mail flow I described at the start of this article.

Internet --> Third Party Spam Filter --> Exchange Online

This was a temporary configuration, but in this setup their cloud mailboxes were seeing a large amount of spam arriving in their inboxes. I had them send me twenty examples of spam messages that had been missed by EOP. Out of the twenty submissions, 18 had originated from IPs on our block list which weren’t detected because of the hop in front of EOP. The number of spam messages slipping through EOP decreased greatly once the MX was changed to point towards EOP.

In this situation, the customer had disabled filtering on their third party spam filter and was relying on EOPs filters. The problem was that EOP was unable to filter out spam based on the sending IP.

Summary

On the mail flow side there is nothing wrong with daisy chaining services with EOP. Be aware though that if your intent is to evaluate the effectiveness of EOP, you should point your MX directly towards EOP otherwise you won’t see the full power of the product.