Claws Mail (email program)

I have just experienced, that it is really time consuming and difficult to get Email encryption to work, when using pre-installed programs in antix. In order to comunicate with people and corporations which use S/MIME type of encryption instead of PGP first I installed Thunderbird as E-Mail client. Therein it took not longer than 10 minutes to import the needed certificates and klick two or three checkboxes to be able to comunicate fully end-to-end encrypted.

Now I wanted to give the pre-installed Claws-Mail client a try, and what I experienced with was really annoying.

Even qute familiar with the concepts I had to research some hours, and encountered several error messages. Moreover there where some tricky steps and commands to be executed a normal user never would get through.

I will report the pitfalls I noticed:

1.) The necessery plugin “claws-mail-smime-plugin” is not pre-installed in antiX (ver 17.x, maybe it is in 19 already present, I can’t check.)

an unexperienced user wouldn’t even be able to figure he would want to install it, or even be aware of it.

2.) When trying to find a checkbox to activate email-encryption user is sent to “S/MIME howto” in order to get instructions. So he will check for the prerequisites listed there first:

apt-cache policy pinentry pinentry: Installiert:          (keine) Installationskandidat: (keine) Versionstabelle: maybe he will check anyway:

pinentry --help No $DBUS_SESSION_BUS_ADDRESS found, falling back to curses pinentry-gnome3 (pinentry) 1.0.0 Copyright (C) 2016 g10 Code GmbH License GPLv2+: GNU GPL version 2 or later  This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law which will clearly show pinentry is installed allready.

apt-cache policy ca-certificates ca-certificates: Installiert:          20200601~deb9u1 Installationskandidat: 20200601~deb9u1 Versionstabelle: *** 20200601~deb9u1 500 500 http://ftp.de.debian.org/debian stretch-updates/main i386 Packages 500 http://ftp.de.debian.org/debian stretch/main i386 Packages 100 /var/lib/dpkg/status

apt-cache policy dirmngr dirmngr: Installiert:          2.1.18-8~deb9u4 Installationskandidat: 2.1.18-8~deb9u4 Versionstabelle: 2.2.12-1+deb10u1~bpo9+1 100 100 http://ftp.de.debian.org/debian stretch-backports/main i386 Packages *** 2.1.18-8~deb9u4 500 500 http://ftp.de.debian.org/debian stretch/main i386 Packages 100 /var/lib/dpkg/status 2.1.18-8~deb9u2 500 500 http://security.debian.org stretch/updates/main i386 Packages

apt-cache policy gnupg gnupg: Installiert:          2.1.18-8~deb9u4 Installationskandidat: 2.1.18-8~deb9u4 Versionstabelle: 2.2.12-1+deb10u1~bpo9+1 100 100 http://ftp.de.debian.org/debian stretch-backports/main i386 Packages *** 2.1.18-8~deb9u4 500 500 http://ftp.de.debian.org/debian stretch/main i386 Packages 100 /var/lib/dpkg/status 2.1.18-8~deb9u2 500 500 http://security.debian.org stretch/updates/main i386 Packages

apt-cache policy gpgme N: Paket gpgme kann nicht gefunden werden. gpgme --help bash: gpgme: Kommando nicht gefunden. Do we really need this last one (pgpme) since it doesn’t seem to exist in antiX repos? Further investigation unsheathed there is installed a packet called

apt-cache policy libgpgme11 libgpgme11: Installiert:          1.8.0-3+b2 Installationskandidat: 1.8.0-3+b2 Versionstabelle: 1.12.0-6~bpo9+1 100 100 http://ftp.de.debian.org/debian stretch-backports/main i386 Packages *** 1.8.0-3+b2 500 500 http://ftp.de.debian.org/debian stretch/main i386 Packages 100 /var/lib/dpkg/status Does this replace or represent the program pgpme in antiX? Where in documentation can this peace of information be found?

Well, I assumed it would fit the needs and proceded to next step: “Configuring & running the GPG agent”

ls $HOME/.gnupg/gpg-agent.conf cat: /home/demo/.gnupg/gpg-agent.conf: Datei oder Verzeichnis nicht gefunden turns out file doesn’t exist. so user will create this file and copy following lines into it:

pinentry-program /usr/bin/pinentry default-cache-ttl 86400  # be aware that the passphrases will be cached for 86400 seconds! set accordingly to your needs max-cache-ttl 86400 disable-scdaemon write-env-file ~/.gnupg/.gpg-agent-info allow-mark-trusted keep-display display :0.0 debug-level basic and save it to disk.

