Rspamd: configuración mínima inicial que realmente funciona

enero 25, 2026 • febrero 3, 2026 • Lectura: 30 min • Views: 7

¿Te fue útil?

Algunos filtros de spam fallan de forma ruidosa. Rspamd falla como un profesional: acepta correo, murmura en los registros y tus usuarios siguen enviándote capturas de pantalla de “Bitcoin invoice.pdf.exe”. Mientras tanto miras un desglose de puntuación que parece correcto, pero nada se rechaza, firma o aprende.

Esta es una guía de puesta en marcha para personas que operan sistemas en producción. Configuración mínima, no pensamiento mínimo. Te llevaremos a una línea base funcional: escaneo con Rspamd, firmado DKIM, estado respaldado por Redis, una IU segura y una integración MTA que no se omite silenciosamente.

Qué significa “mínimo” en producción

Mínimo no es “menos líneas de configuración”. Mínimo es “menos piezas móviles que aún te dan resultados predecibles”. Para Rspamd, esa línea base es:

Un demonio rspamd en ejecución y rspamd_proxy manejando el escaneo.
Redis habilitado para historial, fuzzy, Bayes y cachés variados (puedes sobrevivir sin él, pero odiarás a tu yo futuro).
Integración MTA que no pueda “ser omitida por accidente”. Para Postfix eso significa un milter, y que el socket sea accesible desde el contexto de proceso de Postfix.
Firmado DKIM para el correo saliente, con claves en un lugar sensato y selectores que puedas rotar.
Umbrales de acción que coincidan con la realidad (rechazar lo obviamente malo, añadir cabecera en borderline), y registros que te digan qué ocurrió.

Lo que mínimo no es:

Activar todos los módulos porque “quizás ayude”. Así terminas poniendo en lista gris tu propio correo de monitorización y llamándolo “seguridad”.
Editar archivos bajo /etc/rspamd/ directamente cuando deberías usar local.d y override.d.
Omitir DKIM porque “no estás listo”. Tus destinatarios están listos; te puntuarán como spammer.

Una verdad operacional: si no puedes explicar cómo un mensaje obtuvo su acción final (rechazar/añadir-cabecera/sin acción), no tienes un filtro de spam, tienes un rumor.

Algunos hechos e historial que cambian decisiones

Estos son el tipo de pequeños hechos concretos que te impiden tomar la decisión arquitectónica equivocada a las 2 a.m.

Rspamd fue diseñado desde el inicio como un sistema multicomponente (tipos de workers, proxy, controlador). No es un monolito; si lo configuras como tal, lo diagnosticarás como tal.
Depende mucho de Redis para cosas más allá de Bayes: resultados en caché, reputación, comprobaciones fuzzy e historial. Trata a Redis como parte de la canalización de correo, no como un “agradable de tener”.
El modelo de puntuación de Rspamd está basado en símbolos: no dice “spam/no spam”, dice “aquí están las razones con pesos”. Por eso ajustar es sobrevivible—si no entras en pánico y editas puntuaciones a lo loco.
La entregabilidad moderna se basa en autenticación: DKIM, SPF, DMARC. El filtrado ayuda la entrada; DKIM ayuda a que el correo saliente no parezca una estafa.
Los milters son antiguos pero efectivos. También son fáciles de cablear mal. La mayoría de los reportes “Rspamd no filtra” son “el MTA nunca lo llamó”.
Rspamd soporta múltiples patrones de integración: milter, proxy LMTP, proxy SMTP. “Mínimo que funciona” depende de tu MTA, pero los modos de fallo son similares: omisión, timeouts, sockets equivocados.
La rotación de claves DKIM es barata operativamente si usas bien los selectores. Si fijas un selector en todas partes para siempre, acabarás programando una ventana de mantenimiento aterradora por una tarea no aterradora.
Rspamd tiene un controlador HTTP incorporado para estadísticas y comandos. Exponerlo sin autenticación es una pequeña tragedia evitable.

Arquitectura mínima funcional (y qué evitar)

Aquí está la arquitectura base que suele “simplemente funcionar” en un único host de correo con Postfix:

Postfix recibe el correo y lo pasa a un socket milter.
rspamd_proxy acepta peticiones milter, llama a los workers de escaneo y luego le dice a Postfix qué hacer y añade cabeceras.
rspamd usa Redis local para cachés y Bayes, y almacena historial para depuración.
El firmado DKIM ocurre dentro de Rspamd para el correo saliente (Postfix pasa el correo por el mismo milter).

Qué evitar al principio:

Clustering de Rspamd en varios nodos. No porque sea malo, sino porque confundirás problemas de red con problemas de puntuación.
Módulos exóticos (múltiples sistemas OCR, reglas Lua personalizadas). Primero asegúrate de que el correo se está escaneando.
Automatización del entrenamiento Bayes antes de tener separación correcta ham/spam y puntuaciones estables. Automatizar un conjunto de datos erróneo es una forma muy eficiente de equivocarse.

Broma #1: Un filtro de spam sin registros es como un paracaídas hecho de opiniones—técnicamente ligero, operativamente valiente.

Instalar y verificar que el demonio realmente esté ejecutándose

Asumiremos un host Debian/Ubuntu con systemd. Si estás en otra cosa, traduce el gestor de paquetes y los nombres de servicio, no la lógica.

