Rspamd: Ajustes antispam que bloquean ataques sin bloquear a las personas

El modelo mental de producción: Rspamd es un motor de políticas, no una caja mágica

Si enfocas Rspamd como un único número de «puntuación de spam» que ajustas hasta que deje de sonar el pager, estarás ocupado para siempre. Si lo
ves como un motor de políticas—un clasificador con opinión, módulos, reputación y mecanismos de ejecución—obtendrás resultados previsibles.

En producción no optimizas por «máximo spam capturado». Optimizarás por: (1) mínimos falsos positivos, (2) uso de recursos acotado bajo ataque,
y (3) reversibilidad rápida cuando tus suposiciones se desmoronen.

El truco es construir una canalización de decisión en capas:

• Autenticar (SPF/DKIM/DMARC) y decidir qué significan las fallas para tus dominios frente al resto del mundo.
• Clasificar contenido (símbolos, reglas, Bayesiano donde convenga) sin dejar que se convierta en un festival de CPU sin límite.
• Aplicar política (ratelimits, greylisting, reputación de URLs, controles de adjuntos) basándose en patrones de abuso observados.
• Entregar con seguridad (reescribir asunto, añadir cabeceras, cuarentena) para que las personas puedan recuperar mensajes cuando el clasificador se equivoque.

Aquí está lo que muchos equipos pasan por alto: el sistema de correo es un entorno adversarial. Los atacantes se adaptan. Tu afinamiento debe ser resistente, no perfecto.
«Perfecto» es lo que dices justo antes de desplegar algo que bloquea la nómina.

Idea parafraseada de Werner Vogels: Todo falla; diseña para ello, detecta rápido y recupérate sin heroísmos.

Hechos e historia interesantes que importan en la práctica

Algunos puntos de contexto que realmente afectan cómo ejecutas Rspamd día a día. No son trivialidades: son cosas que cambian las decisiones.

1. La autenticación de correo es joven comparada con SMTP. SMTP data de principios de los 80; SPF, DKIM y DMARC llegaron décadas después, y gran parte del mundo aún está poniéndose al día.
2. Rspamd se construyó alrededor de un sistema modular de símbolos. No «obtienes una puntuación»; obtienes una bolsa de símbolos con pesos, y por eso el ajuste es manejable.
3. Redis se convirtió en el backend de estado común para filtrado moderno. Reputación, ratelimits, hashes fuzzy y estado Bayesiano necesitan memoria compartida rápida; Redis es la elección pragmática en muchas implantaciones.
4. El greylisting funciona porque los spammers optimizan por rendimiento. Los MTAs legítimos reintentan; los bots baratos a menudo no lo hacen. Ya no es tan mágico como antes, pero sigue siendo útil cuando se afina.
5. DMARC cambió el contrato social. Permite a los propietarios de dominios publicar intención de «reject/quarantine», lo que finalmente autoriza a los receptores a ser estrictos con ciertos dominios.
6. El “spam” evolucionó hacia el robo de credenciales. El ROI pasó de vender píldoras a robar accesos. Eso cambia qué señales importan: suplantación de marca, reputación de URLs y trucos con el display-name.
7. Las oleadas de correo suelen ser una cortina de humo. Los atacantes bombardean una bandeja mientras intentan restablecimientos de contraseña o transacciones fraudulentas en otro lugar.
8. El spam moderno usa infraestructura legítima. Cuentas SaaS comprometidas y plataformas de marketing envían correo que «pasa la autenticación», obligándote a apoyarte en controles de contenido y comportamiento.

Broma #1: El correo es el único protocolo donde «probablemente está bien» tradicionalmente se valida esperando tres días y viendo quién se queja.

Cómo Rspamd toma decisiones (y dónde vive realmente el ajuste)

Rspamd evalúa mensajes y produce:

• Símbolos: detecciones nombradas como R_SPF_FAIL o DKIM_VALID.
• Puntuaciones: pesos aplicados a símbolos, combinados en una puntuación de acción global.
• Acciones: qué hacer en umbrales (sin acción, añadir cabecera, greylist, reescribir asunto, rechazar).

Las acciones son la política. Las puntuaciones son solo el cableado.

La mayor parte del dolor en producción viene de confundir «ajuste de puntuación» con «ajuste de política». El enfoque estable:

• Mantén las acciones conservadoras: no rechaces agresivamente hasta haber demostrado bajos falsos positivos.
• Usa cuarentena o reescribir asunto como pasos intermedios mientras aprendes tu flujo de correo.
• Favorece ratelimits y greylisting para oleadas, porque controlan el uso de recursos incluso cuando la clasificación es ruidosa.

Los módulos que realmente deberías cuidar

Un «conjunto central» pragmático para muchos entornos:

