Falsos positivos en Rspamd: afina la puntuación antispam sin dejar pasar basura

El modelo mental: acciones, símbolos y por qué ocurren los falsos positivos

Rspamd no “decide spam”. Suma señales. Cada señal es un símbolo con una puntuación. La puntuación total se mapea a una acción: no acción, add_header, greylist, rewrite subject, reject o quarantine (según tu política).

Los falsos positivos suelen venir de cuatro lugares:

1. Suposiciones erróneas sobre los umbrales. Alguien puso reject = 6 porque “6 se siente bien” y luego olvidó que una DKIM rota más un golpe de reputación pueden disparar una newsletter limpia.
2. Un símbolo con una puntuación desproporcionada. Una regla regexp personalizada pensada para detectar “invoice attached” ahora marca cada mención de “invoice”, incluida la de tu propio equipo de facturación.
3. Autenticación desalineada. SPF pasa para un dominio, DKIM firma como otro, DMARC falla y el mensaje recibe un golpe de puntuación que no merece, especialmente en reenvíos y listas de correo.
4. Deriva en entrenamiento y reputación. Bayes entrenado en la carpeta equivocada; fuzzy hashes que aprendieron un patrón que coincide con plantillas legítimas; fuentes de reputación históricas que cambiaron comportamiento.

La disciplina es esta: afinás símbolos, no sensaciones. Afinás por clase de tráfico, no por toda la internet. Y nunca “arreglas falsos positivos” simplemente subiendo umbrales hasta que el spam gane.

Una verdad seca de operaciones: “Simplemente iremos subiendo el umbral de reject” es el equivalente en correo de silenciar una alarma de humo quitando las pilas. Funciona hasta que realmente, realmente no funciona.

Tampoco olvides una cita para tu pared. Werner Vogels tiene una idea parafraseada que es oro operativo: todo falla, así que diseña para el fallo como condición normal. Aplícalo aquí: asume que algunas reglas estarán mal y construye un proceso que las detecte y corrija rápido.

Hechos y contexto que realmente importan en producción

Seis a diez puntos de contexto rápidos, porque los sistemas en producción se construyen sobre historia aunque no lo admitamos:

• Hecho 1: Rspamd fue diseñado como un reemplazo de alto rendimiento para filtros monolíticos antiguos, usando un motor de reglas modular y E/S asíncrona para mantener la latencia predecible bajo carga.
• Hecho 2: El modelo de “símbolos” es intencionalmente transparente en comparación con muchos filtros solo-ML: puedes explicar por qué un mensaje obtuvo 9.3, lo cual importa cuando Legal llama.
• Hecho 3: La greylist fue un triunfo casi gratuito porque los bots de spam tempranos no reintentaban correctamente; la infraestructura de spam moderna sí reintenta, así que greylist es ahora una decisión de política, no un truco.
• Hecho 4: La adopción de DMARC cambió el panorama de puntuación: fallar la alineación no es automáticamente malicioso, pero correlaciona fuertemente con abuso—especialmente para dominios lookalike.
• Hecho 5: Las listas de correo históricamente rompen DKIM porque modifican headers/cuerpo; “DKIM fail” puede significar “lista de correo” más a menudo que “spam”.
• Hecho 6: Autolearn (entrenamiento automático Bayes) ha sido fuente de dolor autoinfligido en múltiples sistemas de spam, no solo Rspamd, porque atacantes pueden empujar tu modelo con contenido borderline.
• Hecho 7: Redis se volvió el almacén por defecto para muchos módulos de Rspamd (Bayes, fuzzy, ratelimit, etc.) porque las búsquedas de baja latencia importan más que una persistencia sofisticada.
• Hecho 8: El parseo MIME y la extracción de URLs son puntos calientes perennes; regresiones de rendimiento a menudo aparecen como “falsos positivos” porque los timeouts cambian qué chequeos se ejecutan.
• Hecho 9: El “correo masivo legítimo” está operativamente más cerca del spam que del correo personal. Trátalo como su propia clase de tráfico con su propia política.

Guía de diagnóstico rápido: encuentra el cuello de botella en minutos

Cuando alguien dice “Rspamd está bloqueando correo legítimo”, no empiezas editando puntuaciones. Empiezas probando qué está pasando.

Primero: confirma qué acción ocurrió y por qué

• Extrae el resultado Rspamd del mensaje (de cabeceras, logs o controller).
• Identifica los 3 símbolos con mayor puntuación.
• Comprueba si la acción (reject/quarantine/greylist) coincide con la política para esa clase de tráfico.

Segundo: verifica si es un cambio sistémico o un único remitente

• Compara la frecuencia de símbolos y puntuaciones medias de hoy vs ayer.
• Busca una subida súbita en un símbolo concreto (por ejemplo, un DNSBL o un símbolo de alineación DMARC).
• Valida la salud del DNS: los timeouts son modificadores silenciosos de puntuación porque cambian qué chequeos se ejecutan.

