Skip to main content

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.

Back to top