• SPF/DKIM/DMARC (señales de autenticación, política de dominio)
• ARC (cadenas de reenvío; evita penalizar listas/forward legítimos)
• RBL / SURBL (reputación IP/dominio; ten cuidado con listas agresivas)
• Reputación (basada en historial, usualmente respaldada por Redis)
• Ratelimit (control de oleadas)
• Multimap (tu lógica allow/deny personalizada a escala)
• Fuzzy (similitud basada en hashes; bueno para campañas repetidas)
• Bayes (útil pero fácil de envenenar y de malinterpretar)

Dónde poner la lógica personalizada

Si sigues añadiendo scripts Lua porque «necesitábamos una regla más», acabarás con un filtro de correo a medida escrito por tres exempleados.
Prefiere:

• multimap para la mayoría de política personalizada (dominios, remitentes, tipos MIME, patrones de asunto)
• local.d/ overrides en lugar de editar la configuración estándar
• Lua pequeño y comprobable solo cuando multimap no pueda expresar la lógica

Estrategia de puntuación: deja de perseguir “la puntuación perfecta”

El sistema de puntuación es una máquina para expresar compensaciones. Tu trabajo es hacer explícitas esas compensaciones.

Comienza con las acciones, luego ajusta pesos

Una línea base común:

• añadir cabecera en una puntuación relativamente baja (informar a downstream, habilitar búsquedas)
• reescribir asunto un poco más alto (hace que los usuarios finales noten)
• greylist usado con moderación (especialmente para entrada desde remitentes desconocidos)
• rechazar solo cuando estés seguro (o cuando un ataque te obligue)

Acepta las “fallas suaves” para señales de autenticación

SPF y DKIM son valiosos, pero el mundo real es desordenado: reenvíos, DNS rotos, remitentes mal configurados.
Usa las fallas como señales que se combinan con otras, no como disparadores únicos de rechazo—a excepción de dominios con políticas DMARC fuertes.

Construye políticas separadas para “tus dominios” vs “internet”

Saliente y entrante son deportes diferentes.

• Para entrante, te importan phishing, suplantación y oleadas.
• Para saliente, te importan compromisos de cuentas y preservación de reputación.

Tus propios dominios pueden exigirse estándares más estrictos: aplica firma DKIM, exige alineación de From, aplica controles de tasa. Si tus propios sistemas no pueden cumplir,
eso no es culpa de Rspamd. Es un problema de gobernanza con disfraz técnico.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas de grado producción «haz esto ahora». Cada una tiene: un comando, qué significa la salida y la decisión que tomarás a partir de ella.
Supuestos: Rspamd instalado, Linux con systemd, Redis disponible y Postfix u otro MTA integrado.

Task 1: Confirmar que Rspamd está realmente sano (no solo en ejecución)

cr0x@server:~$ systemctl status rspamd --no-pager
● rspamd.service - Rspamd daemon
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2026-02-04 08:10:21 UTC; 2h 12min ago
   Main PID: 1423 (rspamd)
      Tasks: 32 (limit: 18958)
     Memory: 410.2M
        CPU: 8min 33.120s
     CGroup: /system.slice/rspamd.service
             ├─1423 rspamd: main process
             ├─1431 rspamd: proxy process (localhost:11332)
             ├─1432 rspamd: controller process (localhost:11334)
             └─1440 rspamd: worker process (normal)

Significado: «Active» es lo mínimo. Memoria/CPU te da una pista temprana sobre fugas, explosiones de reglas o condiciones de avalancha.
Múltiples procesos son normales; revisa el recuento de workers y su crecimiento.

Decisión: Si la memoria sube sin control o la CPU está al tope, omite ajustar pesos y ve al playbook de diagnóstico rápido.

Task 2: Comprobar la sanidad de la configuración de Rspamd antes de cambiar nada

cr0x@server:~$ rspamadm configtest
syntax OK
modules OK

Significado: Syntax OK significa que Rspamd puede cargar la config. «Modules OK» indica que los módulos se inicializan sin errores.

Decisión: Si esto falla, no recargues y «veamos qué pasa». Arregla el error de configuración primero; las colas de correo son excelentes bombas de tiempo.

Task 3: Verificar el acceso al controlador y ver distribuciones de símbolos en vivo

cr0x@server:~$ rspamc stat
Uptime: 7964 seconds
Messages scanned: 184295
Messages learned: 312
Messages with action reject: 3911, 2.12%
Messages with action add header: 22144, 12.01%
Messages with action rewrite subject: 8021, 4.35%
Messages with action no action: 150219, 81.52%
Scanned messages per second: 23.15
Actions histogram:
no action: 150219
add header: 22144
rewrite subject: 8021
reject: 3911

Significado: Esto es tu gráfico de control. Picos repentinos en «reject» o «rewrite subject» suelen correlacionar con una campaña entrante o un remitente roto.