Instalar paquetes

cr0x@server:~$ sudo apt-get update
...output...
cr0x@server:~$ sudo apt-get install -y rspamd redis-server
...output...

Decisión: Si los paquetes de tu distro están desactualizados, lo notarás en módulos faltantes y errores que no deberías depurar. Pero “mínimo que funciona” sigue funcionando con paquetes de distro—solo no pretendas que esté al día.

Comprobar que los servicios están arriba

cr0x@server:~$ systemctl status rspamd --no-pager
● rspamd.service - Rapid spam filtering system
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2026-01-03 09:01:12 UTC; 2min ago
...output...
cr0x@server:~$ systemctl status redis-server --no-pager
● redis-server.service - Advanced key-value store
     Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2026-01-03 09:01:03 UTC; 2min ago
...output...

Decisión: Si alguno no está active (running), detente. Arregla eso primero. El escaneo de correo es una canalización; un componente muerto no está “degradado”, no está sucediendo.

Confirmar que Rspamd está escuchando

cr0x@server:~$ sudo ss -lntp | egrep '11334|11333|11332'
LISTEN 0      4096         127.0.0.1:11334      0.0.0.0:*    users:(("rspamd",pid=1827,fd=6))
LISTEN 0      4096         127.0.0.1:11333      0.0.0.0:*    users:(("rspamd",pid=1827,fd=7))
LISTEN 0      4096         127.0.0.1:11332      0.0.0.0:*    users:(("rspamd",pid=1827,fd=8))

Lo que significa: los puertos por defecto de Rspamd están activos (proxy/controlador/interfaces worker dependen del empaquetado).

Decisión: Si no están escuchando, estás mal configurado o el paquete usa sockets diferentes (a menudo UNIX). No conectes Postfix a un puerto que no hayas probado que existe.

Distribución de la configuración: cómo no pelear con Rspamd

La configuración de Rspamd es por capas. Trata la configuración del proveedor como de solo lectura. Tu trabajo es sobreescribir limpiamente.

/etc/rspamd/: configuración base distribuida por el paquete
/etc/rspamd/local.d/: tus cambios locales (lo más común)
/etc/rspamd/override.d/: sobreescrituras estrictas cuando debes sobreescribir defaults

Regla: si editas /etc/rspamd/rspamd.conf directamente, te estás apuntando a dolor durante las actualizaciones y a arqueología del tipo “por qué cambió esto”.

Validar configuración antes de reiniciar

cr0x@server:~$ sudo rspamd -t
syntax OK

Lo que significa: el parser está de acuerdo con tus archivos.

Decisión: Si esto falla, no reinicies. Corrige sintaxis primero; un filtro de spam roto tiende a fallar abierto de formas que no notarás hasta que lo hagan los usuarios.

Redis: la única dependencia en la que no debes escatimar

Sí, puedes ejecutar Rspamd sin Redis. Aún escaneará. Y aún perderás la visibilidad y el estado que hacen que el escaneo sea fiable: Bayes, fuzzy, historial y cachés. En producción, Redis no es opcional; es tu memoria.

Configuración mínima de Redis para Rspamd

En un host único, usa un socket UNIX local para velocidad y claridad de permisos. Pon esto en /etc/rspamd/local.d/redis.conf:

cr0x@server:~$ sudo tee /etc/rspamd/local.d/redis.conf > /dev/null <<'EOF'
servers = "unix:/run/redis/redis-server.sock";
EOF

Ahora asegura que Redis expone ese socket y que Rspamd puede leerlo. En sistemas tipo Debian, suele hacerlo. Verifica:

cr0x@server:~$ ls -l /run/redis/redis-server.sock
srwxrwx--- 1 redis redis 0 Jan  3 09:01 /run/redis/redis-server.sock

Lo que significa: los permisos de grupo importan. Si rspamd no está en el grupo redis, no puede hablar.

Decisión: Añade rspamd al grupo redis (o configura ACLs) en lugar de cambiar Redis a TCP “porque es más fácil”. Fácil hoy, incidente mañana.

cr0x@server:~$ sudo usermod -aG redis rspamd
cr0x@server:~$ sudo systemctl restart rspamd
...output...

Confirmar que Rspamd puede usar Redis

cr0x@server:~$ sudo rspamadm configdump redis
servers = "unix:/run/redis/redis-server.sock";

Decisión: Si aún apunta a otro sitio, pusiste el archivo en el lugar equivocado o tu paquete usa un orden de inclusión distinto. Arregla eso antes de afinar cualquier otra cosa.

Integración con Postfix (milter) que realmente filtra correo

El modo de fallo principal es vergonzosamente simple: Postfix nunca llama a Rspamd. Todo lo demás que hagas—Redis, DKIM, Bayes—se vuelve arte performativo.

Para la configuración mínima, usa un socket milter local provisto por Rspamd proxy. Muchos paquetes exponen /run/rspamd/milter.sock. Verifica primero:

cr0x@server:~$ sudo find /run -maxdepth 2 -type s -name '*milter*sock' -o -name 'rspamd*.sock'
/run/rspamd/milter.sock

Decisión: Si no tienes un socket, o bien necesitas habilitar el worker milter o tu paquete usa TCP. No adivines; inspecciona.

Configurar Postfix para usar el milter de Rspamd

