Kmail, again

email, software

I’m not sitting still with my favorite bike-shedding subject: email clients. Decided to give Kmail another go.

It’s still not good. It looks good, but it is not. Still not…

Let’s start with setup. This used to be and still is extremely laborious. Not only do you have to manually setup up IMAP and SMTP accounts, you also have to manually map them, and every single folder in the accounts, to an ‘identity’. To which you also need to map your PGP key. I thought I’d cut this short by importing from Thunderbird, which is possible. However, this mismatches folders, so the ‘concepts’ folder for one account may be assigned to the ’trash’ folder of another. Complete chaos. After painstakingly reverting all this and setting it correctly, I though I’d test the KDEPIM im-/export tool again. Still does not import correctly, and will generate a huge mess in the process. It seems it needs to connect to each IMAP server first, before it can designate e.g. the ‘sent’ folder as ‘sent’ folder. However, the credentials for the IMAP account are not in the exported settings, but you can’t enter it during import. So, since it can’t find the folder it’ll assign, seemingly, as random one, across any accounts that you may have set up.

I tried to figure out where Kmail/Kontact store their files. Searching across the webs I can’t find this out. I do find that the Akonadi database only holds a copy but isn’t the primary source of config info. However, I can’t figure out where those are then stored. In my HOME, I can only find my IMAP strings in ~/.config/akonadi_imap_resource_*rc, but moving them to another machine does not result in the creation of a mailaccount. I arrived at the following command for gathering all related files, but as I said, putting them back on a new machine does not result in a fully configured Kontact or even Kmail. I should try to add the akonadi-db (after running akonadictl vacuum!). But not yet, I’ll come to that later.

ZSTD_CLEVEL=21 tar -I zstd -cvpf kmail.tar.zst ~/.config/*mail* ~/.config/akonadi*rc

One more thing I couldn’t get to work at all in the Kontact version that comes with Fedora 32, which I run on my work laptop. That thing is setting up Google Calender. I share a few for work, so accessing them is pretty important. The Google-resource setup in this version of Kontact/Korganiser uses a QWebkit/QWebEngine windows for the Google auth workflow. Google complains that I’m using an outdated browser and refuses to auth. Accessing the Google calenders over CalDAV doesn’t work either (results in HTTP error 401), presumably because Google requires clients to not access the resource over HTTP but HTTPS/OAUTH.

Using the very current Flatpak image for Kontact I could establish that the former (Google OAUTH) works now, because the system browser is used rather than a Qt-provided one. CalDAV doesn’t work unfortunately, which is how I access the calenders in Thunderbird. Another nice thing is that the flatpak image seems to keep its config confined to .var/app/org.kde.kontact, which would make backup simple as I don’t have to keep guessing at which files to backup. However, flatpak Kontact is supercrashy. The 10 minutes I used it, it crashed 10 times. I don’t want to debug any further, so I’ll retry Kmail/Kontact when I upgrade to Fedora 34 in a month or two, which I presume will come with a current version that let’s me setup my Google calenders. Then, I’ll see if I can make a usable backup by including the akanadi-db (which can grow very large because it caches all your mail).

Some other things on my list of things bad about Kmail:

So unfortunate, because Kmail looks good! It’s Qt, it snappy (when it doesn’t crash), descriptions that don’t apply to Thunderbird. In a few months I’ll circle back, checkout the then fully open sourced Mailspring and continue the bikeshedding!