Tercero: verifica la canalización (Rspamd y dependencias)

• ¿Los workers de Rspamd están sanos? ¿Sin crash loops? ¿Sin backlog?
• ¿Latencia en Redis y evictions? (Pérdida de datos Bayes/fuzzy puede cambiar el comportamiento.)
• Rendimiento y corrección del resolvedor DNS.

Cuarto: aplica la solución mínima posible

• Si un símbolo está mal, ajusta ese símbolo o limita su alcance (por dominio, por IP, por remitente).
• Si la alineación de autenticación es ruidosa, afina esos símbolos pero no los inutilices.
• Si debes relajar acciones, hazlo temporalmente y acompáñalo con un control compensatorio (quarantine en lugar de reject; añadir cabeceras y monitorizar).

Tareas prácticas: comandos, salidas y qué hacer a continuación

Estas son las tareas que ejecutas durante un incidente o una sesión de ajuste. Cada una incluye un comando, un fragmento realista de salida, qué significa y la decisión que tomas después.

Tarea 1: Confirma que Rspamd esté en ejecución y qué versión estás afinando

cr0x@server:~$ systemctl status rspamd --no-pager
● rspamd.service - Rspamd rapid spam filtering system
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2026-01-03 08:41:12 UTC; 2h 13min ago
   Main PID: 1342 (rspamd)
      Tasks: 18 (limit: 18910)
     Memory: 212.4M
        CPU: 7min 11.402s

Qué significa: Está levantado. Si está en flapping, no estás afinando puntuaciones—estás arreglando fiabilidad.

Decisión: Si es estable, procede a recopilar evidencia. Si es inestable, para y arregla crashes/bucles de recarga de configuración primero.

Tarea 2: Inspecciona umbrales de acción y confirma que no heredaste una trampa

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

Qué significa: Greylist en 4 es agresivo; add_header en 6 está bien; reject en 15 es conservador. Si tus falsos positivos son rechazos con reject=15, es probable que unos pocos símbolos estén sobreponderados o que haya un bug.

Decisión: Si reject es bajo (p. ej., 6–8), trátalo como probable contribuyente y muévete hacia quarantine/add_header mientras afinas símbolos.

Tarea 3: Extrae el resultado de un mensaje específico de los logs (por queue ID)

cr0x@server:~$ grep -F "q1bC7R2kQz" /var/log/rspamd/rspamd.log | tail -n 1
2026-01-03 10:55:21 #1342(normal) <9c1f0b>; task; rspamd_task_write_log: id: <q1bC7R2kQz@mail.example>, qid: q1bC7R2kQz, ip: 203.0.113.44, from: <billing@vendor.example>, (default: F (no action): [8.11/15.00] [DMARC_POLICY_REJECT(3.50){vendor.example;reject;},DKIM_REJECT(2.00){fail;},R_SPF_FAIL(1.80){-all;},MANY_INVISIBLE_PARTS(0.80){2;},MIME_HTML_ONLY(0.20){},ARC_NA(0.10){},ASN(0.01){AS64500;}] len: 48712, time: 110.2ms real, 36.7ms virtual, dns req: 18, digest: <d2c7...>, mime_rcpts: <ap@yourco.example>

Qué significa: No fue rechazado, pero puntuó 8.11. Los impulsores principales son DMARC_POLICY_REJECT + DKIM_REJECT + R_SPF_FAIL. Eso no es “aleatorio”; es fallo de alineación/autenticación.

Decisión: No rebajes las puntuaciones de DMARC/DKIM/SPF globalmente. Investiga si el remitente está mal configurado, si un reenvío rompió SPF o si recibes a través de un gateway que reescribe correo.

Tarea 4: Analiza picos de frecuencia de símbolos (chequeo de tendencia barato)

cr0x@server:~$ awk -F'[][]' '/rspamd_task_write_log/ {print $4}' /var/log/rspamd/rspamd.log | \
tr ',' '\n' | sed 's/(.*//' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  4821 R_DKIM_ALLOW
  3912 R_SPF_ALLOW
  1104 MIME_HTML_ONLY
   988 DMARC_POLICY_REJECT
   811 R_SPF_FAIL
   620 DKIM_REJECT
   507 MANY_INVISIBLE_PARTS

Qué significa: DMARC_POLICY_REJECT y DKIM_REJECT son altos. O estás recibiendo spoofing dirigido (posible) o algo cambió en los chequeos de autenticación (también posible).

Decisión: Correlaciona con cambios en DNS, cambios en la ruta del MTA o incorporación de proveedores. Si solo un proveedor dispara el problema, aplica una solución por remitente/dominio en lugar de debilitar reglas globales.

Tarea 5: Comprueba la salud del resolvedor DNS desde el host de Rspamd

cr0x@server:~$ resolvectl statistics
Transactions               Current Transactions  0
Cache                       Cache Size           4632
Cache                       Cache Hits           191022
Cache                       Cache Misses         22114
DNSSEC Verdicts             Secure               0
DNSSEC Verdicts             Insecure             0
DNSSEC Verdicts             Bogus                0