Next the guide tells to start gpg-agent using the command which produces confusingly the message it is running allready.

eval 'gpg-agent --daemon' gpg-agent[8197]: /home/demo/.gnupg/gpg-agent.conf:5: obsolete option "write-env-file" - it has no effect gpg-agent[8197]: enabled debug flags: ipc gpg-agent[8197]: DBG: chan_4 <- OK Pleased to meet you, process 8197 gpg-agent[8197]: DBG: chan_4 -> BYE gpg-agent: a gpg-agent is already running - not starting a new one gpg-agent: secmem usage: 0/65536 bytes in 0 blocks so probably user will remember the way services and daemons are started in antiX and try

which will show him there is no deamon named “gpg-agent” existing. How is it to be accessed (restarted) in antiX? He might try

service gpg-agent start gpg-agent: unrecognized service in analogy to all the other services and daemons in use. But this will produce an error message only. At this point normal user is lost.

Let’s step over to next chapter: “Importing S/MIME certificates into gpgsm”

(which is the same as one would have installed in thunderbird.) It contains your private certificate, the root-certificate (Class1) of your Certificate Authority (CA) as well as the intermediate Certificate (Class3) along with your private Key.

Next the guide asks user to import certificates:

which will import 108 keys, but 12 keys are refused. User will not be able to decide from the output whether this is a problem or can be neglected. Now he is asked to test them:

gpgsm --list-secret-keys gpgsm: enabled debug flags: ipc gpgsm: DBG: chan_4 <- OK Pleased to meet you, process 7861 gpgsm: DBG: connection to agent established gpgsm: DBG: chan_4 -> RESET gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttyname=/dev/pts/1 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttytype=xterm gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION display=:0.0 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION xauthority=/home/demo/.Xauthority gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-ctype=de_DE.UTF-8 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-messages=de_DE.UTF-8 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> GETINFO version gpgsm: DBG: chan_4 <- D 2.1.18 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION allow-pinentry-notify gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> HAVEKEY **************************************** gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> KEYINFO **************************************** gpgsm: DBG: chan_4 <- S KEYINFO **************************************** D - - 1 P - - - gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> HAVEKEY **************************************** gpgsm: DBG: chan_4 <- ERR 67108881 Kein geheimer Schlüssel  gpgsm: DBG: chan_4 -> HAVEKEY **************************************** gpgsm: DBG: chan_4 <- ERR 67108881 Kein geheimer Schlüssel  gpgsm: DBG: chan_4 -> HAVEKEY **************************************** gpgsm: DBG: chan_4 <- ERR 67108881 Kein geheimer Schlüssel  gpgsm: DBG: chan_4 -> HAVEKEY **************************************** gpgsm: DBG: chan_4 <- ERR 67108881 Kein geheimer Schlüssel  gpgsm: DBG: chan_4 -> HAVEKEY **************************************** gpgsm: DBG: chan_4 <- ERR 67108881 Kein geheimer Schlüssel  [....] a hundred times [...] /home/demo/.gnupg/pubring.kbx -          ID: *********** S/N: ****** Issuer: /CN=CA Cert Signing Authority/OU=http:\x2f\x2fwww.cacert.org/O=Root CA/EMail=support@cacert.org Subject: /CN=CAcert WoT User/EMail=my.email.address@somewhere.org aka: my.email.address@somewhere.org validity: 2021-01-09 21:43:16 through 2021-07-08 21:43:16 key type: 4096 bit RSA key usage: digitalSignature keyEncipherment keyAgreement ext key usage: emailProtection (suggested), clientAuth (suggested), 1.3.6.1.4.1.311.10.3.4 (suggested), serverGatedCrypto.ms (suggested), serverGatedCrypto.ns (suggested) fingerprint: **:**:**:**:**:**:**:**:*:*:*:*:*:*:*:*:*:*:*:*

secmem usage: 0/16384 bytes in 0 blocks OK, user may be confused a little, and concerned about all these ERR 67108881 messages what lies at the root of these?

At least, his Email certificate is propperly displayed in the end, so he hopefully goes on without sorting out all the other errors.

Configuring GnuPG S/MIME

ls $HOME/.gnupg/gpgsm.conf ls: Zugriff auf '/home/demo/.gnupg/gpgsm.conf' nicht möglich: Datei oder Verzeichnis nicht gefunden well, let’s create this file and put the follwing contents into it:

