We have released new updates for Rspamd and Rmilter: 1.3.1 and 1.9.1 accordingly. There are a couple of important bugfixes and some useful new features in these releases.

Systemd activation has been removed from Rspamd and Rmilter

Over the recent years, we have experienced constant issues reported by users about Systemd socket activation. This feature seems to be completely broken in systems with both IPv4/IPv6 enabled. Moreover, it seems to be harmful as Rspamd setup time is quite significant whilst socket activation is mostly intended for interactive on-demand daemons. Socket activation has been added under the pressure of Debian packaging rules, though Rspamd is completely rotten in Debian official repos and we strongly discourage Debian users from using the official Debian packages. While we are still looking for a new Debian maintainer for Rspamd, I can declare that there will be no sockets activation enabled by default in Rspamd nor Rmilter.

The switch to standalone mode should be transparent for users. The only significant difference is use of rspamd.service instead of rspamd.socket in service management commands. In some cases you might need to restart Rmilter after upgrade (for example, in Debian Jessie):

systemctl restart rmilter.service

Rmilter crash on BSD systems

There was a bug that was caused by use of pthread_specific variables. Unfortunately, libmilter is poorly designed and can destroy or move certain threads which causes horrific errors. Linux is somehow not affected, however, there is still use-after-free bug with this approach. In Rmilter 1.9.1, this issue has been fixed.

New multimap features in Rspamd

The multimap module has been significantly updated in Rspamd 1.3.1. It now supports maps that are checked conditionally depending on combinations of other symbols. There is now also support for multiple symbols and scores per map. A new hostname map type has been added to support matching of hostnames. Many new tests have been written to cover multimap functions and to provide resistance against regressions.

Greylisting fixes in Rspamd

There are a couple of fixes in the greylisting module, including authenticated users whitelisting, general logic fixes and restoration of selective greylisting.

Critical issue with Catena password scheme

There was a regression in 1.3 that prevented Catena password encryption scheme from being correctly read by the controller. It has been fixed in 1.3.1, so Catena passwords (those with $2$ prefix) could be used again.

Critical fix for Hyperscan cache

There was a race condition when a worker that writes Hyperscan file was killed in the middle of this process. Afterwards, a cache file was left in an inconsistent state which wasn’t detected or corrected on subsequent Rspamd runs. That caused multiple issues with regular expressions processing, including false and failed matches on arbitrary texts. Since 1.3.1, Rspamd strictly ensures that a Hyperscan cache file has been correctly written to the filesystem.

Message size limit in Rspamd

We now limit the incoming size of a message to prevent crashes on insane input. By default, this limit is set to 50Mb, however it can be changed by max_message setting in the options section:

# local.d/options.inc
max_message = 100Mb;

Rspamd configuration files includes logic

From this version, the behaviour of local.d and override.d is consistent with their description: values in local.d add values to the existing configuration overwriting the same keys, and values from override.d overwrites the whole sections. For example, if we have the original configuration that looks like this:

# orig.conf
rule "something" {
  key1 = value1;
  key2 = {
    subkey1 = "subvalue1";
  }
}
rule "other" {
  key3 = value3;
}

and some local.d/orig.conf that looks like this:

# local.d/orig.conf
rule "something" {
  key1 = other_value; # overwrite "value1"
  key2 = {
    subkey2 = "subvalue2"; # append new value
  }
}
rule "local" { # add new rule
  key_local = "value_local";
}

then we will have the following merged configuration:

# config with local.d/orig.conf
rule "something" {
  key1 = other_value; # from local
  key2 = {
    subkey1 = "subvalue1";
    subkey2 = "subvalue2"; # from local
  }
}
rule "other" {
  key3 = value3;
}
rule "local" { # from local
  key_local = "value_local";
}

If you have the same config but in override.d directory, then it will completely override all rules defined in the original file:

# config with override.d/orig.conf
rule "something" {
  key1 = other_value;
  key2 = {
    subkey2 = "subvalue2";
}
rule "local" {
  key_local = "value_local";
}

Other bugfixes and improvements

There are couple of other important bugfixes and improvements including a critical fix for extracting values from the top received header. The test framework has been improved with new functional tests and better integration with CircleCI