Decisión: Si la tasa de rejects sube de golpe, investiga símbolos y orígenes antes de ajustar umbrales. No «arregles» una campaña bajando estándares permanentemente.

Task 4: Inspeccionar los símbolos principales para encontrar qué está impulsando las acciones

cr0x@server:~$ rspamc counters
Symbol: R_SPF_FAIL: 12401
Symbol: DKIM_SIGNED: 98234
Symbol: DMARC_POLICY_REJECT: 821
Symbol: RBL_DBL_SPAM: 6402
Symbol: URL_COUNT_5: 4901
Symbol: MIME_HTML_ONLY: 17322
Symbol: BAYES_SPAM: 2501
Symbol: BAYES_HAM: 1811

Significado: Los contadores muestran la frecuencia de símbolos. Símbolos de alta frecuencia no son siempre malos; te dicen cómo es el entorno.

Decisión: Si un solo símbolo está causando la mayoría de los rejects, valídalo contra muestras reales de correo. Arregla la regla o el peso, no toda la política.

Task 5: Extraer el resultado de escaneo de un mensaje específico (cabeceras o EML)

cr0x@server:~$ rspamc -h localhost:11334 -P 'controllerpass' symbols < /var/spool/mail/samples/suspect.eml
{"is_spam":true,"score":18.50,"required_score":15.00,"action":"reject","symbols":{"R_SPF_FAIL":{"score":2.00},"DMARC_POLICY_REJECT":{"score":4.00},"RBL_DBL_SPAM":{"score":5.00},"MIME_HTML_ONLY":{"score":1.00},"PHISHING":{"score":6.00}}}

Significado: Esto es el «por qué». No basta saber que el mensaje fue rechazado; necesitas ver qué símbolos lo empujaron por encima.

Decisión: Si DMARC policy reject se dispara para un dominio que debería estar permitido (reenvíos, listas), investiga ARC y la cadena de autenticación, no solo los pesos.

Task 6: Validar la salud y latencia de Redis (Rspamd depende de él más de lo que crees)

cr0x@server:~$ redis-cli -h 127.0.0.1 -p 6379 INFO stats | egrep 'instantaneous_ops_per_sec|keyspace_hits|keyspace_misses'
instantaneous_ops_per_sec:1240
keyspace_hits:9319921
keyspace_misses:42112

Significado: Ops/sec muestra la carga. Hits vs misses muestra la efectividad de la caché. Muchos misses pueden significar caché fría o churn.

Decisión: Si ops/sec se dispara durante oleadas, asegúrate de que Redis no esté saturando un solo hilo, y considera aislarlo o escalar los workers de Rspamd en consecuencia.

Task 7: Verificar la memoria de Redis y la política de expulsión (para evitar “olvidar” reputaciones)

cr0x@server:~$ redis-cli INFO memory | egrep 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
used_memory_human:2.13G
maxmemory_human:3.00G
mem_fragmentation_ratio:1.12

Significado: Si estableciste un maxmemory y Redis comienza a expulsar, tu estado de reputación y ratelimit se vuelve poco fiable. La fragmentación insinúa el comportamiento del asignador.

Decisión: Si la memoria está justa, aumenta maxmemory o reduce lo que almacenas (módulos, retención). «Dejar que expulse» es una decisión de política, no una opción por defecto.

Task 8: Ver si Rspamd está limitado por CPU (reglas demasiado pesadas, demasiados workers, o pocos)

cr0x@server:~$ pidstat -p $(pidof rspamd | tr ' ' ',') 1 3
Linux 6.1.0 (server)  02/04/2026  _x86_64_  (8 CPU)

12:40:11 PM   PID  %usr %system  %CPU  Command
12:40:12 PM  1423  1.00    0.00  1.00  rspamd
12:40:12 PM  1440 92.00    2.00 94.00  rspamd
12:40:12 PM  1441 88.00    1.00 89.00  rspamd

Significado: Workers al 100% son normales bajo carga, pero un pegado sostenido con colas crecientes significa cuello de botella.

Decisión: Si la CPU está saturada, reduce comprobaciones costosas (profundidad de extracción de URLs, regex pesados, demasiadas consultas DNS) o añade capacidad. No «arregles» la CPU bajando umbrales de rechazo.

Task 9: Medir la salud de resolución DNS (muchos módulos dependen de DNS)

cr0x@server:~$ resolvectl statistics
Transactions: 219381
Cache Hits: 171224
Cache Misses: 48157
DNSSEC Verdicts Secure: 0
DNSSEC Verdicts Insecure: 0
DNSSEC Verdicts Bogus: 0

Significado: Muchos misses pueden significar caché pobre o TTLs agresivos. En filtrado de correo, DNS suele ser el impuesto oculto de latencia.

Decisión: Si los misses son altos y la latencia es visible, pon un resolvedor de caché local en el mismo host o LAN y asegura que Rspamd lo use.

