I have been playing with some of the settings it the main server level (webmin), the virtual server level (Virtualmin) and checking the impact at the user level (Usermin)
These relate to the filtering and spam setup/control in Usermin
Steps to replicate:
Ensure the SpamAssassin and Procmail Mail Filter modules in Webmin/Usermin configuration are checked.
In Usermin the default score should display 3 but displays 4
I believe that this always shows the main server’s required_score for SpamAssasin.
In Usermin set the required_score to 2
Received messages in Usermin now display a required_score of 2
Return to the Usermin Modules in Webmin and remove the SpamAssassin Module.
Back in Usermin you will no longer have access to it but any settings made previously will still be in effect. Messages received still display a required_score of 2 which should have changed to the virtual server setting of 3.
You will either need to manually edit (or delete?) the pref file or re-enable the module to revert any changes made there.
There is also the option in Virtualmin to toggle the Allow mailbox users to create mail filters.
Since it is under Spam and Virus Scanning my assumption was that it will disable the SpamAssassin settings previously made. This however appears to be wrong. According to the help it blocks access to the local user Procmail file where all custom filters made by a user are stored. From what I can see it has no impact at all on SpamAssassin.
Maybe the idea originally was that users may use custom filters to search for Spam? Since I use these filters for organizing messages and SpamAssassin for Spam it makes little sense to me.
I personally believe that this command is in the wrong location or the Dialog Title needs to be re-thought.
Default settings for the SpamAssassin ‘required_score’ do not display changes from current overriding settings
Changing the accessibility of the SpamAssassin module in Usermin only hides access to the tool but does not change any previously saved configuration which could result in unexpected behaviours for users.
User prefs file needs to be deleted or possibly renamed if it might need to be reused if access is granted later.
The Spam and Virus Scanning dialog under Virtualmin contains features that do not actually pertain to Spam specifically but instead to Filtering tools which can also result in unexpected behaviours and confusion for users.
First Issue
SpamAssassin reads its configuration from many places in the following order
/usr/share/spamassassin /etc/spamassassin /etc/mail/spamassassin (which is a symlink to the previous directory) /etc/webmin/virtual-server/spam/[vm_id] (some files are symlinks, but virtualmin.cf is editable in the UI) /home/[domain]/homes/[mailboxes]/.spamassassin/user_prefs
Actually you set the score value in different places this is the reason you get a different behavior. My advice is to set the values for a virtual server in virtualmin.cf, for all mailboxes or per mailbox in user_prefs. Please do your own test by changing the scores in the local.cf, virtualmin.cf, user_prefs files, one by one, and after a change send an email to yourself. Check the header for score number to understand what config file was loaded by SA.
Second Issue
The option Allow mailbox users to create mail filters has nothing to do with SpamAssassin. Initially I was misled because it is in the SpamAssassin/ClamAV section. However, this option allows you to filter messages using Procmail. Basically, you create a .procmail file in the mailbox and filter the messages based on certain conditions. Unfortunately, this feature is very little addressed, although it has been in Virtualmin for a long time. There aren’t even any examples. I think the option should be changed and the word Procmail introduced, to be clearer. I know the tooltip is there for a purpose, but a word put there can solve the confusion even for an advanced user like me.
Yes, That’s why I have only made setting changes within Webmin, Virtualmin and Usermin GUIs. I specifically did that to maintain a logical workflow.
I would expect, logically, that as you move down the hierarchy from main sever, virtual server to User that the SpamAssassin configurations would have increasing preference over the level above. The most general to most specific with the last setting taking the highest precedence. I would expect this hierarchy as a standalone or shared sever could be managed by the main admin using Webmin. At the next level you would have virtual servers managed by the Domain holders who could be using Virtualmin to manage and the last level would be individual users who may manage their access using Usermin.
Generally, this does appear to be how it happens, but the Default required_score setting does not appear to be consistent. I tested by making changes and then sending emails and checking. At each change I tried to ensure that things were saved and updated and in some cases I logged out and logged back in to make sure the settings had changed to what they should be.
The 2nd issue is a problem for a user who may have had access to SpamAssassin at one point (in Usermin) but then the Domain owner decides to revoke this access by removing the SpamAssassin module. In this case the existing settings in the users account will still be used, even though they may not be visible. That particular pref file needs to be deleted or renamed so the Domain settings that are visible to the server administrator become the active ones. If this does not happen an admin could be trying to solve an issue that is caused by those preferences and not seeing them unless they check specifically for that file.
The 3rd issue is the misleading positioning (location) of the Allow Mailbox users to create mail filters under Spam and Virus settings. As you said it does not fit here.
If this is set to ‘No’, a warning is displayed in the Usermin mail filter area that explains this. However, it is a Filter setting not a Spam/Virus setting.
I considered submitting this as a Webmin/Usermin Issue but thought I should air it on this forum in case I have incorrect information.
