[Bug] rspamd_settings.conf template: per-user whitelist never applied (priority 4 < prefs medium)

[castris]

DirectAdmin version: 1.696
rspamd: via CustomBuild (spamd=rspamd)
Affected template: /usr/local/directadmin/data/templates/rspamd_settings.conf

Summary​

The rspamd_settings.conf template generates per-user whitelist blocks in /etc/rspamd/users.d/*.conf that never take effect due to two issues:

1. Priority bug: whitelist blocks use priority = 4 (hardcoded), but prefs blocks use priority = medium (which equals 5 in rspamd). Since rspamd selects the highest-priority matching settings block, _prefs (5) always wins over _whitelist (4). The whitelist settings are never applied.

2. Missing apply.actions: Even if the priority were correct, whitelist blocks only have want_spam = yes without an apply { actions { ... } } override. This means rspamd still adds X-Spam-Status: Yes headers, and Exim's domain filter still routes the message to the spam folder.

Note: The _blacklist blocks in the same template correctly use priority = high (=10) and include apply { actions { ... } }. So blacklisting works, but whitelisting does not.

How to reproduce​

1. As a DA user, go to E-Mail → SpamAssassin Setup → Whitelist
2. Add a sender address (e.g., [email protected])
3. Check the generated /etc/rspamd/users.d/USERNAME.conf
4. Send a message from that whitelisted address with a score above the user's threshold
5. Expected: message delivered to inbox (whitelist should override)
6. Actual: message delivered to spam folder — rspamd applied _prefs settings (priority medium=5) instead of _whitelist (priority 4)

You can confirm which settings block rspamd selected in the log:

grep "settings.lua" /var/log/rspamd/rspamd.log | grep USERNAME

It will always show settings_id: USERNAME_prefs — never USERNAME_whitelist.

Current template (whitelist section)​

|*if whitelist_count>"0"|
|WHITELIST_ID| {
    priority = 4;               ← lower than _prefs (medium=5)
|CUSTOM12|
|RCPT|
|whitelist_from_list|
    want_spam = yes;            ← no apply.actions block
|CUSTOM13|
}

Suggested fix​

The whitelist blocks should:

• Use a priority higher than medium (e.g., 6) so they override _prefs
• Include apply { actions { ... } } to actually suppress spam marking

|*if whitelist_count>"0"|
|WHITELIST_ID| {
    priority = 6;
|CUSTOM12|
|RCPT|
|whitelist_from_list|
    want_spam = yes;
    apply {
        actions {
            "add header" = 9999;
            "rewrite subject" = null;
        }
    }
|CUSTOM13|
}

This maintains the correct priority chain:

blacklist (high=10) > whitelist (6) > prefs (medium=5) > default

Workaround​

Create a custom template override:

mkdir -p /usr/local/directadmin/data/templates/custom/
cp /usr/local/directadmin/data/templates/rspamd_settings.conf \
   /usr/local/directadmin/data/templates/custom/rspamd_settings.conf

Then edit the custom copy with the changes above. This survives DA updates.

Note: Existing users.d/*.conf files need manual patching or a user action (changing SA prefs in the panel) to be regenerated from the new template.

Related threads​

• Rspamd (possible) bug found in DA generated user settings conf — 2019 bug where _blacklist used action instead of apply { actions }. Fixed for blacklist, but whitelist was never given an apply block.
• Whitelist/Blacklist not work with Exim + Rspamd — 2020 report describing the same symptom (whitelist not working), never resolved.

Impact​

Every DA server using spamd=rspamd where users have configured SpamAssassin whitelists via the panel is affected. The whitelist entries are stored correctly in user_prefs and appear in the generated users.d/*.conf, but they have no practical effect on mail delivery.


If this isn't the best way to get this information, please direct me to the best place.

Best regards.