Task 10: Probar una ruta de lookup RBL/SURBL (y detectar timeouts)

cr0x@server:~$ dig +time=1 +tries=1 2.0.0.127.zen.spamhaus.org A +short
127.0.0.2

Significado: Una respuesta rápida significa que tu ruta DNS funciona y la lista es alcanzable. Los timeouts aquí se convierten en retrasos por mensaje.

Decisión: Si las consultas expiran, arregla el egress DNS, cambia de resolvedor o desactiva la lista. Los timeouts bajo carga son la forma de auto‑DDoS de tu gateway de correo.

Task 11: Confirmar que Postfix realmente entrega correo a Rspamd (sanidad de integración)

cr0x@server:~$ postconf -n | egrep 'smtpd_milters|non_smtpd_milters|milter_protocol|milter_default_action'
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332
milter_protocol = 6
milter_default_action = accept

Significado: Si los milters no están configurados, estás afinando un filtro que nunca ve tráfico. milter_default_action «accept» es una elección de seguridad durante fallos.

Decisión: Mantén milter_default_action=accept a menos que disfrutes explicando por qué el sistema de correo falló cerrado en el peor momento posible.

Task 12: Vigilar el throughput en vivo y la presión de colas (la verificación “¿esto es un ataque?”)

cr0x@server:~$ mailq | tail -n +1 | head -n 12
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     2480 Tue Feb  4 12:38:02  sender@example.net
                                         recipient@yourdomain.com

F6G7H8I9J0     3121 Tue Feb  4 12:38:02  sender2@random.tld
                                         recipient@yourdomain.com

-- 2814 Kbytes in 742 Requests.

Significado: Una cola creciente indica lentitud downstream: Rspamd, DNS, comprobaciones de contenido o problemas de entrega.

Decisión: Si la cola crece durante una oleada de spam, habilita o ajusta ratelimits/greylisting en lugar de solo ajustar puntuaciones de contenido.

Task 13: Inspeccionar los logs de Rspamd por timeouts y fallos de módulos

cr0x@server:~$ journalctl -u rspamd --since "30 min ago" | egrep -i 'timeout|slow|error|redis' | tail -n 12
Feb 04 12:22:11 server rspamd[1440]: <0c1d3a>; lua; lua_rsa.lua:142: slow hash computation: 215ms
Feb 04 12:22:18 server rspamd[1441]: ; rbl; rbl.c:512: timeout while resolving zen.spamhaus.org for 203.0.113.44
Feb 04 12:23:04 server rspamd[1440]: ; redis; redis_pool.c:98: cannot connect to redis: Connection refused

Significado: Estos mensajes señalan qué módulos están causando latencia o fallos. Timeouts en RBL = DNS o egress. Problemas de conexión a Redis = módulos de estado fallando abierto/cerrado.

Decisión: Arregla la dependencia (DNS/Redis) antes de afinar reglas. Si no, estarás afinando con sensores rotos.

Task 14: Recargar Rspamd con seguridad después de cambios de configuración

cr0x@server:~$ rspamadm configtest && systemctl reload rspamd && systemctl is-active rspamd
syntax OK
modules OK
active

Significado: Reload mantiene el uptime del proceso mientras aplicas cambios; «active» confirma que no entró en crash-loop.

Decisión: Siempre ejecuta configtest antes de reload. No quieres aprender reglas de sintaxis mediante una caída del servicio de correo.

Playbook de diagnóstico rápido

Cuando la entrega de correo se vuelve lenta, los rechazos aumentan, o los usuarios empiezan a reenviar capturas con círculos rojos: haz esto en orden.
El objetivo es encontrar el cuello de botella en minutos, no realizar una antropología completa de tu cultura de spam.

Primero: ¿es throughput, latencia o política?

• Problema de throughput: colas crecientes, tasa de escaneo bajando, CPU al tope.
• Problema de latencia: retrasos por mensaje, timeouts en logs, bloqueos DNS.
• Problema de política: falsos positivos/negativos repentinos, cambios en la distribución de acciones.

Segundo: revisa los tres sospechosos de siempre

1. DNS:
   • Busca timeouts de RBL/SURBL en los logs.
   • Revisa estadísticas del resolvedor caché.
   • Prueba consultas representativas con dig usando timeout bajo.
2. Redis:
   • ¿Está Redis arriba? ¿Está intercambiando a disco? ¿Está expulsando?
   • Revisa picos de latencia y errores de conexión.
3. Presión de CPU/memoria:
   • ¿Los workers de Rspamd están pegados? ¿Pasan tiempo en un módulo pesado?
   • ¿La máquina está thrashing por memoria o I/O de disco (especialmente si Redis persiste)?

Tercero: mira el histograma de acciones y los símbolos principales