Qué significa: Si los cache misses explotan y la latencia sube, Rspamd puede agotar los timeouts en chequeos basados en DNS (SPF, búsquedas de claves DKIM, DNSBL), cambiando el comportamiento de puntuación y a veces creando falsos positivos o acciones inconsistentes.

Decisión: Si el DNS está enfermo, arréglalo primero. Afinar puntuaciones en un entorno degradado es cómo conviertes el outage en “política”.

Tarea 6: Mide la latencia de Redis y la presión de memoria

cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock INFO stats | egrep 'instantaneous_ops_per_sec|keyspace_hits|keyspace_misses'
instantaneous_ops_per_sec:1420
keyspace_hits:982211
keyspace_misses:44102

cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock INFO memory | egrep 'used_memory_human|maxmemory_human|evicted_keys'
used_memory_human:1.62G
maxmemory_human:2.00G
evicted_keys:18219

Qué significa: Las evictions significan que estás olvidando cosas. Bayes y fuzzy pueden degradarse de forma impredecible si Redis descarta estado constantemente.

Decisión: Deja de afinar hasta que Redis tenga margen. Añade memoria, ajusta maxmemory policy o mueve Bayes/fuzzy a una instancia Redis dedicada.

Tarea 7: Usa rspamc para analizar un mensaje sospechoso (desde un archivo guardado)

cr0x@server:~$ rspamc -h /run/rspamd/rspamd.sock symbols /tmp/suspect.eml
Results for file: /tmp/suspect.eml (0.221 seconds)
Symbol: DMARC_POLICY_REJECT (score: 3.50)
Symbol: DKIM_REJECT (score: 2.00)
Symbol: R_SPF_FAIL (score: 1.80)
Symbol: MIME_HTML_ONLY (score: 0.20)
Message-ID: <1c9f...@vendor.example>
Action: no action
Spam: false
Score: 7.50 / 15.00

Qué significa: Puedes reproducir la puntuación fuera del MTA. Eso es esencial para afinar con seguridad.

Decisión: Si es reproducible, ajusta la configuración y vuelve a probar con el mismo corpus antes del despliegue.

Tarea 8: Vuelca la puntuación configurada de un símbolo y su grupo

cr0x@server:~$ rspamadm configdump --path scores | egrep 'DMARC_POLICY_REJECT|DKIM_REJECT|R_SPF_FAIL'
DMARC_POLICY_REJECT = 3.5;
DKIM_REJECT = 2;
R_SPF_FAIL = 1.8;

Qué significa: Confirma que no persigues fantasmas; esos son pesos reales, no “dinámicos”.

Decisión: Si necesitas reducir el dolor, prefiere acotar (por dominio/remitente) en vez de reducirlos globalmente.

Tarea 9: Inspecciona overrides de política por dominio (fuente común de sorpresas)

cr0x@server:~$ rspamadm configdump --path settings
settings {
    yourco.example {
        priority = high;
        apply {
            actions {
                reject = 12;
            }
        }
    }
}

Qué significa: Alguien bajó reject solo para tu dominio principal (o lo subió, etc.). Esto suele ser intencional, a veces olvidado.

Decisión: Valida si esto coincide con requisitos de negocio. Si existe el override, documéntalo y asegúrate de que el monitoreo refleje esa política especial.

Tarea 10: Comprueba hits de multimap allowlist (para ver si dependes de cinta adhesiva)

cr0x@server:~$ grep -F "MULTIMAP" /var/log/rspamd/rspamd.log | tail -n 3
2026-01-03 10:52:11 #1342(normal) <7a2e1c>; lua; multimap.lua: MULTIMAP_ALLOWLIST_DOMAIN hit for domain vendor.example
2026-01-03 10:54:40 #1342(normal) <11bd77>; lua; multimap.lua: MULTIMAP_ALLOWLIST_IP hit for ip 198.51.100.9
2026-01-03 10:54:45 #1342(normal) <1f33a9>; lua; multimap.lua: MULTIMAP_ALLOWLIST_FROM hit for from billing@vendor.example

Qué significa: Ya estás saltándote chequeos para algunos remitentes. Eso puede estar bien, pero es un ítem de riesgo, no una medalla.

Decisión: Si el allowlisting es abundante, reduce su alcance: prefiere allowlisting basado en identidad DKIM o restringe por rangos IP que controles, y fija revisiones de caducidad.

Tarea 11: Valida que tu configuración recargue sin errores

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

Qué significa: No rompiste el parseo. Esto no prueba que tu política sea buena. Prueba que no va a tumbar los workers.

Decisión: Solo después de que configtest pase recargas. Si no, estás depurando producción con vendaje en los ojos.

Tarea 12: Recarga Rspamd sin reiniciar la máquina

cr0x@server:~$ systemctl reload rspamd