Edita la configuración principal de Postfix. Usa rutas tanto SMTPd como no-SMTPd si te importan las entregas locales. Valores mínimos y fiables:

cr0x@server:~$ sudo postconf -e 'smtpd_milters=unix:/run/rspamd/milter.sock'
cr0x@server:~$ sudo postconf -e 'non_smtpd_milters=unix:/run/rspamd/milter.sock'
cr0x@server:~$ sudo postconf -e 'milter_protocol=6'
cr0x@server:~$ sudo postconf -e 'milter_default_action=accept'
cr0x@server:~$ sudo postconf -e 'milter_mail_macros=i {mail_addr} {client_addr} {client_name} {auth_authen}'

Lo que significa:

milter_default_action=accept es conservador: si Rspamd cae, el correo fluye. Esto evita caídas totales, pero puede ser aprovechado si atacantes fuerzan timeouts.
milter_protocol=6 es lo bastante moderno para soporte de macros común.

Decisión: En algunos entornos, “fallar abierto” es aceptable; en otros, es un problema de cumplimiento. Si eres un objetivo de alto valor, considera tempfail una vez confíes en la estabilidad.

Recargar Postfix y verificar que use el socket

cr0x@server:~$ sudo systemctl reload postfix
...output...
cr0x@server:~$ sudo postconf | egrep 'smtpd_milters|non_smtpd_milters|milter_default_action'
smtpd_milters = unix:/run/rspamd/milter.sock
non_smtpd_milters = unix:/run/rspamd/milter.sock
milter_default_action = accept

Decisión: Si Postfix muestra los valores correctos pero el correo sigue sin filtrarse, probablemente tengas un problema de permisos del socket o un límite de chroot.

Comprobar que Postfix puede acceder al socket milter

cr0x@server:~$ sudo ls -l /run/rspamd/milter.sock
srwxrwx--- 1 rspamd rspamd 0 Jan  3 09:01 /run/rspamd/milter.sock

Lo que significa: si el socket es rspamd:rspamd con 770, los procesos de Postfix podrían no estar en ese grupo.

Decisión: Añade el usuario Postfix al grupo rspamd, o ajusta los permisos del socket en la configuración del worker de Rspamd. No hagas chmod 777 a un límite de seguridad y lo llames “temporal”. Temporal suele ser permanente con denegación.

cr0x@server:~$ sudo usermod -aG rspamd postfix
cr0x@server:~$ sudo systemctl restart postfix
...output...

Firmado DKIM: mínimo pero correcto

DKIM no es solo teatro de entregabilidad. Es una señal fuerte para los receptores de que tu correo saliente es consistente, no falsificado y no un pase de una noche.

El DKIM mínimo en Rspamd necesita:

Un par de claves almacenado en disco con permisos correctos.
Un selector (como s2026) que puedas rotar.
Un mapeo de tu dominio al selector y la ruta de la clave.

Generar una clave DKIM

Crea un directorio para claves y ciérralo:

cr0x@server:~$ sudo install -d -m 0750 -o rspamd -g rspamd /var/lib/rspamd/dkim

Genera una clave de 2048 bits (base común):

cr0x@server:~$ sudo rspamadm dkim_keygen -b 2048 -s s2026 -d example.com -k /var/lib/rspamd/dkim/s2026.example.com.key > /tmp/s2026.example.com.txt
cr0x@server:~$ sudo chown rspamd:rspamd /var/lib/rspamd/dkim/s2026.example.com.key
cr0x@server:~$ sudo chmod 0640 /var/lib/rspamd/dkim/s2026.example.com.key

Lo que significa: la clave privada es legible por Rspamd; no por el mundo; no por demonios aleatorios.

Decisión: Si te tienta poner claves DKIM en /etc con permisos laxos “para que las copias de seguridad las cojan”, arregla las copias de seguridad en su lugar. Los secretos no dejan de ser secretos porque sean inconvenientes.

Configurar el módulo de firmado DKIM

Crea /etc/rspamd/local.d/dkim_signing.conf:

cr0x@server:~$ sudo tee /etc/rspamd/local.d/dkim_signing.conf > /dev/null <<'EOF'
path = "/var/lib/rspamd/dkim/$selector.$domain.key";
selector_map = "/etc/rspamd/dkim_selectors.map";
key_map = "/etc/rspamd/dkim_keys.map";
signing_table = "/etc/rspamd/dkim_signing.map";
use_esld = false;
allow_username_mismatch = true;
EOF

Ahora crea los tres pequeños archivos de mapa. Mantenlos explícitos; “auto mágico” es como firmas el dominio equivocado.

cr0x@server:~$ sudo tee /etc/rspamd/dkim_selectors.map > /dev/null <<'EOF'
example.com s2026
EOF
cr0x@server:~$ sudo tee /etc/rspamd/dkim_keys.map > /dev/null <<'EOF'
example.com /var/lib/rspamd/dkim/s2026.example.com.key
EOF
cr0x@server:~$ sudo tee /etc/rspamd/dkim_signing.map > /dev/null <<'EOF'
*@example.com example.com
EOF

Lo que significa: cualquier correo de @example.com se firma con la clave del dominio example.com, selector s2026.

Decisión: Si alojas múltiples dominios, no “reuses una clave para todos los dominios”. Funciona técnicamente; es un olor a mala higiene y entregabilidad.