Si «reject» o «rewrite subject» explotan, no edites pesos de inmediato.
Extrae 10 muestras (mezcla de rechazados y borderline) y compara conjuntos de símbolos. Buscas uno de estos:

• Una única fuente de reputación mala (RBL devolviendo falsos positivos, envenenamiento DNS, listas de bloqueo demasiado agresivas)
• Cambios en la cadena de autenticación (reenvíos, nueva plataforma de marketing, rotación de claves DKIM rota)
• Un nuevo patrón de campaña (nuevas URLs, nuevo tipo de adjunto, nuevos trucos en el asunto)

Cuarto: elige la palanca correcta

• Oleada de ataque: ratelimit + greylisting + controles de conexión.
• Phish dirigido: multimap/reglas de URL + manejo estricto de DMARC para marcas protegidas + heurísticas de asunto/display-name.
• Falsos positivos: cuarentena + allowlists estrechas + arreglar el peso del módulo específico.
• Colapso de rendimiento: reducir módulos DNS lentos, añadir caché, aislar Redis, escalar workers.

Tres micro-historias corporativas desde la trinchera

1) El incidente causado por una suposición errónea: “DKIM válido significa seguro”

Una empresa mediana pasó a un gateway de correo entrante único con Rspamd. Acababan de terminar un proyecto de «entregabilidad» de meses,
así que la autenticación era la estrella: SPF alineado, DKIM firmado, DMARC aplicado en sus propios dominios.
Asumieron que el correo entrante con DKIM_VALID era mayormente legítimo porque «los spammers no pueden hacer DKIM».

Luego llegó la oleada de phishing. No era suplantación. Fue enviado desde cuentas comprometidas en una plataforma SaaS legítima que firma DKIM correctamente.
El correo pasó SPF y DKIM, y DMARC estaba alineado porque el atacante usó un dominio parecido con autenticación válida.
El contenido era mínimo, la URL recién registrada y la carga vivía detrás de una cadena de redirecciones que no aparecía en comprobaciones básicas.

La primera respuesta del equipo fue subir los pesos de los símbolos de contenido. Eso ayudó un poco y perjudicó mucho: de repente respuestas “de una línea” y notificaciones de RRHH
tuvieron asuntos reescritos, porque muchos correos mínimos parecen sospechosos en el vacío.

La solución fue menos emocionante y más efectiva: dejaron de tratar DKIM como una señal de confianza y comenzaron a tratarla como una señal de identidad.
Construyeron reglas multimap para marcas protegidas y flujos internos, añadieron comprobaciones de reputación de URL que resolvían redirecciones de forma segura,
e introdujeron un flujo de trabajo de cuarentena para mensajes «que pasan autenticación pero son sospechosos». DKIM siguió importando, pero no votaba dos veces.

Después de eso, el sistema atrapó la próxima oleada sin romper el correo normal. El equipo también aprendió una lección útil:
pasar autenticación es cada vez más común para correo malicioso, porque los actores maliciosos aprovechan infraestructura buena.

2) La optimización que salió mal: “Habilitamos todas las RBL”

Otra organización tenía un problema de spam y un problema de compras. No querían pagar nada nuevo, y el equipo
encontró una larga lista de listas DNS. Alguien propuso: «Habilitarlas todas. Más listas, más protección».
Suena razonable hasta que recuerdas cómo funciona DNS bajo carga.

Habilitaron un conjunto de proveedores RBL/SURBL con timeouts agresivos y muy poca caché. Durante el primer día, parecía increíble.
Los rejects subieron, las quejas por spam bajaron y el equipo disfrutó esa rara sensación de tener razón.

Al segundo día llegó una oleada. Las consultas DNS se dispararon, los timeouts empezaron y los workers de Rspamd pasaron su tiempo esperando respuestas que nunca llegaron.
Las colas de Postfix crecieron. El correo legítimo se retrasó minutos. Entonces alguien «lo arregló» aumentando el número de workers de Rspamd, lo que solo multiplicó la presión sobre DNS.
El sistema ya no filtraba spam; estaba haciendo DDoS a su propio resolvedor.

La recuperación fue simple pero no glamurosa: redujeron las RBL a un conjunto pequeño con señal probada,
pusieron un resolvedor de caché local por delante y establecieron timeouts sensatos por módulo para que las fallas degradaran de forma elegante.
También mantuvieron métricas de latencia DNS. Es difícil discutir con un gráfico que grita.

3) La práctica aburrida pero correcta que salvó el día: “Cuarentena y revisión, siempre”

Una firma regulada manejaba correo legal, financiero y aquel tipo de correo de RRHH que se convierte en evidencia si se maneja mal.
Querían rechazo agresivo de spam. El equipo de correo se negó. Implementaron una política de cuarentena en su lugar:
la mayoría del spam de “alta confianza” era rechazado, pero cualquier cosa en una zona gris quedaba en cuarentena por un periodo definido.

