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.
I am wondering if there are anyone from Exchange Online support team can verify this behavior ?
I opened support ticket with Fortinet and Microsoft, Fortinet support 's attitude is "not my problem, ask Microsoft"; The Microsoft support working on my case doesn't seem understand the issue so far.
Now I see other customers are having same problem:
https://www.reddit.com/r/fortinet/comments/un12cw/fortimail_recipient_verification_using_rcpt/
"I’ve come across an interesting issue that support from either side has been unable to solve so far"
This doesn't look promising.
The result is Fortimail will count any bogus email as a valid user account and consume a user license.
I opened support ticket with Fortinet and Microsoft, Fortinet support 's attitude is "not my problem, ask Microsoft"; The Microsoft support working on my case doesn't seem understand the issue so far.
Now I see other customers are having same problem:
https://www.reddit.com/r/fortinet/comments/un12cw/fortimail_recipient_verification_using_rcpt/
"I’ve come across an interesting issue that support from either side has been unable to solve so far"
This doesn't look promising.
The result is Fortimail will count any bogus email as a valid user account and consume a user license.
Arindam_Thokder
Microsoft
MicrosoftIt can very well be an issue with attribution. Jack_Chen1780 - If you share the ticket number with e, I can have a look internally.
- Thanks Arindam, I have PMed you with the ticket number, let me know if you need any other information.
- Arindam_ThokderJack_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.