chore: default to Rspamd from v17.0.0

Description

I cite reasoning for preferring Rspamd as a maintainer here.

I am interested in feedback from anyone that prefers any of the existing suite of services that Rspamd replaces, which I'm now considering as legacy services in DMS (they are not pleasant to maintain/troubleshoot and have cost a fair amount of time over the years, unresolved issues aside):

Legacy services:

Amavis - Frontend to SpamAssassin and ClamAV
OpenDKIM (integrated via Postfix milter)
OpenDMARC (integrated via Postfix milter)
SpamAssassin (we do not use the spamd daemon, our support relies upon Amavis to call SA via the SA Perl library AFAIK?)
policyd-spf (integrated via Postfix check_policy_service)
PostGrey (integrated via Postfix check_policy_service) - Greylisting support (Equivalent feature in Rspamd is likewise opt-in)

Links are to their associated setup script in DMS, but most have config/docs/tests elsewhere in the project and many associated past issues in the project.

An example of an issue I recently noticed was a difference in behaviour with SA scanning from DMS v14 (released in June 2024, upgraded to Debian 12 (June 2023) base image + SpamAssassin 4.0 (Dec 2022)), these sorts of issues require a fair amount of time to investigate and ideally resolve / document the cause when we lack maintenance expertise for these services.

The legacy set of services will remain for the time being as a fallback / alternative option. We've had Rspamd offered since DMS v12 (April 2023) and improved our support and docs a fair amount since then.

Eventually it would be preferrable to unload the burden of maintaining support for the legacy services. Thus if any users could share any concerns/experiences for why they might prefer any of the legacy services over Rspamd that'd be appreciated. Most alternatives to DMS already use Rspamd instead of our equivalent legacy set of services to my knowledge.

DMS v15 docs for Rspamd have had an initial revision with the intention of being easier to grok for users wanting to switch early. There will likely be some breaking changes for Rspamd in DMS v17, I may also try to push for upstream Rspamd to publish packages to their deb repo we use so that we can actually pin Rspamd releases for more deterministic image builds.

Beside that SA just works for me, I can imagine switching to Rspamd. If it works as flawless as SA, I see no problems 👍

But it's not only a switch from one service to another, but switching 6 service to 1. For several reasons, I am a huge fan of the unix philosophy "Make each program do one thing well". Making DMS more and more monolithic is a questionable route IMO.

If for some reason, I'll ever have a problem with one service, I can just disable it. Rspamd can only be disabled all together (easily) right now.

I may have overlook something, but at the moment I see these issues:

It's currently not possible to use Rspamd and ClamAV together? When disabling Amavis, ClamAV ends up in a restart loop. So no AV scanning while using Rspamd?
It's not possible to just use Rspam's SPF, DKIM, etc. features on their own, without using "Rspam itself (SPAM scanning)"? --> ENABLE_RSPAMD=0. In comparison, currently it's possible to use SPF etc., even when SA is disabled.

I don't think we have anyone interested in providing support for the legacy stack, and I know I may be one of the only maintainers to really dig into these various softwares docs/source to troubleshoot some issues.

You probably have a better overview than me, so I am asking this: Do we really have real issues with the current SPF/DKIM etc. services? Afaik are almost all issues related to users faults / configurations? Those issues will remain, independent of the used program? IIRC there was also a good portion of issues, that were Rspam related, or the switch to it.

For me those services were just "enabling and forgetting about it". They do just work. I never had any issue with them. That's why I'd like to keep those tiny services 😆

But it's not only a switch from one service to another, but switching 6 service to 1. For several reasons, I am a huge fan of the unix philosophy "Make each program do one thing well". Making DMS more and more monolithic is a questionable route IMO.

I totally agree with you here, but I'm against that when the software as individual components is doing a worse job for users and us as maintainers. This doesn't apply to all services I've put in the legacy set, but they pretty much all are subpar for us vs Rspamd when it comes to maintenance and in some regards features/support.

I'll be inlining this information into relevant scripts via a commit at some point, but here's an overview:

# Debian 12 package: opendkim 2.11.0
# https://salsa.debian.org/debian/opendkim
# Official project page (no HTTPS available):
# http://www.opendkim.org/
# Links to SourceForge for project source which directs users to Github:
# Last commit Dec 2022:
# https://github.com/trusteddomainproject/OpenDKIM/tree/develop
# Last release 2.11.0 (Nov 2018):
# https://github.com/trusteddomainproject/OpenDKIM/releases