cr0x@server:~$ journalctl -u rspamd -n 5 --no-pager
Jan 03 11:02:10 server rspamd[1342]: config reloaded successfully
Jan 03 11:02:10 server rspamd[1342]: workers state: normal workers: 4

Qué significa: La recarga funcionó; los workers se mantuvieron activos.

Decisión: Verifica inmediatamente la puntuación con un corpus de prueba y monitoriza tasas de reject/quarantine durante la próxima hora.

Tarea 13: Confirma que el MTA recibe las cabeceras de resultado de Rspamd

cr0x@server:~$ postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5    48211 Thu Jan  3 11:03:12  billing@vendor.example
                                         ap@yourco.example

cr0x@server:~$ postcat -q A1B2C3D4E5 | egrep -i 'X-Spam|X-Rspamd|Authentication-Results' | head -n 20
X-Spam-Status: No, score=7.50 required=15.00
X-Spam-Action: no action
X-Spam-Score: 7.50
X-Spam-Level: *******
Authentication-Results: mx.yourco.example; dkim=fail header.d=vendor.example; spf=fail smtp.mailfrom=billing@vendor.example; dmarc=fail header.from=vendor.example

Qué significa: Las cabeceras confirman la misma historia. Si faltan cabeceras, tus falsos positivos pueden ser un problema de política del MTA, no de Rspamd.

Decisión: Si el MTA actúa con una señal distinta a la esperada (p. ej., milters, chequeos de cabecera), alinea la canalización antes de tocar puntuaciones de Rspamd.

Tarea 14: Rastrea recuentos de acción en un intervalo corto

cr0x@server:~$ grep -oE 'default: [^ ]+ \([^)]*\)' /var/log/rspamd/rspamd.log | tail -n 2000 | sort | uniq -c | sort -nr
  1602 default: F (no action)
   287 default: R (reject)
    91 default: G (greylist)
    20 default: A (add header)

Qué significa: Los rejects son relativamente altos. Si eso es “malo” depende de tu mezcla de tráfico. Para correo corporativo, 287 rejects en los últimos 2000 decisiones registradas merece investigación.

Decisión: Muestrea 20 rejects. Si son mayoritariamente spam obvio, bien. Si incluyen remitentes legítimos, encuentra los símbolos recurrentes y arregla esos específicamente.

Broma 1: El correo es el único producto donde “deliverability” significa “por favor permite que esta persona sea interrumpida por mi mensaje”.

Una estrategia de puntuación sensata: cambia menos, mide más

Cuando ajustas para reducir falsos positivos, negocias entre dos modos de fallo:

• Tipo I: spam entregado (molesto, riesgoso)
• Tipo II: correo legítimo bloqueado (rompe negocio)

La mayoría de organizaciones dicen temer más al spam. No es cierto. Temen más perder un correo real, porque eso provoca disfunción visible. Tu política debería admitir esa realidad y codificarla.

Elige acciones según el radio de impacto del negocio

Acciones comunes y cómo se comportan en el mundo real:

• add_header: el valor predeterminado más seguro para “quizás spam”. Mantiene el flujo de correo y permite que usuarios y SIEMs vean la puntuación. Contras: los usuarios ignorarán cabeceras hasta que los entrenes (o enrutes según cabeceras).
• greylist: útil para remitentes desconocidos, pero doloroso para sistemas automatizados que no reintentan correctamente. Úsalo cuando toleres retrasos y sepas que tus remitentes legítimos se comportan como MTAs correctos.
• quarantine: la alternativa adulta al reject para spam de confianza media. Reduce daño por falsos positivos y mantiene la basura fuera de las bandejas de entrada.
• reject: resérvalo para alta confianza. Si rechazas correo de baja confianza, has creado un generador de outages que dispara al azar.

Cambia la puntuación como cambias reglas de firewall

Cuatro reglas que te mantienen honesto:

1. Haz un cambio a la vez salvo que estés revertiendo un deploy conocido y malo.
2. Prefiere acotar a cambios globales: por dominio, por destinatario, por IP, por usuario autenticado.
3. Mantén un corpus de pruebas: al menos 50 mensajes buenos y 200 malos conocidos (o lo que ajuste a tu entorno). Recalifica antes/después.
4. Registra la decisión: por qué cambiaste un símbolo y qué métrica esperas mover.

Dónde se esconden usualmente los falsos positivos: correo “bueno” que parece spam

Mensajes legítimos que comúnmente acumulan señales de spam:

• Proveedores que envían facturas desde una plataforma nueva (IPs nuevas, auth desajustada)
• Newsletters de marketing (muchas URLs, tracking, HTML-only, patrones de envío masivo)
• Alertas de seguridad (texto corto + asunto alarmante + enlaces)
• Invitaciones de calendario y notificaciones automáticas (estructuras MIME raras)
• Correo reenviado (SPF se rompe; DMARC falla a menos que ARC se use correctamente)

El objetivo no es fingir que estos son “correo personal”. El objetivo es identificarlos y tratarlos como una categoría con política propia.