Reiniciar y verificar que el módulo DKIM se cargue

cr0x@server:~$ sudo rspamd -t
syntax OK
cr0x@server:~$ sudo systemctl restart rspamd
...output...
cr0x@server:~$ sudo journalctl -u rspamd -n 50 --no-pager
...output...

Decisión: En los registros, quieres ausencia de errores DKIM. Si ves “cannot load key”, suele ser desajuste de ruta o permisos.

Acciones y umbrales: rechazar, añadir cabecera, greylist

Rspamd puede hacer muchas acciones. La configuración mínima es: añadir cabeceras siempre, rechazar solo para spam de alta confianza, y hacer algo sensato para el correo borderline.

Pon esto en /etc/rspamd/local.d/actions.conf:

cr0x@server:~$ sudo tee /etc/rspamd/local.d/actions.conf > /dev/null <<'EOF'
actions {
  add_header = 6.0;
  rewrite_subject = 8.0;
  reject = 15.0;
  greylist = 4.0;
}
EOF

Lo que significa: por debajo de 4 está limpio; 4–6 lista gris; 6–8 añade cabeceras; 8–15 reescribe asunto; 15+ rechaza. Tus números variarán. Este conjunto tiende a ser sobrevivible para un primer despliegue.

Decisión: Si tu organización tiene tolerancia cero a correo retrasado, sube el umbral de greylist o desactívalo inicialmente. La greylisting no es “precisión gratis”; cambia latencia por señal.

Broma #2: La greylisting es como compras corporativas—todo se aprueba eventualmente, solo que no mientras sigues en la llamada.

Interfaz web: asegúrala o apágala

La interfaz de control es útil. También es una mina de operación si la expones a Internet, porque puede cambiar configuración y disparar aprendidos según permisos.

Vincular el controlador a localhost (valor predeterminado seguro mínimo)

En muchos paquetes ya es así. Verifica y fuerza en /etc/rspamd/local.d/worker-controller.inc:

cr0x@server:~$ sudo tee /etc/rspamd/local.d/worker-controller.inc > /dev/null <<'EOF'
bind_socket = "127.0.0.1:11334";
password = "$2$5$z0JwF4Tj9p7vVh2q3l8y8u3n7q9rHk0rHk0rHk0rHk0rHk0rHk0";
enable_password = "false";
EOF

Lo que significa: el controlador solo es accesible localmente. El hash de contraseña mostrado es un formato de marcador; genera el tuyo con rspamadm pw.

Generar un hash de contraseña para el controlador:

cr0x@server:~$ rspamadm pw -p 'ChangeThisNow'
$2$5$V1m0JwA3WcEoTg6hS2mY3uWJ5FzqKXHcGJ7x1VZy9uVw9d9QmGq2

Decisión: Si necesitas acceso remoto, ponlo detrás de un reenvío de puerto SSH o una VPN. Si insistes en vincularlo a una interfaz pública, también necesitas reglas de firewall y autenticación fuerte. “Es solo una UI” es como haces que desconocidos cambien la política de correo.

Tareas prácticas (comandos + salidas + decisiones)

Esta sección es la carne: tareas concretas que ejecutarás el primer día. Cada una incluye qué significa la salida y la decisión operacional que tomas a partir de ella.

Tarea 1: Confirmar qué workers de Rspamd están corriendo

cr0x@server:~$ sudo rspamadm control stat
Uptime: 0 days, 00:03:21
Messages scanned: 122
Messages learned: 0
Connections: 18

Lo que significa: el escaneo ocurre al menos en algún lugar; “Messages scanned” distinto de cero es bueno.

Decisión: Si scanned es cero mientras el correo fluye, estás omitiendo Rspamd. Ve directo a cableado milter de Postfix y registros.

Tarea 2: Verificar que Postfix realmente llama al milter

cr0x@server:~$ sudo journalctl -u postfix -n 80 --no-pager | egrep -i 'milter|rspamd'
... postfix/smtpd[2140]: milter-connect: connect to unix:/run/rspamd/milter.sock: No such file or directory

Lo que significa: Postfix intentó, falló al conectar. El filtro está omitido (porque pusimos default_action=accept).

Decisión: Arregla la ruta del socket o asegúrate de que el worker/proxy rspamd esté configurado para crearlo. No “resuelvas” esto cambiando a TCP sin entender por qué falta el socket.

Tarea 3: Inspeccionar existencia y propiedad del socket milter

cr0x@server:~$ sudo ls -l /run/rspamd/milter.sock
srwxrwx--- 1 rspamd rspamd 0 Jan  3 09:01 /run/rspamd/milter.sock

Lo que significa: solo propietario/grupo pueden conectar.

Decisión: Asegura que Postfix tenga acceso de grupo (añadir al grupo o cambiar modo del socket vía config del worker). No le pongas permisos 777 en un sistema compartido.

Tarea 4: Confirmar que Rspamd puede hablar con Redis

cr0x@server:~$ sudo rspamadm configdump redis
servers = "unix:/run/redis/redis-server.sock";

Lo que significa: Rspamd cree que Redis está en ese socket.

Decisión: Si Redis está en TCP o en otro socket, alinéalo. “Dos configuraciones de Redis” es un clásico fallo autoinfligido durante reinicios.

Tarea 5: Comprobar rápidamente salud y latencia de Redis

cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock ping
PONG
cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock --latency -i 1
min: 0, max: 1, avg: 0.22 (55 samples)

Lo que significa: Redis responde; la latencia es baja. Si ves picos a decenas/centenas de ms, Rspamd lo sentirá como escaneo lento.

Decisión: Si la latencia es alta, revisa IO de disco, swapping y si Redis está haciendo persistencia agresiva. Arregla la salud del host antes de afinar reglas de spam.

Tarea 6: Probar escaneo de un mensaje de ejemplo localmente

cr0x@server:~$ printf 'From: a@example.net\nTo: b@example.com\nSubject: test\n\nHello\n' | rspamc
Results for file: stdin (0.012 seconds)
[Metric: default]
Action: no action
Spam: false
Score: 0.30 / 15.00
Symbol: MIME_GOOD (-0.10)
Symbol: R_SPF_ALLOW (-0.20)
Symbol: R_DKIM_NA (0.60)

Lo que significa: el escaneo funciona; se producen símbolos. DKIM es “NA” porque es entrante y no está firmado.

Decisión: Si rspamc puede escanear pero el flujo de correo no muestra cabeceras, tu integración MTA está mal, no Rspamd.

Tarea 7: Confirmar que se añaden cabeceras en correo real

cr0x@server:~$ sudo postqueue -p
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9C1B23D4A1      1244 Sat Jan  3 09:10:05  alerts@example.com
                                         user@example.com
-- 1 Kbytes in 1 Request.

Lo que significa: el correo está en cola; no es prueba de filtrado.

Decisión: Toma un mensaje entregado y comprueba que tenga cabeceras X-Spam- o Authentication-Results. Si faltan, Postfix no lo pasó por el milter.

Tarea 8: Verificar que se firma DKIM en correo saliente

cr0x@server:~$ sudo journalctl -u rspamd -n 120 --no-pager | egrep -i 'dkim|sign'
... rspamd[1827]: dkim_signing: sign example.com with selector s2026

Lo que significa: Rspamd intentó firmar; buena señal.

Decisión: Si nunca ves registros de firmado DKIM, confirma que el correo saliente atraviesa el milter (non_smtpd_milters importa para envíos locales).

Tarea 9: Generar el registro DNS desde la salida de la clave pública

cr0x@server:~$ sudo head -n 5 /tmp/s2026.example.com.txt
s2026._domainkey IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." ) ;

Lo que significa: esto es lo que publicas en DNS. El selector forma parte de la etiqueta DNS.

Decisión: Hasta que el DNS se publique y propague, los receptores no validarán DKIM. No es culpa de Rspamd; es tu gestión de cambios.

Tarea 10: Comprobar rendimiento y tiempo por mensaje de Rspamd

cr0x@server:~$ sudo rspamadm control stat | egrep 'Messages scanned|Uptime'
Uptime: 0 days, 00:08:44
Messages scanned: 486

Lo que significa: los mensajes se procesan. Compara la tasa de escaneado con tu tasa de correo entrante.

Decisión: Si el escaneo queda atrás respecto al volumen, revisa CPU, DNS y latencia de Redis antes de ajustar el número de workers.

Tarea 11: Identificar reglas lentas con logs (basado en síntomas)

cr0x@server:~$ sudo journalctl -u rspamd -n 200 --no-pager | egrep -i 'slow|timeout|lua'
... rspamd[1827]: rspamd_task_timeout: processing of task exceeded 8.0 seconds

Lo que significa: Rspamd alcanzó un timeout, a menudo por DNS, comprobaciones HTTP o recursos sobrecargados.

Decisión: Si ocurren timeouts durante el tráfico, en la práctica estás “fallando abierto”. Arregla dependencias (DNS/Redis/CPU) antes de endurecer la acción por defecto del milter.

Tarea 12: Comprobar velocidad de resolución DNS desde el host de correo

cr0x@server:~$ time dig +tries=1 +timeout=1 mx gmail.com @127.0.0.53 | egrep 'status|Query time'
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59504
;; Query time: 18 msec
real	0m0.040s
user	0m0.010s
sys	0m0.004s

Lo que significa: DNS es rápido. Si el tiempo de consulta es alto o ocurren timeouts, Rspamd se enlentecerá y verás demoras en milter.

Decisión: Si DNS es lento, arregla el caché del resolvedor local o la fiabilidad del DNS ascendente. El filtrado de spam es una carga de trabajo muy dependiente de DNS.

Tarea 13: Comprobar que tus cambios provienen de local.d (no ignorados)

cr0x@server:~$ sudo rspamadm configdump actions | head
actions {
    add_header = 6;
    greylist = 4;
    reject = 15;
    rewrite_subject = 8;
}

Lo que significa: tu actions.conf está cargado.

Decisión: Si muestra valores distintos, editaste el archivo equivocado o otra sobreescritura está ganando. Arregla el orden de capas de configuración antes de perseguir comportamientos fantasma.

Tarea 14: Confirmar versión de Rspamd y opciones de compilación

cr0x@server:~$ rspamd --version
Rspamd 3.4

Lo que significa: tu versión en tiempo de ejecución. Esto importa porque los defaults y la sintaxis de módulos evolucionan.

Decisión: Si estás en algo muy antiguo, evita afinar profundamente hasta planear una actualización. No quieres ajustar alrededor de bugs.

