Forum Discussion
Solved
Weird behavior of Exchange Online for none-existing email address
I am see a weird behavior of Exchange Online for none-existing email address, wondering if anyone can explain it. I am setting up a Fortimail Cloud service ( third party email protection service ...
- 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.
Thanks Arindam! Your answer helped me to understand a little more of the behavior.
By "sending IP", do you mean there is a "front-end" EOP server and work like :
like "smtp client" -> EOP front-end IP shared between tenants ( sending IP ? ) -> different servers for different tenants?
I can see many (if not all) EOP Canada server share same two IPs currently:
104.47.75.228
104.47.75.164
I am still confused why when testing from a Azure VM to 104.47.75.164, "RCPT TO" is working perfectly for multiple tenant's email addresses; but when testing from Fortimail to same 104.47.75.164, "RCPT TO" doesn't work as expected at all.
I guess the front-end server might have rules :
If the smtp client IP is a known high traffic SMTP servers, don't check with backend tenant server and just accept "RCPT TO" and verify later ;
if it's a unknown client IP, verify the address in "RCPT TO" step with backend tenant servers.
By "sending IP", do you mean there is a "front-end" EOP server and work like :
like "smtp client" -> EOP front-end IP shared between tenants ( sending IP ? ) -> different servers for different tenants?
I can see many (if not all) EOP Canada server share same two IPs currently:
104.47.75.228
104.47.75.164
I am still confused why when testing from a Azure VM to 104.47.75.164, "RCPT TO" is working perfectly for multiple tenant's email addresses; but when testing from Fortimail to same 104.47.75.164, "RCPT TO" doesn't work as expected at all.
I guess the front-end server might have rules :
If the smtp client IP is a known high traffic SMTP servers, don't check with backend tenant server and just accept "RCPT TO" and verify later ;
if it's a unknown client IP, verify the address in "RCPT TO" step with backend tenant servers.
Arindam_Thokder
Microsoft
MicrosoftJack_Chen1780 - Hello Jack, by sending IP, I meant the IP that connects to EOP. The Fortimail IP address must be shared between many tenants and not a dedicated for you. If it's a dedicated IP Address, then you might have an On-premises type connector from that IP Address in your tenant. You can try by deleting the connector or changing the connector type to Partner to see if the behavior changes. But this won't change anything if the Fortimail IP Address is shard.
- I am more confused now 😞
EOP should allow any sending IP send emails to any tenants. I don't think you have a way to identify a sending IP belong to a particular tenant.
For example, I have a Azure VM with public IP 20.48.254.109. when I use it to connect to EOP Canada VIP 104.47.75.164 :
telnet 104.47.75.164 25
Trying 104.47.75.164...
Connected to 104.47.75.164.
Escape character is '^]'.
220 YT3CAN01FT005.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Thu, 29 Sep 2022 13:29:17 +0000
helo test.com
250 YT3CAN01FT005.mail.protection.outlook.com Hello [20.48.254.109]
mail from:email address removed for privacy reasons
250 2.1.0 Sender OK
rcpt to:email address removed for privacy reasons
550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [YT3CAN01FT005.eop-CAN01.prod.protection.outlook.com]
rcpt to:email address removed for privacy reasons
250 2.1.5 Recipient OK
quit
telnet 104.47.75.164 25
Trying 104.47.75.164...
Connected to 104.47.75.164.
Escape character is '^]'.
220 YT3CAN01FT013.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Thu, 29 Sep 2022 13:30:57 +0000
helo test.com
250 YT3CAN01FT013.mail.protection.outlook.com Hello [20.48.254.109]
mail from:email address removed for privacy reasons
250 2.1.0 Sender OK
rcpt to:email address removed for privacy reasons
550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [YT3CAN01FT013.eop-CAN01.prod.protection.outlook.com]
rcpt to:email address removed for privacy reasons
250 2.1.5 Recipient OK
quit
221 2.0.0 Service closing transmission channel
I don't believe EOP has any way to identify 20.48.254.109 belong to a tenant; when it is connected to EOP, before the "RCPT TO", there isn't any data indicating which EOP tenant it want to send email. Yet EOP can still correctly response with 500 or 250 for multiple tenants.
The problem is when I do exact same test from Fortimail Cloud 154.52.4.131 , EOP only response with 250.
EOP Canada is treating sending IP 154.52.4.131 and 20.48.254.109 differently.- Arindam_ThokderJack_Chen1780- I think you got confused by the line "The Fortimail IP address must be shared between many tenants and not a dedicated for you". Let me try to explain - Some IP Addresses of servers/devices are shared and used to send to multiple tenant (and by this line, I am not trying to say that the IP belongs to a particular tenant). Some tenant can create an inbound connector (of type on-premises or partner) to accept email from that IP, sometime multiple tenants can create Inbound connector from same IP Address as the sending IP is shared and that can cause issue with attribution. It's not as simple as just RCPT TO. I suggest you read the techcommunity blog to know about that- https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143
You 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.- Thanks for the detailed explanation Arindam! That make much better sense now. I will try to setup inbound connector for 20.48.254.109 , see if I can reproduce the problem.
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.