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.
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].
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 ------------
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.
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.
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.
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.