Guía de diagnóstico rápido

Estás de guardia. El correo es lento o el spam pasa. Tienes diez minutos antes de que alguien diga “¿podemos simplemente desactivarlo?”. Aquí está el orden que encuentra cuellos de botella rápido.

1) ¿Se está escaneando realmente el correo?

Comprueba estadísticas de Rspamd: sudo rspamadm control stat. Si scanned está plano mientras el correo fluye, el MTA está omitiendo.
Revisa los logs de Postfix por conexiones/errores de milter.

Interpretación: si se omite, ajustar puntuaciones no sirve. Arregla el cableado.

2) ¿La ruta del milter es accesible desde Postfix?

¿Existe el socket? ls -l /run/rspamd/milter.sock
¿Los permisos permiten que Postfix conecte? Membresía de grupo y modo.
¿Te atrapa un chroot? Si Postfix corre en chroot para smtpd, el socket debe existir dentro de ese path chroot o debes deshabilitar el chroot para ese servicio.

Interpretación: “connection refused” o “no such file” es casi siempre permisos/path locales, no red.

3) ¿Rspamd está lento porque una dependencia está lenta?

Latencia de Redis: redis-cli --latency
Tiempo DNS: dig con timeout corto y comprueba tiempo de consulta
CPU y carga: top o systemd-cgtop
Presión de disco: si la persistencia de Redis se atasca, lo verás como picos de latencia

Interpretación: timeouts en logs de Rspamd suelen apuntar a DNS/HTTP o recursos sobrecargados. Arregla la plataforma primero.

4) ¿Rspamd actúa, pero tu política es demasiado suave?

Inspecciona símbolos de una muestra de spam: rspamc -h 127.0.0.1:11333 (o por defecto)
Revisa umbrales de acciones vía rspamadm configdump actions
Confirma que Postfix no esté eliminando cabeceras aguas abajo (algunos filtros de contenido lo hacen)

Interpretación: si siempre “añades cabecera” pero nunca rechazas, los usuarios dirán “el spam pasa”. No están equivocados; simplemente no le dijiste a Postfix que haga algo más contundente.

5) Solo entonces: afina puntuaciones o habilita módulos extra

Una vez confíes en la canalización y el rendimiento, ajusta umbrales y considera módulos como greylisting, multimap, fuzzy y cadencia de entrenamiento Bayes.

“La esperanza no es una estrategia.” — General James N. Mattis

Errores comunes: síntoma → causa raíz → solución

1) “Rspamd está en ejecución, pero no aparecen cabeceras en el correo entregado”

Síntoma: La UI muestra actividad, pero los mensajes en buzones carecen de cabeceras X-Spam; el spam pasa sin cambios.
Causa raíz: Postfix no está usando el milter para esa ruta de correo (a menudo falta non_smtpd_milters), o el socket es inaccesible por permisos/chroot.
Solución: Configura tanto smtpd_milters como non_smtpd_milters. Valida accesibilidad del socket y ajustes chroot de Postfix. Reinicia Postfix y confirma en logs conexiones exitosas al milter.

2) “Los logs de Postfix muestran timeouts de milter; el correo está lento”

Síntoma: Las sesiones SMTP se bloquean; el log de Postfix menciona timeout de milter; logs de Rspamd muestran timeouts de tarea.
Causa raíz: Lentitud del resolvedor DNS, latencia de Redis, CPU sobrecargada o comprobaciones externas largas (módulos HTTP tipo RBL).
Solución: Mide tiempo de consulta DNS, latencia Redis y CPU. Arregla caché del resolvedor, contención de recursos o reduce módulos costosos antes de cambiar timeouts.

3) “El firmado DKIM no ocurre en absoluto”

Síntoma: No hay cabecera DKIM-Signature saliente; logs silenciosos.
Causa raíz: El correo saliente no atraviesa el milter (ruta de envíos bypass), o las tablas de firmado no coinciden con el dominio remitente.
Solución: Asegura que non_smtpd_milters esté configurado. Verifica que las tablas de firmado coincidan con patrones del From/envelope. Observa logs para decisiones de firmado.

4) “Errores de firmado DKIM: cannot load key”

Síntoma: Logs de Rspamd muestran fallos al cargar claves; firmado omitido.
Causa raíz: Ruta de archivo errónea en mapas, combinación selector/dominio equivocada, o permisos demasiado restrictivos (u ownership incorrecto).
Solución: Confirma que la ruta de la clave existe, que el propietario es rspamd, que el modo permite lectura y que los mapas apuntan a la ubicación correcta. Ejecuta de nuevo rspamd -t.

5) “Todo es marcado como spam tras habilitar greylisting”

Síntoma: Correo legítimo retrasado o rechazado temporalmente repetidamente; empiezan las quejas.
Causa raíz: Umbrales de greylist demasiado bajos, o estás poniendo en greylist relays internos y proveedores SaaS que no reintentan en el patrón esperado.
Solución: Incrementa el umbral de greylist, pon en lista blanca remitentes conocidos, o desactiva greylisting hasta modelar el comportamiento de los remitentes.

6) “Rspamd funciona para entrante, pero saliente es rechazado por receptores”