Herramientas de ajuste focalizado: multimap, groups y políticas por dominio

El ajuste focalizado es cómo reduces falsos positivos sin bajar el puente levadizo para el spam. En Rspamd tienes tres palancas prácticas:

• Settings (por dominio/usuario/IP/destinatario) para ajustar acciones, aplicar cambios de símbolo o saltarse chequeos.
• Multimap para allowlists/blocklists basadas en cabeceras, envelope, IP u otros selectores.
• Symbol scores and groups para mantener chequeos relacionados balanceados (auth, contenido, reputación).

Prefiere “suavizar” sobre “deshabilitar”

Deshabilitar chequeos es tentador y por lo general equivocado. Si los fallos DMARC causan falsos positivos para un socio porque su mail está mal configurado, tienes opciones:

• Pídeles que lo arreglen. (Sí, puedes. Los proveedores responden más rápido cuando dejan de llegar facturas.)
• Reduce temporalmente la penalización solo para ese socio.
• Quarantine en lugar de reject para esa clase de correo hasta que la autenticación esté corregida.

Ejemplo: settings por dominio para evitar rechazar correo borderline

Para un dominio con alto impacto de negocio (p. ej., el propio), podrías elegir quarantine a una puntuación más baja que reject, manteniendo los rejects para spam claramente flagrante.

Práctica clave: usa overrides para acciones, no allowlisting absoluto. Deja que el sistema puntúe; solo cambia qué haces con el resultado.

Ejemplo: multimap allowlist con guardarraíles

Si debes allowlistear, hazlo con sesgo hacia identidad verificable:

• Allowlista un patrón de dominio firmado con DKIM que confíes (y verifica que sea estable).
• Allowlista un rango IP solo si el remitente lo publica y no es infraestructura compartida.
• Evita allowlistear por campo “From:” o nombre de muestra a menos que disfrutes ser phished.

Broma 2: La forma más rápida de conseguir presupuesto para filtrado de spam es permitir un phishing y llamarlo “iniciativa de educación al usuario”.

Autenticación y alineamiento: SPF, DKIM, DMARC sin culto cargo

Muchos falsos positivos son en realidad problemas de “desacuerdo de autenticación”. No puedes tunearte fuera de un ecosistema de remitentes roto—al menos no limpiamente. Pero puedes entender los modos de fallo y elegir políticas que reduzcan daño colateral.

SPF: útil hasta que el correo se reenvía

SPF compara la IP conectante con la política del dominio remitente. El reenvío rompe SPF porque la IP del servidor de reenvío no está autorizada por el remitente original. Eso no es Rspamd siendo malo; es cómo funciona SPF.

Decisión operativa: si tu entorno reenvía mucho correo (alias a sistemas externos, herramientas de ticketing, etc.), no trates R_SPF_FAIL como una señal casi-rechazo. Mantenla significativa, pero equilibrada.

DKIM: sobrevive el reenvío pero falla con modificaciones

DKIM firma el contenido del mensaje. Las listas de correo, footers y gateways que reescriben HTML pueden romper DKIM. Verás picos de DKIM fail cuando un servidor de listas cambia comportamiento o un appliance de seguridad empieza a “sanitizar” contenido.

Decisión operativa: un DKIM fail debe ser una señal fuerte cuando se combina con contenido sospechoso o indicadores de spoofing, no un martillo independiente.

DMARC: la alineación es el punto, y por eso duele

DMARC verifica si SPF y/o DKIM se alinean con el dominio visible en “From:”. Así se detiene el spoofing obvio. También penaliza flujos legítimos pero desordenados.

Decisión operativa: trata DMARC policy reject/quarantine como señales importantes de reputación/autenticación, pero ten cuidado de no sobrerreaccionar para ecosistemas legítimos conocidos (listas de correo, cadenas de reenvío). Considera validar ARC si tu flujo lo soporta.

ARC: el amigo complicado que a veces tiene razón

ARC (Authenticated Received Chain) puede preservar resultados de autenticación a través de intermediarios. Cuando se despliega correctamente, reduce falsos positivos en correo reenviado. Cuando se despliega mal, añade más confusión.

Decisión operativa: si ves mucho reenvío y ARC está presente, valida si tu build de Rspamd y la configuración lo evalúan correctamente. Si ARC falta consistentemente, eso también es una señal.

Bayes y fuzzy: entrenar sin envenenarte

El filtrado bayesiano es potente y extremadamente fácil de estropear. El fuzzy hashing es excelente para detectar campañas de spam casi duplicadas, y también fácil de sobreadaptar. El tema: controla tus entradas.

Bayes: úsalo, pero no lo dejes conducir

Bayes en Rspamd puede aprender de mensajes que clasificas como ham/spam. La trampa de falsos positivos ocurre cuando:

• Usuarios marcan newsletters como spam porque están molestos, no porque sea realmente spam.
• Spam aterriza en un buzón compartido y luego se mueve, confundiendo pipelines de entrenamiento.
• Los umbrales de autolearn están demasiado agresivos, entrenando con mensajes borderline.

