How to configure KMail with GPG on Slackware Linux 14.1

No additional software is required on a full Slackware 14.1 install.
Slackware 14.1 ships with KDE 4.10.5.


If you don’t already have a key pair (secret and public key), then your first order of business is to create one. The preferrable option is to use the CLI with the command:

gpg --gen-key

KDE provides two graphical tools for working with GPG, namely KGpg and Kleopatra.  KGpg will walk you through the initial setup using an interactive wizard and subsequently create the needed key pair and config files (do not use Kleopatra for your initial setup).
If you’re importing an existing private key then make sure to change the default trust level afterwards.

Regarding the key properties, most folks recommend the RSA/RSA algorithm and a key size of 4096 bits (if you’re really paranoid security conscious).

Enabling the GPG Agent on Slackware Linux

The gpg-agent is a daemon to manage secret (private) keys independently from any protocol. It is used as a backend for gpg and gpgsm as well as for a couple of other utilities.

Basically the gpg-agent will take care of caching the passphrase securely between applications and thus removing the need for typing the passphrase everytime we use our key.

Enabling the gpg-agent is simple enough, edit ~/.gnupg/gpg.conf and remove the comment sign in front of the use-agent directive.

# Edit your gpg.conf
vi ~/.gnupg/gpg.conf
# Remove the comment sign in front of use-agent

Configuring pinentry on Slackware Linux

Pinentry is a small collection of dialog programs that allow GnuPG to read passphrases and PIN numbers in a secure manner.

In short, Pinentry will pop up and ask for the passphrase when using our GPG key.

# Create gpg-agent.conf in your home path
vi ~/.gnupg/gpg-agent.conf
# Add the following directives to gpg-agent.conf
pinentry-program /usr/bin/pinentry-qt4
default-cache-ttl 3600

As KDE is based on the Qt framework, pinentry-qt4 is a viable choice (pinentry is also available in curses, qt and gtk-2).
The default-cache-ttl directive specifies the amount of time (in seconds) in which the passphrase should be cached. The no-grab directive avoids having the pinentry dialog glued to your keyboard, which is no fun at all.

Adding startup and shutdown scripts for KDE on Slackware Linux

We need to have the gpg-agent running before KDE starts up. To achieve this, we’ll use two bash scripts that will start and subsequently kill the gpg-agent daemon.

KDE has a feature called “Pre-KDE Startup” that let us run user defined scripts at the earliest stage. Those scripts resides in the ~/.kde/env directory. This folder is not available by default, so we’ll create it and add the script.

# Create the env folder and the startup script
mkdir ~/.kde/env
vi ~/.kde/env/
# Add the code below to
eval "$(gpg-agent --daemon)"
# Make the script executable
chmod +x ~/.kde/env/

We don’t want to have multiple instances of gpg-agent running when logging in and out of sessions. KDE has a Shutdown feature for user defined scripts as well, so we’ll make another script to kill  gpg-agent when our KDE session ends. The shutdown script is to be placed in ~/.kde/shutdown/, another folder that doesn’t exist on a default installation.

# Create the shutdown folder and the shutdown script 
mkdir ~/.kde/shutdown/
vi ~/.kde/shutdown/
# Add the code below to
if [ -n "${GPG_AGENT_INFO}" ]; then
 kill $(echo ${GPG_AGENT_INFO} | cut -d':' -f 2) >/dev/null 2>&1
# Make the script executable
chmod +x ~/.kde/shutdown/

Verify that gpg-agent is running as a daemon

Log out and start a new KDE session.
Run the following code to verify that the gpg-agent is running and available:

gpg-agent status

Configuring KMail

Start KMail and select:
“Settings” => “Configure KMail” => “Manage Identities” => Modify {your identity} => “Cryptography”.

KMail - Cryptography
KMail – Cryptography

Select your key for signing and encryption, and optionally your preferred format. Save and your’e good to go.
You might also want to set signing and encrypting messages as preferred options by editing the default settings under:
“Settings” => “Configure KMail” => “Security” =>  “Composing”.


Don’t fiddle with the GnuPG Log Viewer .
Changing the debug level sounds like a plan during troubleshooting, but it’s not. The result will instead be a corrupted gpg.conf.
If that should be the case then just remove the lines in question, they will look similar to this:

###+++--- GPGConf ---+++###
debug-level guru
Viewing a signed and decrypted message with KMail.
Viewing a signed and decrypted message with KMail. is silently discarding email messages

A while back I did some consulting work for a small ISP who had received complaints from a few customers that believed they could not use the ISP’s SMTP server to send email to or accounts. These customers claimed they never got any bounce message (Non-Delivery Report)  in return, so they firmly believed the problem resided with the ISP. vs Bart Simpson
Dear Microsoftian overlords, we’ll be good from now on.

After checking the IP addresses in question against all publicly available DNS based email blacklists, I performed the standard sender test by using the ISP’s SMTP server to mail a few messages to my own account. This was done while closely monitoring the communication between the ISP’s SMTP server and the receiving SMTP server on behalf of

Any lost soul administrating SMTP servers is painfully aware that there is an abundance of potential errors causing delivery between these servers to fail . The only reliable approach is to observe the message log and study the communication between the sending and receiving SMTP server. In this case, I could confirm that my message was accepted and received by

