ConfigServer Community Forum

cool, sounds like a plan. Thanks!
I'll get back to you.

The spam.whitelist.rules are indeed managed by the configserver MSFE, and rewritten regulary by a perl script thats part of MSFE.
Some things in this way of function are useful, like adapt the rule automatically when adding or removing domains for WHM etc.
But for those who want for x reasons make changes to the behavior of spamassassin outside or as a *complement* to the configfiles managed by MSFE : nothing inhibits from adding a spamassassin ".cf" files for example in /etc/mail/spamassassin/ with your own name, for example "ZZ_my_own_setting.cf". (and back it up....)
Of course, there will be no web-interface to manage it, and the syntax of spamassassin config-files has to be followed.
So before restarting / reloading mailscanner (witch can be done in the webinterface of configserver MSFE), you have to test if the syntax is correct with a
# spamassassin --lint
command, and correct the syntax errors if there are.
Even if whitelists can be "dangerous" (a "From:" header can easily be spoofed, so there should be additional testing on DKIM-Signature:, or SPF etc (but good luck with it, as a lot of sites have wrong settings, so this with trigger flags :-( , so testing on other non-official criteria can be useful), you *can* put in such a file things like :
-----)
# BEGIN RULE_202112181723_HAM
# stackcommerce to @*********.fr
header __From_202112181723 From: =~ /\email\.sourcedomain\.com/
header __To_202112181723 To: =~ /\@destinationdomain.com/
meta RULE_202112181723_HAM (__From_202112181723 && __To_202112181723)
score RULE_202112181723_HAM -20.99
describe RULE_202112181723_HAM *********-MOD sourcedoomain to targetdomoain
(-----
This works : mail *claiming* to come from *@email.sourcedomain.com will be authorizes when it goes to the destinationdomain (but other domains are unaffected). This can be setup to the mailbox level.
The spamassassin rules are regex, so "@" and dots or "-" have to be escaped (or they will be interpreted as regex)
A negative "score" will move the mail to the "spam" category, a positive "score" will get it almost whitelisted (if there are no other problems, like virus, of filename rules, etc...
The rules files are interpreted in alphabetical order, and settings in the first can be overwritten in the second. So a "ZZ" in the beginning of the rule-name can do it have "the last word".
Of course, doing so you are managing things *partly* outside of MSFE and WHM/CPANEL : so specific care and organization is needed.
And nothing inhibits the possibility to have this ZZ_my_own_setting.cf file to be written automatically by a script ..., that can get its orders for a database etc...
Personally, "in my humble opinion", this is better as wanting to force MSFE to do things is it is not designed for, and avoiding conflicts with other precious automations that are done by WHM/CPANEL and configservers MSFE
An other way is to write a "custom function" inside /usr/mailscanner/ but it needs knowledge of perl objects.
An other way is to use spamassassin possibility to read data from SQL database that can be configured inside the configserver MSFE "MailScanner configuration" web interface in the section "Database SQL Configuration Settings".
As says MSFE : "This section allows you to over-ride any setting in this file or its related "include"d files with a setting or a ruleset in an SQL database"
Of course there is a protocol and syntax to be followd, but it is documented at
https://cwiki.apache.org/confluence/dis ... N/UsingSQL
And the population of this SQL database can be scripted too.
As always : no-trust for user-input via webforms.

@Sarah
1/ Maybe, as WHM/CPANEL does, when MSFE rewrites a rule file, add a comment / warning at the beginning, something like
"DO NOT EDIT, Direct modifications WILL be lost upon subsequent regeneration of this configuration file"
This could avoid frustration
2/ Maybe provide (if this can find its place in your legitimate own development choices), provide some client "include" files, example :
"To have your modifications retained, you should create/edit administrator-specific include files: ....."
that could be added by configserver MSFE scripts at the end of the generated rule file, and would give an easy way for users wanting this to add / over-write things with their own rules ?