My organisation has moved to office365 but has not enabled EWS. This make the akonadi EWS component useless to me. On the other hand they have enabled IMAP with OAUTH2. Thunderbird support IMAP+OAUTH2 for both receiving and sending and therefore works in my use case. kmail sadely doesn't as I cannot select oauth2 with an IMAP server.
With Microsoft having started to disable all forms of basic auth for their office365 tenants, I think this bug deserves a higher importance.
Given that Office365 situation, I agree. I think it's still "wishlist" because it's a feature request, but I'll increase from "normal" to "high".
*** This bug has been confirmed by popular vote. ***
Does this commit is a good base to implement it? https://invent.kde.org/pim/kimap/-/commit/f953e1bac598388154138282a90529d7ff04aca2 It was written by @dvratil
Does someone tried https://github.com/simonrob/email-oauth2-proxy ?
I need this badly. Our IT department just changed the settings so I can no longer access my email on Office365 via IMAP. In addition, EWS is also failing since none of the user agents are supported (and there's a bug where it's impossible to override it for the first time, but this is unrelated to IMAP).
Since Microsoft now mandates the use of oauth2 for IMAP with office365, this bug is now more important than ever. It is now impossible to use KMail/Kontact with Office365 without jumping through some major hoops with proxies, etc. Many corporate organizations use office365. I'm now stuck with Thunderbird for my work email and I am not at all happy about running that CPU pig (CPU usage is pegged at well over 100% at all times).
*** Bug 455113 has been marked as a duplicate of this bug. ***
*** Bug 462042 has been marked as a duplicate of this bug. ***
*** Bug 444301 has been marked as a duplicate of this bug. ***
(In reply to Björn Bidar (Thaodan) from comment #8) > *** Bug 455113 has been marked as a duplicate of this bug. *** Bug 455113 is an actual bug because it does something it shouldn't: connecting to Gmail when it's a Yahoo address. In light of this, shouldn't this bug be considered an actual one too, instead of being classified as a mere wishlist item?
This bug has 3 duplicates, all of which have importance "NOR normal": 444301 455113 462042. I think it should be fair that the present issue has the same importance.
I just want to add that this bug will also affect Microsoft Personal users in the near future as Microsoft will disable Basic Authentication for personal users on 2024-09-16 (source: https://support.microsoft.com/en-us/office/modern-authentication-methods-now-needed-to-continue-syncing-outlook-email-in-non-microsoft-email-apps-c5d65390-9676-4763-b41f-d7986499a90d). As far as I know & experimented so far, personal users cannot use the EWS protocol (& have no admin they can ask for enabling it), which makes that even more bad. But, I can slightly understand why enabling XOAUTH2 for Microsoft Office 365 / Personal as well might be not as simple as it may seem, because KMail will then also need hard-coded settings for Microsoft’s OAuth2 endpoints, which includes a per-application secret (which feels ridiculous as they can easily be extracted, especially in the case of open-source software).
For information, I now use https://github.com/simonrob/email-oauth2-proxy + akonadi with success.
(In reply to zocker.network from comment #13) > But, I can slightly understand why enabling XOAUTH2 for Microsoft Office 365 > / Personal as well might be not as simple as it may seem, because KMail will > then also need hard-coded settings for Microsoft’s OAuth2 endpoints, which > includes a per-application secret (which feels ridiculous as they can easily > be extracted, especially in the case of open-source software). I hear what you say. At the same time thunderbird manages to provide it. I think the per application secret is more subtle than just having one for the application as a product but I need to dig on that.
In my case, I can't use EWS and must use IMAP with Office365 due to another bug in Akonadi with the EWS protocol. If you have a lot of email, like I do, the server will send an error message telling the EWS client to stop downloading email for some period of time, i.e. 5 minutes. Unfortunately, Akonadi and most other EWS clients do not handle this and barf. The only email client I can run now on Linux with Office365 with Oauth is Thunderbird, which I hate.
This is getting dire at this point. I cannot log into my Outlook (dot) com account on Debian 12. I have 2 factor authentication on and have tried using an app password but I keep getting an error about "Login failed, server replied: A000004 NO AUTHENTICATE failed." We need OAUTH2 logins supported immediately on Kontact.
I can also confirm it is no longer working and I am getting the A000004 NO AUTHENTICATE error in KMail on Fedora 40 with a personal Outlook account. I'd really prefer staying on KDE rather than switching over to Thunderbird
Pushing this. The deadline has already past and I can no longer receive emails in KMail unless a workaround is given.
(In reply to Michael Tsang from comment #19) > Pushing this. The deadline has already past and I can no longer receive > emails in KMail unless a workaround is given. The workaround is given in comment #14, however what needs to be done on the website of Microsoft is quite unclear. At least I could not figure it out.
I ended up adding a normal IMAP account, using output from https://git.sr.ht/~runxiyu/tooch/tree/master/item/ykpsmuttauth/ykpsmuttauth.go as the Password field, and selecting OAUTH2 as the authentication method. The program above is my cleaned-up version of https://github.com/muttmua/mutt/blob/master/contrib/mutt_oauth2.py, which generates a refresh token. The refresh token goes in the password field. This works for me, but it's not obvious, and a proper interface would be appreciated.
(In reply to Runxi Yu from comment #21) > I ended up adding a normal IMAP account, using output from > https://git.sr.ht/~runxiyu/tooch/tree/master/item/ykpsmuttauth/ykpsmuttauth. > go as the Password field, and selecting OAUTH2 as the authentication method. > > The program above is my cleaned-up version of > https://github.com/muttmua/mutt/blob/master/contrib/mutt_oauth2.py, which > generates a refresh token. The refresh token goes in the password field. > > This works for me, but it's not obvious, and a proper interface would be > appreciated. I was wrong; the token expires in about half a hour. That was an access token, not a refresh token.