Fuzzy: alcance estrecho, alta confianza

Fuzzy funciona mejor cuando hashéas elementos de alta señal: plantillas de spam conocidas, kits de phishing conocidos y cargas recurrentes. Funciona peor cuando hashéas plantillas comerciales comunes (facturas, notificaciones de envío) porque eventualmente te hashéas a ti mismo y empezarás a rechazar media internet.

Guardarraíles que deberías imponer

• Requerir revisión manual para conjuntos de entrenamiento que cambian comportamiento Bayes/fuzzy.
• Separar entrenamiento de correo corporativo vs correo masivo si puedes. El correo masivo (incluso legítimo) comparte rasgos con el spam.
• Monitorizar la distribución de confianza de Bayes, no solo “spam atrapado”. Un modelo Bayes siempre incierto suele estar hambriento o contaminado.

Rendimiento y retropresión: cuando el filtrado causa los falsos positivos

Esta es la parte que la gente pasa por alto: los falsos positivos pueden ser artefacto de timeouts y chequeos degradados.

Rspamd ejecuta múltiples chequeos: búsquedas DNS, consultas a Redis, extracción de URLs, parseo MIME, consultas a reputación externa. Cuando las dependencias son lentas, algunos chequeos fallan por timeout. Dependiendo de la configuración, podrías ver:

• Señales negativas faltantes (el spam se cuela).
• Señales positivas faltantes (el correo legítimo pierde puntos “allow” y sube en la puntuación).
• Comportamiento de fallback conservador (p. ej., fallos temporales tratados como sospechosos).

Qué monitorizar que correlaciona con falsos positivos

• Latencia de consultas DNS y tasas de fallo
• Latencia de Redis, evictions, problemas de persistencia
• Tiempo CPU de workers Rspamd vs tiempo real (virtual vs real en logs)
• Número de consultas DNS por mensaje (picos pueden indicar campaña con explosión de URLs)

Patrón de diseño: “quarantine ante la incertidumbre”

Si tu entorno sufre forzados por dependencias, considera una política donde resultados borderline vayan a quarantine en lugar de reject. Es menos dramático. También te da una vía de recuperación para falsos positivos.

Tres micro-historias corporativas desde el frente

Micro-historia 1: El incidente causado por una suposición errónea

Una compañía mediana operaba Rspamd detrás de un gateway Postfix. Tenían una política simple: cualquier cosa por encima del umbral reject se devolvía. Alguien asumió “reject significa más seguro”, así que bajaron reject de un valor conservador a algo más cercano al umbral de add_header. El cambio entró un viernes. Por supuesto.

El lunes por la mañana, finanzas se quejó de que remesas de proveedores “no estaban llegando”. El correo no se retrasó; fue rechazado. Los bounces fueron a un buzón sin atender porque el proveedor usaba una dirección no-reply. Así que el proveedor no supo, finanzas no supo y el gateway hizo exactamente lo que le dijeron.

Cuando muestreamos mensajes rechazados, la mayoría estaban limpios pero tenían problemas de alineación DMARC porque el proveedor migró a una plataforma nueva y configuró mal DKIM. Rspamd no estaba paranoico; era consistente. El error fue asumir que el umbral de reject es solo “la línea de spam”. En realidad es “la línea de outage del negocio”.

La solución fue aburrida y efectiva: restaurar el umbral conservador de reject, enrutar correo de confianza media a quarantine y crear un proceso de onboarding de proveedores que verifique SPF/DKIM/DMARC antes de la primera factura.

Micro-historia 2: La optimización que salió mal

Otra organización quería reducir latencia de correo. Notaron que las consultas DNS por mensaje eran altas durante campañas, así que “optimizaron” cambiando resolvedores y ajustando timeouts. En laboratorio se veía bien: respuestas más rápidas, menos latencias largas.

En producción, el nuevo resolvedor a veces rate-limitó o descartó consultas bajo carga de ráfaga. Los logs de Rspamd empezaron a mostrar tiempos “reales” más largos y menos búsquedas exitosas para SPF y claves DKIM. La parte graciosa es que el spam empezó a colarse y el correo legítimo empezó a puntuar más—porque los símbolos “allow” no se asignaban consistentemente.

El incidente se manifestó como “Rspamd es inconsistente”. No lo era. La dependencia lo era. Tras revertir los cambios del resolvedor, añadieron un resolvedor de caché local en la misma red del host, aumentaron timeouts sensatos y monitorizaron tasas de fallo DNS como métrica de primera clase. Su latencia mejoró y los falsos positivos bajaron sin tocar puntuaciones.

La lección: optimizaciones de rendimiento en dependencias son cambios de política disfrazados. Trátalos con el mismo control de cambios que usarías para umbrales de spam.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía global tenía la costumbre que parecía burocrática: cada trimestre revisaban sus 20 símbolos top por contribución agregada y sus 20 dominios remitentes más rechazados. Sin heroísmos. Solo reportes aburridos, una reunión corta y una lista de tickets.