La cuarentena no era una carpeta de basura en un buzón de usuario. Era un control operativo:
searchable, auditable, con acceso basado en roles y un flujo de trabajo de incidentes. Cada falso positivo tenía una vía de recuperación.
Cada evento de liberación registraba quién lo hizo y por qué.

Una tarde un socio rotó claves DKIM incorrectamente y empezó a fallar alineación. Su correo parecía suplantación y parte aterrizó en cuarentena.
El impacto de negocio fue real pero contenido: mensajes retrasados, no destruidos.

Porque el equipo tenía la práctica aburrida en su lugar, el incidente fue un ejercicio operativo de 30 minutos, no una tormenta de culpas de varios días.
Ajustaron una excepción temporal con alcance restringido, dijeron al socio qué falló y retiraron la excepción una vez que el socio arregló el DNS.
No pasó nada «ingenioso». Por eso funcionó.

Ajustes para ataques modernos: oleadas, phishing y “suplantación empresarial”

Oleadas de spam y mail-bombs: gana acotando el uso de recursos

Durante una oleada, la clasificación de contenido es menos fiable porque los atacantes pulverizan variaciones. La mejor jugada es controlar el radio de impacto:
limita tasas por IP/remitente, ralentiza desconocidos y protege tu MTA y buzones downstream.

Usa el módulo ratelimit de Rspamd y considera greylisting selectivo:

• Ratelimit basado en patrones de IP o ASN cuando una campaña se concentra.
• Ratelimit basado en destinatario durante mail‑bombs (un buzón recibiendo palizas).
• Greylist remitentes desconocidos que fallen comprobaciones básicas de higiene (sin rDNS válido, sin autenticación, HELO sospechoso), pero evita greylistar proveedores mayores que ya tienen buena reputación.

Phishing de credenciales: trata las URLs como la carga maliciosa

La mayoría de correos de phishing son sistemas de entrega de URLs, no de adjuntos. Tu afinamiento debe reflejar eso:

• Extrae URLs de forma fiable (pero no dejes que la extracción sea un infierno de CPU).
• Comprueba reputación de URLs y dominios recién registrados.
• Detecta dominios parecidos y señuelos de marca en display names.
• Ten cuidado con cadenas de redirección; los atacantes se esconden detrás de dominios de tracking “legítimos”.

Impersonación y ataques tipo BEC: la autenticación no es suficiente

El comprometedimiento empresarial a menudo usa:

• Suplantación del display name (“Nombre CEO” desde un dominio aleatorio)
• Manipulación de Reply‑To (From se ve bien; Reply‑To va a otro lado)
• Secuestro de hilos (reusar asuntos como “Invoice” y “Re: Payment”)

Rspamd puede ayudar con reglas personalizadas (multimap/Lua), pero el control real es la política:
enruta patrones sospechosos de “impersonación” a cuarentena o añade una cabecera ruidosa para clientes que muestren banners.

Broma #2: Lo único más persistente que el spam es la invitación a reunión «Quick Sync» que sigue resurgiendo como un evento maldito del calendario.

Mantener humanos desbloqueados: controlar falsos positivos como un adulto

Los falsos positivos no son solo «molestos». Son deuda operacional. La gente busca soluciones alternativas usando cuentas personales y apps de chat,
y de repente tu historia de gobierno de datos se convierte en danza interpretativa.

Diseña la “vía de recuperación” antes de endurecer la política

• Cuarentena para correo borderline, con un flujo de revisión definido.
• Reescribir asunto para spam de confianza media, para que los usuarios puedan autofiltrar sin perder el correo.
• Añadir cabeceras para baja confianza. Deja que sistemas downstream decidan (SIEM, reglas de buzón, clientes).

Prefiere allowlists estrechas sobre las amplias

«Permitir el dominio del remitente» suele ser demasiado amplio. Prefiere:

• Allowlist una combinación específica de envelope sender + dominio DKIM
• Allowlist un rango IP específico que controlas
• Allowlist el dominio de envío dedicado de un proveedor conocido (no todo su dominio corporativo)

Sé estricto donde es seguro: tus propios dominios y marcas de alto riesgo

Para correo que reclama ser de tus propios dominios, la estricticidad es innegociable:
From desalineado debe castigarse. Así detienes la suplantación e intentos de impersonación interna.

Para «marcas protegidas» (bancos, proveedores de nómina, proveedores de identidad), la estricticidad también está justificada:
son dominios que los atacantes usan porque los usuarios confían en ellos.

Bayes: úsalo, pero no lo dejes conducir el autobús

El filtrado Bayesiano puede ayudar, especialmente en entornos de correo estables. También puede:

• Ser envenenado por campañas dirigidas
• Sobreajustarse al argot interno
• Crear acoplamientos invisibles entre «comportamiento de entrenamiento» y resultados de correo

