When the SMTP server uses a self-signed certificate, kmail asks whether to trust the certificate. However, if one clicks on "Details" and leaves the details dialogue with the only button "Close", the former dialogue is also gone and the mail dispatcher starts using more and more memory. Within minutes, heavy swap activity starts.

Reproducible: Always

Steps to Reproduce:
1. Create fresh user and set up kmail (in my test, I first configured a pop3 source)
2. Configure an account for sending with SMTP, TLS and authentication; the outgoing server uses a self-signed certificate in this test
3. Send an e-mail (test body "123")
4. Password dialogue for sending e-mail: enter password and continue
5. Dialogue certificate not signed by trusted authority (actual text is a bit longer) - click "Details"
6. Click "Close" (that's the only way forward)
Actual Results:  
The dialogue "certificate not signed by trusted authority" is missing on the screen and in "top" on the command line, one can see /usr/bin/akonadi_maildispatcher_agent growing RSS memory allocation. On my virtual machine, memory use grows at approximately 10 MiB per second (30 MiB per "top" refresh). I started observing this at around 240 MiB and killed the agent when it reached 1 GiB. After killing the process, the password dialogue re-appears in kmail but after completing it again, the certificate dialogue does still not show. Furthermore, the workaround below indicates that the certificate has been stored as "trusted permanently".

Expected Results:  
After clicking "Close", the dialogue "certificate not signed by trusted authority" should be on the screen again (it should be behind the details dialogue - sorry didn't check moving the details dialogue to the side to see whether it is there while the other dialogue is shown).

Furthermore, the akonadi mail dispatcher agent should not use over 1 GiB of memory as a reaction to some unexpected behavior from the GUI application.

Finally, no decision as to whether the certificate can be trusted should be stored since the user did not make any decision (the user only reviewed the details and hit "Close").

Workaround: After reviewing the certificate, finding it trustworthy and clicking "Close", kill the mail dispatcher (you should soon see it as a process using a lot of memory in "top" or any other system information tool) and restart. Apparently, the certificate has been marked as "trust permanently".

If there is an issue with the certificate, maybe (I didn't test this) it is not too late if you haven't pressed "Close" yet. If so, maybe a restart prevents the certificate details from being accepted.