When I checked my account, I found my message waiting in my inbox as expected. Everything seemed to be working just fine and I suspected this was just another case of mail ending up in the spam folder. I also made sure to check the list of messages reported as not being delivered to from the customers, and could confirm that those messages was received and accepted by mx[1-4] as well.

However, the customers didn’t agree with my assumptions and insisted that the messages I confirmed as being delivered to, never actually made it to the recipient’s inbox. Being out of ideas, I told the customer to contact Microsoft support for further assistance. Microsoft replied a few days later with the following message:

We have not identified any problem with our services, please consult your service provider.

That was a let down as I had already confirmed that the messages in question had been delivered, and there was never any NDR from Besides, that kind of answer told me that “Support” had at best glanced at the service health dashboard. To eliminate the possibility that my sender address had been whitelisted by my own account by reason of prior relationship, I signed up for a brand new account.

When I tried to mail my new account from the same sender address as before, I could again confirm that mx[1-4] accepted and received the message. One notable difference this time around though: the message never ended up in my inbox (or spam folder), even after repeated efforts.

This would suggest (the following is speculation) that in addition to DNS based blocking (which will reject “bad hosts” when connecting to mx[1-4] and whatever other enforced policy they’re applying, Microsoft is also doing some rather aggressive IP filtering on their end. However, this filtering will take the backseat if the sender address is known by the receiving account. I guess this would imply that any address added to your contact list would also be whitelisted.

Providing this additional information to Microsoft finally gave us some answers :

Our research shows that there are no active blocks against these IP’s, but some messages were filtered. We have confirmed that these IP’s qualify for conditional mitigation but can be subject to low daily email limits until they have established a good reputation. Please note that mitigating this issue does not guarantee that your emails will be delivered to a user’s inbox.

Guarantees or not, our delivery “issues” with and accounts were resolved in a couple of days.

IPredator OpenVPN Slackware Linux 14.1 setup

IPredator is a swedish VPN service offered with the stated goal of providing internet privacy.

This guide assumes a full Slackware Linux installation.
All certificates and configuration files are provided by IPredator.


I’ve recorded the process and posted it at Youtube. The video shows the setup using automated scripts instead of taking the long and winding road. The video quality is unfortunately  rather horrendous:
The scripts used in the video are available here: and rc.openvpn

Installing additional software

We’ll be using openresolv to avoid DNS leaks. DNS leaks happen when your DNS requests are routed through your ISP’s DNS servers, instead of those provided by the VPN provider. is providing a SlackBuild for openresolv here.

Download the SlackBuild but leave the source alone as it’s out of date. Extract openresolv.tar.gz and edit openresolv.SlackBuild by replacing the following line:

# with 

Download the source for openresolv 3.6.1 from this link and add it to the SlackBuild folder. Build openresolv with the command:

OPENVPN=yes ./openresolv.SlackBuild

(OPENVPN=yes tells the script to copy the update-resolv-conf file to /etc/openvpn folder during installation) Install the package with the command:

installpkg /tmp/openresolv-3.6.1-x86_64-1_SBo.tgz

Configuring OpenVPN.

You might just as well browse through the Debian guide at as I’m mostly replicating those steps over here.

Head over to the IPredator site and download the IPredator-CLI-Password.conf. Edit IPredator-CLI-Password.conf and add the openresolv instructions just below the user authentication part like shown below:

# <snip>
auth-user-pass /etc/openvpn/IPredator.auth
auth-retry nointeract

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
# </snip>

Make sure the update-resolv-conf file actually resides under /etc/openvpn (remember the SlackBuild). If not then adjust accordingly.

Next, we’ll create the file containing our username and password for the service. It should only have two lines containing your username and password repectivly.

# Create the auth file
vi /etc/openvpn/IPredator.auth

# Add username and password

The last step of the configuration is moving the config files to /etc/openvpn and changing permissions.
Note that I’m renaming the IPredator-CLI-Password.conf to IPredator.conf to avoid mistaking the config file for the authentication file (it’s probably just me).

mv $HOME/Downloads/IPredator-CLI-Password.conf /etc/openvpn/IPredator.conf
mv $HOME/Downloads/IPredator.auth /etc/openvpn/IPredator.auth

chown root:root /etc/openvpn/IPredator.conf
chown root:root /etc/openvpn/IPredator.auth

chmod 400 /etc/openvpn/IPredator.conf
chmod 400 /etc/openvpn/IPredator.auth
chmod 755 /etc/openvpn/update-resolv-conf

The update-resolv-conf file will be updating /etc/resolv.conf with the correct DNS servers.

Testing the service.

Verify that the connection works as expected:

openvpn --config /etc/openvpn/IPredator.conf

Provided that everything worked as expected, we can now initiate OpenVPN from the commandline by issuing openvpn /etc/openvpn/IPredator.conf and killing it with ctrl+c. That works, but it’s neither reliable or user-friendly.
The Slackware way of controlling services is by using simple init scripts that resides in /etc/rc.d

There are a few unofficial rc.openvpn scripts available for Slackware, but they differ greatly in quality. Giancarlo Razzolini is the author of the rc.openvpn script I’ve adopted. This script had a couple of minor bugs, which is why I’ve modified it, but all credit goes to Mr. Razzolini.

Installing the rc.openvpn service script

# Create the rc.openvpn script
vi /etc/rc.d/rc.openvpn

Get the source from this link: rc.openvpn
Make the script executable with the command

chmod 755 /etc/rc.d/rc.openvpn


/etc/rc.d/rc.openvpn start|status|stop|restart