I missed that. We use groups.conf now, but still use metrics§.conf although it is still workable but deprecated. We ought to move the metrics.conf to action.conf
unknown_weight = 1.0; # Enable if need to set score for all symbols implicitly
# Each new symbol is added multiplied by gf^N, where N is the number of spammy symbols
#grow_factor = 1.1;
I would like to enable the firts one
unknown_weight = 1.0;
if a symbol does not get a weight, the weight is 1
the bad thing now could drive us to change our way of mind:
Indeed the UI gets precedence over static by the dynamic map, so once a new settings is put in the web UI, static settings in configuration files are not used anymore.
Therefore we are going to a full rspamd UI I think, maybe not if we want to change the spam subject message but probably one day we could be able to do it in rspamd.
Actually the new way if you want to only add header and no rewrite subject, the way is to blank the value rewrite subject and save in the web UI of rspamd.
All new settings are saved in the dynamic map that you can edit online in the configuration tab (/var/lib/rspamd/rspamd_dynamic)
I know it is a new way that can change a lot of our habits maybe more for people using the CLI
IMHO options available in rspamd UI should be removed from the server manager.
Also a label like this should be added: “Options x,y,z can be configured using http://rpsmadUI”
I liked the idea to “disable” the mail-filter tab if rspamd takes the control. If we plan to replace Email with Email 2 as automated RPM update during ns7 lifecycle, I prefer the UI is not changed.
If the UI is misleading, it must be changed.
For example, if after the upgrade the UI has no real effect on the configuration, we can’t leave everything as is.
But we should inform the user about the change using something like the label suggested above
I think we all agree. If we cannot control rspamd settings from server manager, the server manager must reflect this situation consistently. What I want to suggest is not change the current UI widgets and labels to avoid “upgrade confusion”; just change the style to “read only/disabled” and put a link to rspamd UI.
It must be clear what is the new place where the thresholds can be tweaked.
@dev_team we have some change I would like to talk
if you look this snippet from /usr/share/rspamd/www/js/app/config.js
function saveActions(callback) {
var elts = loadActionsFromForm();
// String to array for comparison
var eltsArray = JSON.parse(loadActionsFromForm());
if (eltsArray[0] < 0) {
rspamd.alertMessage("alert-modal alert-error", "Spam can not be negative");
} else if (eltsArray[1] < 0) {
rspamd.alertMessage("alert-modal alert-error", "Rewrite subject can not be negative");
} else if (eltsArray[2] < 0) {
rspamd.alertMessage("alert-modal alert-error", "Probable spam can not be negative");
} else if (eltsArray[3] < 0) {
rspamd.alertMessage("alert-modal alert-error", "Greylist can not be negative");
} else if (
(eltsArray[2] === null || eltsArray[3] < eltsArray[2]) &&
(eltsArray[1] === null || eltsArray[2] < eltsArray[1]) &&
(eltsArray[0] === null || eltsArray[1] < eltsArray[0])
) {
callback("saveactions", null, null, "POST", {}, {
data: elts,
dataType: "json"
});
} else {
rspamd.alertMessage("alert-modal alert-error", "Incorrect order of metric actions threshold");
}
}
you saw that now the rewrite_subject action gets its own score and you cannot set the same score than the add_header because it breaks the UI. For now I added 0.1 more than the add_header but we can imagine to get a specific threshold for the rewrite_subject.
