Microsoft teams email address is classed as catch all, even though it isn't

[cortopy]

Email Provider

Microsoft teams

What happened?

Email addresses for a domain hosted by Microsoft Teams/365 always return as risky. This is because they all appear to be "catch-all", event though they aren't.

Relevant log output

I have debugged this in detail and this is what I was able to find:

When the validation process checks if the address is [catch_all](https://github.com/reacherhq/check-if-email-exists/blob/master/core/src/smtp/connect.rs#L233) it tries to send an email to a random address in the same domain. The problem is that the Exchange server actually returns 250:


 Code {
        severity: PositiveCompletion,
        category: MailSystem,
        detail: Zero,
    },
    message: [
        "2.1.5 Recipient OK",
    ],


But the thing is that the email doesn't exist!! 

I have verified this by sending an email myself to that address. Indeed, I get an email saying that the address doesn't exist.

It seems to me that Microsoft is protecting domains against enumeration attacks, and it will always return positive. Not sure if there is an alternative way of checking but if not, it may be worth reporting in the documentation to manage expectations about the "Risky" result

[amaury1093]

Hey @cortopy! Yes, I also noticed this issue some time ago, and recently implemented a Hotmail/Outlook check using Microsoft's password recovery page. You can take a look at the code here: https://github.com/reacherhq/check-if-email-exists/blob/master/core/src/smtp/hotmail.rs.

It's still new, so I didn't release a version with it yet. But I probably could release a 0.9.1 with this feature, if it's needed.

If you're using the backend directly, it's available in the latest docker image (tagged with beta).

[cortopy]

Thanks @AmauryM for your prompt response on a Sunday!!!

When I forked, I was curious about whether the new headless feature had something to do with this. But then it's only triggered on "outlook" and "hotmail" domains right? So I ignored it. Microsoft Teams/365 would be used with companies' own domains. Maybe it could be used with the resolved DNS hosts as well?

[amaury1093]

It's triggered when the DNS MX record contains the word "outlook", see https://github.com/reacherhq/check-if-email-exists/blob/master/core/src/smtp/mod.rs#L67.

So it should be triggered on *@company.com if company.com uses Microsoft Teams, but I'm happy to debug if it's not the case.

[cortopy]

The new part didn't get triggered when testing in local yesterday, but I'll try again this week setting the webdriver properly too. Thanks again!

[amaury1093]

You can also try on app.reacher.email (Microsoft teams emails should not return risky), though locally, you will also see logs.

[cortopy]

I tried that, but for some reason it was returning "invalid". I could send the email address in question, although not sure how

[cortopy]

I've just been trying the new feature, and this is what I've observed:

• If I use ciee without headless feature, I get Risky (as per my descirption above)
• If I test the headless feature in local, I'm getting "invalid". The headless flow did happened, as the address was resolved as <company>.mail.protection.outlook.com.
• Reacher API returns invalid for my email address. I guess because the new feature is already deployed?

The problem with this feature seems to be that the url is hardcoded to https://account.live.com/password/reset, which is only for individuals and it will never work for Microsoft 365 accounts, which is https://passwordreset.microsoftonline.com

The differences can be seen by doing the following:

1. Go to office.com
2. Click on "Sign in"
3. Click on "Can't access acount"
4. If you select, personal, you get https://account.live.com/password/reset, otherwise you get https://passwordreset.microsoftonline.com. The bad news is that the latter has a captcha, so I'm unsure if the headless feature could ever be used there

[amaury1093]

Reacher API returns invalid for my email address. I guess because the new feature is already deployed?

That's correct!

which is only for individuals and it will never work for Microsoft 365 accounts

Interesting, I also tested with a company custom domain using hotmail, and was able to verify both invalid and safe emails on that domain.

Could you send me an email, which you can find here, with the domain name you're using? I can also send you the one I'm testing against, and we can try to cross-check to debug this.

[amaury1093]

In #1196, I removed the usage of the headless password recovery page for Microsoft 365 emails. I only kept it for @hotmail.com/@outlook.com emails.

So now we're back at square 1, i.e. @cortopy's initial issue: they are all catch-all.

@cortopy There's an alternative method for testing Microsoft 365 accounts: #1194. Would you like to test that too? Edit: My initial tests show that it's also not super reliable.

[Nyceane]

@AmauryM how does the headless thing work?

I just use RCH_HOTMAIL_USE_HEADLESS=http://localhost:4444 in the enviroment? what do I have to do with 4444 port?

[amaury1093]

@Nyceane you need to run chromedriver on port 4444, which is used to perform the headless password recovery.