Un trimestre notaron un aumento constante en rejects relacionados con DMARC de un proveedor SaaS legítimo usado por RRHH. Antes de llegar a crisis, abrieron un caso con el proveedor, aportaron evidencia de fallos de autenticación y aplicaron temporalmente una política por remitente que cuarentenaba en lugar de rechazar. RRHH nunca notó.

Dos semanas después, el proveedor arregló la alineación DKIM. La empresa quitó la excepción temporal. Sin cicatrices permanentes de allowlist. Sin ejecutivos enojados. Sin “por qué no nos avisaste”.

Este es el triunfo silencioso: la revisión rutinaria detecta deriva temprano y las excepciones temporales acotan outages mientras mantienes el resto de la postura intacta.

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

Síntoma: Correo legítimo es rechazado con puntuaciones altas dominadas por símbolos de autenticación.

Causa raíz: Remitente mal configurado en SPF/DKIM/DMARC, o reenvíos/listas de correo que rompen la alineación.

Solución: Acotar la política: quarantine en vez de reject para ese remitente, y presionar al remitente para corregir la alineación. Evita reducir globalmente puntuaciones de DMARC/DKIM.

Síntoma: Los falsos positivos suben al mismo tiempo que aumenta el conteo “DNS req” en los logs.

Causa raíz: Latencia/fallo del resolvedor DNS causa resultados inconsistentes en los chequeos.

Solución: Estabiliza el DNS (cache local, timeouts sensatos, capacidad). Luego re-evalúa puntuaciones.

Síntoma: Bayes de repente etiqueta una plantilla de negocio común como spam en varios departamentos.

Causa raíz: Entradas de entrenamiento malas (usuarios marcando correo masivo legítimo como spam) o autolearn demasiado agresivo.

Solución: Revisa el pipeline de entrenamiento; reduce autolearn; reentrena desde conjuntos curados; separa manejo de correo masivo.

Síntoma: “Arreglas” falsos positivos subiendo el umbral de reject, y el volumen de spam en bandejas sube en días.

Causa raíz: Cambiaste el control equivocado; el desbalance de símbolos subyacente permanece.

Solución: Revierta el cambio de umbral; identifica los símbolos top en falsos positivos; afina/override acotado; añade una tier de quarantine.

Síntoma: Una aplicación interna envía correo constantemente marcado, pero el correo externo está bien.

Causa raíz: La app genera MIME malformed, solo HTML, falta Date/Message-ID, o usa infraestructura compartida con mala reputación.

Solución: Arregla la generación de correo de la app (cabeceras correctas, parte de texto, DKIM consistente). Si es necesario, añade una política por IP con relajación mínima mientras se remedia.

Síntoma: Los logs de Rspamd muestran puntuación normal, pero el MTA aún rechaza o re-enruta correo.

Causa raíz: Otro filtro/milter/chequeo de cabeceras está actuando, o el MTA interpreta cabeceras incorrectamente.

Solución: Traza la canalización; confirma que la política del MTA mapea a la acción de Rspamd; elimina chequeos conflictivos o alinea decisiones.

Síntoma: Clasificaciones aleatorias tras un reinicio de Redis o evento de presión de memoria.

Causa raíz: Redis ha expulsado Bayes/fuzzy/metadata; el estado del modelo cambió.

Solución: Provee margen de memoria; evita evictions; separa instancias Redis; confirma estrategia de persistencia; monitoriza evicted_keys.

Síntoma: Allowlisting “arregla” el problema pero el phishing empieza a saltarse filtros.

Causa raíz: Allowlisting por identificadores débiles (cabecera From, dominio sin DKIM), o rangos IP demasiado amplios.

Solución: Reemplaza allowlists amplias con settings acotados y cheques de identidad fuertes; usa expiraciones y revisiones periódicas.

Listas de verificación / plan paso a paso

Paso a paso: reducir falsos positivos de forma segura (sin abrir las compuertas)

1. Recopila evidencia: 20–50 falsos positivos con cabeceras completas y desglose de símbolos Rspamd.
2. Clasifica por tipo de tráfico: correo personal, transaccional de proveedores, bulk/marketing, alertas de sistema, listas de correo.
3. Identifica símbolos recurrentes en falsos positivos (top 3 por mensaje; frecuencia agregada).
4. Confirma salud de dependencias: DNS, Redis, saturación CPU, latencia de workers.
5. Elige la mitigación menos riesgosa:
   • Override por remitente o dominio (accion: quarantine en lugar de reject).
   • Ajustar un score de símbolo ligeramente (deltas pequeños, p. ej., -0.5 no -3.5).
   • Arreglar autenticación del remitente o composición de correo interna.
