Compartilhar via

Inbound Connector Configuration You’ll Want to Avoid

  • Artigo

I recently worked with a customer who had a configuration in their EOP outbound connector that broke inbound mail for a newly added domain. I want to share this tale in hopes that you not only learn more about EOP partner connectors, but that you decrease the change of breaking your own mail flow. So grab your favourite caffeinated beverage, tilt back in your office chair, and read along.

To begin, let’s first look at what the inbound mail flow looks like.

It is against best practices to daisy chain services like this (ie. Pointing your MX towards a 3rd party filtering service which then relays to EOP). I won’t get into the disadvantages of this setup here but will write about it soon. For EOP to accept mail from the 3rd Party spam filter, the following connector was created in Office 365 (note: this connector is actually not required in this situation, more on this further down in the article).

General tab

Security tab

Scope tab

Mail flow with this setup worked fine. The MX records for all accepted domains pointed towards the third party filtering service, and the IP in the Partner Connector is the IP that this 3rd party service used to relay the message to EOP.

Everything was perfect… until a new domain was added, let’s use contoso.com to protect the innocent. The MX record for contoso.com was set to point towards EOP and not the third party filtering service (the plan was to have all MX records pointed towards EOP, but this had not yet happened, except for contoso.com). All mail sent to contoso.com would be directed to EOP, which would result in an NDR (sent from EOP) back to the sender which included the following error.

BN1BFFO11FD051.mail.protection.outlook.com gave this error:
Relay Access Denied ATTR1

Your message wasn't delivered due to a permission or security issue. The address may only accept email from certain senders or another restriction may be preventing delivery. For more tips to resolve this issue see DSN code 5.7.1 in Exchange Online. If the problem continues contact your help desk.

This is certainly not an ideal situation, unless of course you don’t want anyone to email you.

What’s happening here?

How come EOP is rejecting inbound mail which is destined for contoso.com? Let’s take a look back at the EOP partner connector. Two things here, this connector has the following configuration.

  • Connector type: Partner
  • Domain restrictions: Restrict domains by IP addresses
  • Sender domains: *

All externally originating mail that comes in to EOP will hit this connector because the type is set to partner and the sender domain is set to *. This connector will then check if the message came from the IP(s) listed in the “sender IP addresses” field of this connector and if there is not a match then EOP will reject the message. For mail that was being relayed from the 3rd party filtering service everything was fine because the IP of this service was in the partner inbound connector. For mail that arrived from a different IP, EOP would reject the message, as was the case with contoso.com because the MX for that domain was pointed directly at EOP.

The solution

In this particular case there were two options if this connector was going to remain enabled. Either set the Domain Restrictions to None, or remove the * from Sender domains and manually type the domains in. Since this connector is picking up all inbound mail, typing in all the domains on the Internet is not exactly an option. Instead, we need to remove the Domain Restrictions on this inbound connector and set this option to none.

Typically Partner Inbound connectors are used to force TLS with a subset of domains so it is very rare to see both an IP Address restriction along with a * for the sender domains. In this scenario, a connector in EOP DOES NOT need to be created to accept mail from the Internet as EOP will accept all mail destined for your domain. This particular customer had created this connector to work around an issue in EOP which has since been fixed.

References

Configure custom mail flow by using connectors
Inbound and Outbound connector FAQ
Decide which connector to use (great article with examples)

Comments

  • Anonymous
    January 01, 2003
    Hi Chad, your right in that this is a rare situation, but one that I've seen multiple times which is why I wanted to write about it.

    As for using a 3rd party spam filter in front of EOP, see http://blogs.technet.com/b/eopfieldnotes/archive/2014/09/11/best-practice-don-t-daisy-chain-filtering-services.aspx. From the mail flow side this is totally fine. The reason that it is not recommended is that EOP detects a large amount of spam based on the sending IP. EOP only looks at the connecting IP, meaning that if a 3rd party filter is in front of EOP, then EOP will only ever see the IP of the 3rd party and never the original IP, thus hindering it's ability to detect spam. If you are very confident in the 3rd party filter then this is a fine situation, just be aware that if the 3rd party misses a piece of spam, EOP might as well, but if the 3rd party was not there EOP may have blocked the messaged based on the sending IP.

    It all depends on what you want to do.
  • Anonymous
    December 08, 2014
  1. Why is having a 3rd party spam filter not a best practice?
    2. If you DO use this configuration, why would you not want to restrict mail to only come from the spam solution?

    Wouldn't the correct solution have been to point mx records for all accepted domains pointed towards the third party filtering service. Or none? Your solution seems like a temporary fix for a rare situation...
  • Anonymous
    July 23, 2015
    If someone is willing to pay extra for a third party filter, they probably aren't all that concerned about the EOP reputation being broken, but it is good to point this out.
  • Anonymous
    April 10, 2017
    Thought I'd add in on the second question. If your spam/threat protection solution is also providing extra protection via things such as url rewriting etc you any wouldn't want anyone bypassing your 3rd party solution and delivering phishing emails with links you can't easily block. I have told people consistently that you are unable to lock this down to your 3rd party provider so I'm happy to wrong about this... but yet to confirm for myself :)