Spamassassin - Create mail filters per mailbox

According to the user manual, the SpamAssassin client can be set as spamassassin (standalone) or spamc (client for SA filter server spamd). When the last one is used, it only reads the global configuration.

Virtualmin offers the possibility to use preferences per virtual server. In this case spamassassin must be set as the client. There is an Allow mailbox users to create mail filters option in the Virtualmin > Email Settings > Spam and Virtus Scanning section.

How does this option work at the mailbox level? Which files are responsible after it is enabled. If this is the only responsible file /home/domain/.spamassassin/user_prefs, it applies to all mailboxes not at the individual mailbox level.

If I go to Virtualmin > Services > SpamAssassin Configuration and I would like to edit the configuration file it opens this file /etc/webmin/virtual-server/spam/[numbers]/virtualmin.cf. What is the scope of the user_prefs file in this case?

The individual user configuration file is called user_prefs and is located in the user’s home directory in the .spamassassin subdirectory. The ability for individual users to have their own user_prefs is a tunable parameter.

According to the SpamAssassin documentation, there is a descending precedence of configuration files that SA considers when starting/restarting:

/usr/share/spamassassin
/etc/mail/spamassassin
/home/[user]/.spamassasin/user_prefs

in which the last one wins.

Virtualmin comes with its own configuration file

/etc/webmin/virtual-server/spam/[vm_number]/

Is this path considered and if so, is it the last one?

I made an attempt and modified the user_prefs file setting the score to the value 1. I restarted the service, but it was not taken into account, the files considered spam used the default value 5.

If I can’t find an explanation how the files from configuration I will set the score in each one at a different value and I will identify the order in which they are retrieved.

From what I can tell on my setup,
/etc/webmin/virtual-server/spam/[vm_number]/
is the .cf that defines the vs spam settings and the
/home/[user]/.spamassasin/user_prefs
is the .cf that defines an individual user’s settings

On mine the individual user’s settings overrides the others I believe.
You might want to check it to be sure because it gets pretty confusing

The local.cf files created in the /etc/webmin/virtual-server/spam/[machine_id] directories are actually symbolic links to /etc/spamassassin/local.cf. Basically we have a common configuration for all virtual servers. The difference appears through the values set in virtualmin.cf that exist for each individual server, the only one having the permission from the domain owner.

Finally, I came to a conclusion after tests. The file

/home/[user]/.spamassassin/user_prefs

applies to the owner of the virtual server and not to the email addresses that belong to the domain.

Virtualmin is able to create a /.spamassassin/user_prefs file for each email address based on that option in the UI set to Yes, but they will have to be edited manually, since they are not detected in the interface, in the server configuration.

If Allow mailbox users to create mail filters option in the Virtualmin > Email Settings > Spam and Virtus Scanning section is set to No, do not edit user_prefs expecting to change the SpamAssassin values for your mailboxes (all at onces). This only applies to the domain owner email address.

I set my Server .cf setup in Webmin, my VS .cf in Virtualmin and the VS user .cf in Usermin
The only weird thing I noticed was the default setting for each of the areas always displays Default(5) which is not really accurate since if you change the setting one level up the Default setting for the lower level should now be that number.
Example: Server set to 5
VS Default should be 5
VS set to 4
User Default should now be 4 but it still defaults to 5 which is misleading

When you say edited manually does that mean that editing in Usemin will do that?
I will have to check this since I believe I have only checked using the domain owner email account.
However, I would think that if you are not allowing users to change the SA rules (set to No) that it should apply to all settings in Usermin. A domain owner can set whatever they want in Virtualmin. I was only using the setting in Usermin to figure out how the system was working. What I do find odd is that if the setting is disabled for individual users in Virtualmin, why would the option be available or even visible in Usermin.

There is an order in which the values are retrieved, I showed it above. Basically there are 3 files that can set the SpamAssassin configuration. I created this post for information, because initially I thought that the user_prefs file created in the /home/domain_owner directory could modify the default values from the other two files for the domain, i.e. for all email addresses created. Well, it was only for the owner’s address, as individual changes were required per email address and not shared. Most likely I will use the values from /etc/mail/spamassassin/local.cf and I will not use individual configurations per email address, not offering this feature of editing especially as it could also be a security breach.

I have not checked what happens in Usermin, but in the Virtualmin interface the user_prefs files that will be created in the directory of each email address can only be edited in File Manager or Terminal. This is the path where the /home/[domain_owner]/homes/[email_address]/.spamassassin/ files will be created.

Just checked my settings and I do allow users to filter emails.

I think its an important tool to help organize and cleanup mail. If this is not checked Procmail won’t have access to the file and no filtering will be done that is set up by the user.