Síntoma: Receptores devuelven bounces citando fallos DMARC/DKIM; tu correo parece no autenticado.
Causa raíz: DKIM no firma, selector DNS ausente, o dominio From no coincide con lo que firmas.
Solución: Publica el registro DKIM en DNS, valida el firmado para el dominio correcto y asegúrate de que SPF/DMARC no se rompan por reescrituras de From en otros filtros.

7) “La UI del controlador es accesible desde Internet”

Síntoma: Un escaneo de seguridad marca el puerto 11334 abierto; recibes cambios raros en la configuración o eventos de aprendizaje extraños.
Causa raíz: El controlador vinculado a 0.0.0.0 sin firewall ni autenticación.
Solución: Vincula el controlador a localhost; exige contraseña; usa reenvío SSH/VPN para acceso. Trátalo como una interfaz administrativa, porque lo es.

Listas de verificación / plan paso a paso

Lista: configuración mínima inicial (host único)

Instalar rspamd y redis-server.
Confirmar que ambos servicios están en ejecución con systemd.
Configurar Redis vía /etc/rspamd/local.d/redis.conf para usar un socket local.
Asegurar que el usuario rspamd puede acceder al socket Redis (membresía de grupo).
Encontrar o habilitar el socket milter de Rspamd.
Configurar Postfix smtpd_milters y non_smtpd_milters para usar ese socket.
Asegurar que Postfix puede acceder al socket milter (permisos, chroot).
Establecer umbrales mínimos de acciones en local.d/actions.conf.
Generar claves DKIM y configurar dkim_signing.conf más los mapas.
Reiniciar Rspamd; validar configuración con rspamd -t.
Recargar Postfix; confirmar en logs que las conexiones al milter tienen éxito.
Escanear un mensaje de ejemplo con rspamc e inspeccionar un mensaje real entregado por cabeceras.

Lista: endurecimiento de producción “listo para enviar” (después de que funcione)

Decidir fallar abierto vs tempfail para caídas del milter (milter_default_action).
Vincular el controlador a localhost y establecer hashes de contraseñas fuertes.
Establecer retención de logs y una alerta simple ante fallos/timeouts repetidos del milter.
Documentar la política de rotación de selectores DKIM (aunque sea “rotar anualmente”).
Definir un flujo de trabajo de entrenamiento ham/spam y quién lo gestiona.
Registrar latencia base: tiempo de tarea Rspamd, latencia Redis, tiempo de consulta DNS.

Tres mini-historias del mundo corporativo

Incidente causado por una suposición equivocada: “Está configurado, así que debe filtrar”

La compañía estaba en migración: correo on-prem antiguo a una nueva pila basada en VM. Instalaron Rspamd, habilitaron Redis, generaron claves DKIM e incluso tenían una captura de pantalla del dashboard en el ticket de cambio. Todos siguieron con otras tareas.

Dos semanas después, el equipo de seguridad escaló: el volumen de phishing había subido y los reportes de usuarios eran consistentemente raros. Los administradores de correo juraban que el nuevo filtro estaba en su lugar. Al fin y al cabo, el servicio estaba corriendo y rspamc funcionaba.

La suposición equivocada fue sutil: pensaron que “Rspamd está en ejecución” implicaba “el correo se está escaneando”. Postfix estaba configurado con smtpd_milters pero no con non_smtpd_milters. La mayoría del correo saliente y buena parte del correo interno era inyectado localmente por una aplicación vía sendmail y nunca pasaba por el daemon SMTP.

Peor aún, tenían milter_default_action=accept. Así que incluso cuando la ruta del socket estaba mal en un host, el correo seguía fluyendo. Fue una degradación gradual hacia un bypass total.

La solución fue aburrida: aplicar el milter a ambas rutas, verificar conexiones exitosas al milter en logs de Postfix y añadir una comprobación diaria de que “messages scanned” aumente con el tráfico. También añadieron un canario basado en cabeceras: un pequeño mensaje interno que siempre debería recibir una cabecera conocida de Rspamd y una alerta si no aparece.

Una optimización que salió mal: “Ahorramos un salto moviendo Redis fuera de caja”

Otra organización tenía un equipo de plataforma fuerte y el reflejo: centralizar estado. Movieron Redis de cada host de correo a un “cluster de caché” compartido porque “es más eficiente”. La red parecía rápida. La latencia parecía bien en pruebas sintéticas.

Luego llegó el lunes. Tráfico en ráfaga más algunos clientes Redis no relacionados causaron picos intermitentes de latencia. No lo bastante grandes para activar alarmas de Redis—solo lo suficiente para que tareas de Rspamd a veces excedieran su presupuesto de tiempo. Las sesiones de Postfix empezaron a acumularse. Los clientes SMTP reintentaron. El volumen aumentó. El sistema entró en la espiral conocida: reintentos crean carga, la carga crea timeouts, los timeouts crean reintentos.

El equipo de correo aumentó los timeouts de Rspamd para “estabilizar”. Eso redujo los bloqueos SMTP pero incrementó colas y presión de memoria. La entregabilidad sufrió porque el correo llegó tarde. Los usuarios culparon al filtro. Técnicamente no estaban equivocados; operativamente era la cadena de dependencias.

La resolución fue volver a poner Redis local para el estado de escaneo de correo (o al menos usar réplicas locales). Centralizar estado estaba bien para algunas aplicaciones; para la canalización de correo, la latencia predecible y baja importaba más que la eficiencia teórica. La optimización ahorró un servidor y compró un mes de dolor intermitente.