Si usas Bayes, trata el entrenamiento como un proceso operativo, no como un hobby. Limita quién puede entrenar, registra eventos de entrenamiento y evalúa periódicamente la precisión.

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

1) Síntoma: pico repentino en rechazo de correo legítimo

Causa raíz: Una fuente de reputación se volvió “caliente” (RBL/SURBL con falsos positivos) o DNS empezó a expirar y fallar de forma sesgada.

Solución: Identifica el símbolo que impulsa los rejects vía rspamc symbols en muestras. Reduce el peso o desactiva esa lista, añade caché DNS, fija timeouts y verifica con pruebas en vivo.

2) Síntoma: colas creciendo, CPU de Rspamd pegada, tasa de escaneo baja

Causa raíz: Demasiadas comprobaciones costosas (RBLs, extracción de URLs, regex) + caché insuficiente; o una oleada empujando el sistema al peor caso.

Solución: Ajusta ratelimits/greylisting, reduce módulos lentos, asegura un resolvedor caché local y escala horizontalmente si es necesario. Mide antes/después.

3) Síntoma: “El spam pasa” aun con puntuaciones altas configuradas

Causa raíz: Rspamd no está realmente en la ruta del correo (milter mal configurado) o está fallando abierto por problemas de dependencias (Redis caído, timeouts).

Solución: Verifica milters del MTA, revisa logs de Rspamd, valida conectividad Redis. No ajustes puntuaciones hasta confirmar que los mensajes se escanean.

4) Síntoma: correo reenviado es rechazado por DMARC

Causa raíz: Reenviar rompe SPF y puede romper DKIM; falla la alineación DMARC y aplicas política demasiado estricta sin manejar ARC.

Solución: Habilita y valida el procesamiento ARC, crea excepciones dirigidas para reenviadores conocidos y usa cuarentena en lugar de rechazo para flujos reenviados ambiguos.

5) Síntoma: correo masivo legítimo (facturas, notificaciones) cae como spam

Causa raíz: Mala configuración del proveedor: faltan cabeceras List-Unsubscribe, mala alineación DKIM, reputación compartida de IP o contenido plantilla de marketing que dispara reglas.

Solución: Construye reglas allow estrechas (dominios/IPs específicos), exige alineación DKIM de proveedores y ajusta pesos solo para los patrones de símbolo observados.

6) Síntoma: fallos intermitentes, “cannot connect to redis”

Causa raíz: Redis en el mismo host compite por memoria/CPU, alcanza maxclients o es reiniciado por el OOM killer.

Solución: Asigna recursos adecuadamente, fija maxmemory con política de expulsión deliberada, monitoriza y considera aislar Redis en infraestructura dedicada.

7) Síntoma: “Todo está greylisted,” usuarios se quejan por demoras

Causa raíz: Greylisting aplicado demasiado amplio (incluye grandes proveedores), o falta whitelist para remitentes buenos conocidos.

Solución: Restringe greylisting a fuentes desconocidas/baja reputación, whitelist MTAs mayores donde corresponda y usa ratelimit para oleadas en lugar de greylist masivo.

8) Síntoma: falsos positivos ligados a un departamento interno

Causa raíz: Sistemas internos enviando correo HTML generado por máquinas o estructuras MIME raras que parecen spam.

Solución: Arregla el remitente para producir MIME sensato, añade DKIM adecuado y solo entonces añade una regla allow estrecha si es necesario.

Listas de verificación / plan paso a paso

Paso a paso: endurecer Rspamd sin detonar la confianza de los usuarios

1. Observabilidad base: histograma de acciones, tasa de escaneo, profundidad de colas, latencia DNS, salud de Redis.
2. Establecer acciones conservadoras: añadir cabecera > reescribir asunto > cuarentena/greylist > rechazar.
3. Validar cadena de autenticación: resultados SPF/DKIM/DMARC/ARC en tráfico representativo (no solo un remitente feliz).
4. Controlar oleadas: habilitar ratelimits; decidir un plan de protección de destinatarios para mail‑bombs.
5. Elegir fuentes de reputación intencionalmente: pocas listas de alta calidad, con timeouts estrictos y caché.
6. Construir política multimap: marcas protegidas, proveedores conocidos, sistemas internos y rutas «nunca rechazar» dirigidas a cuarentena.
7. Definir flujo de excepciones: quién puede allowlist, cuánto duran las excepciones, cómo auditas y las eliminas.
8. Ejecutar un simulacro de falso positivo: simula una falla de DKIM de un socio; confirma que puedes recuperar correo de la cuarentena rápidamente.
9. Prueba de estrés: reproduce oleadas de spam de muestra; verifica tasa de escaneo y comportamiento de colas bajo carga.
10. Itera semanalmente: cambios pequeños, impacto medido, capacidad de revertir.

