May 9, 2022 Roberto Puzzanghera 0 comments
- More info: http://www.fehcom.de/ipnet/ucspi-ssl.html
- Download from: http://www.fehcom.de/ipnet/ucspi-ssl/ucspi-ssl-0.12.3.tgz
- Author: Erwin Hoffmann
- Version: 0.12.3
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.
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
tar xzf /usr/local/src/ucspi-ssl-0.12.3.tgz cd host/superscript.com/net/ucspi-ssl-0.12.3 ./package/install
The configuration of the supervise script for
qmail-smtps is inside the configuration page.
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
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.
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.
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
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
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 [126.96.36.199] doesn't solve 2022-02-01 09:53:05.772497500 helo-dns-check: HELO [sagredo.eu] is a local domain but IP [188.8.131.52] 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
- not solving
HELO/EHLOs, i.e. random strings or domains with no
Arecord at all.
HELO/EHLOs containing one of our domains, when the
DNSdoesn't solve to one of our
RELAYCLIENTis not defined;
- clients whose
Arecord 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.