ucspi-ssl - TLS encryption for Client/Server IPv6/IPv4 communication

May 9, 2022 Roberto Puzzanghera 0 comments

sslserver, sslclient, and sslhandle are command-line tools for building SSL client-server applications. 

sslserver listens for IPv6 and/or IPv4 connections, and runs a program for each connection it accepts. The program environment includes variables that hold the local and remote host names, IP addresses, and port numbers. sslserver offers a concurrency limit on acceptance of new connections, and selective handling of connections based on client identity supporting CIDR IP address notation. sslserver supports STARTTLS and STLS.

sslclient requests a connection to either a IPv6 or IPv4 TCP sockets, and runs a program. The program environment includes the same variables as for sslserver.

sslhandle is a pre-forking sslserver; though without STARTTLS/STLS capabilities.

With sslserver we can have a secure connection on port 465 to receive our emails.

You have already installed fehQlibs, which are supplementary C libraries needed for ucspi-ssl.

tar xzf /usr/local/src/ucspi-ssl-0.12.3.tgz
cd host/superscript.com/net/ucspi-ssl-0.12.3

The configuration of the supervise script for qmail-smtps is inside the configuration page.

e-mail indexing with Solr FTS Engine

April 21, 2022 Roberto Puzzanghera 0 comments

Solr is a Lucene indexing server. Dovecot communicates to it using HTTP/XML queries. With this indexing server, you can do text searches in your emails.


Solr is a java servlet which requires openjdk v. 8 or later. Be sure that you have the java binary in you path, for example


Download the binary version of Solr and install

cd /usr/local/src
wget https://www.apache.org/dyn/closer.lua/lucene/solr/8.11.1/solr-8.11.1.tgz?action=download -O solr-8.11.1.tgz

Extract the installer from the archive and run it. The installer will work for most Linux distributions based on systemd.

tar xzf solr-8.11.1.tgz solr-8.11.1/bin/install_solr_service.sh --strip-components=2
sudo bash ./install_solr_service.sh solr-8.11.1.tgz

The server will be launched by systemd at boot time.

LXC scripts for unprivileged containers

April 12, 2022 Roberto Puzzanghera 0 comments

Handling LXC unprivileged containers as root is not possible with the default LXC programs, because they must be called by the user who owns them and sometime is also necessary to specify the container's configuration file. For example, running lxc-ls as root shows all the unprivileged containers as stopped even when they are running, while lxc-start aborts the containers' startup sequence due to id mapping issues.

Since I prefer to run/stop/create/destroy/etc. my containers just typing my commands as root, not after the usual su - owner each time, I wrote my own wrapper scripts collection for the main LXC commands, just to simplify my tasks. In addition, all the unprivileged containers will be created in the same directory, say /usr/local/lxc, and not in the owner's home directory.

I use them both for privileged (owned by root itself) and unprivileged containers. In the latter case the owner of the container is determined dinamically.

These scripts allow an administrator to use LXC running his applications in separate containers, each one (or group of them) runned by a different user and id map.

I wrote them for my Slackware linux distro, but I think that they remain valid for any other Linux flavor.

If you are a Slackware user and you are looking for unprivileged containers documentation, you should take a look to Chris Willings' guide, which was my starting point on this topic. Also the Stéphane Graber's article is a suitable reading at the beginning.

Denying bad DNS HELO/EHLOs

February 26, 2022 Roberto Puzzanghera 0 comments

The RFC-821 Section 3.5 states that 

The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter.

The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.

Not denying clients with a bad HELO/EHLO DNS can be also considered a wise thing, just not to update too frequently our whitelist for those clients who don't set up their DNS properly.

On the other hand, it is a matter of fact that most spammers use fake domains -very often our own domains-, or even random strings or not solving domains, as their HELO/EHLOs.

For example, consider the following log lines (I have plenty of them in my logs):

2022-02-01 10:19:53.142643500 helo-dns-check: HELO [yq3H9cDKgS] from [] doesn't solve
2022-02-01 09:53:05.772497500 helo-dns-check: HELO [sagredo.eu] is a local domain but IP [] is not a RELAYCLIENT

I think that at least such kind of failures should be blocked. I'll explain below how to set up a filter which deny clients with these particular DNS failures:

  1. not solving HELO/EHLOs, i.e. random strings or domains with no A record at all.
  2. fake HELO/EHLOs containing one of our domains, when the DNS doesn't solve to one of our IPs and RELAYCLIENT is not defined;
  3. clients whose A record doesn't match the domain in their HELO/EHLO. This is completely against RFC-821, so my configuration will not refuse these connections, just log them.