I was thinking of another checkbox I saw in one of the dialogs which controlled the creation of SpamAssasin rules by individual users.

I think this might be the location that Usermin settings are applied to.

Until now I mostly solve SPAM using access tables in Postfix and proper configuration for all restrictions in their order. It was enough to reject SPAM with an RFC error and a client never came back. But when you have to deal with a huge number of messages per minute, it is not advisable to do everything in MTA. For this reason I hand over the tasks to SpamAssassin which, if properly configured, is an extremely powerful tool.

In this case Usermin is working as expected.

Configuring the values in /home/[domain_owner]/.spamassassin as I did initially is wrong because it does not apply to all email addresses created in that domain, but only to the domain_owner’s address. This was the case without setting Allow mailbox users to create mail filter to Yes.

There are discussions over the time I found searching the Internet, but none of them have reached a conclusion.

Another situation that I need to check is related to the situation in which the value in the UI for Allow mailbox users to create mail filters is set to No, because the files created when the value was Yes are not deleted, but remain in place.

Are these files still taken into account or not? If SpamAssassin takes into account their existence (as I think it happens) then it is not good. They should be deleted, but that would mean their loss forever.

I am having issues with the function as it appears to impact 2 different things.
Its under Spam and Virus Scanning but appears to impact ALL mail filters


According to the help by selecting No it blocks access to the .procmailrc files
I believe this is where all the mail filter rules are stored.
Maybe it also blocks the local.cf file for the individual users’ spam settings?.

What happens when you want one but not the other. Filters may or may not have to do with Spam or viruses. Some additional information around how this works would certainly be helpful.

I am not quite sure why the filter stuff should be under the Spam and Virus heading.

If it is set to No, then SpamAssassin will take into account two configuration files, which it accesses in order from top to bottom

/usr/share/spamassassin/local.cf
/etc/mail/spamassassin/local.cf

The local.cf files in /etc/webmail/virtual-server/spam/[vm_id]/ are actually symbolic links to /etc/mail/spamassassin/, so we have a single configuration for all of them.

If it is set to Yes, then the directory /.spamassassin is created in each mail box inside a virtual server. There are three files inside, including local.cf, which will be access last after the two previously mentioned before.

However, a configuration can be applied for each virtual server when the option is set to No, provided that the settings are added to the virtualmin.cf file (it can be edited in the Virtualmin user interface). For information, the configuration files in a directory are read by SpamAssassin in alphabetical order, priority being those that start with numbers.

After installing Virtualmin and creating a virtual server in the /home/[domain] directory, there is no .spamassassin directory.

If we go to the UI Virtualmin > Email Settings > Spam and Virus Scanning and choose the Allow mailbox users to create mail filters option, then the /.spamassassin directories are created for the domain itself and for each individual email address. This directory contains three files, including user_prefs which is read last by SpamAssassin.

The order of reading the configuration files is from top to bottom in the following directories

/usr/share/spamassassin

/etc/mail/spamassassin

/etc/webmin/virtual-server/spam/[vserver_id]/

(note: in this directory there are symbolic links to the directory above. there is still virtualmin.cf which is read last)

/home/[domain]/homes/[email_box]/.spamassassin/

If in the meantime the previously mentioned option is set to No, the /.spamassassin directories remain created in /home, which is not right because SpamAssassin will still continue read the user_prefs file and apply the configuration. I noticed this when I changed the score in the first two directories above, but the one in /home was always taken over.

Virtualmin has a bug and I will report it. When the option is reset to No, all /.spamassassin directories in /home/[domain] must be deleted.

These tests were done in Debian 10. Now I discovered that in Debian 12 the .spamassassin directories are not created when the option is changed to Yes.

(still investigating before reporting as a new issue)

I’m using Centos 7.9

I just tested removing the SpamAssassin Mail Filter Module Webmin/Usermin Configuration/Avalable Modules


And Yes, the menu item is now gone from Usermin, however, the SpamAssassin setting I had originally placed (3.5) is still active even though it is no longer available to the user and the VServer setting (set in Virtualmin) is set to 4. I think I would have to manually edit the user file to fix that.
Just to check, I set the filter setting to No for users and sent another message and the Spam setting still indicates a Required_Score of 3.5 which was the users setting not the VServer setting.
If I manually edit the /home/vserver/homes/user/.spamassassin/user_prefs file the changes are used by the system even though I have set the Allow mailbox users to create mail filters to No
Another reason that I don’t think that item belongs under Spam and Virus scanning.

As you pointed out the user_pref file would have to be deleted, renamed or emptied. when the choice is changed.

It does do as the help points out and blocks the .procmailrc file in the users’ home directories so other filtering will not work

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.