6. Recalifica un corpus de prueba usando rspamc antes de desplegar cambios.
7. Despliega con reload, no con restart, y vigila logs para éxito de recarga.
8. Monitorea tasas de acción (reject/quarantine/greylist/add_header) por al menos un día laborable.
9. Backstop con quarantine para confianza media hasta que las métricas se estabilicen.
10. Documenta excepciones con responsables y fechas de revisión de expiración.

Checklist: lo que deberías tener antes de afinar

• Una cuarentena o al menos una vía recuperable para falsos positivos
• Logging centralizado y forma de buscar por Message-ID/queue ID
• Un corpus curado de ham/spam para regresiones
• Dashboards para latencia DNS, evictions de Redis, latencia de workers Rspamd
• Un changelog para cambios de scores/settings (los mensajes de commit cuentan)

Checklist: lista de “no hacer”

• No deshabilites globalmente cheques DMARC/DKIM/SPF porque un proveedor no puede configurar su correo.
• No allowlistees por cabecera From sola.
• No afines durante un outage (problemas DNS/Redis) y lo llames “política”.
• No pongas umbrales de reject cerca de add_header en entornos de correo empresarial.
• No autolear agresivamente a menos que estés preparado para auditar entradas de entrenamiento.

Preguntas frecuentes

1) ¿Debo arreglar falsos positivos subiendo el umbral de reject?

Sólo como medida de contención temporal, y sólo si lo emparejas con quarantine o monitorización por add_header. A largo plazo, arregla los símbolos que causan los picos o acota la política al tráfico afectado.

2) ¿Cuál es la configuración de acción más segura para correo corporativo?

Usualmente: add_header para baja sospecha, quarantine para media, reject para alta. Greylisting puede funcionar, pero crea retrasos y comportamiento frágil para remitentes automáticos.

3) Un proveedor no deja de fallar DKIM y DMARC. ¿Lo allowlisteo?

Prefiere una política acotada: quarantine en lugar de reject para ese dominio remitente y mantén la puntuación intacta. Si debes allowlistear, hazlo lo más estrecho posible (identidad DKIM estable o un rango IP ajustado) y fija una fecha de revisión.

4) ¿Por qué las listas de correo causan falsos positivos?

Suelen modificar mensajes (footers, tags en el asunto, cambios de cabeceras), lo que puede romper DKIM. También cambian la ruta de entrega de formas que rompen SPF. DMARC entonces ve desalineación y puntúa acorde.

5) ¿Cómo sé qué símbolo está “mal”?

No lo adivines. Agrega tus falsos positivos y encuentra los contribuyentes recurrentes principales. Si un símbolo aparece en la mayoría y no se correlaciona con spam real en tu entorno, es candidato para afinar o acotar.

6) ¿Puede Bayes causar falsos positivos aun si todo lo demás está bien?

Sí. Un modelo Bayes contaminado puede etiquetar con confianza plantillas comunes. Endurece entradas de entrenamiento, reduce autolearn agresivo y reentrena desde conjuntos curados si hace falta.

7) ¿Por qué los falsos positivos empeoran cuando Redis tiene presión de memoria?

Las evictions quitan estado aprendido y cachés. Eso cambia probabilidades Bayes y comportamiento fuzzy/reputación. El sistema se vuelve menos consistente, lo que se siente como cambios “aleatorios” en clasificaciones.

8) ¿Sigue siendo útil la greylisting?

A veces. Es útil contra remitentes de baja calidad y cierto spam oportunista, pero retrasa correo legítimo de primer contacto y muchos spammers modernos reintentan correctamente. Úsala intencionalmente, no nostálgicamente.

9) ¿Cómo afino sin dejar pasar más spam?

Acota cambios (por remitente/dominio), prefiere quarantine ante la incertidumbre y mantiene un corpus de regresión. No debilites símbolos de autenticación globalmente a menos que tengas controles compensatorios fuertes.

10) ¿Cuál es una buena señal de que el problema no es la puntuación sino la infraestructura?

Cuando patrones de símbolos cambian con timeouts, errores DNS o evictions de Redis, y cuando “real time” en logs sube mientras “virtual time” se mantiene bajo. Arregla dependencias primero.

Conclusión: próximos pasos que puedes hacer esta semana

Si sólo haces unas pocas acciones, haz estas:

1. Construye un pequeño corpus de falsos positivos con cabeceras completas y desglose de símbolos Rspamd. Deja de ajustar basado en anécdotas.
2. Implementa quarantine para confianza media para poder recuperar errores sin impacto de negocio.
3. Audita la salud de dependencias: DNS y Redis suelen disfrazarse de problemas de puntuación.
4. Ajusta por acotamiento: settings por dominio/remitente vencen a reducciones globales de puntuación casi siempre.
5. Programa una revisión trimestral aburrida de símbolos top y remitentes rechazados top. Es el trabajo de fiabilidad más barato que harás.

Los falsos positivos no son un misterio. Son una señal de que tu entorno cambió, tus suposiciones estaban equivocadas o tus dependencias están tambaleantes. Trátalos como un problema operacional, no como superstición, y Rspamd se comportará.