Bug 325524

Summary:	Mail dispatcher stuck in loop when it can't send mail due to SSL problem
Product:	[Frameworks and Libraries] Akonadi	Reporter:	Frank Steinmetzger <dev+kde>
Component:	Mail Dispatcher Agent	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	anmeldungen, brian, mail, vkrause
Priority:	NOR
Version:	4.11
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Frank Steinmetzger 2013-10-01 22:57:30 UTC

At the moment I can't send mails via one of my mail providers (gmx). I first noticed it in mutt, so I tried it with KMail. Upon the first attempt, it shows me a message saying that the SSL certificate does not match the host with the three choices Cancel, View details and Continue.
If I then choose to view the certificate details, a KDE SSL certificate window opens. Once I closed that again, the mail dispatcher agent gets stuck in some kind of loop. It hogs one CPU core and starts eating ever more RAM (3–4 MB per second on this 3 GHz Pentium 4).

I looked at it with Akonadi Console and it said “Sending <email subject> (0%)”. I am able to abort the sending process via the agent’s context menu. Then the CPU load goes back to idle, but the used up memory is not reclaimed. For a while both KMail and the Console becomes unresponsive, but eventually come back.
Subsequent attempts of sending don’t give me the SSL warning, but the agent gets stuck again.

This lockup loop does not occur if I simply abort the sending instead of viewing the SSL details. I don’t really want to try what happens if I choose “Continue”, in case someone really hacked the provider. :o)

I can give you more info if you tell me what you need.

Reproducible: Always

Steps to Reproduce:
Send a mail over an SMTP that is secured with SSL/TLS. SSL authentication fails (host does not match).
Actual Results:
Mail dispatcher agent is stuck in a CPU and memory loop.

Expected Results:
The dispatcher should handle such an event more gracefully.

BTW: When I close the SSL viewer, the dialogue which asked me on how to
process is gone. However, it should still be there, because I haven’t answered
yet whether to proceed or abort.

Comment 1 Frank Steinmetzger 2013-10-01 23:01:58 UTC

Addendum: re-reading my text, it occured to me that “View details” implicitly selects “Continue“ once the SSL viewer is closed. That is not nice behaviour in my opinion, because it is nowhere hinted that it would do that. Either don’t attempt automatic sending afterwards (re-display the messagebox), or reword its choices to [Continue], [View details and continue], [Cancel].

Comment 2 Jan 2013-11-14 11:22:33 UTC

I had same similar problem. Starting akonadi from the command line, i get these messages over and over again and the mail isn't displayed in kmail.
------------
akonadi_imap_resource_4(12395)/kdepimlibs (kimap) KIMAP::SessionThread::reconnect: connectToHostEncrypted "217.8.55.178" 8752
akonadi_imap_resource_4(12395)/kssl KTcpSocket::showSslErrors: "Der Name des Hosts ist keiner aus der Liste der für dieses Zertifikat gültigen Hosts"
akonadi_imap_resource_4(12395)/kssl KTcpSocket::showSslErrors: "Das Zertifikat ist selbstsigniert und daher nicht vertrauenswürdig"
akonadi_imap_resource_4(12395)/kdepimlibs (kimap) KIMAP::SessionThread::reconnect: connectToHostEncrypted "217.8.55.178" 8752
------------

Comment 3 Brian DeRocher 2013-11-20 15:16:32 UTC

I have this issue too.  Yesterday i renewed the TLS certificate.  Today the machine was slow.  The mail dispatcher agent was pegged.  I killed the process and a new one spawned up.  There was a dialog box to confirm the certificate.  It still had the old one.  I viewed the details of that certificate, and then the confirmation dialog was gone.  I agree, that needs improvement.

I opened Kmail and removed the outgoing account and recreated it.  In Akonadi Console, i removed the agent and created a new one.

My machine is behaving better now.

Comment 4 Brian DeRocher 2013-11-20 15:24:00 UTC

I would like to add, the akonadi connection for the DAV calendar probably had a similar issue.  It was hogging the cpu.  I killed that process too.

Regarding confirming the certificate above, it's was difficult or impossible to see which process wanted me to confirm this certificate.  Perhaps not an issue when you *just* made a connection, but when you machine starts up and you get multiple certificate dialog boxes, you should know what they are for.

Memory usage was very high for both the dispatcher agent and the davgroupware agent.  It was higher than virtuoso and iceweasel (firefox).  34% iirc.

I did not need to confirm the usage of new certificates because they were signed by CAcert.

Comment 5 Denis Kurz 2016-09-24 20:32:39 UTC

This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.

Comment 6 Denis Kurz 2017-01-07 22:49:21 UTC

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.