disable-policy-checks auto-issuer-key-retrieve include-certs -1 # this will include all certificates in the chain up to the root debug-level basic save and exit.

will add the default key to the file. (What will happen if I will have to handle more than one e-mail certificate later, since this one belongs to the email-certificate issued for a specific email address?)

Setting up the trust:

Setting up Claws Mail itself:

Configuration-->Plugins, activate: PGP/Core, S/MIME. Configuration-->Email-Account GPG: Chose Key from e-mail-address. Now everything should be fine, since the .p12 file contains root certificates allready. But trying to sign a mail now produces an error message:

What the heck!?

I decided to install these certificates which build the chain again manually (they should have been present, since they were merged into the pkcs12 file):

gpgsm --import class3_X0E.crt gpgsm --import root_X0F.crt which led to next error message while trying to send signed mail in claws-Mail:

Well, after researching this error message I found this was due to pinentry wasnt’t able to display on any screen. About twenty different solutions were to be found in internet, including strange loopback constructions. But I decided just to check what applications are present in ls /usr/bin/pinentry* so I tried to enter each of them one after another into gpg-agent.conf file.

Finally, after restarting claws-mail the entry “pinentry-program /usr/bin/pinentry-gtk-2” did the job.

I was sometimes asked to set up additional passwords during the whole proccess I don’t have a clue what these are good for.

And finally, since this is a persistent antiX running from USB-Stick still, how can all these encryption settings get backuped in case of messing up system on next upgrade, what has to be transfered to another USB-Stick, where are alle the corresponding files located? This is a question rather designed for a developer as for standard user. In thunderbird I simply copy one single profile directory and everything is fine.

And finally: will all this still work after next reboot? Or do I have to create some startup entries?

Conclusions of my self-experiment:

The instructions found in the guide claws-mail sends user to during encryption setup ''(“Informationen darüber, wie S/MIME Zertifikate in Verbindung mit GPGSM funktionieren, finden Sie unter:

http://www.claws-mail.org/faq/index.php/S/MIME_howto”)'' will disorient antiX users, since the tools listed there seem not to be present. Indeed, they are present, but in other places and they have partly different names nobody could guess. Moreover they require partly different commands.

You might imagine, I have needed about 3 to 4 hours to get end-to-end encryption working in claws-mail, having the pkcs12 file at hand allready. And now compare this with the setup way employed in thunderbird, which was done in 5 to 10 minutes maximum, selecting the pkcs12 file from a directory and import it, then checking two or three well documented checkboxes in general setings and email-account settings. That was all. No joke.

I really dislike the way mozilla behaves in the last period of time, but in this case they have done something the right path. It is not a really good idea to leave user on his own on this difficult task, foraging in the engine room. Is anybody around who is able to make the process in Claws mail version delivered with antiX more convenient? Maybe a wrapper script might help? At least please point out what is the correct way here? I’m not sure whether I was making some detours after all, or creating some security issues by messing around unknowingly, but finally I got it work at least. This is not what I’d like other antiX users to experience while they enyoy this distro…

I am not that familiar with this encryption tools behind the screen, but I think that normal user would resign at some point in this process.

I managed to get through, but it was a pain. May somebody could tell me whether I have done anything wrong, what would have been the straight way and where it is documented.

-

-

How to deal with more than one email certificate once it would be needed?

Given you have set up the encryption using the components described above for claws mail, you’ll have to edit a config file manually now. Let me start again at the point, having your additional pkcs12 certificate bundle present already (just as you would import it to any other email client also).

1.) Then you need first to perform the command

in a terminal window, using your new certificate this time. In case you obtained it from the same Signing Authority (Root-CA) you had got your first certificate from, you don’t need to re-import their root certificates again, otherwise repeat the correspondent steps from above.

2.) Now enter in terminal window the command

and open the file

using a text editor like “geany” or “leafpad” (again, don’t use a word processing software like e.g. “libreoffice” for this!). Compare the keys displayed from the terminal output carefully with the findings in the trustlist file. Simply add the key which is not present in the file already in a new line of this file, save and close it.

There is no need to restart the deamons.

3.) Start claws mail and look into the account settings of each mail account using encrypted transfer, menu entry “plugins–>s/mime–>signing keys” and set it to “chose key appropriate to email address”. Make also sure you have set in menu “account–>privacy the standard privacy system to “s/mime” and checked all the checkboxes, probably except for the very last, (which says to store all mails unencrypted on your hard drive) according to your needs.

Now claws mail will chose the correct certificate for every email sender address when sending a mail automatically.