Resolved Spamassassin issue - not compiled or not compiled properly

[trialotto]

Username:

TITLE

Spamassassin issue - not compiled or not compiled properly

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Tests on 3 OSes, various results

OS with compilation errors :
Product version: Plesk Obsidian 18.0.59.2
OS version: Ubuntu 18.04 x86_64
Build date: 2024/02/29 17:00
Revision: 4d5def438d80f901f8ade594e9abb2c9ee467dd3
Product version: Plesk Obsidian 18.0.58.2
OS version: Ubuntu 18.04 x86_64
Build date: 2024/01/23 22:00
Revision: 37aa23e80de6aa54485384af35d425af8d131d4b


OS without compilation errors - only 403 'body_0' compiled rules:
Product version: Plesk Obsidian 18.0.58.2
OS version: Ubuntu 20.04 x86_64
Build date: 2024/01/23 15:00
Revision: 37aa23e80de6aa54485384af35d425af8d131d4b

PROBLEM DESCRIPTION

SYMPTOMS - error notifications in /var/log/maillog or /var/log/maillog.processed

spamd[xxxxx]: Can't locate Mail/SpamAssassin/CompiledRegexps/body_neg2000.pm in @INC (you may need to install the Mail::SpamAssassin::CompiledRegexps::body_neg2000 module) (@INC contains: /var/lib/spamassassin/compiled/5.026/3.004002 /var/lib/spamassassin/compiled/5.026/3.004002/auto /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.1 /usr/local/share/perl/5.26.1 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 2046) line 1.

STEPS TO REPRODUCE

STR:

In order to recreate the error notification regarding the body_neg2000 module, just

- restart spamassassin service
- investigate the maillog (or run command : service spamassassin status)

ACTUAL RESULT

RESULT 1 :

IF and only if spamassassin has not been compiled, then

- the error notification will appear in the maillog (and startup logs of the spamassassin service), AND
- the following lines are shown at startup :

spamd[xxxxx]: zoom: able to use 408/408 'body_0' compiled rules (100%)
spamd[xxxxx]: spamd: server started on IO::Socket::IP [127.0.0.1]:783 (running version 3.4.2)

RESULT 2 :

IF spamassasin has been compiled, a restart of spamassassin service can give at startup:

spamd[xxxxx]: zoom: able to use 393/403 'body_0' compiled rules (97.518%)
spamd[xxxxx]: server started on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783 (running version 3.4.4)

NOTE :
Please note the difference of

- 403 versus 408 'body_0' compiled rules when 3.4.4 version is running
- IO::Socket::IP [::1]:783 mentioned twice when 3.4.4 version is running

and I am not sure whether the deviations for version 3.4.4 are a bug or not.

EXPECTED RESULT

Spamassassin should be compiled and the error notification with respect to the body_neg2000 module should NOT be present.

In addition, the

- double IO::Socket::IP [::1]:783
- the 403 'body_0' compiled rules

in version 3.4.4 should be investigated, since it is an indicator of the version 3.4.4 not being compiled properly recently.

ANY ADDITIONAL INFORMATION

I will add once I can confirm that the version 3.4.4 is also not being compiled.

SOLUTION :

run the commands :

sa-update
sa-compile
service spamassassin restart

given that the required packages re2c and sa-compile should already be installed!

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[trialotto]

ADDITION

ISSUE : spamassassin 3.4.4 NOT recompiled - the 403 'body_0' compiled rules issue

OS
Product version: Plesk Obsidian 18.0.58.2
OS version: Ubuntu 20.04 x86_64
Build date: 2024/01/23 15:00
Revision: 37aa23e80de6aa54485384af35d425af8d131d4b

NOTES

When running

sa-update
sa-compile
service spamassassin restart

on a machine with the

spamd[xxxxx]: zoom: able to use 393/403 'body_0' compiled rules (97.518%)
spamd[xxxxx]: server started on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783 (running version 3.4.4)

notifications at startup, the recompilation (sa-compile) will result in

spamd[xxxxx]: zoom: able to use 408/408 'body_0' compiled rules (100%)
spamd[xxxxx]: server started on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783 (running version 3.4.4)

at restart of spamassassin.

