Home

Exchange Hybrid centralized email flow bypass issue

%3CLINGO-SUB%20id%3D%22lingo-sub-184332%22%20slang%3D%22en-US%22%3EExchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-184332%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20deployed%20the%20Exchange%20hybrid%20scenario%20where%20all%20emails%26nbsp%3Breceived%20from%20Internet%26nbsp%3Bget%20filtered%20through%20an%20on-premises%20Spam%20appliance.%26nbsp%3B%20MX%20records%20are%20pointing%20to%20on-premises%20Spam%20appliance%26nbsp%3Bso%20the%20email%20flow%20is%20as%20follows%3A%20Email%20from%20Internet%20-%26gt%3B%20on-premises%20Spam%20Appliance%20-%26gt%3B%20on-premises%20Exchange%20Server%20-%20%26gt%3B%20on-premises%26nbsp%3B%20Hybrid%20Server%20-%26gt%3B%20Exchange%20Online%20mailbox.%26nbsp%3B%20Exchange%20Online%20has%20an%20Inbound%20connector%20to%20verify%20incoming%20emails%20from%20Exchange%20Hybrid%20by%20checking%20the%20SSL%20certificate.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAll%20runs%20well%20as%20long%20as%20the%20sender%20uses%20the%20MX%20records%20to%20send%20through%20on-premises%20Spam%20appliance%2C%20but%20how%20about%20the%20scenario%20where%26nbsp%3Bthe%20sender%20(let's%20call%20him%2Fher%20%22Spammer%22)%20connects%20directly%20to%20EOP%20service%20port%2025%20and%20starts%20sending%20messages%20to%20Exchange%20Online%20users%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIt%20looks%20like%20EOP%20is%20%22happy%22%20to%20accept%20those%20messages%20from%20Internet%20and%20sends%20them%20to%20on-premises%20Exchange%20Hybrid%20server%20that%20just%20relays%20them%20back%20to%20Exchange%20Online.%20The%20new%20email%20flow%20is%26nbsp%3BEmail%20from%20Internet%20-%26gt%3B%20Exchange%20Online%20EOP-%26gt%3B%20on-premises%26nbsp%3B%20Hybrid%20Server%20-%26gt%3B%20Exchange%20Online%20mailbox.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20question%20is%20how%20to%20block%20EOP%20from%20accepting%20these%20messages%20in%20the%20first%20place%3F%20As%20far%20as%20I%20can%20see%20in%20Exchange%20Online%2C%20we%20can't%20define%20an%20%22Internet%22%20connector.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAlso%2C%20what%20is%20the%20point%20of%20doing%20a%20SSL%20cert%20check%20on%20Hybrid%20connector%20if%20EOP%20is%20relaying%20Internet%20messages%20through%20Exchange%20Hybrid%20therefore%20with%20no%20security%20or%20validation.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EScenario%20described%20can%20be%20easily%20validated%20by%20doing%20a%20telnet%20to%20a%20EOP%20server%20(e.g.%20mail-to1can010042.inbound.protection.outlook.com%20)%20on%20port%2025%20and%20sending%20a%20message%20manually.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-184332%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EExchange%20Online%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EExchange%20Server%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EHybrid%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-207478%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-207478%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20created%20a%20transport%20rule%20which%20intercepted%20messages%20with%20%22onmicrosoft.com%22%20in%20the%20%22to%22%20header%20and%20rejected%26nbsp%3Bthem%20with%20the%20status%20code%205.7.1%20except%20if%20the%20sender%20IP%20address%26nbsp%3Bbelonged%20to%26nbsp%3Bour%20on-premises%20SMTP%20gateways%20or%20if%20the%20sender%20was%26nbsp%3Bin%20our%20organization's%20smtp%20domain.%20This%20stops%26nbsp%3Bunknown%20senders%26nbsp%3Bsending%20in%20'directly'%20to%20our%20EOL%20mailboxes.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-187311%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-187311%22%20slang%3D%22en-US%22%3E%3CP%3EOk%20but%20remember%20connectors%20are%20cumulative%2C%20all%20you%20are%20doing%20here%20is%20adding%20additional%20ways%20to%20receive%20and%20not%20restricting%20anything%20as%20per%20your%20original%20question.%3C%2FP%3E%3CP%3EYou%20need%20to%20do%20something%20with%20the%20original%20connector%20that%20is%20accepting%20internet%20mail.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-186808%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-186808%22%20slang%3D%22en-US%22%3E%3CP%3EI%20did%20not%20get%20a%20chance%20to%20test%20the%20change%20but%20please%20take%20a%20look%20at%20this%20link%20that%20provides%20a%20different%20solution%20for%20exactly%20the%20same%20scenario%20%3CA%20href%3D%22https%3A%2F%2Fo365info.com%2Fconfigure-exchange-online-inbound-mail-flow-to-accept-smtp-connection-only-from-a-specific-mail-security-gateway-ip-address%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fo365info.com%2Fconfigure-exchange-online-inbound-mail-flow-to-accept-smtp-connection-only-from-a-specific-mail-security-gateway-ip-address%2F%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-186753%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-186753%22%20slang%3D%22en-US%22%3E%3CP%3EDid%20this%20resolve%20your%20issue%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-185898%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-185898%22%20slang%3D%22en-US%22%3E%3CP%3EI%20believe%20this%20needs%20to%20be%20set%20to%20true%20else%20this%20is%20just%20accepting%20any%20email%20as%20long%20as%20its%20TLS%2C%20you%20will%20need%20to%20test%20as%20much%20as%20possible%20because%20im%20not%20sure%20how%20this%20will%20handle%20the%20wildcard.%20See%20the%20value%20settings%20below.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fpowershell%2Fmodule%2Fexchange%2Fmail-flow%2Fnew-inboundconnector%3Fview%3Dexchange-ps%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fpowershell%2Fmodule%2Fexchange%2Fmail-flow%2Fnew-inboundconnector%3Fview%3Dexchange-ps%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-185890%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-185890%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20still%20have%20users%20on-premises%20so%20we%20do%20not%20want%20to%20do%20Spam%20scanning%20for%20Internal%20emails%20between%20Office365%20users%20and%20Exchange%20on-premises%20users.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-185888%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-185888%22%20slang%3D%22en-US%22%3E%3CP%3EPlease%20see%20command%20output.%20Note%20that%20I%20have%20a%20domain%20set%20under%20%22TlsSenderCertificateName%22%20but%20I%20now%20see%20that%20%22RestrictDomainstoCertificate%22%20is%20set%20to%20%22False%22%2C%20is%20this%20the%20option%20to%20change%20to%26nbsp%3Bonly%20accept%20emails%20from%20Hybrid%20Exchange%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-185870%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-185870%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20inbound%20connector%20should%20be%20locked%20down%20depending%20on%20what%20you%20entered%20into%20the%20hybrid%20wizard%2C%20can%20you%20post%20the%20output%20of%20get-inboundconnector%20%7C%20fl%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-184371%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%20Hybrid%20centralized%20email%20flow%20bypass%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-184371%22%20slang%3D%22en-US%22%3E%3CP%3ESo%20point%20the%20connector%20to%20your%20Spam%20appliance%3F%20Or%20am%20I%20missing%20something%20here%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E
Mirel Popa
Occasional Contributor

We have deployed the Exchange hybrid scenario where all emails received from Internet get filtered through an on-premises Spam appliance.  MX records are pointing to on-premises Spam appliance so the email flow is as follows: Email from Internet -> on-premises Spam Appliance -> on-premises Exchange Server - > on-premises  Hybrid Server -> Exchange Online mailbox.  Exchange Online has an Inbound connector to verify incoming emails from Exchange Hybrid by checking the SSL certificate.

 

All runs well as long as the sender uses the MX records to send through on-premises Spam appliance, but how about the scenario where the sender (let's call him/her "Spammer") connects directly to EOP service port 25 and starts sending messages to Exchange Online users?

 

It looks like EOP is "happy" to accept those messages from Internet and sends them to on-premises Exchange Hybrid server that just relays them back to Exchange Online. The new email flow is Email from Internet -> Exchange Online EOP-> on-premises  Hybrid Server -> Exchange Online mailbox.

 

The question is how to block EOP from accepting these messages in the first place? As far as I can see in Exchange Online, we can't define an "Internet" connector.

 

Also, what is the point of doing a SSL cert check on Hybrid connector if EOP is relaying Internet messages through Exchange Hybrid therefore with no security or validation. 

 

Scenario described can be easily validated by doing a telnet to a EOP server (e.g. mail-to1can010042.inbound.protection.outlook.com ) on port 25 and sending a message manually.

9 Replies

So point the connector to your Spam appliance? Or am I missing something here?

The inbound connector should be locked down depending on what you entered into the hybrid wizard, can you post the output of get-inboundconnector | fl

Please see command output. Note that I have a domain set under "TlsSenderCertificateName" but I now see that "RestrictDomainstoCertificate" is set to "False", is this the option to change to only accept emails from Hybrid Exchange?

We still have users on-premises so we do not want to do Spam scanning for Internal emails between Office365 users and Exchange on-premises users. 

I believe this needs to be set to true else this is just accepting any email as long as its TLS, you will need to test as much as possible because im not sure how this will handle the wildcard. See the value settings below.

 

https://docs.microsoft.com/en-us/powershell/module/exchange/mail-flow/new-inboundconnector?view=exch...

Did this resolve your issue?

I did not get a chance to test the change but please take a look at this link that provides a different solution for exactly the same scenario https://o365info.com/configure-exchange-online-inbound-mail-flow-to-accept-smtp-connection-only-from...

 

Ok but remember connectors are cumulative, all you are doing here is adding additional ways to receive and not restricting anything as per your original question.

You need to do something with the original connector that is accepting internet mail.

We created a transport rule which intercepted messages with "onmicrosoft.com" in the "to" header and rejected them with the status code 5.7.1 except if the sender IP address belonged to our on-premises SMTP gateways or if the sender was in our organization's smtp domain. This stops unknown senders sending in 'directly' to our EOL mailboxes.