Skip to content

rspamd policy per mailbox wrongly removed on mailuser update

Summary

If you update a mailbox from ispconfig interface, without change the spamfilter policy, the rspamd per-user configuration is removed

Steps to reproduce

  1. install a server default with autoinstaller (debian 11/12) with rspamd as mailfilter
  2. create a mailbox
  3. set to this mailbox a spamfilter policy (example normal)
  4. save
  5. you will see the file rspamd/local.d/{user}.conf file written
  6. then enter again on the mailbox from ispconfig
  7. try to update the quota with a different value, without change the spamfilter policy
  8. save
  9. now you will see the file rspamd/local.d/{user}.conf removed

Correct behaviour

The correct behaviour is that the mailbox will be updated, without the rspamd policy custom of the mail user removed

Environment

Server OS + version: (Debian 11/12) ISPConfig version: latest stable Software version of the related software: everything to the latest stable Output of the command: n/a

Proposed fix

This is NOT a proposted fix, but some information that hope could be useful. Basically I have found that when a mailbox user is updated from ispconfig without changing the spamfilter policy, on the file /usr/local/ispconfig/server/plugins-available/rspamd_plugin.inc.php at the row 285 the variable $data['new']['policy_id'] is always empty so intval($data['new']['policy_id']) is always 0 and the if is entered and the file removed:

if((!$this->isValidEmail($app->functions->idn_encode($email_address))) || !isset($data['new']['policy_id']) || intval($data['new']['policy_id']) == 0 && $type == 'spamfilter_user') {
    if(is_file($settings_file)) {
        unlink($settings_file);
    }
} else {
    [...]

In my testing server in order to avoid that i did something like this:

if ((!$this->isValidEmail($app->functions->idn_encode($email_address)))){
[...]

but i known that THIS IS NOT THE SOLUTION (due i did only on test, for debug purpose). Due that is really needed to understand: or why the $data['new']['policy_id'] is empty, or if it is that correct, accordingly change the original if to manage them properly. If you can reproduce this, i think that a patch is urgently required because as you can understand is very easy to have misleading anti spam settings for certain users.

Edited by Luca