SUMMARY It is impossible for me to set up a gmail account in Kmail. I use imap and OAuth2. When i select "yes" in the message sent to my mobile phone, there appears a screen of the kmail account whizzard saying: "Sign in with Google temporarily disabled for this app". This happens on Debian testing but today I tried on Neon User Edition too and got the same result. STEPS TO REPRODUCE 1. start with a clean Debian testing/Neon User Edition installation 2. try to create a gmail account in kmail using the account whizzard 3. in my case (imap OAuth2) it ends with a screen saying: "Sign in with Google temporarily disabled for this app" OBSERVED RESULT No gmail account is set up EXPECTED RESULT I get a working gmail account in kmail SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian testing / Neon User Edition (available in About System) KDE Plasma Version: Debian testing 5.14.5 / Neon User Edition 5.15.2 KDE Frameworks Version: Debian 5.54.0 Qt Version: Debian 5.11.3 ADDITIONAL INFORMATION
Created attachment 118581 [details] Error message for gmail sign in Error message displayed by Kontact/Kmail following Gmail authentication failure.
There's currently an issue with the API keys used by Kontact to authenticate against Google. We are working on getting the app re-enabled again for new users. For now, you can use PLAIN authentication method (instead of XOAUTH2/Gmail) to authenticate with Gmail (if you use 2-factor authentication you will need to generate an app-specific password on accounts.google.com).
Created attachment 118627 [details] Greyed out password for Gmail
Created attachment 118628 [details] Greyed out authentication for Gmail
Thank you for your speedy response, glad to hear that work is ongoing. Unfortunately I don't think the workaround will be successful - though very happy to be contradicted. I'm very new to Kontact/Kmail but I believe there are two ways to add mail accounts - within the Configure - Kontact window select Accounts and you then have an option to 'Add...' either 'Add Mail Account' or 'Custom Account' If you go for the first option 'Add Mail Account' then there is no option to choose the PLAIN authentication method - it simply takes you through to the previously posted dialogue which results in the error. With the second option 'Custom Account' - when you enter details of a Gmail account it greys out both the password and the authentication options. See attached screenshots. Again you are back to the previous error. I do use Google 2FA and have created an application specific password, but due to the above 'greying' out there is nowhere to enter this. My OS is Kubuntu 18.04 and Kontact is version 5.7.3. I suspect there will be no way for Gmail users to add accounts until the wider bug is corrected? Again thanks for your help.
Dear Joco, I tried setting up my gmail-account in kmail without succes. This afternoon I looked in the /Settings menu under /Kmail Settings (bottom entry). Then with "Accounts" highlighed on the left side (upper entry) I noticed that everything in the "send" and " receive" tabs was already filled out! I only had to give the generated password in both tabs and kmail worked like a charm. Easier than i thought.
*** Bug 405185 has been marked as a duplicate of this bug. ***
What version of Kontact do you have? Indeed in previous versions it wasn't possible to switch to other authentication methods when the server URL was imap.gmail.com, but in the more recent version (I think since KDE Applications 18.04 or 18.08 - that's Kontact 5.8 or 5.9) it is possible if you select "Custom Account" -> "IMAP" then in the "Advanced" tab, the authentication method combo box should be accessible and you should be able to select PLAIN method and enter your username and password normally.
Daniel - Thanks for your reply. I'm using Kubuntu 18.04 LTS and Kontact is version 5.7.3. I only downloaded it this month (switching from Ubuntu), so that is the version of Kontact that is included in the LTS version of the OS. Sounds like I could try updating to a newer version of Kontact or Kubuntu (or wait for the bug to be fixed). Thanks for your help. PK - Thanks for your reply too; however this didn't work, probably due to version differences.
I was having similar issues with Kmail in KDE Neon where Google was saying Kmail was "Not Verified by Google" (see https://bugs.kde.org/show_bug.cgi?id=405185). Though the error was different, my bug was marked a duplicate of this bug. After receiving recently updated packages (thought Kmail still seems to be the same version), the bug seems to have gone and I can successfully add my gmail account. Interesting, though, Google named the app "Akregator" and not "Kmail".
Sorry, "Akonadi" not "Akregator".
Software openSUSE Tumbleweed 20190723 KDE Plasma version: 5.16.2 KDE Frameworks version: 5.59.0 Qt version: 5.13.0 Kernel version: 5.2.1-1-default OS Type: 64-bit Hardware Processors: 8 x AMD Ryzen 5 2500U wit Radeon Vega Mobile Gfx Memory: 7.5 GiB of RAM
*** Bug 410027 has been marked as a duplicate of this bug. ***
*** Bug 410225 has been marked as a duplicate of this bug. ***
So bwl what is your story? Apart from that you are using openSUSE Tumbelweed etc? If i had to take a gamble I would say that you can't (again) setup a Gmail account in Kmail. At least that is at the moment my problem. I am using Debian (bullseye) testing. Plasma 5.14.5. The issue, dating from march 2019, repeats itself. I get the same error message from Google and my gmail-account is not set up in Kmail.
(In reply to Wolfgang Bauer from comment #13) > *** Bug 410027 has been marked as a duplicate of this bug. *** I am not convinced this (ie my bug entry 410027 being recorded as a duplicate of this bug) is correct. I am not trying to set up a new account. The account has been set up for years, and KMail has been functioning perfectly well accessing it until recently. It may be that the cause is the same, though.
gmail account is valid and integrates with KDE/akonadi on a parallel system (see below): Operating System: openSUSE Tumbleweed 20190723 KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.13.0 Kernel Version: 5.2.1-1-pae OS Type: 32-bit Processors: 2 × Intel® Core™2 Duo CPU E4500 @ 2.20GHz Memory: 1.9 GiB of RAM When initiated on this system (32-bit) a token was generated by google which replaced the password. With the new (64-bit) system no token is being offered by google. Google simply generates the message "Sign in with Google temporarily disabled for this app This app has not yet been verified by Google in order to use Google sign in" Receiving status reads as "ready". Switching from Gmail authentication to PLAIN or LOGIN yields "Server is not available" The 64-bit system is a fresh install with no modification. Previous attempts made to resolve with older builds clearing the akonadi database etc. with no effect. Therefore new build. What (if any) further info can I supply to help resolve this? Kind regards Barry
Système d'exploitation : Debian GNU/Linux Version de KDE Plasma : 5.14.5 Version de Qt : 5.11.3 Version de KDE Frameworks : 5.54.0 Version de noyau : 4.19.0-5-amd64 Type de système d'exploitation : 64-bit Processeurs : 4 × Intel® Core™ i5-6300HQ CPU @ 2.30GHz Mémoire : 11,6 Gio de mémoire vive i get the same probleme on fresh install (kde + debian).
*** Bug 410327 has been marked as a duplicate of this bug. ***
*** Bug 410077 has been marked as a duplicate of this bug. ***
Could we add "oauth" and "gmail" to the bug summary? That might help others find this report and prevent more duplicates, especially under the circumstance that the error message Google gives is localised into the user's language and will thus likely not match the English error message in this bug's summary.
Same issue here: Fedora Rawhide 31 - KMail 5.11.3 And here: Debian Buster - KMail 4.18
Same issue: Kubuntu 19.04 (fresh install) Kde Plasma: 5.15.4 Kde Frameworks: 5.56.0 Qt: 5.12,2 Kernel: 5.0.0-21
Same issue: was working after setting to plain auth from GMAIL, but as of today will not sync at all with any auth settings. KDE Neon 5.16 (fresh install) Kde Plasma: 5.16.4 Kde Frameworks: 5.60.0 Qt: 5.12.3 Kernel: 5.0.0-24
Manjaro and Arch linux latest updates also failing Kde Plasma: 5.16.3/4 Kde Frameworks: 5.60.0 Qt: 5.13 Kernel: 5.2.2-1-MANJARO
The same damn thing on Kubuntu 19.04. I am not able to set up KMail to work with GMail! Ans PLAIN is not working as a workaround BTW.
Just ran into this bug - bloody hell it's annoying. It is working fine on a parallel system (presumably the old token is still valid on that?). The bodge to disable kmail's "gmail" authentication by switching from "imap.gmail.com" to and IP address and using PLAIN authentication has worked for me but this is a poor fix. I can't find any way to switch to PLAIN without nobbling the address which is really annoying but this should (at least) be an available option.
I think this issue just needs to be solved. i mean Akonadi and Gmail needs to work with oauth. and hopefully it needs to be solved asap
(In reply to davidblunkett from comment #28) > Just ran into this bug - bloody hell it's annoying. It is working fine on a > parallel system (presumably the old token is still valid on that?). > > The bodge to disable kmail's "gmail" authentication by switching from > "imap.gmail.com" to and IP address and using PLAIN authentication has worked > for me but this is a poor fix. > > I can't find any way to switch to PLAIN without nobbling the address which > is really annoying but this should (at least) be an available option. Are you sure about the address thing? I have been able to use it by just switching the authentication to SSL/TLS, port 993, PLAIN (still using imap.gmail.com).
*** Bug 410700 has been marked as a duplicate of this bug. ***
Apparently it's not really a bug in the software, but rather a policy problem that needs to be solved. https://mail.kde.org/pipermail/kde-pim/2019-August/042400.html
Created attachment 122012 [details] attachment-31863-0.html Sure Wolfgang, the Google authentication not working I can see as an issue between the Google Goliath and the Akonadi PIM David (guess who's gonna win). But what about the "Custom Account" route not letting me fully customize the settings, but instead forcing me to use the (broken) Google authentication method as soon as it detects the Google IMAP server? In "Custom" mode, I should be in full control of all settings, even to mess them up royally if I so desire - no? Ekkehard On Thu, Aug 8, 2019 at 2:57 AM Wolfgang Bauer <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=404990 > > Wolfgang Bauer <wbauer@tmo.at> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |wbauer@tmo.at > > --- Comment #32 from Wolfgang Bauer <wbauer@tmo.at> --- > Apparently it's not really a bug in the software, but rather a policy > problem > that needs to be solved. > https://mail.kde.org/pipermail/kde-pim/2019-August/042400.html > > -- > You are receiving this mail because: > You are on the CC list for the bug.
(In reply to Ekkehard Blanz from comment #33) > But what > about the "Custom Account" route not letting me fully customize the > settings, but instead forcing me to use the (broken) Google authentication > method as soon as it detects the Google IMAP server? In "Custom" mode, I > should be in full control of all settings, even to mess them up royally if > I so desire - no? I see, so your bug report actually was about not being able to change the settings, which of course is not a duplicate of this. I'll reopen your report then (you should have been able to do that yourself btw... ;-) )
Created attachment 122042 [details] attachment-26075-0.html Yup - I could have made that clearer. I mentioned the "other bug" just to help prioritize this bug, as "my bug" annihilates the only workaround. > I'll reopen your report then (you should have been able to do that yourself btw... ;-) ) I didn't know that I could do that. But let me take this opportunity to say that here my ignorance is really bliss, as this ignorance stems from having to file KDE bug reports only VERY rarely (once in several years as a moderate user), which, and that cannot be stressed enough, is a darn good thing!!! On Fri, Aug 9, 2019 at 5:28 AM Wolfgang Bauer <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=404990 > > --- Comment #34 from Wolfgang Bauer <wbauer@tmo.at> --- > (In reply to Ekkehard Blanz from comment #33) > > But what > > about the "Custom Account" route not letting me fully customize the > > settings, but instead forcing me to use the (broken) Google > authentication > > method as soon as it detects the Google IMAP server? In "Custom" mode, I > > should be in full control of all settings, even to mess them up royally > if > > I so desire - no? > I see, so your bug report actually was about not being able to change the > settings, which of course is not a duplicate of this. > I'll reopen your report then (you should have been able to do that yourself > btw... ;-) ) > > -- > You are receiving this mail because: > You are on the CC list for the bug.
I too just did a fresh install of KDE 19.04...partly so that I could get my Gmail account into the Kontact PIM enviro and am getting that same error: "Sign in with Google temporarily disabled for this app This app has not been verified yet by Google in order to use Google Sign In." I've tried to setup my account using IMAP...and have tried two different App Specific passwords and can't complete the account. Maybe I've missed it in this thread, but is someone supposed to contact Google/Alphabet to get Kontact/Kmail "approved"?
easylee has asked a valid question. Has Google/Alphabet been contacted? By who, when? If not why not? Who owns this problem? Why no recent activity on this? No malice intended. Kind regards, Barry
realy who is in charge to this issue? there are 3 weeks that i can not use my gooogle account with kmail!! does kmail is a bad spyware that google reveal? should i stop use it? what about my others accounts? a kde/kmail user!
It's "simply" Google's new API implementation, but no, I don't know why access hasn't been organised for KMail. Evolution has access to GMail. an ex-KMail user, due to this issue being the final straw.
Hello Team ! Just back to KDE after a long long trip now and found my dearest Kmail not working with Gmail lire said many here "Akonadi is kind of broken..." Possible to get this fixed so we can be back on the track again ! Thank You for your works Blessings !
until this has not been fixed working with kde is a mess ... thunderbird or evolution are no real alternative ... so is there any timeline when this gets fixed?
(In reply to Dirk Davidis from comment #41) > until this has not been fixed working with kde is a mess ... thunderbird or > evolution are no real alternative ... so is there any timeline when this > gets fixed? Are you not able to use the workaround mentioned in comment 2?
https://www.reddit.com/r/kde/comments/cj7t7c/kmail_doesnt_let_me_sign_in_with_gmail/evccssj/ Tldr: It's not a bug in KMail or Akonadi but a Google not being happy with KMail privacy policy.
> Tldr: It's not a bug in KMail or Akonadi but a Google not being happy with > KMail privacy policy. I don't understand what this means in practical terms. Does it matter whether we call it a Kmail / Akonadi bug or Google being unhappy with what it does? After all, we are talking about gmail. The way I see it (and maybe I am wrong, then tell me) it can be fixed two ways: One is to convince Google that they are wrong and change their ways, the other would be to say we accept it as a feature bug and we fix it to make Google happy. I frankly don't care which route is taken as long as it gets done. If it was me, I knew which basket to put my eggs in, but I wouldn't impose... On Friday, August 16, 2019 5:14:22 AM PDT carl wrote: > https://bugs.kde.org/show_bug.cgi?id=404990 > > carl <schwancarl@protonmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |schwancarl@protonmail.com > > --- Comment #43 from carl <schwancarl@protonmail.com> --- > https://www.reddit.com/r/kde/comments/cj7t7c/kmail_doesnt_let_me_sign_in_wit > h_gmail/evccssj/ > > Tldr: It's not a bug in KMail or Akonadi but a Google not being happy with > KMail privacy policy.
As I understand it, there is no bug in KMail that needs fixing; rather, Google needs to unblock KMail.
The work-around (setting the auth method to plain) will only work if you also turn on the "less secure app" use in Google settings. Otherwise it will not authenticate.
Right, that's basically Google trying to get people to use only email clients they pre-approve (obviously their own is on the "we've verified that it's secure" list). KMail isn't the only mail client to experience this issue. I went through the same thing with my mother-in-law's Apple Mail app a month or so ago; new account setup failed in exactly the same way, and the workaround was exactly the same; apparently Google demoted them too. After a few weeks Apple mail somehow got back on the approved list and setup with GMail was easy again. Unfortunately KDE lacks the size and market power of other email client publishers. This may be something we need to escalate to the KDE e.V. I'll see what I can do.
(In reply to Dirk Tombaugh from comment #46) > The work-around (setting the auth method to plain) will only work if you > also turn on the "less secure app" use in Google settings. Otherwise it will > not authenticate. Page https://myaccount.google.com/lesssecureapps complains that I can't turn on "less secure app" when I have 2FA on. So this work-around involves losing some security.
Could all the people who complain so loudly here please contact Google support on the matter? Maybe that helps them to realise that we're not talking about only 1 or 2 users here, but they are actually loosing business. And sometimes public shaming of a company on Twitter or similar and spreading the news through the right channels helps them to understand that they are also damaging their reputation. (In reply to matkaz1003 from comment #48) > Page https://myaccount.google.com/lesssecureapps complains that I can't turn > on "less secure app" when I have 2FA on. So this work-around involves losing > some security. Thanks for the info. My organisation requires 2FA, so using the workaround is not possible at all.
There's nothing to complain about, Google has some requirements, we have to fulfill them if we want to integrate with their services. At some point they found out we do not comply with their requirement, sent us a warning, but I did not have time and energy to act on it, so they blocked new logins. I've now did the necessary changes and filed a request to have the login enabled again.
Hi Daniel, many thanks for taking care. I am sorry for my clear words now but I hope my statements aren't too hurtful. If you defined yourself as responsible maintainer for the KDE PIM - Goggle interface, the statement not having time to take care is frightening. Many people using this piece of KDE software trusting that someone is taking care. If you are no longer willing to support this topic someone else should be assigned as responsible person. However, I can understand your frustration with Google's policies but this should not lead to a situation as we are facing it right now. Thanks again, Sebastian
I understand that. The KDE e.V. board has full access to the API keys on Google Cloud Console, so in the worst case they can handle this themselves or grant access to another member of the community. Historically, I've been taking care of this because I've initially implemented the Google integration and thus I have access to the API keys as well. Usually when some action needs to be taken the Board asks me to handle it. Lately I've been a bit busy, so I wasn't able to act soon enough. Hopefully this was the last action that had to be taken for a long while again :)
(In reply to Daniel Vrátil from comment #50) > I've now did the necessary changes and filed a request to have the login > enabled again. Hi, Daniel, Are you expecting that Google will notify when your request has been processed? I am still seeing "Sign in with Google temporarily disabled for this app" when Akonadi is trying to log into my MFA enabled GMail account. Thanks
For the record (because Daniel's blog post claims otherwise), existing users can indeed be affected by this: I've had two GMail accounts accessed from three serparate machines all start refusing logins over the last few weeks, at different times. It seems like some kind of expiry happens, at which point logins start failing. PLAIN works for me, fortunately. Feels like Google's really skirting anticompetitive/antitrust territory here. But maybe I'd have a different opinion given a bit more transparency on what they were actually asking for. Either way, thanks for going to bat for us, Daniel!
(In reply to Brendon Higgins from comment #54) > For the record (because Daniel's blog post claims otherwise), existing users > [...] In case someone else also wonders what blog post Brendon talks about: https://www.dvratil.cz/2019/08/kontact-google-integration-issue/
(In reply to Brendon Higgins from comment #54) > For the record (because Daniel's blog post claims otherwise), existing users > can indeed be affected by this: I've had two GMail accounts accessed from > three serparate machines all start refusing logins over the last few weeks, > at different times. It seems like some kind of expiry happens, at which > point logins start failing. PLAIN works for me, fortunately. > > Feels like Google's really skirting anticompetitive/antitrust territory > here. But maybe I'd have a different opinion given a bit more transparency > on what they were actually asking for. Either way, thanks for going to bat > for us, Daniel! I can also confirm that existing accounts definitely can be affected. Mine has been configured for a long time and only about 3 weeks ago it started denying me access. I was able to switch to PLAIN authentication using an app specific password though.
What plain authentication you guys are talking about? It's only for outgoing setup, incoming has to be configured in a way it's asked by Google anyway and basically that's where this problem is happening at least for me. I have a bunch, around 10 account setup in the right way in Kontact, I have 2 step auth.. so there is no option to set less secure app in Google account but in that case it won't be necessary in theory. It doesn't work for me either, same message appears for all of my account so I just wait.
(In reply to Andras from comment #57) > What plain authentication you guys are talking about? It's only for outgoing > setup, incoming has to be configured in a way it's asked by Google anyway > and basically that's where this problem is happening at least for me. I have > a bunch, around 10 account setup in the right way in Kontact, I have 2 step > auth.. so there is no option to set less secure app in Google account but in > that case it won't be necessary in theory. It doesn't work for me either, > same message appears for all of my account so I just wait. You can do the same for incoming mail by going to the 'connection settings' section of the 'advanced' tab in the dialog that opens when you click 'modify' on an incoming account.
(In reply to Kishore Gopalakrishnan from comment #58) Oh my I just didn't noticed this cuz so obvious I'd love to use Google's supervision for login lol. Anyways thanks it works for me. Probably I've to use this option for now hm. Also correction, I meant it's not possible to turn on less secure app when there is 2 step verification is used and in this case Google gives the option for app password what should work for less secure apps too, well it doesn't work either. I used my accounts in Kontact with app pw for years and now I had to reconfigure Akonandi for whatever misbehaving after some upgrade and this message just started appearing for all of my setup. Anyways, I hope it'll be solved somehow soon.
*** Bug 411248 has been marked as a duplicate of this bug. ***
Any further update on this? Down for 6 months now !
(In reply to Daniel Vrátil from comment #50) > I've now did the necessary changes and filed a request to have the login > enabled again. Hi Daniel! Do you have news from Google? Was the information about the access / permissions Akonadi requests you provided to them enough?
Same problem on Kubuntu 19.04; Might this problem get fixed in 19.10? KMail 5.10.3 KDE Plasma 5.15.4 KDE Frameworks 5.56.0 Qt 5.12.2
*** Bug 412873 has been marked as a duplicate of this bug. ***
Hi everybody, I'd like to confirm (should this help anyone else) I've been able to set up a Gmail account by using PLAIN authentication and a password app from Google Security Settings. Just setup the Gmail account inside Kmail normally, double check it does not work, then manually change server to imap.gmail.com, set the password as above said, change server settings to SSL-TLS port 993 auth PLAIN. Worked for me.
At Kubuntu 18.04 with backports Kontact 5.7.3 I am able to generate app specific password via google account, but switching to plane is not possible. Whenever i put imap.gmail.com as imap server address, the password option get gray with no possibility to set password. BTW There are only 2 places in Kontact I can find plain authentication: smtp settings, which I believe is not the one to change, but in imap settings there is only Sieve settings have this option. Is this the place to change to plain? anyway this is also greyed-out when gmail is imap server. Could somebody please produce step by step instructions for this workaround so that more people like me - not being power users could work with gmail accounts / calendars / contacts? have a nice day Piotr
Created attachment 123235 [details] kmail settings I managed to get kmail going by walking the road that leads to the failure message of Google but stil saying "create account" in kmail. After that when you go to the kmail settings there is (in my case) one gmail-item under "receive" (ontvangen) and one gmail item under "send" (verzenden). By dubbel-clicking on those items you can open them and edit them. There you can fil in the following: receive... - Imap server: imap.gmail.com connection settings - SSL/TLS - 993 - PLAIN send... - smtp.googlemail of gmail.com connection settings - starttls - 587 - PLAIN (of topic - this is one thing I really like about Evolution Mail (gnome): you only have to fill in your Google credentials ONE TIME in the system settings (on line accounts) and calendar, contacts and email work! Oh how I wish that the kontact pim suite would get this!)
(In reply to wozny.piotr from comment #66) > At Kubuntu 18.04 with backports Kontact 5.7.3 > > I am able to generate app specific password via google account, but > switching to plane is not possible. > > Whenever i put imap.gmail.com as imap server address, the password option > get gray with no possibility to set password. > > BTW There are only 2 places in Kontact I can find plain authentication: smtp > settings, which I believe is not the one to change, but in imap settings > there is only Sieve settings have this option. Is this the place to change > to plain? anyway this is also greyed-out when gmail is imap server. > > Could somebody please produce step by step instructions for this workaround > so that more people like me - not being power users could work with gmail > accounts / calendars / contacts? > > have a nice day > Piotr Just as comment 67 outlined, what I meant with "create the gmail account normally" was to create just as if the 2-factor auth worked. It will fail to complete as previously said, but then you can go in the settings and modify them manually.
(In reply to Daniel Vrátil from comment #50) > I've now did the necessary changes and filed a request to have the login > enabled again. Hello Daniel! Did you hear anything from Google in the last two months? Do they need any more information? Is there anything anyone can help you with?
Hi Daniel, Hi Guys, it is now nearly 6 month + that this feature of KDE Kontact is deactivated. So for me it is not possible to use Kontact anymore. I was there for moving completly from Gnome to KDE. So i use "Franz" to access my mails on KDE. I think it should been resolved now. If not possible then the Team should deactivate oauth2 authentication for Google in KDE Kontact.
(In reply to Dirk Davidis from comment #70) > Hi Daniel, > Hi Guys, > > it is now nearly 6 month + that this feature of KDE Kontact is deactivated. > So for me it is not possible to use Kontact anymore. I was there for moving > completly from Gnome to KDE. So i use "Franz" to access my mails on KDE. I > think it should been resolved now. If not possible then the Team should > deactivate oauth2 authentication for Google in KDE Kontact. I'd say also, since this looks to me more of a legal than software issue, shall we (users) do anything/complain everywhere, just ask us. I'm personally keen in using Kmail since it's a great client - I think others here also are, and would surely participate to a group complain to Google or anything similar. Hadn't it ever worked I'd be like "ok, never mind", but it did. It's unacceptable.
*** Bug 413472 has been marked as a duplicate of this bug. ***
Hi all, there is no update since weeks on this bug/issue. it seems no high priority as far as i can see. no answer to our questions is an answer ;-). it is sad to see that gmail and kontact with oauth2 comes unusable in KDE .... . it would be glad when someone from kde can tell us if this issue will be solved or not.
Well, it seems, that the relationship to google is lacking in general. Here's an assortment of my own findings: https://bugs.kde.org/show_bug.cgi?id=414010, https://bugs.kde.org/show_bug.cgi?id=410936
Workaround doesn't work in Kmail v5.7.3 because both password and connection settings (to set to "plain") are disabled. Even for a freshly created IMAP connection. Something in KDE is disabling these because the email is @gmail ?
Yup, as soon as you set the IMAP server to imap.gmail.com you can see the password field goes disabled and the advanced connection settings are disabled and "gmail" type is forced. This "helpful" would seem easy to undo, and then at least there would then be a way to connect KMail to Gmail again, because right now the feature is dead (and has been for months ?!?).
Can't even work around this by using Akonadi Console to ('configure remote') set the Authentication to "1" instead of "9" because it's reset shortly after Kmail starts, and you get the popup of doom from Google again :(
For me just oauth2 will work in my GSuite Account so all other workarounds dont. So i am still waiting that this issue will be sorted out after mmmmh more then half a year.
I suggest we users try to make a more appropriate complaint. A Google group maybe? Anything google may take more care of than KDE bugtracking system? I don't know, I'm asking anyone with more experience. It's not exactly fair it all seems like it's KDE's fault whereas it's Google unreasonably f*cking us. Moreover it used to work initially and pretty soon as the strong auth methods made their way into G accounts, so why now kmail has suddenly become unsecure to them?
(In reply to Tom Chiverton from comment #75) > Workaround doesn't work in Kmail v5.7.3 because both password and connection > settings (to set to "plain") are disabled. > Even for a freshly created IMAP connection. > Something in KDE is disabling these because the email is @gmail ? Try to use imap.googlemail.com as server, see https://bugs.kde.org/show_bug.cgi?id=410700#c3
That works, nice.
Are we going to throw a party for this poor little bug when it is a year old ? What a complete shambles. Who owns this problem and what is being done to progress it? The lack of concrete information is shameful. Can someone please take responsibility for this and provide an update. No more workarounds or blame shifting. Be professional.
FYI, for those wanting an update, the last status update was comment #50 , and now the onus is on google's side to act on it.
So comment 50 by Daniel on 18.08.2019 Indicated a request to have the login enabled again was submitted Since then . . . . What? Please understand this is not aimed at Daniel. He stated that he is too busy, but also that the KDE e.V.board has access to the API keys and can delegate this task to others if Daniel has no time. Therefore we need to know when was the last contact with Google and when can we expect a response. The KDE e.V. board need to wake up and start handling this properly and professionally. No single point of failure.
Right now I would say the single point of failure is on Google. KDE (Daniel and everyone else) can only do so much. They don't have the pull of say Microsoft. It is frustrating, but instead of commenting here about it being a KDE issue, we need to start complaining to Google (if that is even possible).
I notice this bug report is assigned to Akonadi. But KAccounts also suffers from the same issue. Should we perhaps create another bug report about it, or would that be a duplicate ?
Yet another comment moaning about the stale nature of this bug follows: I really don't understand why this has been allowed to fester for so long by the KDE developers. A capable email system is an essential component of a desktop system and that means working with key email providers (which gmail is). I realise there is an inelegant kludge to get around this problem but it comes at a cost of constant whinging from google about security and the kludge is not a fit way for regular lay users to use email. Leaving this to fester is sticking two fingers up to friendly computing and saying to non-technically savvy users "find a better OS". When they find a better OS, the critical mass for KDE will **** off and it will wither. That's a shame because I quite like KDE. This rant comes from me having to fix yet another lay users' kmail, spend an hour arsing around with kmail and akonadi, putting up with gmail's whinging etc. I think next time the answer will be a more cared for desktop. Lay users cannot be arsed with this and they will go elsewhere. Perhaps we shouldn't care but it seems sad if we don't. Replies that say "it's in google's hands" don't count, the rest of the world seems to be able to work it.
You don't have to stop using all KDE software; you can just swap KMail out for Thunderbird for example, and it works great. That's what I had to do. :(
This still doesn't work? Wow, I (too) reported this months ago. At risk of another "me too" reply, yes, me too. Evolution works just fine under KDE, with GoogleMail, and has address book and calendar, as the K-suite has, and doesn't have Akonadi, which is also a great plus.
With my board hat on: We'll look into what we can do to push this forward. Daniel, could you send us info on the ticket you raised with Google so we may take it up for you if you're too busy? Note we'll push for getting this process and the access credentials documented with the sysadmin team, to avoid things getting stuck in the future. If you need to escalate to us it usually already went wrong ideal-process-wise :-)
Dear audience, Regarding this issue, simple workarounds exist, follow https://bugs.kde.org/show_bug.cgi?id=410700 please. In general, it would be nice to not spread FUD about Akonadi/Kmail. As a long time heavy user (once started with KDE 2), I can confirm, that Akonadi/Kmail is one of the most powerful MUAs available today. If you have high demands, you need to tweak the defaults a bit (e.g. by using PostgreSQL) and provide enough resources. But be assured, that the only MUA that comes close, Thunderbird, start to suck rocks, if you throw enough mails on it. My biggest mailbox is about 140 GB(!), and I have a dozen accounts to manage.. Kmail starts in less than 60 seconds, with a full scan on it! Try this with Thunderbird. Sure, issues exist. An currently, the google integration sucks in several ways. But basically, it is good enough to be used on a daily base.
There is no FUD. KDE should pull the GMail integration from KMail, instead setting up a pure IMAP link, unless or until they win the fight with Google. This would be an excellent interim solution that would lead to frustrated users (see above).
If mail was the only feature I cared about, I would just use IMAP and not really care about this issue. However, I need to plugin for Google Calendar support. There is no good read/write workaround for that which I know of.
(In reply to Tom Chiverton from comment #92) > There is no FUD. > > KDE should pull the GMail integration from KMail, instead setting up a pure > IMAP link, unless or until they win the fight with Google. > > This would be an excellent interim solution that would lead to frustrated > users (see above). Interesting that it is such an issue for this project. I by now have moved to Thunderbird and email (IMAP) & calendar integration works like a charm. For the calendar to synchronize in bi-directionally, you need to grab and install this Addon: https://addons.thunderbird.net/en-US/thunderbird/addon/provider-for-google-calendar/ I've got thte information from this video: https://www.youtube.com/watch?v=wbN9hHGNwIM
Google is disabling password access altogether I got the following email yesterday: ---------------- From: The G Suite Team <gsuite-noreply@google.com> Beginning June 15, 2020, non-Google apps that use only a password to access Google accounts will no longer be supported. Starting February 15, 2021, G Suite accounts will only allow access to apps using OAuth. Password-based access will no longer be supported. Dear Administrator, We're constantly working to improve the security of your organization's Google accounts. As part of this effort, and in consideration of the current threat landscape, we'll be turning off access to less secure apps (LSA) — non-Google apps that can access your Google account with only a username and password, without requiring any additional verification steps. Access through only a username and password makes your account more vulnerable to hijacking attempts. Moving forward, only apps that support a more modern and secure access method called OAuth will be able to access your G Suite account. Access to LSAs will be turned off in two stages: June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts. What do I need to do? To continue using a specific app with your G Suite accounts, users in your organization must switch to a more secure type of access called OAuth. This connection method allows apps to access accounts with a digital key instead of requiring a user to reveal their username and password. We recommend that you share the user instructions (included below) with individuals in your organization to help them make the necessary changes. Alternatively, if your organization is using custom tools, you can ask the developer of the tool to update it to use OAuth. Developer instructions are also included below. MDM configuration If your organization uses a mobile device management (MDM) provider to configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, these services will be phased out according to the timeline below: June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for new users. February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth. Other less secure apps For any other LSA, ask the developer of the app you are using to start supporting OAuth. If you use other apps on iOS or MacOS that access your G Suite account information through only a password, most access issues can be resolved by removing then re-adding your account. When you add it back, make sure to select Google as the account type to automatically use OAuth. Scanners and other devices No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth. User instructions If you are using an app that accesses your Google account with only a username and password, take one of the following actions to switch to a more secure method and continue to access your email, calendar, or contacts. If you do not take one of the following actions, when LSA access is discontinued after February 15, 2021, you will begin receiving an error message that your username-password combination is incorrect. Email If you are using stand-alone Outlook 2016 or earlier, move to Office 365 (a web-based version of Outlook) or Outlook 2019, both of which support OAuth access. Alternatively you can use G Suite Sync for Microsoft Outlook. If you are using Thunderbird or another email client, re-add your Google Account and configure it to use IMAP with OAuth. If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use only a password to login, you'll need to remove and re-add your account. When you add it back, select “sign in with Google” to automatically use OAuth. Mac OS iOS mail app view Mac OS mail app view iOS Calendar If you use CalDAV to give an app or device access to your calendar, switch to a method that supports OAuth. We recommend the Google Calendar app [Web/iOS/Android] as the most secure app to use with your G Suite account. If your G Suite account is linked to the calendar app in iOS or MacOS and uses only a password to login, you'll need to remove and re-add your account to your device. When you add it back, select “sign in with Google” to automatically use OAuth. Read more Contacts If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and uses only a password to login, you'll need to remove your account. When you add it back, select “sign in with Google” to automatically use OAuth. Read More If your G Suite account is syncing contacts to any other platform or app via CardDAV and uses only a password to login, switch to a method that supports OAuth. Note: If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth, or ask your admin to contact the supplier of your app and request that they add OAuth as a way of connecting your Google account. Developer instructions To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps. How can I get help? If you have additional questions or need assistance, please contact G Suite support. When you call or submit your support case, reference issue number 145694552. Thanks for choosing G Suite. —The G Suite Team
(In reply to Nicholas Sushkin from comment #95) > Google is disabling password access altogether > > I got the following email yesterday: > > ---------------- > From: The G Suite Team <gsuite-noreply@google.com> > > Beginning June 15, 2020, non-Google apps that use only a password to access > Google accounts will no longer be supported. > > Starting February 15, 2021, G Suite accounts will only allow access to apps > using OAuth. Password-based access will no longer be supported. > > Dear Administrator, > > We're constantly working to improve the security of your organization's > Google accounts. As part of this effort, and in consideration of the > current threat landscape, we'll be turning off access to less secure apps > (LSA) — non-Google apps that can access your Google account with only a > username and password, without requiring any additional verification steps. > Access through only a username and password makes your account more > vulnerable to hijacking attempts. Moving forward, only apps that support a > more modern and secure access method called OAuth will be able to access > your G Suite account. > > Access to LSAs will be turned off in two stages: > > > June 15, 2020 - Users who try to connect to an LSA for the first time will > no longer be able to do so. This includes third-party apps that allow > password-only access to Google calendars, contacts, and email via protocols > such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to > this date will be able to continue using them until usage of all LSAs is > turned off. > February 15, 2021 - Access to LSAs will be turned off for all G Suite > accounts. > > What do I need to do? > > To continue using a specific app with your G Suite accounts, users in your > organization must switch to a more secure type of access called OAuth. This > connection method allows apps to access accounts with a digital key instead > of requiring a user to reveal their username and password. We recommend > that you share the user instructions (included below) with individuals in > your organization to help them make the necessary changes. Alternatively, > if your organization is using custom tools, you can ask the developer of > the tool to update it to use OAuth. Developer instructions are also > included below. > > MDM configuration > > If your organization uses a mobile device management (MDM) provider to > configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, > these services will be phased out according to the timeline below: > > > June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync > (Google Sync) will no longer work for new users. > February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange > ActiveSync (Google Sync) will no longer work for existing users. Admins > will need to push a Google Account using their MDM provider, which will > re-add their Google accounts to iOS devices using OAuth. > > Other less secure apps > > > For any other LSA, ask the developer of the app you are using to start > supporting OAuth. > If you use other apps on iOS or MacOS that access your G Suite account > information through only a password, most access issues can be resolved by > removing then re-adding your account. When you add it back, make sure to > select Google as the account type to automatically use OAuth. > > Scanners and other devices > > No change is required for scanners or other devices using simple mail > transfer protocol (SMTP) or LSAs to send emails. If you replace your > device, look for one that sends email using OAuth. > > User instructions > > If you are using an app that accesses your Google account with only a > username and password, take one of the following actions to switch to a > more secure method and continue to access your email, calendar, or > contacts. If you do not take one of the following actions, when LSA access > is discontinued after February 15, 2021, you will begin receiving an error > message that your username-password combination is incorrect. > > Email > > > If you are using stand-alone Outlook 2016 or earlier, move to Office 365 (a > web-based version of Outlook) or Outlook 2019, both of which support OAuth > access. Alternatively you can use G Suite Sync for Microsoft Outlook. > If you are using Thunderbird or another email client, re-add your Google > Account and configure it to use IMAP with OAuth. > If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use > only a password to login, you'll need to remove and re-add your account. > When you add it back, select “sign in with Google” to automatically use > OAuth. > > > Mac OS iOS > > > mail app view Mac OS > > mail app view iOS > > > > Calendar > > > If you use CalDAV to give an app or device access to your calendar, switch > to a method that supports OAuth. We recommend the Google Calendar app > [Web/iOS/Android] as the most secure app to use with your G Suite account. > If your G Suite account is linked to the calendar app in iOS or MacOS and > uses only a password to login, you'll need to remove and re-add your > account to your device. When you add it back, select “sign in with Google” > to automatically use OAuth. Read more > > Contacts > > > If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and > uses only a password to login, you'll need to remove your account. When you > add it back, select “sign in with Google” to automatically use OAuth. Read > More > If your G Suite account is syncing contacts to any other platform or app > via CardDAV and uses only a password to login, switch to a method that > supports OAuth. > > Note: If the app you are using does not support OAuth, you will need to > switch to an app that offers OAuth, or ask your admin to contact the > supplier of your app and request that they add OAuth as a way of connecting > your Google account. > > Developer instructions > > To maintain compatibility with G Suite accounts, update your app to use > OAuth 2.0 as a connection method. To get started, follow our developer > guide on using OAuth 2.0 to access Google APIs. You can also refer to our > guide on OAuth 2.0 for mobile & desktop apps. > > How can I get help? > > If you have additional questions or need assistance, please contact G Suite > support. When you call or submit your support case, reference issue number > 145694552. > > Thanks for choosing G Suite. > > —The G Suite Team This all is starting to sound like a joke to me. Timing was great.
Starting today I can no longer even send email via KMail. Can we please get Google to re-authorize KMail?
I have a idea for workaround. For the context, read carefully: https://developers.google.com/gmail/api/auth/about-auth It mentions verification of *public* applications. Google permits usage of Google APIs without app verification unless you application is published. For example, I use my own little script for automated processing of some specific types of emails that I receive daily on my Gmail address - Google doesn't care about verification in this case because it's my personal app. So, what if we let KMail users create their "applications" at Google API Console [1] and force KMail to use the new app token instead of the KMail's official token? This sounds like an abuse Google APIs at first, but we can view this as if the user forked KMail and created a new app token for it since their "forked" version of KMail is now personal application. To make this workaround easy to employ, we need to un-hardcode the Akonadi's Google app ID and put it in a configuration file. At the moment it is hardcoded as https://github.com/KDE/kdepim-runtime/search?q=554041944266 - in these two files: - resources/google/common/googlesettings.cpp - resources/imap/gmailpasswordrequester.cpp [1] https://console.developers.google.com/
*** Bug 415280 has been marked as a duplicate of this bug. ***
Looks like this has now gone across the KDE platform. After re-installing KDE/Tumbleweed, I can no longer sign into google via the system settings > online accounts nor via dolphin > networks.
Agree, same here. This had me to unfortunately shift towards the gnome desktop environment. Hope this will be addressed really soon. Cheers, David -------- Original message -------- From: David Bate <bugzilla_noreply@kde.org> Date: Sun, 29 Dec 2019, 17:34 To: dsijbesma@gmail.com Subject: [Akonadi] [Bug 404990] Sign in with Google temporarily disabled for this app https://bugs.kde.org/show_bug.cgi?id=404990 --- Comment #100 from David Bate <va3dbj@outlook.com> --- Looks like this has now gone across the KDE platform. After re-installing KDE/Tumbleweed, I can no longer sign into google via the system settings > online accounts nor via dolphin > networks. -- You are receiving this mail because: You are on the CC list for the bug.
Hi everybody, first of all, Happy New Year! I'm pretty curious, is there any idea about an eta of a fixed version? Next to that, is ther anything I can help with? Cheers, David On Sun, 2019-12-29 at 16:34 +0000, David Bate wrote: > https://bugs.kde.org/show_bug.cgi?id=404990 > > --- Comment #100 from David Bate <va3dbj@outlook.com> --- > Looks like this has now gone across the KDE platform. After re- > installing > KDE/Tumbleweed, I can no longer sign into google via the system > settings > > online accounts nor via dolphin > networks. >
(In reply to Daniel Vrátil from comment #50) > I've now did the necessary changes and filed a request to have the login > enabled again. Best of luck in 2020, everyone! Indeed, is there any news on the progress of the request you filed, Daniel? Since this issue is now relevant not only to KMail but the whole K-stack, it seems a bit odd for Google to ~ignore~ process the request for so long. Sorry if I've missed it, but does this request cover just KMail or will KOrganizer get fixed as well as a result?
I received a response from Adriaan de Groot <groot@kde.org>: > Please see https://euroquis.nl/kde/2020/01/13/google.html .. there is progress, although Google's review of KMail's use of access to GMail is still pending. tl;dr: The contacts and calendar issues should be fixed by the upcoming February 2020 update of KDE Apps, but the email problem is still work in progress.
I am able to get back in and now everything is working as it was before the total shutout. Calendar/Contact are now working and email is working again via the "Plain" setting. The glitch at the moment is the files access. I went through the motions via the KDE settings, online accounts, it went through the approval and a window came up saying the Google files access is now available and now (Google) is now listed. But now when i click on Google in dolphin, a New Account icon is showing, not the actual file area. I click on that, and it open the Online Accounts, with (Google) already there. Kinda takes you through a bit of a repeated cycle. You never do actually get to your files on Google, even though the earlier process said it was completed. Hmm..
I confirm: On Fedora 31 Google Contacts, Calendars and Tasks work again in Akonadi (as expected from Adriaan's reply), while GMail does not (which is also as expected).
In case you want to know more of the background, there is an article in German magazine iX and Heise Online. In the last paragraph, the KDE PIM issue is being mentioned. https://www.heise.de/ix/meldung/Mailbox-org-Google-sperrt-unsichere-Dritte-von-Kalender-aus-4640540.html
Unfortunately GMail is still blocked, but Evolution works. It's a shame that you can't use kmail under KDE but have to switch to GTK Greeting
May I kindly ask you to read https://bugs.kde.org/show_bug.cgi?id=404990#c91 Thanks
Are we having a birthday party for this bug next month?
(In reply to davidblunkett from comment #110) > Are we having a birthday party for this bug next month? Definitely the way to go
Funnily enough, I managed to declare my Google accounts in the "Online accounts". This seems to handle the OAuth2 process better (but that does not translate into KMail being set up). Perhaps as a workaround there's a way to copy the credentials stored in .config/libaccounts-glib/accounts.db into akonadi's wallet entries
The issue is also found for me at Kubuntu 18.04 when using Kio Gdrive from Dolphin.
(In reply to Said Bakr from comment #113) > The issue is also found for me at Kubuntu 18.04 when using Kio Gdrive from > Dolphin. That's fixed already (in kaccounts-providers 19.12.2): https://cgit.kde.org/kaccounts-providers.git/commit/?id=0a71da4e3caae0defe200a85954fc7e2012010c1 But that has nothing to do with Akonadi or its IMAP resource.
*** Removed by KDE Sysadmin ***
*** Removed by KDE Sysadmin *** Really unfair :'(
Well, this bug is one year old now and as youthful as it has ever been - I suspect it might have the same longevity as the ever youthful "Multiple merge candidates, aborting" bug.
That's not a reason for spamming dozens of users with your useless comment. Unless you have valuable input for this bug report (spoiler: you don't), please avoid commenting.
Created attachment 126602 [details] attachment-13124-0.html All, Any news on this, what's the current status? As mentioned before, I'm happy to contribute to speed up the process. Please let me know! Cheers, David On Wed, Mar 4, 2020, 18:58 Christophe Giboudeaux <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=404990 > > --- Comment #118 from Christophe Giboudeaux <christophe@krop.fr> --- > That's not a reason for spamming dozens of users with your useless comment. > > Unless you have valuable input for this bug report (spoiler: you don't), > please > avoid commenting. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
*** Bug 419913 has been marked as a duplicate of this bug. ***
So, this bug is still ongoing, for more than one year. When Kontact can't register an account with the login page, it should at least point out to a help page which contains more information about that. Apart from that: GMail is one of the largest providers in the world and KDE one of the largest IDEs out there - it should be possible to find a solution for the users!
Google has approved KMail access to Gmail via Googla Sign-in today, so it should work again. Should you still see some errors, please let us know. https://www.reddit.com/r/kde/comments/gi5bol/kmailkontact_oauth_signin_with_gmail_enabled_again/
Thank you, it works! :)
To my regret I must say that on my system it doesn't work (completely). - to start I tried configuring kmail using the new tool in the systemsettings and that didn't work at all - the I used the good old account wizzard of kmail itself and that went fine. Only when I, some time later, tried to send an email, it went wrong. I was informed that to send an email I had to use a app-specific password or so.
It works on my side. OpenSUSE Tubleweed updated to the latest patches. So really glad. Thanks, David On Tuesday, May 12, 2020 7:20:55 PM CEST you wrote: > https://bugs.kde.org/show_bug.cgi?id=404990 > > --- Comment #124 from PK <pieterkristensen@gmail.com> --- > To my regret I must say that on my system it doesn't work (completely). > - to start I tried configuring kmail using the new tool in the > systemsettings and that didn't work at all > - the I used the good old account wizzard of kmail itself and that went > fine. Only when I, some time later, tried to send an email, it went wrong. > I was informed that to send an email I had to use a app-specific password > or so.
(In reply to PK from comment #124) > To my regret I must say that on my system it doesn't work (completely). > - to start I tried configuring kmail using the new tool in the > systemsettings and that didn't work at all > - the I used the good old account wizzard of kmail itself and that went > fine. Only when I, some time later, tried to send an email, it went wrong. > I was informed that to send an email I had to use a app-specific password or > so. I resolved updating the connection settings. Go to Settings > Configure Kmail > Sending tab [1] > Select your Gmail account, then Modify. General tab: - Outgoing email: smtp.gmail.com - Activate "The server requires authentication" - Username: your email address - Password: leave it empty - Save SMTP password: unchecked Advanced tab: - Cipher: STARTTLS - Port: 587 - Authentication: XOAUTH2 Leave all other fields empty and the checkboxes deactivated. With these settings my Kmail works as expected when sending emails. [1] I use Kmail in Italian, so I don't know the exact strings used.
I followed Aldo Latino of comment 126 and it worked flawlessly! Thank you so much! I hope others don't have this problem. But thank you!
I received the news stating this had been addressed, it didn't work either. I simply waited for a few hours, and it worked.
Sending also works, following advice by Aldo. But not very well. I am having to restart akonadi every now-and-then, because other wise, the email never leaves the local outbox. It looks like the restart requests a new [SASL-XOAUTH2] token. Am I doing something wrong? Is this a separate bug report?
(In reply to Vishnu from comment #129) > Sending also works, following advice by Aldo. Okay. > But not very well. I am having to restart akonadi every now-and-then, > because other wise, the email never leaves the local outbox. I do not send email so often, so today I'm seeing that my emails don't leave the outbox. > It looks like the restart requests a new [SASL-XOAUTH2] token. Am I doing > something wrong? Is this a separate bug report? I confirm. Restarting Akonadi (akonadictl restart) "solves" the issue, but perhaps temporarily. I will check in the next days.
(In reply to Aldo Latino from comment #130) > [cut] I confirm. Restarting Akonadi (akonadictl restart) "solves" the issue, but > perhaps temporarily. I will check in the next days. After a few hours I had to restart Akonadi to send an email.
Please discuss issues unrelated to the "Sign in with Google temporarily disabled for this app" message in a separate ticket.
Opened a report for that: https://bugs.kde.org/show_bug.cgi?id=421664