Bug 421664

Same history for me.
Sending stops working exactly when the access token acquired at startup or restart expires.
Apparently the software responsible for transferring the message from the Outbox to the smtp server does not handle access token expiry correctly.

akonadi and kmail version 19.04.0

I am in the same, exact situation as Vishnu.

I am using KDE neon 5.19.1 with latest updates.

I have done some debugging and found a couple of issues in smtpjob.cpp (kmailtransport) and accountmanager.cpp (libkgapi).

1.
When SmtpJob::startPasswordRetrieval(true) is executed and calls KGAPI2::AccountManager::instance()->refreshTokens after a successful findAccount, the AccountPromise created for findAccount has not yet been destroyed and is reused by the createPromise function.
Since mRunning is true, the only action of refreshTokens is to return the AccountPromise, and since its emitFinished() has already been executed, nothing more happens.

2.
When the previous AccountPromise is removed from the mPendingPromises hash table before refreshTokens is called, refresh succeeds and the mail is successfully sent to the SMTP server, but the mail is not deleted/moved from the outbox.
This is due to a missing removeSubjob for the TokenExpired case in the SmtpJob::slotResult function, leading to the !hasSubjobs() condition for sending a noError result is not fulfilled.

3.
loginJob:result is connected to SmtpJob::slotResult both explicitly and as a result of addSubJob, leading to  SmtpJob::slotResult receiving duplicated result signals from loginJob.

4.
Not really a problem, but an unsuccessful login attempt on expired token can be avoided by adopting the algorithm used in gmailpasswordrequester.cpp from kdepim-runtime. When refresh is not forced, gmailpasswordrequester calls KGAPI2::AccountManager::instance()->getAccount, which does a token refresh if a comparison between current time and calculated expiry time indicates that it is needed.

5.
Not really related, but the code at the end of SmtpJob::startSmtpJob looks like it could start a password retrieval and a sendjob at the same time.

I too am seeing this
on KMail 5.16.2

I've been having the issue since I installed openSUSE Leap 15.2. After upgrade to 15.3 the problem is still there.

What helps is to turn on "Less secure app access" in the Google account settings and in KMail switch the authentication for sending mail from XOAUTH2 to PLAIN.

This unfortunately lowers the security. More on this here: https://support.google.com/accounts/answer/6010255?p=less-secure-apps&hl=en&visit_id=637647624340977026-1695581600&rd=1#zippy=,if-less-secure-app-access-is-on-for-your-account,update-your-app-or-operating-system,use-more-secure-apps,use-an-app-password

The bug is more than a year old now. Any expectation to get it fixed? I'd be happy to report the bug to openSUSE once it's solved upstream so it can be backported to openSUSE Leap.

*** This bug has been confirmed by popular vote. ***

It seems only oauth will be supported by Gmail from 30 May 2022, so the workaround in comment #5 will stop working then.

Does anyone still have this issue? STMP with XOAUTH2 on Gmail works for me without any problems (I earlier had the issue described here).

SOFTWARE VERSIONS
kmail2 5.20.3 (22.04.3)
Operating System: Arch Linux
KDE Plasma Version: 5.25.2
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5
Kernel Version: 5.18.10-arch1-1 (64-bit)
Graphics Platform: X11

XOAUTH2 does work for me.
However after a period of "idle" time I have to restart akonadi for sending email to work. 
It is now a routine for me now when sending via Gmail to restart akonadi..

My other (non google) mail accounts do not have this issue.

KDE APPS 22.04.3

I don't remember if SMTP worked for me, but POP stoped working a few weeks ago (again) so I decided to just ditch gmail.

(In reply to Kishore Gopalakrishnan from comment #8)
> Does anyone still have this issue? STMP with XOAUTH2 on Gmail works for me
> without any problems (I earlier had the issue described here).

I still have the same problem, SMTP stops working after a while and requires an Akonadi restart so can't realistically use KMail at work any more. 

Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.3
Kernel Version: 5.15.0-41-generic (64-bit)
Graphics Platform: X11

(In reply to Kishore Gopalakrishnan from comment #8)
> Does anyone still have this issue? STMP with XOAUTH2 on Gmail works for me
> without any problems (I earlier had the issue described here).

Yes, irregularly. Every once in a while, e-mail sending fails; in those cases, trying to send it again also fails. Issuing "akonadictl restart" fixes it for a few days. I have KMail and Akonadi 5.20.3 (22.04.3).

I've been having problems sending mail via XOAUTH2 for about a year. Sending will work fine one moment then, for no apparent reason, not work the next. The time between sends does not seem to be an issue. If the computer is up all night and I send a file in the morning, often times the send works, sometimes it doesn't.

Some more detail.

Create message.
Hit send.
Message goes into Outbox.

If message sent, then OK.

If message NOT sent (often get Remote Host closed the connection)
      sometimes, after waiting through multiple Message Sent Failed errors, the message finally gets sent OR
      close KMail, disconnect from internet, reconnect, restart KMail -- often times message will be sent OR
      have to logout, log back-in, restart KMail. Usually that will cause message to be sent.

Running kubuntu. All software is up to date.

I have to use my cell phone as my internet connection, i.e., I do not have high speed internet.

Git commit d677a08c21fd99e7e8be0a0899f797f9237207e4 by Fabian Vogt.
Committed on 22/11/2022 at 07:19.
Pushed by fvogt into branch 'release/22.12'.

Don't cache promises for AccountManager::findAccount

Unlike AccountManager::getAccount and AccountManager::refreshTokens, this
method does not return an authenticated account. However, the promises are
cached for all of them in the same store, so it was possible for a call to
e.g. refreshTokens to get a promise created by findAccount instead, resulting
in an unexpected result. Just don't cache promises created by findAccount.
Related: bug 406839, bug 409122, bug 456923

M  +18   -20   src/core/accountmanager.cpp

https://invent.kde.org/pim/libkgapi/commit/d677a08c21fd99e7e8be0a0899f797f9237207e4

Git commit 7b2a5ccea0c54b81245acdbbea77a13e570bba2b by Fabian Vogt.
Committed on 01/12/2022 at 12:12.
Pushed by fvogt into branch 'release/22.12'.

SmtpJob: Fix use of KCompositeJob

SmtpJob overrides slotResult, but this had two issues. First, it connected
to LoginJob::result itself, though addJob already does that. Second, in two
cases it did not remove finished jobs from the list of subjobs, leading to
dangling pointers and messing up state. This was most likely only reached
in the case of an expired XOAUTH2 access_token and caused the job to fail
after a successful refresh.
Related: bug 406839, bug 409122, bug 456923

M  +2    -2    src/kmailtransport/plugins/smtp/smtpjob.cpp

https://invent.kde.org/pim/kmailtransport/commit/7b2a5ccea0c54b81245acdbbea77a13e570bba2b

Thank you for fixing this. I tested with all my accounts including Gmail and sending works perfectly now, even when the box has been sitting idle for hours sending email still works!
No need to keep restarting akonadi to send Email anymore.