Hi there
I own a FP4 running e/os/1.8.1-s-20230203257059-stable-FP4 and since about a month, I am not able to reach the server at login.microsoftonline.com, no matter how (switching networtk providers / WLANs, via various browsers (Connection failed), apps (teams), simple pings (timeout), traceroutes (resolve to localhost, finish after one hop).
I checked the /etc/hosts file (nothing to see there) and interestingly, when sharing my internet via a mobile hotspot, the connected devices can access login.microsoftonline.com.
Do you have an idea, what the problem could be?
(So far no other website seemed to be blocked; maybe it has something to do with the latest updated, but this is a really wild guess…)
Thanks for an answer
you need to disable a tracker rule
for the long version, there is a linked gitlab issue at Mail with Outlook/Office365 servera - #2 by tcecyk
thank you so much for the quick and working solution 
- have a nice weekend
My Microsoft applications ceased to work due to that, and I had not a single clue what was happening.
That is the login servers which are blocked by this rule. At some point, if we want to login, we have to get tracked, don’t we?
There should be something helping the user to understand that is some privacy rule which is blocking the basic functionality he wants to use.
I have ended up here, at last finding another solution than moving away from /e/, only because even the browser could not anymore log into Microsoft Web sites such as Outlook online, which I seldom use. There too, the message was quite unhelpful, just saying login.microsoftonline.com was unreachable, without any hint about privacy rules.
And for those arriving here, mind that you have to unblock the tracker named “Mobile engagement” on every app with which you use a Microsoft login. Do not just attempt to do that only for DuckDuckGo, which in my case I do not have anyway. (Using Qwant.)
it’s generally an unfortunate case. There’s now more documentation for users at Advanced Privacy - but I think it would be better to contest the tracker itself.
As tracker- / blocklists rely on volunteer work, the tracker in question I think (but haven’t tested !) can no longer be used at all since a longer time now and can be seen historical - so its removal could be warranted. But that would take engagement with ETIP - the Exodus tracker database and you’ll need to make your case without doubt.
I took the time to add that info to the Gitlab issue on this one - maybe this is taken up or I’ll try myself if I feel volunteer-y.
This topic was automatically closed after 30 days. New replies are no longer allowed.