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 fake 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.

Greylisting for qmail

February 11, 2022 Roberto Puzzanghera 7 comments

Greylisting is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again after a delay, and if sufficient time has elapsed, the email will be accepted.

While greylisting is not effective as in the past, it still cut a certain fraction of the total spam.

qmail-spp greylisting plugin

I introduce here how greylisting can be implemented on qmail by means of another qmail-spp plugin, which saves the data in MySQL. Having the data in MySQL is useful to measure how much spam is blocked by greylisting.

  • More info here
  • Author: Manuel Mausz

Dovecot vpopmail-auth driver removal. Migrating to the SQL driver

March 9, 2021 Roberto Puzzanghera 40 comments

Those who are still using the Dovecot's vpopmail auth driver should consider a migration to another backend, as on January 4, 2021 dovecot-2.3.13 was released and the vpopmail auth driver removed (more info here).

I'll show below how to support domain aliases with the sql driver both with all domains in the same vpopmail table and with one table for each domain (--disable-many-domains). You can find how to setup the driver in this page. A short reference to vpopmail's vconvert program is presented toward the bottom of this page, in case one is planning to switch to sql.

If you browse the comments below you'll find some other nice solutions to replace the vpopmail driver:

Saving vpopmail's aliasdomains to MySQL

As some commentators have pointed out, switching to the dovecot's sql auth driver can be painful if one has domain aliases. I will show below how to make dovecot aware of the vpopmail's aliasdomains, so that a user who tries to login with a domain alias can pass the authentication.

The idea is to save the pairs alias/domain in a new "aliasdomains" MySQL table, for example:

MariaDB [vpopmail]> SELECT * FROM aliasdomains; 
| alias                | domain               | 
| alias.net            | realdomain.net       | 

...and then modify the dovecot's sql query in order to select the user's domain from this table in case the domain is an alias or from the vpopmail table otherwise.

I patched vpopmail so that it  will transparently do the sql stuff when creating/deleting the alias in the usual way by means of the vaddaliasdomain/vdeldomain vpopmail's programs.