# Debian 12 package: opendmarc 1.4.2
# https://salsa.debian.org/kitterman/opendmarc
# Official project page (no HTTPS available):
# http://www.trusteddomain.org/opendmarc/
# Links to SourceForge for project source which directs users to Github (since April 2021):
# Last commit Dec 2021:
# https://github.com/trusteddomainproject/OpenDMARC/branches/all
# Last release 1.4.2 (Dec 2021):
# https://github.com/trusteddomainproject/OpenDMARC/blob/master/RELEASE_NOTES

# Debian 12 package: postfix-policyd-spf-python 3.0.4 (April 2023)
# https://salsa.debian.org/python-team/packages/spf-engine
# Previously `policyd-spf` until Dec 2016, then renamed to `spf-engine`:
# https://launchpad.net/pypolicyd-spf
# https://salsa.debian.org/kitterman/postfix-policyd-spf-perl
# Official project page + repo:
# https://code.launchpad.net/spf-engine
# Last commit and release 3.1.0 (Aug 2024):
# https://git.launchpad.net/spf-engine/

# Debian 12 package: postgrey 1.37
# https://salsa.debian.org/debian/postgrey
# Official project page:
# https://postgrey.schweikert.ch/
# Last commit Feb 2024 (mostly whitelist updates since 2016):
# https://github.com/schweikert/postgrey
# Last release 1.37 (Sep 2016):
# https://github.com/schweikert/postgrey/tags

# Debian 12 package: spamassassin 4.0.0 (Dec 2022)
# Lack of 4.0.1 potentially causing regression/bugs in DMS v14+
# https://salsa.debian.org/debian/spamassassin
# Official project page:
# https://spamassassin.apache.org/
# NOTE: Github repo is a mirror (antiquated process for contributions/reports)
# Last commit Feb 2025:
# https://github.com/apache/spamassassin
# Last release 4.0.1 (March 2024):
# https://github.com/apache/spamassassin/tags

# Debian 12 package: amavisd-new 2.13.0 (Jan 2023)
# https://salsa.debian.org/debian/amavisd-new
# Official project page:
# https://www.ijs.si/software/amavisd/
# https://www.amavis.org/
# Last announced release 2.11.0 (2016) + 2.11.1 (Oct 2018):
# https://www.ijs.si/software/amavisd/release-notes.txt
# Development migrated to Gitlab with release 2.12.0 (July 2019)
# Last commit Feb 2025:
# https://gitlab.com/amavis/amavis
# Last release 2.13.1 (March 2024):
# https://gitlab.com/amavis/amavis/-/tags

Especially with OpenDKIM and OpenDMARC these projects no longer seem maintained, despite various issues and PRs. Postgrey seems fine (as pointed out here, commits over the years are effectively whitelist/docs, so no need for a new release). Amavis + SA appear actively developed/maintained, but they're not pleasant to me regarding docs and upstream interaction.

I would like rspamd package to have a pinnable version before we default to it though, so that image builds will be more consistent. We don't want the CI publishing a release at the time that Rspamd also pushes out a new release that has breaking changes, although it's more likely just to affect edge builds or users performing custom builds after release.

@georglauterbach

Rspamd can only be disabled all together (easily) right now.

My understanding is that the equivalent services in Rspamd are modules and those are easily disabled with single enable = false lines to the relevant module config file. I'll need to get more familiar with Rspamd myself or @georglauterbach can confirm, but if that's the case it'd be rather trivial to support toggling.

We should be able to swap the existing ENV like ENABLE_OPENDKIM to ENABLE_DKIM and have that toggle based on a new ENV that supports legacy/rspamd as values. If we can identify any valid use-cases for interleaving both legacy services + rspamd, we can look into supporting that, otherwise I'd rather we clearly enforce the feature boundary between legacy and rspamd which will simplify some conditionals in our scripts.

It's currently not possible to use Rspamd and ClamAV together? When disabling Amavis, ClamAV ends up in a restart loop. So no AV scanning while using Rspamd?

I tested ClamAV with Rspamd very recently and it works absolutely fine. EICAR was detected, which I don't recall it being when ClamAV was disabled. Which version of DMS did you test with?

It's not possible to just use Rspam's SPF, DKIM, etc. features on their own, without using "Rspam itself (SPAM scanning)"? --> ENABLE_RSPAMD=0. In comparison, currently it's possible to use SPF etc., even when SA is disabled.

I can't comment on that just yet, I believe it should be possible to opt-out of various rules/modules to get roughly the same effect.