SUMMARY
It seems to be the case that spamassassin service is NOT recompiled somehow.

 

[Peter Debik]

Thank you, forwarded to developers for further analysis as PPS-15771.

 

[danami]

If I remember correctly the default SpamAssassin packages are provided by the OS not Plesk so this would probably be something for the package maintainer. Also this error could just be caused by a bad rule. SpamAssassin can use the Rule2XSBody plugin to compile rules into native code to speed them up. I don't think that it's enabled by default however on RPM based systems. I would try to disable the plugin by commenting it out and see if it fixes your issue. You can search for the plugin using:

grep Rule2XSBody /etc/mail/spamassassin/*.pre

I would also check for errors in the spamassassin config with:

spamassassin --lint

 

[trialotto]

If I remember correctly the default SpamAssassin packages are provided by the OS not Plesk so this would probably be something for the package maintainer. Also this error could just be caused by a bad rule. SpamAssassin can use the Rule2XSBody plugin to compile rules into native code to speed them up. I don't think that it's enabled by default however on RPM based systems. I would try to disable the plugin by commenting it out and see if it fixes your issue. You can search for the plugin using:

grep Rule2XSBody /etc/mail/spamassassin/*.pre

I would also check for errors in the spamassassin config with:

spamassassin --lint

@danami

I have reported a "bug" that is related to the Plesk eco environment and that produces an "annoying" error notification in the maillog at restarts of spamassassin.

It does not have a major impact on the functionality of spamassassin, only a slight effect can be noticed.

The problem here is that "compilation" is absent - it does not matter whether the package provider or Plesk ascertains that "compilation" takes place.

It only matters that compilation occurs at a frequent interval.

Since the spamassassin all have similar issues (not bugs) and since the "compilation" is really simple (two lines of code), it could be managed by Plesk.

A simple cronjob or script could suffice.

Frequent "compilation" is desirable, since otherwise a messy spamassassin service can arise that can be exploited by certain people with bad intents.

Again, another reason to have "compilation" to be managed by Plesk.

As a final note, it has nothing to do with a "bad rule" or the (active/inactive) state of the Rule2XSBody plugin- it simply is a crystal clear error notification in /var/log/maillog (or .. maillog.processed) that indicates that the body_neg2000.pm file cannot be located : it is not or not properly compiled, hence the issue.

Kind regards....

 

[danami]

> The problem here is that "compilation" is absent - it does not matter whether the package provider or Plesk ascertains that "compilation" takes place. A simple cronjob or script could suffice.

The default SpamAssassin package already includes a daily cron in /etc/cron.daily/spamassassin which will compile rules automatically.

> Frequent "compilation" is desirable, since otherwise a messy spamassassin service can arise that can be exploited by certain people with bad intents.

SpamAssassin works just fine without any compiled rules. Rules will get updated daily as usual (just not compiled). Additionally I would say that having compiled rules is more of a security risk because the Rule2XSBody plugin requires that gcc and make is installed on the server (which isn't ideal).

Just my thoughts.

 

[trialotto]

Thank you, forwarded to developers for further analysis as PPS-15771.

@Peter Debik

It seems to be an URGENT matter.

In some cases, the spam filter regexp - for instance, those used to whitelist domains in the form of *@domain.com - will not work properly.

As a result, particular mails will not be received.

I am not sure (yet) how these cases particular cases are defined and/or in what exact situation they occur, but it seems to be an intertwined (and hence infinite) combination of config settings on both the sending mail server as the receiving mail server.

Nevertheless, the mere fact that the regexp are not working as they should before the compilation update is applied, should be a strong indicator or urgency.

Kind regards...

 

[danami]

1. Have you tried deleting the compiled rules in /var/lib/spamassassin/compiled/ then recompile them with the sa-compile command and see if you get the same error when you restart spamassassin?
2. Make sure to check the spamassassin config again with "spamassassin --lint". It should return no output if the config is fine.
3. I double checked some Ubuntu servers that we manage and none of them have this error.

 

[trialotto]

1. Have you tried deleting the compiled rules in /var/lib/spamassassin/compiled/ then recompile them with the sa-compile command and see if you get the same error when you restart spamassassin?
2. Make sure to check the spamassassin config again with "spamassassin --lint". It should return no output if the config is fine.
3. I double checked some Ubuntu servers that we manage and none of them have this error.

@danami

First of all, the command spamassassin --lint is a very rough indicator of config errors, not of compilation or code errors.

I too have checked a number of Ubuntu servers, with new and old Plesk versions.

The older Plesk versions have this (and some other minor) issue(s), the newer Plesk versions seem to be fine, but they are actually not.

For instance, the servers that do not indicate issues at spamassassin service restart, those servers still have the "403 body_rules" issue - highly unexpected.

Please note that I do maintain some "to-be-patched-servers" (read: servers that are not updated, in order to recreate very specific issues) and some freshly installed "old" servers (read: old Plesk variants and/or old OSes) for test purposes - in most cases where spamassassin has been installed recently, there is no issue, if I am not mistaken.

In essence, I see this "issue" occurring on Plesk instances that are automatically updated ....... by - indeed - the cron job.

If we untangle cause/consequence, then we will always end up with an issue that is related to compilation.

I am not sure how it happens, but it does ...... and it affects the ability of spamassassin to tackle regexp, at least to some minor extent.

By the way, I am not sure why you are talking about the Rule2XSBody plugin, since that does not seem to be the culprit.

I do agree that gcc/make on any production server is not ideal, but they are already installed and sa-compile depends on these packages.

Kind regards.....

 

[danami]

> First of all, the command spamassassin --lint is a very rough indicator of config errors, not of compilation or code errors.

Try adding the --debug option to spamassassin --lint to get more detailed output:

spamassassin --lint --debug

 

[danami]

1. I would also confirm that you have the re2c package installed as it's required by the sa-compile command.
2. Confirm that the Rule2XSBody plugin is really enabled (not commented out) in the config.

Most of the people with this error had misconfiguration of the Rule2XSBody plugin or errors in their config. A quick Google shows people with the exact same error that you first posted and how they fixed it:

Linux: SpamAssassin Can't locate CompiledRegexps - Maffert.net

Can't locate Mail/SpamAssassin/CompiledRegexps/body_neg2000.pm in @INC (you may need to install the Mail::SpamAssassin::CompiledRegexps:: ...

www.maffert.net

 

[trialotto]

1. I would also confirm that you have the re2c package installed as it's required by the sa-compile command.
2. Confirm that the Rule2XSBody plugin is really enabled (not commented out) in the config.

Most of the people with this error had misconfiguration of the Rule2XSBody plugin or errors in their config. A quick Google shows people with the exact same error that you first posted and how they fixed it:

Linux: SpamAssassin Can't locate CompiledRegexps - Maffert.net

Can't locate Mail/SpamAssassin/CompiledRegexps/body_neg2000.pm in @INC (you may need to install the Mail::SpamAssassin::CompiledRegexps:: ...

www.maffert.net

@danami

The re2c package should be included by default and also the plugin is enabled by default - at least, that is or should be the default on Ubuntu OS.

However, this does not explain the issue itself ..... but yes, you are right : people should first check those packages/settings before running sa-compile.

Kind regards....

 

[danami]

@trialotto If I remember correctly I don't think that the Rule2XSBody plugin is enabled by default. I unpacked the default spamasssasin packages on Ubuntu 24 and Debian 12 and it's commented out in the config. SpamAssassin has a tonne of packages perl package dependencies that are not included by default because the maintainers consider them optional plugins. Not everyone wants to have gcc, make, and re2c automatically installed on their server as would need to happen to have it enabled by default.

 

[danami]

Actually on Debian and Ubuntu they have them all as dependencies on the sa-compile package so they should all get automatically installed when you install it.

 

[Peter Debik]

The product issue has been confirmed and is now tracked as PPPM-14367.

 

[synctecho]

I am getting this error and also I can't reupload the file Cannot read properties of undefined (reading 'state')
Any one can guide me.

 

[Peter Debik]

@synctecho Could you please open your own, separate thread for your question? It has nothing to do with the topic discussed in this thread.

 

[synctecho]

The problem is I can't create a separate. I am getting this message while creating a new thread
thread.

 

[Hangover2]

Fixed with the release of Plesk Obsidian 18.0.60.