Hold up, does this mean outlook sends your full credentials to Microsoft when you try to set up an outlook account? I'm sure they pinky promise they keep your credentials secure, but this feels like it breaks all sorts of security/privacy expectations.
Not just an “outlook account” - any account in outlook, with default settings at least.
I run a mail server, mainly for me but a couple of friends have accounts on there too, and a while ago one friend reported apparently being locked out and it turned out that it was due to them switching Outlook versions and it was connecting via a completely different address to those that my whitelists expected sometimes at times when they weren't even actively using Outlook. Not only were active connections due to their interactive activity being proxied, but the IMAP credentials were stored so the MS server could login to check things whenever it wanted (I assume the intended value-add there is being able to send new mail notifications on phones/desktops even when not actively using mail?).
> but this feels like it breaks all sorts of security/privacy expectations.
It most certainly does. The behaviour can be tamed somewhat, but (unless there have been recent changes) is fully enabled by default in newer Outlook variants.
The above-mentioned friend migrated his mail to some other service in a huf as I refused to open my whitelist to “any old host run by MS” and he didn't want to dig in to how to return behaviour back to the previous “local connections only, not sending credentials off elsewhere where they might be stored”.
https://www.xda-developers.com/privacy-implications-new-micr...
No, I'll keep my credentials stored and used locally, thanks.
It looks like Microsoft Edge had the _ability to disable_ this added in 2020 or 2021, but it isn't currently the default and the Group Policy unintuitively only applies to unencrypted HTTP Connections.
Are you talking about NTLM hashes? It's a weak hash, but not the same as "sending your password". The biggest difference is that even a weak hash can't be reversed if the password has high enough entropy.
It was the Ethernom Beamu, company now defunct.
>I would expect such a feature to use end-to-end encryption for the data
How would "end-to-end encryption" when such features by definition require the server to have access to the credentials to perform the required operations? If by "end to end" you actually mean it's encrypted all the way to the server, that's just "encryption in transit".
Already many years ago I remember installing a firewall on my phone and noticing in surprise that Outlook was not connecting at all to my private mail server, but instead only sending my credentials to their cloud and downloading messages from there.
The only Android mail client not making random calls to cloud servers was (back then) K-9 Mail.
or the “See Plans and Pricing” on the homepage?
Christ, my poor grandmother…
Yeah you're right, if you don't specify the password (eg. -u user), it prompts you for it
>there obviously isn't a legit user account test@example.com with a password of password either at microsoft or at the Japanese imap server.
But presumably the fact it's there at all suggests it's a required parameter? Maybe "password" is just a placeholder, but it's unclear based on the command line transcript alone.
Wait, does their autodetect send email and password to their servers, instead of just domain???
Working on Linux automation systems we would need to make sure to disable anything related to Avahi in our images otherwise name resolution would fail for some customers.
It's like when .dev became a gTLD, knowingly breaking a bunch of setups for a mix of vanity and a cash grab. Obviously dropped the ball on the engineering side.
But also, yes Microsoft documentation used .local before mDNS reserved it, and IIRC Microsoft was also involved in suggesting it for mDNS as mDNS came out of the multi-company standardization efforts from Apple's Bonjour. That said, my impression of most of that documentation from that time is that it was incorrectly using .local as a fake TLD where they should have been using .example or .example.com and also pointing people to the RFCs that those were not valid choices in a real setup. A problem with such documentation is that it is too easy to take literally. A follow up problem was sort of the "accidental security through obscurity" benefits of using non-globally resolvable addresses becomes "best practice" through essentially stubbornness and status quo (related to all the recent rediscussions on HN about NAT44 is not a firewall except by accident and you can have very good firewalls that aren't NAT44).
When setting up Active Directory on Windows Server 2003, there was a note in the wizard that explicitly called out .local as a domain suffix that would prevent DNS lookups from hitting the public internet, which many people (myself included) took as an endorsement.
If you actually try to find an evidence for this (even time traveling to 2015 before the great wipe of most pre-Vista docs) you wouldn't find a confirmation for this. What you would find is what the official docs always recommended the root domain to be an official bought one on the public internet. And this excludes .local.
Support patiently explained .local is reserved for something else and kindly provided Wikipedia links.
They never responded why they used .local in their docs, trainings, webinars they provided, though :)
Good times.
It’s clearly not using the DNS records for discovery because they don’t exist, the only other option I can see is some weird fall through or hard coded value and it seems like an odd one to pick.
Not quite true, SMTP will use the A record if there is no MX.
$ host -t mx example.com
example.com mail is handled by 0 .
I always make up some impossible domains like domain.tmptest
Otherwise you're one DNS "misconfiguration" away from sending dev logs and auth tokens to some random server.
> Since at least February 2020, Microsoft's Autodiscover service has incorrectly routed the IANA-reserved example.com to Sumitomo Electric Industries' mail servers at sei.co.jp, potentially sending test credentials there.
"Aha, the defective trucks only cause injuries to people who have their hands on the wheel at highway speeds, but I've never bothered holding the wheel at high speed, I just YOLO so I wouldn't be affected"
If people had used IANA's reserved TLDs they too would be unaffected because although Windows will stupidly try to talk to for example autodiscover.example that can't exist by policy and so the attempt will always fail.
I always use the ISO-3166 "user-assigned" 2-letter codes (AA, QM-QZ, XA-XZ, ZZ), with the theory being that ISO-3166 Maintenance Agency getting international consensus to move those codes back to regular country codes will take longer than the heat death of the universe, so using them for internal domains is probably safe.
It is reserved by ICANN since 2024-07-29.
https://en.wikipedia.org/wiki/.internal https://www.ietf.org/archive/id/draft-davies-internal-tld-00...
https://www.akamai.com/blog/security/autodiscovering-the-gre...
According to it, it seems that if someone registers autodiscover.com then example.com lacking autodiscover.example.com will make Outlook try checking if autodiscover.com has an entry.
It's just a braindead system.
Source: I'm on the board of dotMeow and wrote the financial plan
The IPv4 for example.com used to be 93.184.216.34
Was there an announcement somewhere
dq a example.com 199.43.135.53Maybe some of their targets did use example.com for some probing, and the NSA had a hand in Sumitomo Electric Industries' mail server.
https://www.akamai.com/blog/security/autodiscovering-the-gre...
According to it, it seems that if someone registers autodiscover.com then example.com lacking autodiscover.example.com will make Outlook try checking if autodiscover.com has an entry.
It's just a braindead system.