Lista de verificación: antes de aumentar agresividad de rechazo

• Existe cuarentena y es buscable con un SLA definido para revisión.
• Se entienden los símbolos principales de rechazo con ejemplos reales.
• Hay caché DNS en su lugar y timeouts de RBL controlados.
• Redis tiene margen y no hay sorpresas de expulsión.
• Se evaluaron rutas de reenvío (ARC donde es necesario).
• Existe un runbook on‑call para “socio rompió DKIM” y “ataque mail‑bomb”.

Lista de verificación: durante un ataque activo

• Confirma que es un ataque: crecimiento de colas + cambios en histograma de acciones + concentración de orígenes.
• Habilita/ajusta ratelimits para orígenes o destinatarios atacantes.
• Considera greylisting temporal para orígenes desconocidos.
• Reduce comprobaciones lentas que amplifican latencia (RBLs extra, extracción de URLs pesada) hasta estabilizar.
• Pon en cuarentena correo sospechoso que pasa autenticación en lugar de rechazar si hay duda.
• Post‑incidente: anula controles amplios temporales y convierte lo aprendido en reglas dirigidas.

Preguntas frecuentes

1) ¿Debería rechazar spam en tiempo SMTP o ponerlo en cuarentena?

Rechaza en tiempo SMTP para casos de alta confianza (malware/phis claro, fallas DMARC con reject para dominios protegidos, IPs conocidas malas).
Usa cuarentena para casos ambiguos. Si no puedes recuperar correo con fiabilidad, no estás listo para rechazar agresivamente.

2) ¿Cuál es la forma más rápida de reducir falsos positivos?

No «bajes todas las puntuaciones». Identifica el/los símbolos principales que impulsan falsos positivos escaneando muestras y revisando contadores. Arregla ese módulo de peso o regla,
y añade una excepción estrecha para el comportamiento específico del remitente si hace falta.

3) ¿Sigue siendo útil el greylisting?

Sí, pero solo cuando es selectivo. El greylisting por defecto castiga a proveedores legítimos de correo masivo y crea retrasos visibles para usuarios.
Úsalo como válvula de presión para orígenes desconocidos o durante oleadas, no como tu filtro principal.

4) ¿Cuántas listas RBL/SURBL debería habilitar?

Menos de lo que piensas. Elige un número pequeño de listas de alta señal, aplica timeouts estrictos y asegúrate de tener caché DNS sólida.
Más listas pueden reducir spam—hasta que reduzcan tu throughput.

5) ¿Por qué pasa spam que cumple SPF/DKIM/DMARC ahora?

Porque los atacantes usan cuentas comprometidas y remitentes legítimos, o registran dominios parecidos y configuran autenticación correctamente.
La autenticación prueba identidad del dominio emisor, no la intención del mensaje.

6) ¿Dónde debo guardar personalizaciones locales?

En local.d/ overrides y definiciones multimap. Evita editar configs estándar directamente; complica upgrades y hace la deriva invisible.

7) ¿Cómo afino Rspamd bajo alta carga sin empeorarlo?

Trata la latencia de dependencias como el enemigo: DNS y Redis primero. Usa ratelimit/greylisting para acotar trabajo.
Desactiva o relaja comprobaciones lentas temporalmente. No añadas más workers a menos que entiendas el cuello de botella compartido.

8) ¿Necesito filtrado Bayesiano?

No siempre. En entornos de correo entrante diversos, Bayes puede ser ruidoso y costoso operativamente.
Si lo usas, restringe el entrenamiento, monitoriza la precisión y asegúrate de que no anule otras señales.

9) ¿Cómo manejo correo reenviado y listas sin caer en phishing?

Habilita evaluación ARC donde corresponda, pone en cuarentena fallas ambiguas y escribe política explícita para reenviadores y listas conocidas.
No ignores DMARC de forma general. Así vuelve la suplantación.

Conclusión: pasos siguientes que puedes hacer esta semana

Rspamd te permitirá construir una catedral complicada de puntuaciones. No lo hagas. Construye una máquina de políticas que degrade con gracia,
sea observable y tenga una vía de recuperación para humanos.

1. Ejecuta rspamc stat y rspamc counters; haz capturas de pantalla de las tasas base de acciones y símbolos principales.
2. Valida dependencias DNS y Redis; arregla timeouts y caché antes de tocar pesos.
3. Implementa (o ajusta) ratelimits para mail‑bombs por destinatario y oleadas obvias por origen.
4. Configura cuarentena para casos borderline; define quién la revisa y con qué rapidez.
5. Crea una política multimap para marcas protegidas y flujos internos críticos.
6. Realiza un cambio de ajuste controlado, mide el impacto por una semana y ten un plan para revertir.

Si haces esas seis cosas, bloquearás más ataques y bloquearás a menos personas—que es la única métrica que importa cuando el negocio está despierto.