KMail is the open-source email client that I’ve always wanted to use. However, I’ve always given up on it after a few hours or days after running into critical bugs. I gave it another shot this month, and here’s how it went.
I’ve been using Evolution for the last few years. I’ve recently had serious issues with it corrupting messages, and its PGP-integration has been buggy for years. A couple of weeks ago, I needed to send off a PGP-encrypted email to [redacted] regarding a security issue. So, I went looking for alternative email clients. As many times before, KMail was the first option on my list.
KMail has every feature I need, including PGP support and integration with my email provider (IMAP/SMTP) and address book server (CardDAV). It’s recommended by Use plain-text email and formats email messages in the way I like it. It even has a Unicode-compatible spellchecker (something Thunderbird is still missing in !) It’s been an appealing option for me for years.
The last time I used KMail, I ran into a bug where it sent a supposedly PGP-encrypted email in clear-text (unencrypted). PGP is complicated and, understandably, both people and software sometimes mess it up. It has been years since that problem got fixed, and I was willing to give it another try. I thought I’d test and verify that PGP was working before sending off a confidential email, of course. But first, I needed to install it and set up my accounts.
I installed KMail as part of the Kontact suite via Flathub. This is an official release version distributed by the KDE project. I believed this would give me additional security in terms of sandboxing in addition to more frequent and faster updates.
In my experience, software distributed by the upstream developer through Flathub is usually promptly updated within hours of an upstream release. The version of Flathub was over a year out of date and it crashed on start-up. The crash is caused by a problem in Akonadi that was fixed upstream over a year ago. There have been multiple major releases of Kontact since the version of Flathub was last updated. I don’t know why KDE has stopped updating the Flatpak version of Kontact, but I couldn’t use this version.
I fell back to installing KMail from the Fedora Linux repository. This did give me the most recent version of KMail. This version worked for about a second, but then it crashed. After launching it from the terminal, I got this error message:
ERROR:proxy_config_service_linux.cc(589)] inotify_init failed: Too many open files (24)
You’ve probably run into variations of this error if you’ve been using the KDE Plasma Desktop in the last year. The desktop environment keeps leaking inotify listeners (file-change notification registrations) until the system is exhausted. (See KDE bug #423928 among others.) Rebooting puts the system back in working order for a few days.
After logging back into the system, I started KMail again. This time it launched but it didn’t greet me with the new account wizard window. Instead, all I got was an empty window with a local mailbox. I dug around in the menus and found the new account wizard. I didn’t get far into the process before I ran into a new problem, however. I entered my email account information and clicked Next. Nothing happened and I got no feedback that anything had gone wrong. I quit and restarted KMail and tried again a few times with the same result. I then launched it from the terminal again and found the following error message:
accountwizard: QObject::connect(KWallet::Wallet, QEventLoop): invalid nullptr parameter
I checked on my system and found that the KWallet service wasn’t enabled. KWallet is KDE’s authentication and password manager. hadn’t used any other application that required KWallet yet, so this wasn’t unexpected. It was, however, unexpected that KMail didn’t handle the situation. I manually started KWallet and created a default wallet.
I restarted KMail and went through the new account wizard again. I got one step further in the process now that KWallet was running! At this point, KMail tried to connect to my email servers for the first time. It ran into another error message. This was the first and only time through this process that KMail provided an error message without silently failing or requiring me to dig through logs:
Could not convert value of setting 'AccountIdentity' to required type.
This cryptic error message seems to be a generic account-creation error. Using WireShark to monitor the network traffic, I discovered that this issue was caused by KMail attempting to connect to IMAP over the wrong port. The new account wizard attempted to connect over port 143 with STARTTLS, but my email provider only supports full-stream TLS over port 993. These are the two standard options for IMAP. KMail didn’t provide me with a way to change the port number or proceed from this stage.
At this point, my systemd journal kept getting flooded with 8 identical messages every second with an error from Akonadi saying:
Resource id’s don’t match: "akonadi_maildir_resource_1" "akonadi_maildir_resource_0"
—and I’d still not managed to add my email account to KMail! I decided that things weren’t working out, and uninstalled KMail. I believe most people would have given up at this point. However, I wanted to know whether this was indicative to my system or if the problems were indeed KMail’s fault.
A few days later, I set up a fresh installation of Fedora 32 Workstation in a virtual machine. I first updated the new installation and then ran KMail. This time, it didn’t crash and it displayed the new account wizard on start-up. I proceeded to set up my IMAP account. It asked me to create a KWallet and everything appeared to work fine up until it tried to connect to the IMAP server. When I got to that stage it said that account creation had failed, and it opened a dialog asking me if I wanted to enable a feature called unified mailboxes. I believe it’s supposed to ask this question if account creation succeeds, so this suggests the process at least partially succeeded.
I clicked Back in the new account wizard and clicked Next without making any changes. This time it said “Setup complete” while simultaneously opening a dialog asking me to re-enter my IMAP password. I entered it again and KMail immediately opened yet another dialog saying the server had rejected my authentication details. The dialog offered me to cancel, try again, or open account settings. The latter option took me to a dialog where I could set the correct port number for my IMAP server.
I’d finally managed to get through the account creation process! However, this is as far as I got. KMail’s main view turned black and the program stopped responding. This is the state you can see in the screenshot at the top of the article I couldn’t work out what was wrong and KMail and its logs weren’t giving me any more hints.
Somewhat motivated by this progression, I went back to my main system and set up a clean user account. When I opened KMail here I was greeted by the new account wizard. However, it had the same problem with KWallet as my main account. On a hunch, I logged out of the new account, and logged back into it with a GNOME session instead of a KDE Plasma desktop session. I normally use Plasma, but I thought I’d try an environment that was closer to the experience I had in the virtual machine. But it still didn’t work.
I thought I’d give it one last try in a virtual machine using Fedora 32 KDE edition instead of the normal Workstation edition with KDE and Plasma bolted on top after the fact. Again, I run into problems with KWallet. However, instead of enabling it, I logged out of the session in the virtual machine, and then logged back in again. This time, I didn’t run into the KWallet problem — but I still ran into all the problems I’ve previously mentioned.
I’ve literally spent hours and have gotten nowhere with KMail. I think I’ve had enough of KMail for a few years. I just can’t get it to work properly!
Bonus story! I first tried to use KMail maybe 12 years ago. My email password back then contained a percentage and an apostrophe character. KMail used URIs to communicate with its backend, but it failed to properly encode the special characters in the password. This of course caused it to fail to log in to my IMAP and SMTP servers because it didn’t correctly transfer authentication details. The issue also made it impossible to overwrite the saved password with a new one from inside the KMail user interface.