La práctica aburrida pero correcta que salvó el día: “Capas de configuración y una única fuente de verdad”

Una empresa del sector financiero tenía el tipo de gobernanza que la gente bromea hasta que paga la renta. Tenían una regla estricta: no editar configs del proveedor. Todos los cambios iban a local.d, y cada archivo se gestionaba mediante un sistema de despliegue con revisión.

Durante una actualización rutinaria del SO, el paquete Rspamd actualizó defaults. En muchas organizaciones, ahí empieza el “¿por qué la puntuación cambió ahora?”. Aquí, la actualización pasó, Rspamd se reinició y el correo siguió fluyendo. Algunos símbolos cambiaron comportamiento, pero acciones clave y firmado DKIM permanecieron estables porque las sobreescrituras locales siguieron intactas.

Luego ocurrió un incidente real: el correo saliente empezó a fallar DKIM para un dominio. Como las configs estaban por capas y registradas, hicieron un diff rápido de los mapas DKIM y encontraron un dominio añadido recientemente con un error tipográfico en la tabla de firmado. Arreglar, reiniciar, listo.

Lo que los salvó no fue una regla Lua ingeniosa. Fue la disciplina poco glamorosa de mantener la política local separada de los defaults empaquetados, más la capacidad de razonar sobre cambios. En sistemas de correo, lo aburrido es una característica.

Preguntas frecuentes

1) ¿Necesito Redis para una configuración “mínima”?

Si quieres una demo de escáner, no. Si quieres un sistema operativo que puedas depurar y mejorar, sí. Redis es donde Rspamd guarda estado útil.

2) ¿Debo usar sockets UNIX o TCP para el milter?

En un host único: sockets UNIX. Menos preguntas de firewall, menos latencia, permisos más claros. Usa TCP cuando realmente necesites separación en red, y entonces trátalo como un proyecto de integración, no como un atajo.

3) ¿Por qué veo “Rspamd está en ejecución” pero mensajes escaneados se quedan en cero?

Porque nadie lo está llamando. Verifica que los milters de Postfix estén configurados, que el socket exista y que Postfix pueda conectar. Usa logs; no te fíes de sensaciones.

4) ¿Cuál es la opción más segura para `milter_default_action`?

accept es la más segura para disponibilidad; tempfail es más segura para postura de seguridad. Elige conscientemente. Si eliges accept, añade monitorización que alerte cuando el milter esté caído.

5) ¿Necesito entrenamiento Bayes desde el día uno?

No. Consigue primero escaneo, acciones y DKIM correctos. Bayes ayuda una vez que tienes clasificación de correo estable y un flujo para alimentar ejemplos buenos/malos.

6) ¿Por qué DKIM está configurado pero los receptores aún muestran “DKIM=fail”?

Lo más frecuente: registro DNS no publicado, selector incorrecto en DNS, firmas para el dominio equivocado, o el mensaje fue modificado después de firmar (algunos filtros aguas abajo reescriben cabeceras). Revisa el orden en la canalización.

7) ¿Puedo ejecutar la UI del controlador en una interfaz pública si pongo contraseña?

Puedes, como puedes guardar copias de seguridad en un USB etiquetado “NO PERDER”. Vincúlalo a localhost y accede por túnel SSH/VPN. Haz el camino seguro el camino fácil.

8) ¿Cuál es el conjunto mínimo de umbrales con el que debería empezar?

Empieza con rechazo conservador (número alto), añadir cabecera en un número moderado y considera tácticas de demora (greylist) solo después de medir el impacto en el negocio. El ejemplo en actions.conf es un buen punto de partida.

9) ¿Cómo sé qué regla causó un rechazo?

Inspecciona los símbolos y la puntuación desde las cabeceras del mensaje o escaneando con rspamc. Todo el sentido del modelo de Rspamd es la explicabilidad—úsala.

10) ¿Debo desplegar Rspamd como proxy SMTP en vez de milter?

No para “mínimo primer uso”. Puede ser excelente, pero añade complejidad de enrutamiento y una mayor superficie de fallo si se configura mal. Estabiliza la canalización milter primero.

Siguientes pasos que deberías hacer realmente

Ahora tienes una configuración mínima que funciona, en la única definición que importa: el correo se escanea, las acciones ocurren, DKIM firma saliente y puedes depurar fallos rápidamente.

Prueba la canalización a diario: crea un correo canario simple y alerta si las cabeceras esperadas de Rspamd no aparecen.
Decide tu postura ante fallos: mantiene accept o pasa a tempfail una vez que rendimiento y dependencias sean fiables.
Publica registros DKIM en DNS y verifica externamente (desde el punto de vista de un receptor) antes de declarar victoria.
Mide latencia bajo carga: latencia Redis, tiempo de consulta DNS y tiempo de tarea Rspamd. Cuando el correo es lento, esos tres te dirán dónde mirar.
Solo entonces afina puntuaciones: ajusta umbrales basándote en falsos positivos/negativos reales, no en anécdotas de la bandeja ejecutiva.

Si quieres que el sistema siga funcionando, trátalo como parte del transporte de correo, no como un accesorio. Los filtros no fallan de forma elegante; fallan silenciosamente. Tu trabajo es hacer el silencio imposible.