I'm hoping that this is a server-side bug and not by-design.
I would be extremely disappointed to see a widely-used enterprise product by a company with such stature to be designed with such little forethought.
Disappointed but not at all surprised. Teams is the poster child of the kind of software that users are forced to use, and so functionality, polish, overall experience, security or anything else doesn't matter to the Microsoft as long as the account managers/IT/COO etc. are kept happy.
You've never used the Cisco suite of alternatives, have you?
Teams is the Discord of integrated business chat from a usability perspective, at least if you want an integrated experience. Cisco's system last I was aware was a hodgepodge of applications, i.e. we had to have two separate Cisco chat applications running at all times.
Other players, its either one or both of:
- a solution less kludgy than Cisco but still a hodgepodge of applications
- a system that can't scale on one or more important axes
- too specialized for a general use case
Remember, on one hand, Telcom uses erlang a lot. On the other hand THEY USE ERLANG A LOT. The sorts of stuff you see in phone systems is brilliant but archaic. And I bring that up because the voice integration in teams is really freaking nice and honestly the users are happier because its less integration hassle when moving numbers around, and that's a win for both IT and users.
Would I prefer discord had a competitive solution or Teams had a competitive UI? Yes. Or that Avaya would come blow everyone away with something amazing.
But part of me is also asking if teams has gotten so crappy lately because this year has likely resulted in them having to scramble on bugs and scaling issues in a way they didn't expect.
In the early days of Exchange I was curious what would happen if I setup a rule for two clients to just reroute emails to each other back and forth.
So a buddy of mine and I tried it. The rerouting was done (as far as we could tell) client side and it seemed there was no inherent server side method of detecting such scenario.
Company email for a few thousand folks went down after the two clients took off doing their thing for a short while.
IIRC the client wasn't immediately inclined to forward other forwarded emails (again enforced on the client) but an easily crafted rule would bypass that easily.
At the time I was surprised there wasn't any automatic prevention of such things, as my career has gone on, I just assume such things aren't there ;)
If by "rerouting" you mean user level forwards, then that's generally done at the mailbox level, but not the client side (depending on system and rules), because users are allowed to set their own forwards.
Mail loops in mail servers have always been a thing, and there are various ways to detect and stop them, usually by adding headers to a message and detecting it's the same one that was seen previously.
If there's actually a client side forward (which mail servers can't prevent because running mail through a local program, whether it be procmail, spamassassin, or some other mail categorization and filtering program) is a valid use case with a long history. There's also the case where the mail client is applying it's own complex rules and sending responses automatically. If the message is actually a new one, there's not an easy way to detect the loop.
There's a reason why Gmail for a long time (still?) didn't allow you to forward your mail to another Gmail address. I would argue that for Exchange, where it's generally much easier to track down individuals, erroring on the side of allowing administrators to do what they want to block this (whether that be company policy, exchange policy, or whatever) is the correct design choice.
My favourite thing many years back ('01 or so IIRC) was that supposedly internal only mailboxes could me sent to via SMTP if you used the LDAP DN for the mailbox as the user part.
Was actually quite useful to me since it meant I could script messages to internal todo list mailboxes from the *n?x boxen, though it did give the windows devs a mild heart attack the first time they saw it happen.
"widely-used enterprise product" usually implies little forethought. Bonus points if it's communication/teleconferencing software.
There was this essay about this being an inevitable result, considering that large companies almost never take user feedback into consideration when selecting "enterprise software". Which is the reason most enterprise videoconfering software sucks.
Enterprise software companies sucks because most companies buy competitors to grow instead of doing R&D. It’s a reactionary process instead on a proactive one, especially for companies with other cash cows.
If they can’t or decide not to acquire a company they will slap together a product like teams hoping to kill slack or zoom. It’s still a reactionary approach instead of doing R&D.
It’s the same in the “Fintech” software world where the large players are merging and acquiring small companies to stave off Stipe, Square, and whatever else hasn’t been picked up yet.
Hahaha. Slack does something similar. My company set a policy to log everyone out of Slack every week. And it “works” except it’s enforced only by the client because you can go into Slack’s files and pull out your user-key which is a session token that never expires, is never rotated, and bypasses SSO and 2FA.
So everyone who doesn’t want to be logged out just extracted their key and uses it to stay logged in on their other clients.
(Also, if you run across some tool/bot that needs a Legacy Token you your user-key will work. When Slack stopped letting users generate them it didn't apply to Slack itself.)