Rspamd would still be handed traffic from Postfix milter and return the action to take, similar to how Amavis works via Postfix content filter (even with SA disabled).

Other services as noted in an earlier comment rely on integration through Postfix via another approach (check_policy_service), but milters are the modern and better integration. I have a separate issue open related to switching those services to use milters.

That's a good point though, something we should probably ensure we support 👍

You probably have a better overview than me, so I am asking this: Do we really have real issues with the current SPF/DKIM etc. services? Afaik are almost all issues related to users faults / configurations?

Please review the package notes I shared in my prior comment. OpenDKIM/OpenDMARC on Github have various issues open and PRs, it doesn't instill much confidence. I'm not even sure I'm happy with the config we have in DMS at a glance.

I believe we've had some issues that aren't at the fault of a user and we did not know how to resolve it but would direct the user to Rspamd and that'd usually fix it for them. Interacting with upstream when it's not Rspamd for the majority of those services is friction I don't want to deal with, and I doubt any other maintainer / contributor really cares enough for either.

For the happy path, sure we seem to be good enough there these days. What concerns me is upgrades / maintenance with time and when things break or fall behind with best practices / standards when the software hasn't been updated for over 5 years. Debian would presumably patch any CVEs that are discovered, but they also may eventually opt to deprecate such packages too as unmaintained. I believe this happened for PostSRSd at one point, or at least during the absence of a Debian package maintainer for a period of time is why we still don't have a v2 release in Debian.

IIRC there was also a good portion of issues, that were Rspamd related, or the switch to it.

That's to be expected as Rspamd support in DMS is far newer and mostly been left to @georglauterbach + community to refine, they've done well AFAIK 😎

I'll be doing an audit/pass over the integration myself, which will likely introduce some breaking changes before I think Rspamd is ready to promote to the default.

I want our test suite in better shape as well (proper DNS tests in place for example), so if this isn't the case by DMS v17, Rspamd as default will be delayed to another major release.

For the most part though, it seems like we've got it in fairly good shape now AFAIK. Docs could do with some work (I've already done an initial pass on that) to benefit our users. We'll still offer the legacy suite as an alternative in the event the wider audience from Rspamd as a default reveals more issues in our support, so that should make the switch less stressful.

For me those services were just "enabling and forgetting about it". They do just work. I never had any issue with them. That's why I'd like to keep those tiny services 😆

My motivation is due to smaller issues already surfacing.

There's the subtle SA regression in behaviour I've noted. There's also users treating DMS as a forwarder with aliases where services like Gmail are becoming more strict lately (this seems to rely on ARC support, which we don't have other than with Rspamd), I've engaged with one user recently where I'm pretty sure the issue is ARC, and we've had another recent query from a past maintainer regarding mailing lists forwarding where ARC is likely the solution for them as well.

This sort of thing will only continue with time, it makes sense to treat these various services as considered legacy going forward which may work for some but no longer likely to see as much support in DMS for bug reports regarding them.

We should be able to swap the existing ENV like ENABLE_OPENDKIM to ENABLE_DKIM

👍

When disabling Amavis, ClamAV ends up in a restart loop.

I tested ClamAV with Rspamd very recently and it works absolutely fine.

Never mind. I am unsure what I did earlier.. I can't reproduce it anymore. Works now fine for me too.

While Rspamd is indeed not conform to the UNIX philosophy in a strict sense, you can enable and disable almost all modules. Hence, you can have SPF but not DKIM, Spam checking but not virus checking, etc.

I'm all in favor of this transition. Maintaining Rspamd has been relatively easy over the course of last year, and DMS also supports ARC with Rspamd out-of-the-box now (with docs). I like the experience better than what I was used with Amavis/SA.

Another advantage of Rspamd seems to be a lower resource consumption. In my setup, there was a difference of 90MB in memory usage between "SA, Amavis, SPF..." vs. "Rspamd".

I will be tackling this for v17.0.0.

Navigation Menu

Repository navigation

chore: default to Rspamd from v17.0.0 #4364

Description

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

chore: default to Rspamd from v17.0.0 #4364

Description

Description

Activity

casperklein commented on Feb 15, 2025

polarathene commented on Feb 15, 2025

polarathene commented on Feb 15, 2025

casperklein commented on Feb 15, 2025

georglauterbach commented on Feb 16, 2025

casperklein commented on Feb 16, 2025

12 remaining items

georglauterbach commented on Aug 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions