Bug template rspamd_settings.conf — Whitelist per-user ineficaz

El problema 
 Las whitelists de SpamAssassin que los usuarios configuran desde el panel de DirectAdmin (E-Mail → SpamAssassin Setup → Whitelist) no funcionan con rspamd. Los remitentes whitelisteados siguen llegando a la carpeta spam. 
 Afecta a todas las versiones de DirectAdmin con spamd=rspamd (verificado hasta DA 1.696). 
 Causa raíz (doble) 
 El template /usr/local/directadmin/data/templates/rspamd_settings.conf genera bloques _whitelist en /etc/rspamd/users.d/*.conf con dos defectos: 
 1. Priority incorrecta 
 El bloque _whitelist tiene priority = 4 hardcoded, pero el bloque _prefs usa priority = medium (= 5 en rspamd). rspamd selecciona el bloque de mayor prioridad → _prefs SIEMPRE gana, la whitelist NUNCA se aplica. 
 2. Falta apply.actions 
 Incluso si la prioridad fuera correcta, el bloque whitelist solo tiene want_spam = yes sin un bloque apply { actions { ... } } . rspamd sigue añadiendo cabecera X-Spam-Status: Yes y el filtro de dominio de Exim sigue enviando a la carpeta spam. 
 Contraste con blacklist 
 Los bloques _blacklist del mismo template sí funcionan porque: 
 
 Usan priority = high (= 10) 
 Incluyen apply { actions { ... } } 
 
 Cómo verificar 
 # Ver qué settings block aplica rspamd para un usuario
grep "settings.lua" /var/log/rspamd/rspamd.log | grep USUARIO

# Siempre mostrará "settings_id: USUARIO_prefs" — nunca "USUARIO_whitelist"
 
 Solución: template custom 
 Paso 1: Crear copia custom del template 
 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
 
 Paso 2: Editar la copia custom 
 En /usr/local/directadmin/data/templates/custom/rspamd_settings.conf , buscar los bloques que contienen whitelist y cambiar: 
 Antes (roto): 
 |*if whitelist_count>"0"|
|WHITELIST_ID| {
	priority = 4;
|CUSTOM12|
|RCPT|
|whitelist_from_list|
	want_spam = yes;
|CUSTOM13|
}
 
 Después (corregido): 
 |*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|
}
 
 Hay dos bloques whitelist en el template (uno con |whitelist_from_list| y otro con listas adicionales). Aplicar el cambio a ambos. 
 Paso 3: Regenerar users.d para usuarios existentes 
 El template custom se aplica cuando: 
 
 Un usuario cambia sus preferencias de spam en el panel 
 Se ejecuta un rebuild que afecta a users.d 
 
 Para forzar la regeneración de un usuario específico, el usuario debe ir a E-Mail → SpamAssassin Setup y guardar (aunque no cambie nada). 
 Para usuarios que ya tenían whitelist activa , hay que parchear manualmente su fichero users.d/*.conf : 
 # Ejemplo para usuario "alufasa" en kvm456
# En /etc/rspamd/users.d/alufasa.conf, buscar el bloque _whitelist y cambiar:
# priority = 4 → priority = 6
# Añadir apply.actions tras want_spam = yes
 
 Cadena de prioridades correcta 
 blacklist (high=10) > whitelist (6) > prefs (medium=5) > default
 
 Persistencia 
 El template custom en data/templates/custom/ sobrevive updates de DirectAdmin. Es el mecanismo oficial de override. 
 Referencia: post en el foro DA 
 Este bug fue reportado en el foro oficial de DirectAdmin: 
 Bug: rspamd_settings.conf template — per-user whitelist never applied (priority 4 < prefs medium) 
 El bug original de blacklist (mismo template) fue reportado en 2019 y corregido. La whitelist nunca recibió el mismo fix. 
 Alternativa: whitelist dinámica via email 
 Independientemente de este bug, existe un sistema de whitelist dinámica gestionado via email que SÍ funciona correctamente — usa multimap con score -100 en vez del mecanismo de settings per-user. Ver la página "Whitelist dinámica de rspamd via email en DirectAdmin" en esta misma wiki. 
 Servidores con template custom desplegado 
 
 
 
 Servidor 
 Fecha 
 Usuarios parcheados manualmente 
 
 
 
 
 kvm456 
 2026-03-19 
 alufasa, amenocalbus, audionica, elayudante, gestemalisal, lopeza, regfiltersl 
 
 
 srv120 
 2026-03-19 
 tmar 
 
 
 srv121 
 2026-03-19 
 neolystic 
 
 
 dar 
 2026-03-19 
 (ninguno con whitelist activa) 
 
 
 
 Nota sobre want_spam = yes 
 want_spam = yes en rspamd settings NO es una whitelist por sí solo. Solo indica que el bloque de settings se aplica también a mensajes clasificados como spam. Sin apply.actions , rspamd sigue marcando el correo como spam. Es una trampa sutil de la documentación de rspamd.