Forum Discussion
Weird behavior of Exchange Online for none-existing email address
- Jack_Chen1780 - This behavior is expected. The DBEB functionality can reject on either RCPT TO or on "End Of Data". The latter happens when the sending IP is shared between multiple tenants, and in order for EOP to correctly attribute to the recipient tenant, we need to traverse the headers which are available only after EoD.
MicrosoftYou mentioned "when it is connected to EOP, before the "RCPT TO", there isn't any data indicating which EOP tenant it wants to send email." - This is not correct. The connecting f IP Address can be mapped to a tenant based on Inbound connector created. You have an Azure VM with public IP 20.48.254.109, and most probably no one has any Inbound connector created to accept email from that IP Address, that's why there is no confusion. But if the IP address is widely used, then it's not that simple. Thats why we need to wait till EOD and see all the headers to make sure we are rejecting an Invalid address properly.
If this is the issue, I can check with Fortinet if they can provide us a dedicated outbound IP. Currently this configuration will cause we exceed Fortimail user license and although they haven't restricted it yet, Fortmail support mentioned they will restrict it in future release, so we need to figure out a way to make sure it's working.
- Arindam_Thokder
Jack_Chen1780 - Dev tenants were used to relay phish emails through EXO using Inbound connector. Because of this misuse, we had to other way but to restrict that.
BTW, EOP doesn't allow Dev tenants to setup incoming connector now: https://techcommunity.microsoft.com/t5/exchange/exchange-online-connector-creation-failed/m-p/3624401
Can someone reason with Microsoft we need to test stuff in dev tenant 😞Thanks Arindam_Thokder and VasilMichev . With your help, I was able to verify EOP's behavior and find a solution.
The blog link send by Arindam provided the information I need.
I have confirmed EOP will behave this way:
1. if the sender IP is not included in any tenant's incoming connector, the message is considered as Incoming, and "RCPT TO" will work as expected for any receipt email address.
2. If the sender IP is include in one or more tenant's incoming connector, the message is considered as Originating and things are getting more interesting.
For originating message, if the "mail from" and "rcpt to" email address match one of the setup incoming connector, then "rcpt to" will work as expected. If either of the "mail from" or "rcpt to" doesn't match the tenant's email, "rcpt to" will always return 250.
So to fix the problem, I will need to create a incoming connector in my tenant with the IP from Fortimail, then change Fortimail 's "Recipient address verification" from "use system setting" to "use domain setting".
So
mail from:noreply @ my email domain .com
rcpt to:my email domain .com
will work as expected ( return 550).
mail from: noreply @ Fortinet .com
rcpt to:my email domain .com
won't work.- Arindam_ThokderJack_Chen1780- Sure, while creating connector, make sure it's of type "Onpremises" and not "Partner".