Microsoft blocks Tutanota users from own service
tutanota.com
tutanota.com
If a privacy-centric service is being blocked because it's privacy-centric, that's an issue. If it's not on a very small list of approved services, because 99% of people have never heard of Tuta Nota, it's an annoyance.
https://www.reddit.com/r/tutanota/comments/wfu0vk/comment/ij...
Microsoft support can do better, no denying, but to use words like "blocked" and "anti-competitive practice" when a technical issue like this may apply to other domains, not just Tutanota, seems hyperbole.
> We asked them to change the domain to a public one, which Microsoft support denied. It must be technically possible, I guess, but here we are.
So I suppose the issue is: when example.com is a verified domain for some AAD organization, users with a live.com account ending @example.com cannot accept invites to become a guest of an external AAD directory (example2.com) due to this error message.
But i'm skeptical if this is MS's problem where they can't downgrade a domain to only allow registrations via `live.com`, or if Tutanota just wants to have the best of both worlds where some email accounts (maybe even employees' personal email accounts) can be manually AAD-registered to allow data governance within their Microsoft 365 organization, while everyone that's not an employee can still create a live.com account and won't have issues joining external AAD directories.
Microsoft's ID systems has been fucked for ages. They are either incapable of fixing it, or just don't give a damn.
About, oh, 8 years ago at a previous company, we signed up for and used AzureAD on a trial. It immediately broke our ability for staff to create a Microsoft account with our domain and a bunch of business processes that depended on those.
Our account rep at the time wasn't able to get us any help, and despite cancelling the trial the domain remained locked to Azure AD. Microsoft wasn't interested in fixing it, only signing us up for AzureAD and O365.
We had the same issue at our company for several years - we put up with it for a while but eventually raised it with microsoft.
To be fair, it take a fair bit of back-and-forth with microsoft to track the problem down, but turns out about 5 or 10 years back when the company was only a few people, one of the directors had played around with setting up a microsoft domain, didn't use it, stopped playing with it and then forgot about it. Didn't cause any issues until years down the track when suddenly we started getting errors like the above.
Once we established that MS worked with us to remove the domain from their systems, the errors went away, and I considered they were very helpful given the very small amount of money we spend on their services.
Anecdote aside, I've had several people not receive my emails at all, some I've been able to actually test, using Tutanota for outbound messages. I've created or helped create Teams accounts for others several times in the past and have never run into anything like this with any other provider. Microsoft is setting a precedent by singling out one provider. I hope it's not a sign of things to come. Virtually all email is de-facto controlled by a Microsoft/Google duopoly.
I looked into running a personal email server on a home machine once and was put off by how many people told me my messages would be undelivered without numerous hoops to jump through.
What a mess.
It's also like saying you don't believe house fires actually happen because yours hasn't "ever in over 20 years, even once"
That has been a problem for a long time too, but it's been a progression. I remember att.com and aol.com blocking mail from legit but small mail servers of my customers since decades ago. It was only a few hosts doing blocking, and they were blocking more selectively like only blocking Road Runner cable modem ip's not all small mail servers. And today it's just a lot worse in both dimensions.
If you never encountered this problem in 20 years, for 15 of those years it just means you didn't happen to encounter one of the few examples, now there are more examples but many of those are new and so you've only had to be lucky not to encounter them for a short time.
This is how a lot of experience gives a false indication. Not encountering a progressing problem like this for 20 years is not like "I've cooked spaghetti this way for 20 years"
No, that is not what I was talking about, nor the comment I was replying to.
I was replying to this:
> Credit card companies calling me because they think I'm committing fraud, retail sites cancelling my orders because they think I'm scamming them
One thing I can't understand is do they just have the one domain? Like almost any good email relay, possibly having more domains to register or a custom domain to register from will fix the issue. This is like being surprised ProtonMail gets blocked when spammers use the service primarily due to anonymity. Duh.. Microsoft Teams doesn't want a bunch of anonymous spammers using their service. Who would have thought?
What the hell am I reading?
=================================
I work for an IT MSP and can attest what you're seeing is by design and occurs for a technical reason and is a security feature by Microsoft as a means of an organization controlling who can and cannot register accounts claiming to be from an organization or is not.
This means that someone created a Microsoft organization (business) account and verified the domain tutanota.com. Once this is done no one can register a personal account.
On the technical side, Microsoft has Teams highly integrated with Exchange Online. When there manages to be both a business org and personal accounts with the same domain, Microsoft services get tricky. When you "share a file" with someone it may not make it to your account. Could be because it tried to send it to the business org but it didn't find an account so it just fails and the recipient never gets anything. Causes all sorts of problems across the board and sometimes we have to go finding all the personal accounts using the company domain and change the email associated with the personal account.
When you are troubleshooting this, there's two ways to login to Microsoft really, the business/organization side or the consumer/personal side. Now if you happen to be on both by registering for a personal Microsoft acct prior to the organization verifying its domain, then some parts of Microsoft's sites/services make some assumptions as to which one you probably want. To rule out account confusion, I go to https://myworkaccount.microsoft.com or https://account.microsoft.com and login with the appropriate account.
If Tutanota does not using Microsoft for any sort of organizational management, Microsoft single sign on, Azure services, etc, then just contact their customer service to tell them that the domain was verified but you can't find the account associated. They may ask you to do your own verification by adding a txt record. Once you have control of the verified domain, you can go through a process to completely remove the domain from Microsoft services.
A random, unknown, probably unwitting customer of tutanota some time years ago used their tutanota email to sign up for azureAD, and MS basically granted ownership of the tutanota domain (for MS purposes) to that unknown rando who does not work for tutanota and does not own their dns domain or anything like that, they just had an email address that ended in tutanota.com or .io or whatever it was.
It means that ever since then, no one else can sign up for teams (and presumably at least some other MS services) using any tutanota email address, because MS treats them all as "you have to see your company's IT dept for that" they're treating the domain like a private corporate domain like mycompany.com that only mycompany.com employees are allowed to use, instead of like aol.com that any rando can use.
By rights, this should be trivial to fix. Tutanota should be able to go to MS and simply prove to someone at MS that they own tutanota.com (or whatever domain) and maybe show their business incorporation paperwork etc, and remove the bogus "account" as it was never a valid account in the first place.
MS is simply not doing it, for no explicable reason.
Basically it's MS's fault at both places, both the initial error having whatever swiss cheese vetting process to even allow a rando to register a domain they don't own, and now not having any way to correct that initial error either.
Basically, can you imagine that this would all play out the same way if the initial bogus registrant had happened to use a hotmail address instead of some other?
Cool I own hotmail.com now as far as MS is concerned, and if anyone wants to make an account for o365 or teams using a hotmail address, they all have to come see me! And if I'm no longer using my hotmail address and don't even know any of this is going on, oh well the entire world of hotmail users can just f-off I guess!
Somehow, I just bet that could never happen in the first place because of course hotmail would already have been getting special handling since day one and could never be accidentally handed to anyone like that, and even if it ever did by some chance, I just somehow predict that MS would somehow be able to accomplish what they say is impossible to tutanota, and fix that shit, in about 8 seconds.