SpamAssassin 3.4.6 in Rocky Linux 9 – Any Plans for Updating to 4.x?

Hello everyone,

I noticed that the current SpamAssassin package provided in the Rocky Linux 9 repositories is still version 3.4.6 from 2021. Upstream SpamAssassin has released several updates since then, including the latest stable version 4.0.2 (August 2025) with improved rulesets, better performance, and more accurate filtering.

This creates challenges for mail servers running on Rocky 9, as the outdated rules often cause legitimate emails to be flagged as spam. My hosting provider (SPanel / ScalaHosting) confirmed that upgrading is technically difficult because Rocky 9 does not provide newer versions in its repo.

My question:
Are there any plans, timelines, or ongoing discussions regarding an update of SpamAssassin for Rocky Linux 9?
Even optional support via a SIG or a newer module would already be extremely helpful.

Any insights or guidance would be greatly appreciated.

Thank you!
Pablo

As you should already know, Rocky 9 is based on RHEL9. Therefore Rocky has the same packages as RHEL. So no, there are no plans to upgrade it. If RHEL upgrade it, then we will have it. Also you should realise this is an EL distribution - Enterprise. So it will never have the latest packages available.

Your alternative if it is a problem for you, is to compile/build your own version and maintain it yourself.

Thank you for the clarification.

Yes, I am aware that Rocky Linux follows RHEL and therefore inherits the same package versions. My concern is mainly that the current SpamAssassin version (3.4.6) is already four years old and the outdated ruleset has a noticeable impact on filtering accuracy in real-world use, especially for hosting providers and users running mail servers.

I fully understand that Rocky Linux, as an Enterprise distribution, does not aim to ship the latest upstream versions. However, since SpamAssassin 4.x provides significant improvements in rule handling and filtering quality, I was hoping there might be an optional SIG, backport, or alternative repository in the future — even if not part of the main EL9 repositories.

Compiling and maintaining a custom build is technically possible, but for many users and hosting environments it is not an ideal long-term solution, especially regarding updates, security, and maintenance.

If you have any recommendations for a safe and supported method of using a newer version within the Rocky 9 ecosystem, I would greatly appreciate it.

Thanks again for your time.

Rocky 10 has SpamAssassin 4 so may be better for you to possibly think about using that instead of Rocky 9. As for SIG’s, you have to remember the team is not huge. So every single SIG request means someone has to manage it. There are only so many people and so many hours in a day. So it would mean someone would have to be willing to take on that extra work and maintain it.

It’s very easy to download a Fedora source rpm, and build this with mock. The Fedora 41 or 42 rpm should build fine on Rocky 9: SpamAssassin Fedora source rpm and this post documents how I did similar with Audacity: How do I install this on Rocky Linux 8? - #13 by iwalker you can adapt some of the commands there for Rocky 9 and EPEL 9 to do it.

Thank you very much for your detailed and prompt reply. Even though there is no direct solution to my problem, I now understand the circumstances better and will see how I can deal with this. Thank you!

While you can’t easily get the newer features of SA4 you can get updated rules, you simply need to enable the sa-update.timer service:

systemctl enable sa-update.timer
systemctl start sa-update.timer

…this will cause SA to automatically update the rules from a scheduled task.

In other words, there is the “SA engine” that handles rules and there are the “SA rules”. Two distinct things, although the engine has limits on what rules it can handle.

Peter did point out that updated rules are available for the old engine. It would be odd for Red Hat to include in RHEL an SA that could not have updated rules as they know RHEL to be used in “real world” by their paying customers. If the available rules are nevertheless “bad”, then a bug report about RHEL would be in order.

Strictly, the SA is not 3.4.6. It is “3.4.6-6.el9” – forked from upstream 3.4.6, with some (backported) changes by Red Hat.