"we strongly suggest you switch to Outlook" on mobile, the native mail apps won't work.
That'll be popular...….
Microsoft has doled out more details on forthcoming changes to the way mail clients authenticate to Exchange Online, the email service used by Office 365. In March 2018, Microsoft said that it would require Modern Authentication for Office 365 services including Exchange Online, and that this would be enforced from 13 October …
Fortunately at least on Android, the choice is not limited to pretty terrible stock email or Outlook terrible. TypeApp, for example, supports OAuth and multiple email accounts, is highly customisable advert-free and free of charge. I'd pick it over the Outlook client any time.
The Outlook app (at least on Android) does not connect "directly" to the specified server. It gives the username and password to some fly-by-night proxy service on the Microsoft Cloud that logs into the email server and collects the email. The Outlook app then connects to this fly-by-night proxy on the Microsoft Cloud to download the MITMed messages. When you delete the Outlook app the fly-by-night proxy in the Microsoft Cloud will continue to collect email from the server for Microsoft's own purposes until you deliberately prohibit the poxy from access (by changing the password or blacklisting the poxy).
At least RIM was plain about the fact that their e-mail service employed a Man-In-The-Middle and that you were giving RIM access to the entire mailbox by giving them the username/password. Contrast Microsoft who keeps this secret.
"I would rather use the native Android Gmail client and calendar simply because its more resource efficient than the Outlook one."
You've circled back around to the comment about being shot with a 9mm or .45. Do I use an email system that is known spyware or one that's so messed up that it may broadcast your private to everybody?
You can integrate the Outlook calendar with the Samsung one if you're on O365 by creating an app password and using that.
If you try to use your normal password, it fails (though I suspect this may also be partly due to the account using MFA).
Hardly a seamless experience to set up.
one bonus(depending on your point of view) to using the outlook app over native, is likely the phone can not be remote wiped by the admins. I didn't have a fear of admins at my org doing that to me but it was more of a fear of a software bug or something tripping that could cause it.
I used office365 mail/calendar on Android native(4.4) up until about July of last year. Newer phone newer Android and using Outlook app since. It's not as nice not being able to use the native calendar app to view things(extra clicks to get to the calendar), but the trade off of having a much lower privileged app vs all the insane permissions the built in stuff got I guess is worth the trade off for me personally. I mean it's one of the least annoying things about using the newer Android system.
The whole idea of email is to not print.
I don't think that was ever part of the RFC. Certainly the aim was to be able to contact people without sending letters but printing has always been possible and countless law cases can attest to the importance of being able to do this.
Our $BIGCORP is migrating to OAuth2 now but has decided not to also allow app passwords even though it's the same thing (per app authorisation which can be rescinded).
As IMAP OAuth2 clients which work with Office 365 are few and far between, they're herding everyone to a) the Outlook app or b) a cloudy email app which slurps company email. Very clever.
People keep saying this but fail to disclose the blast radius of such issues. An org that has a downed exchange system affects only that org. Doesn't affect dozens, hundreds or in some cases thousands of orgs.
MS has had a large number of outages in their services over recent years.
One thing that pissed me off most about office 365 recently is a bug in Outlook web access. If I sent plain text emails (which I did until I gave up on getting the bug fixed) the OWA client would merge all the lines together making things unreadable in many cases. It looked fine from the "Sent" folder, but received emails were jumbled up. Super easy to reproduce. IT team informed MS, and we waited for a fix. Meanwhile I was fine to stay on the "legacy" UI which had no such problem. (and yes the majority of my email is done from linux on OWA, I do run Outlook 2010 on a windows VM which is hooked up as well but that gets a minority of use, mainly for better searching, and yes I know 2010 will break later this year).
Fast forward a few months and they turn off the "legacy" UI, and the bug still isn't fixed. So I have to switch to html email.
Similar issues with "cloud" Confluence from Atlassian, they are dramatically changing their UI breaking TONS of things and there is no recourse. It's quite sad the state of software these days and it's getting worse.
Having on prem, or at least self managed, would allow you to wait until you are ready to upgrade.
God this is so juvenile and tiring. Instead of praising MS for taking a sensible and responsible decision on oauth, we get the usual shit Microsoft grumbles. Don't use MS if you don't like em, or don't work for a company that does.
I have been in this game a long time and am still surprised at the MS bashing on here and other channels. The conclusion I draw is that many commentards do this because they don't have the knowledge and experience to offer much in the way of informed opinion. It's an easy way to grab some tech kudos and pretend to yourself and others that you know more than you do. For those people I'll advise you on the facts: MS are a giant corporation, like Google (who are decidedly less ethical than MS even), Facebook (worse still, and in extremis) , Apple, Twitter et Al. The company has one purpose: generating cash. They all do.
I use Mint as a desktop and I love it, definitely better than Windows. But frig me, there are some annoying limitations and bugs in newly released versions. Strangely, people don't seem to mention them and class the entire Linux ecosystem as shite because Bluetooth is playing up on cinnamon desktop.
MS aren't uniquely bad, and you aren't on the smart side of the argument just because you slag them off. They have done enormous good and a lot of damage. And they have acted as shameless bullies and profiteers. You will NEVER find a big company that hasn't.
Yeah, Exchange Online might not have 100% uptime, but that is not why corporate customers use it. They use it because it meets their requirements on uptime, cost and supportability. Why is it that everyone on here expects perfection from Microsoft, but doesn't want to pay for it? I work for a cloud provider that provides much better uptime figures and better SLAs in other areas than MS / O365 / Azure. Trouble is, it costs a small fortune to provide that service, and few companies are willing to pay.
You (if you have a personal account) or your employer / customer sign up to those terms willingly, you know what the risks and benefits are. If service doesn't match your requirements, claim your service credits, then move your business elsewhere, move jobs if it's so unbearable.
In Azure / O365 you are leveraging economies of scale and division of labour to achieve low cost. You might not be getting vintage claret, but you're not paying for it either. You're not even asking for it! You're getting something lower end, but that's all you've bought. Change the bottle, pay a bit more, but if you can't afford top end plonk, you'll be on the Lambrini.
All reasonable comments.
Also there is a fair bit of moaning about aspects of MS products that were true 10, 15 or 20 years ago but were fixed an awful long time ago as well.
It does seem - and I've said it before here - that some of the the very vocal proponents for freedom of choice are fine with the concept providing that choice aligns with their own.
Oh yes people do blame the whole of Linux when something fairly obscure does not work for them on one distro. The difference with Microsoft is their screwups have a bigger effect. Microsoft also use their position to dictate to the market. This can be a good things such as in security but bad if it's used to force business to use them not through choice.
Lets look at the alternative - on-premise systems.
You install you on-premise Exchange system. In 7 years time (or less depending when you installed it) it reaches end of life and you should replace it. You don't, because you are in control.
Two to three years later, you have a number of security issues, you end up using a third-party to provide additional security that stops working with your end-of-life environment and suddenly you have OS/Application/Client upgrades in one massive, expensive hit. All to do the things you refused to do in a timely fashion when you had choice. Add in a few security scares that necessitate significant effort to address (i.e. downtime for patching or new systems to provide missing functionality) and the end-user experience can quickly turn sour.
Cloud is the other extreme - change happens very quickly and is often difficult to keep up with if you have a significant amount of integration between business systems. But I believe the cloud approach is more manageable for most businesses over a medium to long time period. And users see a system that mostly works 24/7 rather than one that always works 8x5 until it doesn't.
Yeah, well the only two reason I can think of to stay on an old version of an application are:
1. It's expensive to change between versions
2. It's technically demanding to change between versions
Neither of these things have to be true for a mail/collab server, although they are certainly true for most versions of Exchange on Prem.
Yes. Older Outlook clients have a crappy IMAP implementation, most people used POP email with them to stay sane. Many others just chose it as default.
That method of deleting email is only the _default_ for POP (vs. IMAP where the default is not to delete). You can have your POP email client do a variety of options for download & delete, or delete on a schedule, etc. etc depending on options you tick.
I use POP on a one (singular) of my devices, all others are IMAP. This allows me access to messages until I am ready to, quite intentionally, remove them from the server, download them, and then archive them using my own methods. Keeping email on IMAP servers, mistaking that for "storage", is a grave mistake and a potential privacy failure if/when your login is hacked.
Speaking of which, I guess it's about time for me to archive again...
I am not leaving my mail on somebody else's server. My mail is mine, and goes to my local storage.
I love POP. I'll never stop using it.
But then, I'm the kind who keeps mainly to himself and doesn't spaff his private life all over the web for all to see without a thought.
I've got an old domain that has a couple of basic POP accounts on it (stupidly set them up for me and the parents >10 years ago) and still use POP to download all the mail into gmail, thus clearing it off the - very limited - accounts on the cheapo server and making them available to gmail in our android devices. It's not pretty but it works; gmail also has the option to send-as those accounts so it looks seamless to recipients.
This post has been deleted by its author
Whatever possessed Microsith to think that describing O364 galley-slaves as "tenants" was in any way a good thing? It makes me think of precarious housing tenants living in ramshackle slums "managed" (or usually not) by evil rogue uncaring landlords, where things never get repaired if they go wrong, and they'll chuck you out on the street at a moment's notice if they feel like it.
Hmm, actually that's probably a more accurate description than they ever intended...
What about people using Office 365 Premium? The article says Office 365 ProPlus. Does that mean that the product that lots of people have bought that works with Outlook will no longer work? What will be the point of office 365 premium? It's a product that comes with Office and email and Sharepoint.
You need to read more carefully. The change is to the Microsoft Cloudy mail servers. It doesn't matter what "client" you are using, they will have to "do OAuth2" to be able to talk to the Cloudy servers after whatever the date is later this year (Halloween? I don't remember since I do not use the Mickey Mouse Cloud).
The reference to "Office 365 ProPlus" is because that is the email client that Microsoft would love you to rent in order to access the Mickey Mouse Cloud since it generates for them the mostest revenue for the leastest work, powers their spying apparatus swimmingly, and is most annoying for the user.
If you use *any* server OTHER THAN the Mickey Mouse Cloud, you are totally unaffected.
As somebody who switched from Windows to Apple several years ago, and is very happy with the way everything works together within the Apple orchard, it will be a right pain if Apple's native Mail app(s) can't cope. I've several email accounts that use 365 (one is for a charity and another an FE college) - around a dozen different accounts all (currently) play nicely together in the native iOS/MacOS Mail app. I have Outlook available but I find the simplicity of Apple's offering far better.
I initially bemoaned the fact, when leaving Outlook behind, that Apple's Mail, Calendar and Reminders apps were separate but, several years down the line, I've actually found keeping them separate works better for me. Mind you, it's helped a lot by the way iOS/MacOS keeps everything in order, in a way that Windows never seemed able to.
Update: I've checked and Apple Mail (in iOS, iPadOS and MacOS) works fine with the new requirements. Haven't checked all versions but, for iOS, the authentication system was implemented in v11. If an account has been set up as SMTP or POP, it probably means deleting the account in Mail and re-adding it as an Exchange one - a task of a few minutes (assuming you can remember the password).
This is an honest question, please don't take the piss as I am sure other people here would like an explanation as well.
Firstly Basic Authentication. I take this to mean username and password sent to a server from a device. The username and password are stored on the device / email client or maybe a copier. It's a simple case of entering these details once and the device will remember them. This does not mean that the details are sent in plain text but encrypted during transit if using the correct protocols, TLS or Starttls etc.
How does modern auth improve on this? How is the device initially configured if not with a username / password?
Yes, I'd like to know what is so wrong with Basic over TLS (IMAPS on a dedicated port). I guess starttls has had issues with "Man in the Middle" with not passing the starttls to the real server, so being able to intercept. But I don't see any difference between IMAPS vs an HTTPS based authenticator. A genuine question from me too!
"Basic Authentication" is an HTTP term that means to send an authentication header as part of the HTTP request with the UserName and Password in plain text. For the purposes of protocols other than HTTP it basically means "Login Plain" as in sending the UserName and the Password in plain text (although this is not called "Basic Authentication" anywhere other than in HTTP).
If your connection between the client and the server has not engaged Encryption, then anyone on the path between the client and the server can "read" the username and password (this is called a Man In The Middle).
Other "standard" methods of authentication include GSSAPI, CRAM-MD5, NTLM, DIGEST-MD5, and APOP (not exhaustive). These methods generally avoid sending the password over the network in clear text by various methods. Most of them are not very resistant to MITM attack unless protected by and Encrypted channel (TLS), though the challenge-response authentication methods are somewhat more resistant.
OAuth2 is yet another authentication protocol to be added to the bunch. It also has minimal resistance to MITM attack unless protected by an Encrypted channel (TLS).
OAuth2 *requires* that the authentication be processed over an encrypted channel and will not permit authentication over a non-encrypted channel.
On almost all "e-mail servers" since the middle of the last decade of the last century (with the exception of those from Microsoft) have a built-in facility that will not permit or advertize "login plain" or "basic authentication" except over an encrypted channel. Many can even be configured to not permit or advertize *any* kind of authorization except over an encrypted channel.
So "modern auth" is merely Microsoft's way of catching up to where the rest of the software world was 25 years ago -- and adding some massive complication while they are at it -- while providing little or no benefit that has not existed elsewhere for many years.
Those with archaic (In fact, some recent not-so-archaic) photocopiers that don't support SSL/TLS for outbound SMTP when scanning-to-email are the scourge of the earth, but unfortunately they're also extremely common. I've lost count of the number of times we've had to set up an SMTP-relay for these cretinous things! :-(
I agree with you but as I mainly deal with Ricoh I can confirm that the vast majority of their machines support SSL encryption for SMTP connections.
Enabling SSL for SMTP Connections
Use the following procedure to enable SSL encryption for SMTP connections.
1Log in as the network administrator from the control panel.
2Press [System Settings].
3Press [File Transfer].
4Press [SMTP Server].
Operation panel screen illustration
5In "Use Secure Connection (SSL)", press [On].
If you are not using SSL for SMTP connections, press [Off].
When "Use Secure Connection (SSL)" is set to [On], the port number changes to 465.
If the option is not shown ask a Ricoh tech to update the firmware / takes around half hour. Unfortunately / officially only Ricoh certified techs can get access to the FW files as it is quite easy to damage the machine and can be expensive to rectify if it is not done properly. The most common machine that is still in the field that does not support it from new is the MP C305 but it can be updated. All machines from around 4 years ago should be fine.
well I travel around a bit and use several devices. Having had a couple of NAS's fail on me I see imap gmail (free!) as very convenient storage (I archive every year or so - time passes quicker with age).
Google have already decided what I'm going to think next week so security is not a problem <g>.
This is to get customers for AzureAD.
The great secret here is, that App password completely bypasses any OAuth2 requirement, MFA etc.
Whatever filtering you create, app password just bypasses it - At least until team Evil gets users to create one for them :-)
Even better than getting user consent in 3 clicks.
Biting the hand that feeds IT © 1998–2020