Correo electrónico: Inundación de spam entrante — sobrevive al ataque sin bloquear usuarios reales

Contra qué te estás enfrentando (y qué no)

Una inundación de spam entrante no es “alguien nos envió spam.” Es un problema de rendimiento y equidad que sucede por SMTP.
El atacante (o un emisor masivo mal configurado, o una botnet comprometida) no necesita ser ingenioso. Solo necesita ser numeroso y persistente lo suficiente para que tu canal de correo se tropiece.

Los modos de fallo que realmente te tumban

• Explosión de la cola: tu MTA acepta mensajes más rápido de lo que puede procesarlos (filtrado, consultas DNS, entrega), así que la cola crece hasta que la presión del disco o de inodos impacta.
• Colapso de CPU: el filtrado de contenido (AV, puntuación de spam, descompresión) se vuelve tu camino más caliente. Un tipo de adjunto malo puede convertirse en una bomba fork de trabajo.
• Amplificación de latencia DNS: cada comprobación SPF/DKIM/DMARC y búsqueda RBL se convierte en un multiplicador de las conexiones entrantes. Resolver lento = todo lento.
• Agotamiento de la tabla de conexiones: demasiadas sesiones SMTP simultáneas; tu kernel y MTA comienzan a dejar caer conexiones legítimas.
• Rebotes y reintentos: si aceptas y luego rechazas, generas bounces o fuerzas reintentos; te conviertes en parte del problema y tu cola permanece caliente por horas.
• Falsos positivos: la “solución” bloquea clientes, sistemas de socios y restablecimientos de contraseña. Así es como los incidentes llegan a escalaciones ejecutivas.

El truco es hacer que tu sistema sea barato para decir que no, y predecible para decir que sí. Rechaza lo más pronto posible (durante el diálogo SMTP),
y reserva el análisis caro de contenido para el correo que probablemente sea legítimo.

Una cita que vale la pena pegar en tu monitor: La esperanza no es una estrategia. — Gene Kranz.
Las inundaciones de correo son donde “simplemente lo observaremos” viene a morir.

Chiste #1: El correo es el único protocolo donde “Por favor, inténtelo de nuevo más tarde” es un flujo de trabajo empresarial legítimo.

Datos interesantes y un poco de historia

Las inundaciones de spam parecen modernas, pero el ecosistema ha ido evolucionando durante décadas. Aquí hay puntos concretos que influyen en las defensas actuales:

1. SMTP precede al spam por diseño: el modelo original asumía hosts cooperativos, por eso tantos controles son añadidos en lugar de integrados.
2. Los relays abiertos fueron un vector de spam importante: el abuso generalizado de relays en los 90 obligó a los MTAs a asegurar el relaying por defecto.
3. Las DNSBL/RBL se hicieron populares porque eran baratas: una consulta DNS podía reemplazar escaneos de contenido caros para fuentes obviamente malas.
4. El greylisting emergió como arma económica: retrasa el primer intento y muchos bots de spam no reintentan correctamente, mientras que los MTA reales sí lo hacen.
5. SPF fue diseñado para detener la suplantación de envelope-from: ayuda, pero no prueba al remitente humano; prueba la autorización de dominio para ese camino.
6. DKIM hizo la autenticación de mensajes escalable: firmar el contenido en cabeceras permite a los receptores verificar integridad sin secretos compartidos.
7. DMARC añadió política e informes: es una capa de aplicación y visibilidad, no un botón mágico de “no spam”.
8. Las botnets cambiaron los patrones de volumen de spam: en lugar de unas pocas fuentes gigantes, obtienes muchas fuentes de bajo volumen que evaden umbrales por IP sencillos.
9. El escaneo de contenido se ha vuelto más pesado con el tiempo: el spam moderno usa archivos anidados, codificaciones extrañas y trampas en “documentos” que son costosas de desempaquetar.

Guía rápida de diagnóstico

Cuando llega la inundación, no tienes tiempo para debatir arquitectura. Necesitas encontrar el cuello de botella en minutos.
Esta secuencia está sesgada hacia MTAs Linux (Postfix, Exim) con stacks de filtrado comunes, pero el razonamiento aplica también a Exchange y gateways alojados.

Primero: ¿Estamos rechazando temprano, o aceptando y ahogándonos después?

• Comprueba las tasas de sesión SMTP entrantes y las conexiones concurrentes.
• Comprueba si el crecimiento de la cola es incoming, active, deferred o hold.
• Comprueba la proporción de aceptaciones 2xx frente a rechazos 4xx/5xx.

Segundo: ¿Qué recurso está saturado ahora mismo?

• CPU: trabajadores de spam/AV al máximo, carga en aumento, mucho cambio de contexto.
• Disco: directorio de cola en almacenamiento lento; iowait en picos; agotamiento de inodos.
• DNS: latencia del resolvedor; toneladas de DNS salientes; timeouts que causan bloqueos SMTP.
• Red: backlog SYN; agotamiento de conntrack; límites de tasa upstream.

Tercero: ¿Cuál es la palanca más barata que gana tiempo sin bloquear usuarios reales?

• Aumenta la fricción para emisores abusivos (límites de conexión, tarpit, postscreen, greylisting).
• Reduce el coste de manejo (omitir escaneos caros para lo obviamente malo; cachear DNS; preferir comprobaciones RBL).
• Protege flujos críticos (allowlists para socios conocidos; MX o puerto/IP separado para correo transaccional).

La mentalidad de respuesta a la inundación: estabiliza, luego mejora. No “refactorices tu sistema de correo” en medio del incidente a menos que disfrutes tickets de cambio que parecen escenas de crimen.

Doce+ tareas prácticas: comandos, salidas y la decisión que tomas

El objetivo aquí no es presumir comandos. Es hacerte rápido: ejecuta algo, interpreta el resultado, elige la siguiente acción.
Los ejemplos asumen un gateway de correo Linux con Postfix y herramientas comunes; adapta rutas para tu distribución.

Tarea 1: Mide el tamaño y la forma de la cola (Postfix)

cr0x@server:~$ mailq | tail -n 5
-- 12437 Kbytes in 1832 Requests.

Qué significa: Tienes 1.832 mensajes en cola; el tamaño es moderado pero el conteo es el verdadero dolor operativo (sobrecarga de procesamiento por mensaje).

Decisión: Si el conteo sube rápido, prioriza el rechazo temprano y el throttling antes de intentar “procesarlo todo”.

Tarea 2: Identifica las IP principales que están golpeando tu servicio SMTP

cr0x@server:~$ sudo ss -tn sport = :25 | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  312 203.0.113.55
  287 198.51.100.22
  190 192.0.2.77

Qué significa: Unas pocas IPs acaparan sesiones. Podrían ser bots o un emisor masivo roto.

Decisión: Aplica límites de conexión por cliente o bloqueos temporales para los peores ofensores solo después de comprobar si son socios legítimos.

Tarea 3: Detecta si estás gastando tiempo en búsquedas DNS

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "10 min ago" | tail -n 6
Jan 04 10:11:20 mx1 systemd-resolved[642]: Transaction 49231 for 55.113.0.203.zen.spamhaus.org. IN A timed out
Jan 04 10:11:20 mx1 systemd-resolved[642]: Transaction 49232 for 22.100.51.198.zen.spamhaus.org. IN A timed out

Qué significa: Las búsquedas RBL están expirando. Tu MTA se detendrá, las sesiones se mantendrán abiertas, la concurrencia aumentará y la cola crecerá.

Decisión: Arregla el rendimiento del resolvedor ahora: resolvedor con caché local, timeouts más cortos, menos comprobaciones caras y paralelas durante el pico.

Tarea 4: Comprueba CPU e iowait (¿es cálculo o disco?)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          28.14    0.00    9.83   34.76    0.00   27.27

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  %util
nvme0n1         12.0   420.0    96.0  8120.0    8.40   98.0

Qué significa: Alto iowait y utilización del disco. La E/S de la cola es tu factor limitante.

Decisión: Reduce la agitación de la cola (rechaza antes, acepta más despacio), y considera mover la cola a almacenamiento más rápido si puedes hacerlo de forma segura.

Tarea 5: Verifica presión de inodos (las colas pueden morir por inodos)

cr0x@server:~$ df -ih /var/spool/postfix
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2        2.0M  1.9M  120K   95% /

Qué significa: Estás cerca del agotamiento de inodos. Incluso con espacio libre, no puedes crear archivos nuevos. A los MTAs no les gusta esto.

Decisión: Limpieza de emergencia: purga el spam obvio de la cola (con cuidado), aumenta la capacidad de inodos a largo plazo y reduce la tasa de aceptación ahora.

Tarea 6: Encuentra qué estado de la cola está explotando (IDs de cola de Postfix)

cr0x@server:~$ sudo qshape deferred | head
T  5 10 20 40 80 160 320 640 1280 2560 5120 10240 20480 40960
5  0  2  3  6 15  44  98 210  380  390  230    54     0     0

Qué significa: Deferred está creciendo: fallos de entrega remota, greylisting en otros sitios o tu ruta de salida está congestionada.

Decisión: Separa la supervivencia entrante de la entrega saliente: considera limitar las tasas de reintentos salientes y asegúrate de que el rechazo entrante ocurra antes de la cola.

Tarea 7: Comprueba la presión de procesos de Postfix

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_client_connection_count_limit|default_process_limit|smtpd_client_message_rate_limit'
default_process_limit = 200
smtpd_client_connection_count_limit = 20
smtpd_client_message_rate_limit = 100

Qué significa: Permites 20 conexiones concurrentes por cliente y 100 mensajes/min por cliente; el límite global de procesos es 200.

Decisión: Durante una inundación, reduce la concurrencia por cliente (los bots se benefician del paralelismo). Aumenta el límite global solo si CPU/disco lo permiten; de lo contrario amplificas el colapso.

Tarea 8: Cuantifica rápidamente rechazos vs aceptaciones desde logs

cr0x@server:~$ sudo awk '{print $6}' /var/log/mail.log | grep -E 'reject:|status=sent|status=deferred' | head
reject:
status=sent
status=deferred

Qué significa: Esto es un muestreo burdo. Necesitas proporciones.

Decisión: Si los rechazos son bajos mientras la cola sube, eres demasiado permisivo en tiempo SMTP. Añade rechazos baratos (RBL, postscreen, HELO estricto) y reduce escaneos caros.

Tarea 9: Extrae los destinatarios principales que están siendo atacados (protégelos)

cr0x@server:~$ sudo grep -h "to=<" /var/log/mail.log | sed -n 's/.*to=<\([^>]*\)>.*/\1/p' | cut -d, -f1 | sort | uniq -c | sort -nr | head
  842 info@
  731 sales@
  690 support@

Qué significa: Los buzones genéricos están siendo bombardeados.

Decisión: Aplica controles por destinatario: filtrado más estricto para catch-all/generales, MX separado para alias públicos o requerir captcha/portal para entradas a ciertas direcciones (decisión de negocio).

Tarea 10: Comprueba el coste y fallos de handshake TLS (al spam le gustan los handshakes caros)

cr0x@server:~$ sudo grep -h "TLS" /var/log/mail.log | tail -n 5
Jan 04 10:12:01 mx1 postfix/smtpd[23102]: TLS handshake failed: SSL_accept error from 203.0.113.55: -1
Jan 04 10:12:02 mx1 postfix/smtpd[23108]: Anonymous TLS connection established from 198.51.100.22: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384

Qué significa: Los fallos de handshake pueden consumir CPU; TLS exitoso es bueno, pero políticas que exigen solo TLS pueden ser abusadas por spammers que pueden pagar CPU.

Decisión: Mantén TLS activado, pero añade postscreen/controles de conexión para no gastar ciclos criptográficos en basura obvia.

Tarea 11: Valida que la caché de tu resolvedor esté funcionando

cr0x@server:~$ resolvectl statistics | head -n 12
Transactions:           98422
Cache Hits:             61210
Cache Misses:           37212
DNSSEC Verdicts Secure: 0

Qué significa: Una buena tasa de aciertos en caché te compra supervivencia. Si los aciertos son bajos, estás repitiendo búsquedas caras.

Decisión: Asegura caché local, ajusta respeto a TTL y evita comprobaciones DNS por mensaje que puedas posponer o cachear en servicios de política.

Tarea 12: Comprueba el respaldo de ClamAV o del escáner de contenido (ejemplo)

cr0x@server:~$ systemctl status clamav-daemon --no-pager | sed -n '1,12p'
● clamav-daemon.service - Clam AntiVirus userspace daemon
     Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled)
     Active: active (running) since Thu 2026-01-04 09:41:22 UTC; 30min ago
     Docs: man:clamd(8)
   Main PID: 1432 (clamd)
      Tasks: 42 (limit: 18956)
     Memory: 1.1G
        CPU: 18min 10.221s

Qué significa: El escáner está vivo, consumiendo CPU, con muchas tareas. No prueba el rendimiento.

Decisión: Si el escáner se vuelve el cuello de botella, cambia temporalmente a “denegar por reputación + comprobaciones básicas” y reserva el escaneo profundo para fuentes permitidas o remitentes autenticados.

Tarea 13: Comprueba si el kernel está descartando conexiones

cr0x@server:~$ netstat -s | egrep -i 'listen|overflow|drops' | head
    2489 times the listen queue of a socket overflowed
    2489 SYNs to LISTEN sockets dropped

Qué significa: Estás perdiendo sesiones antes de que Postfix siquiera las vea. Los remitentes legítimos reintentarán, pero estás añadiendo caos.

Decisión: Aumenta backlog y ajusta límites del kernel, pero solo después de aplicar throttles a nivel MTA; de lo contrario solo aceptas más dolor.

Tarea 14: Muestra cabeceras de mensajes de la cola (no adivines)

cr0x@server:~$ sudo postcat -q 3F2A1C2B9E | sed -n '1,25p'
*** ENVELOPE RECORDS active ***
message_size: 28412              452             1               0               28412
sender: spammer@example.net
*** MESSAGE CONTENTS ***
Received: from unknown (HELO user) (203.0.113.55)
Subject: Invoice attached

Qué significa: Puedes ver patrones: HELO malo, asuntos sospechosos, fuentes repetidas.

Decisión: Convierte los patrones en reglas baratas en tiempo SMTP (restricciones HELO, postscreen, RBL), no en filtrado pesado después de aceptar.

Chiste #2: El filtro de spam más rápido es un código 554. También es el único que nunca necesita actualización de firmas.

Controla el radio de efecto: puntos de estrangulamiento que importan

En una inundación, no “luchas contra el spam.” Controlas el consumo de recursos. Tu MTA es básicamente una línea de fábrica:
aceptar conexión → negociar → recibir mensaje → ejecutar comprobaciones → encolar → entregar → reintentar si hace falta.
Cualquier etapa que sea lenta se convierte en un atasco detrás de ella.

1) Manejo de conexiones: reduce conversaciones caras

La defensa más subestimada es hacer que las conexiones SMTP entrantes sean aburridas y baratas. La mayoría de inundaciones de spam dependen de que tú hagas trabajo:
handshakes TLS, retrasos en el banner, búsquedas de políticas, filtros de contenido. Tu trabajo es hacer menos por remitente malo.

• Límites de concurrencia por cliente: a los bots les gustan las sesiones paralelas. Los MTA legítimos normalmente se comportan.
• Limitación de tasa de conexiones: limita nuevas conexiones por ventana de tiempo por IP/subred.
• Postscreen (Postfix): mantiene al demonio SMTP alejado de basura obvia hasta que el cliente demuestre competencia básica.
• Tarpitting: añade un pequeño retraso para clientes sospechosos. No demasiado—minutos son autolesión.

2) Rechazo en tiempo SMTP: nunca aceptes lo que ya sabes que vas a rechazar

Si aceptas un mensaje y luego decides que es spam, ya pagaste el coste: E/S de disco, entradas en cola, tiempo de escaneo,
y a menudo una tormenta de reintentos. Rechaza en connect/helo/mail-from/rcpt-to siempre que sea posible.

• Bloquea patrones HELO/EHLO inválidos: “HELO user” desde una IP pública rara vez es un servidor serio.
• Requiere un remitente de sobre apropiado donde corresponda.
• Usa RBLs con cuidado: una lista sólida supera a cinco inestables que hacen timeouts.
• Validación de destinatarios: rechaza destinatarios desconocidos en tiempo SMTP para evitar backscatter y crecimiento de la cola.

3) Equidad para usuarios reales: protege a remitentes y destinatarios críticos

“No bloquear usuarios reales” no es sentimental; es operativo. Tus mejores clientes activarán los mismos controles que atrapan al spam si los pones de forma contundente.
La solución es segmentación y excepciones explícitas.

• Allowlists de socios a nivel gateway (rangos IP, fuentes autenticadas o dominios conocidos con infraestructura estable).
• MX entrante separado: un MX público que absorba la basura y un canal protegido para tráfico transaccional/partner.
• Diferentes políticas por destinatario: ejecutivos y direcciones de restablecimiento de contraseña merecen baja latencia y mayor confianza.

Estrategia de filtrado durante una inundación: prioriza el flujo sobre la perfección

El escaneo de contenido es donde las buenas intenciones se quedan al 100% de CPU. En tiempos normales, puedes permitir descomprimir adjuntos,
ejecutar AV, hacer hashing difuso y calcular puntuaciones de spam elaboradas. Durante una inundación, cada milisegundo extra se convierte en un multiplicador.

Primero reputación, segundo contenido

Comienza con señales baratas que terminan temprano:

• Reputación IP y saneamiento básico de protocolo: postscreen, RBL, pipelining de comandos inválidos, demasiados errores.
• Política de sobre: rechaza destinatarios inexistentes; limita destinatarios por mensaje; bloquea dominios locales obviamente falsificados.
• Comprobaciones de autenticación: resultados SPF/DMARC pueden usarse para puntuar o rechazar en dominios de alto riesgo, pero cuidado con la dependencia de DNS.

Cuándo usar greylisting (y cuándo es una trampa)

El greylisting puede ser salvador en una inundación repentina: convierte tu servidor en una máquina de “vuelva a intentarlo más tarde”, y mucho software de spam se rinde.
Pero también retrasa remitentes legítimos de primera vez, lo cual es desagradable si estás incorporando clientes nuevos o recibiendo tickets sensibles en tiempo.

Un término medio práctico: aplica greylist solo con señales sospechosas (sin reverse DNS, HELO inválido, IP nueva con mal comportamiento),
y exime a remitentes conocidos o socios autenticados.

DMARC/SPF/DKIM durante la tormenta

Estas comprobaciones ayudan, pero no las dejes convertirse en tu cuello de botella:

• SPF: excelente para eliminar suplantaciones obvias, pero pesado en DNS. Cachea resultados y establece timeouts agresivos.
• DKIM: la verificación suele ser de coste razonable, pero las firmas rotas son comunes; trata fallos como señales, no siempre como rechazos.
• DMARC: potente para dominios que publican políticas estrictas. Para otros, es mayormente puntuación e informes.

Defer vs reject: elige tu dolor

Un fallo 4xx temporal indica a los MTA legítimos que reintenten más tarde. Los spammers también reintentan, pero muchos lo hacen mal. Un rechazo 5xx es más limpio y barato,
pero aumenta el riesgo de bloquear un mensaje real por una señal falsa positiva.

Durante una inundación, usa deferimientos dirigidos (fuentes sospechosas, remitentes desconocidos a destinatarios delicados) y rechazos confiados
(reputación conocida mala, destinatarios inválidos, violaciones de protocolo). Evita deferimientos en bloque que solo llenan tu tabla de conexiones.

Colas, discos y la parte que los ingenieros de almacenamiento arreglan en silencio

Las inundaciones de spam a menudo se diagnostican como “problema de correo” y se resuelven como “problema de almacenamiento.” Los directorios de cola son infierno de archivos pequeños:
miles de pequeñas escrituras, patrones fsync, búsquedas en directorios y agitación de metadatos. Tu NVMe elegante ayuda; tu sistema de archivos de red sobrecargado no.

Fundamentos de la arquitectura de colas (por qué duele)

La mayoría de MTAs almacenan cada mensaje como múltiples archivos (sobre, contenido, estado diferido). Bajo carga pesada:

• Las operaciones de directorio dominan (crear, renombrar, unlink).
• La sobrecarga de journaling se hace visible.
• Los inodos se consumen rápidamente.
• Agentes de backup, antivirus en acceso o herramientas de indexación pueden convertir los directorios de cola en una tragedia a cámara lenta.

Movidas prácticas de almacenamiento que ayudan durante inundaciones

• Mantén el spool en almacenamiento local rápido: no NFS, no “ese volumen SAN compartido que usa todo el mundo.” NVMe local o SSD es la elección aburrida y correcta.
• Separa el spool de los logs masivos: evita contención con rotación o envío de logs.
• Vigila el uso de inodos: las alertas basadas en tamaño pasan por alto este fallo completamente.
• Minimiza escrituras síncronas donde sea seguro: cuidado con las opciones de montaje; la fiabilidad importa, pero a menudo puedes ajustar sin engañar al sistema de archivos.
• Mantén herramientas de limpieza de cola listas: no quieres escribir un script improvisado bajo presión.

La gestión de colas es respuesta a incidentes, no trabajo de conserjería

Una cola creciente no es automáticamente “mala.” Es un buffer. El incidente ocurre cuando el buffer crece más rápido que tu tasa de recuperación y comienza a consumirlo todo.
Tu objetivo es modelar la cola para que el correo importante se entregue primero y la basura se rechace temprano.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana ejecutaba un par de gateways de correo y un sistema de tickets separado. Tenían filtrado decente y creían estar seguros porque “tenemos un proveedor cloud al frente.”
La suposición equivocada fue pensar que el proveedor absorbería cualquier inundación y reenviaría solo “correo real.”

La inundación llegó como un hervor lento: miles de mensajes pequeños por minuto, mayormente a support@ e info@.
El proveedor los entregó diligentemente, porque eran técnicamente SMTP válidos y no obviamente maliciosos.
Los gateways on-prem los aceptaron y luego los pasaron al escaneo de contenido. Los escáneres no colapsaron; simplemente se ralentizaron. La cola creció. El iowait del disco aumentó.

Los correos de clientes reales empezaron a expirar. Los emails de restablecimiento de contraseña (también respuestas entrantes y bounces) se retrasaron.
La solución temporal del equipo de soporte fue pedir a los clientes que “usen chat.” El proveedor de chat los limitó por tasa. Así es como los incidentes de correo cobran vida.

La solución no fue “comprar más filtrado.” Fue mover el rechazo hacia adelante: validación de destinatario en tiempo SMTP, límites estrictos por cliente y gating estilo postscreen.
Luego crearon un camino protegido para correo entrante de alto valor: partners y respuestas transaccionales tuvieron un MX separado con allowlists estrictas.

Conclusión del postmortem: un borde cloud no es un motor de políticas a menos que lo hayas configurado como tal. Si tu gateway lo acepta, tú lo posees.

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

Una empresa minorista intentó acelerar el procesamiento de correo aumentando el número de workers: más procesos Postfix, más hijos Amavis, mayor concurrencia en todas partes.
Funcionó maravillosamente en un entorno de staging silencioso, lo cual es una frase que siempre debería hacerte sospechar.

Durante una ola de spam, la “optimización” se volvió un multiplicador. Con más concurrencia, aceptaron más mensajes por segundo e inmediatamente los volcaron al disco y a los escáneres.
Los escáneres saturaron la CPU. El disco saturó IOPS. La latencia aumentó, lo que mantuvo las sesiones SMTP abiertas por más tiempo, lo que aumentó aún más la concurrencia.
El sistema no explotó; se asfixió lentamente.

También ajustaron los timeouts DNS al alza “para ser robustos.” En la práctica, esto significó esperar más por respuestas RBL lentas,
manteniendo las sesiones abiertas y consumiendo procesos mientras el resolvedor luchaba.

La recuperación implicó hacer lo contrario de sus instintos: reducir la concurrencia a un nivel que el disco pudiera sostener, acortar timeouts DNS
y rechazar más en tiempo de conexión. El rendimiento mejoró porque el sistema dejó de trastabillar.

La lección: en sistemas en pipeline, “más paralelismo” no siempre equivale a más rendimiento. Si una etapa downstream está saturada, la concurrencia solo agranda el problema.

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

Una organización de servicios financieros tenía fama de ser lenta para cambiar y insoportablemente estricta con los runbooks. También rotaban on-call como si fuera un ritual sagrado.
Esto no los hacía populares en el happy hour, pero hizo su sistema de correo resiliente.

Tenían tres cosas mundanas en su lugar: (1) directorio de cola en SSD local dedicado con monitorización de inodos, (2) resolvedor con caché local con métricas,
y (3) un “conjunto de políticas de incidente” preaprobado para Postfix que se podía habilitar en minutos: RBLs más estrictas, menor concurrencia por cliente, mayor agresividad de postscreen,
y deferrals temporales para fuentes sospechosas.

Cuando llegó una inundación, el on-call no improvisó. Activaron la política de incidente, vieron la estabilización del crecimiento de la cola y luego relajaron reglas selectivamente para un partner
cuyo correo estaba siendo atrapado por una comprobación HELO demasiado agresiva. Ese partner recibió una entrada en allowlist con un ticket de expiración.

El impacto al negocio se limitó a retrasos en buzones entrantes de baja prioridad. Los ejecutivos nunca lo notaron.
Después, el equipo revisó logs, encontró los principales ASN de la botnet y actualizó la política a más largo plazo.

La lección: “lo aburrido” es una característica. Perillas preaprobadas y fundamentos monitorizados vencen a las heroicidades.

Listas de verificación / plan paso a paso

Fase 0: Antes de la inundación (no harás esto durante la inundación)

1. Instrumenta la canalización: tamaño de cola, distribución de antigüedad en cola, tasa de sesiones SMTP, recuentos de rechazo/aceptación, latencia DNS, iowait de disco, CPU por filtro.
2. Separa roles: el MX entrante no debe ser la misma máquina que ejecuta trabajos pesados no relacionados. El correo quiere recursos predecibles.
3. Construye un conjunto de políticas de incidente: una configuración “modo tormenta” preprobada que puedas activar rápidamente.
4. Mantén allowlists con responsables: cada entrada de allowlist debe tener una razón y un plan de expiración.
5. Conoce tus flujos críticos de correo: restablecimientos de contraseña, facturación, integraciones con socios, notificaciones legales. Identifica destinatarios y IPs/dominios emisores.

Fase 1: Primeros 15 minutos (estabilizar)

1. Confirma que es entrante: comprueba la tasa de conexiones SMTP y el crecimiento de la cola entrante.
2. Identifica el cuello de botella: CPU vs disco vs DNS vs descartes del kernel.
3. Activa el modo tormenta: baja la concurrencia por cliente, habilita postscreen/tarpit/greylisting selectivamente, ajusta el uso de RBLs.
4. Protege remitentes críticos: añade allowlists temporales para proveedores transaccionales conocidos y socios clave si quedan atrapados.
5. Deja de aceptar lo que no puedes procesar: prefiere rechazos tempranos; si es necesario, 4xx temporales para fuentes sospechosas para preservar el servicio.

Fase 2: Siguiente hora (restaurar flujo)

1. Reduce el escaneo caro: deshabilita recursión profunda de archivos, limita tamaños de adjuntos para fuentes no autenticadas/no confiables y asegúrate de fallar cerrado solo cuando lo pretendas.
2. Arregla DNS: resolvedor con caché local, ajusta timeouts y reduce el número de comprobaciones DNS por mensaje.
3. Gestiona la cola: prioriza correo legítimo y considera poner en cuarentena el tráfico obvio de la inundación.
4. Comunica: informa a soporte qué se está retrasando, qué es seguro y qué canales alternativos existen sin prometer milagros.

Fase 3: Tras la estabilización (limpiar y endurecer)

1. Elimina bloqueos temporales con trazabilidad en tickets y comprobaciones de expiración.
2. Cuantifica falsos positivos: muestrea correo en cuarentena/rechazado, ajusta reglas.
3. Plan de capacidad: mide tasas máximas de aceptación y rendimiento de escaneo; decide dónde gastar dinero (cómputo, almacenamiento o filtrado upstream).
4. Documenta lo que funcionó, lo que no y qué perillas eran demasiado riesgosas.

Errores comunes (síntomas → causa raíz → solución)

1) Síntoma: La cola crece, la CPU está bien, iowait es alto

Causa raíz: cola en almacenamiento lento/contendido; demasiadas operaciones con archivos pequeños; presión de inodos; posiblemente antivirus escaneando el directorio de la cola.

Solución: mueve el spool a disco local rápido; excluye el spool del escaneo en acceso; reduce la tasa de aceptación con rechazos en tiempo SMTP; monitoriza inodos.

2) Síntoma: Muchas sesiones SMTP atascadas, pocos rechazos, timeouts en logs

Causa raíz: búsquedas DNS que caducan (RBL/SPF/DMARC), causando espera en las sesiones; resolvedor sobrecargado o upstream bloqueado.

Solución: resolvedor con caché local; reduce número de comprobaciones DNS; acorta timeouts; asegura que el DNS saliente no esté limitando por tasa; considera desactivar temporalmente comprobaciones no esenciales.

3) Síntoma: Pico en load average, procesos de escáner se multiplican, entregas lentas

Causa raíz: el escaneo de contenido es el cuello de botella (AV/puntuación de spam, recursión en archivos, extracción PDF/Office).

Solución: limita la profundidad de recursión; omite tipos MIME caros para remitentes no confiables; usa gating por reputación antes del escaneo; escala el escaneo horizontalmente si forma parte de tu diseño.

4) Síntoma: El correo de un socio legítimo queda bloqueado tras endurecer reglas

Causa raíz: uso brusco de RBL, comprobaciones HELO estrictas o greylisting agresivo sin exenciones.

Solución: añade allowlists con dueños; usa puntuación multi-señal en vez de rechazo por una sola regla; greylista solo fuentes sospechosas; prueba cambios con tráfico muestreado de socios.

5) Síntoma: Kernel reporta descartes SYN / overflow de cola de escucha

Causa raíz: inundación de conexiones; backlog insuficiente; MTA no acepta lo bastante rápido; demasiadas sesiones SMTP concurrentes.

Solución: primero límites/ratelimits a nivel MTA; luego ajusta backlog del kernel; considera filtrado upstream o protección a nivel TCP si está disponible.

6) Síntoma: Correo saliente retrasado mientras ocurre la inundación entrante

Causa raíz: recursos compartidos (misma cola/disco/CPU) y tormentas de reintentos; procesos de entrega salientes hambrientos.

Solución: separa roles entrante/saliente o al menos separa colas; limita reintentos salientes; asegura que los rechazos entrantes prevengan crecimiento innecesario de la cola.

7) Síntoma: Ves muchos bounces que no pretendías enviar

Causa raíz: aceptar spam y luego rechazar o generar DSNs a remitentes falsificados (backscatter).

Solución: rechaza en tiempo SMTP; valida destinatarios durante RCPT TO; evita generar DSNs para inbound no autenticado cuando sea posible.

Preguntas frecuentes

1) ¿Debería bloquear países o ASN enteros durante una inundación?

Solo si tu realidad de negocio lo permite. El geo-bloqueo puede ganar tiempo, pero es un instrumento contundente con daños colaterales previsibles.
Si lo haces, que sea temporal, registrada y revisada. Prefiere bloques por ASN basados en tráfico abusivo observado en lugar de intuiciones.

2) ¿Sigue siendo útil el greylisting en 2026?

Sí, de forma selectiva. El greylisting global molesta a remitentes legítimos de primera vez y rompe algunos mailers SaaS mal hechos.
Greylista fuentes sospechosas, exime remitentes conocidos y monitoriza el impacto en retrasos sobre soporte y ventas.

3) ¿Por qué no subir la puntuación de spam a “muy agresiva” y darlo por resuelto?

Porque la parte cara suele ser la propia puntuación. Además, la alta agresividad aumenta los falsos positivos justo cuando tus usuarios son más sensibles.
Durante inundaciones, desplázate hacia la izquierda: rechaza barato y temprano; escanea en profundidad solo el correo que pasa puertas básicas de confianza.

4) ¿Cómo evito bloquear correos de restablecimiento de contraseña y registros?

Separa los flujos transaccionales. Idealmente, los gateways entrantes deberían tener un camino protegido para correo de tus propios proveedores y socios clave,
con allowlists estrictas y autenticación donde sea posible. Tampoco rutas tus emails críticos por la misma política de “MX público” que el tráfico aleatorio entrante.

5) ¿Cuál es el cuello de botella más común que “no pensamos”?

DNS. Cada característica anti-spam que parece “ligera” a menudo se traduce en consultas DNS bajo carga.
Si tu resolvedor es lento o tu upstream te limita por tasa, tu sistema de correo se convierte en una sala de espera distribuida.

6) ¿Puedo borrar la cola para recuperarme rápido?

Puedes, pero probablemente no deberías. Primero, estabiliza la aceptación para que la cola deje de crecer.
Luego elimina quirúrgicamente el tráfico obviamente malo (por rangos de remitente IP, destinatarios como info@ bajo ataque, o firmas de spam conocidas) con auditoría.
Borrar todo convierte un incidente de correo en un incidente de negocio con condimentos legales.

7) ¿Debo desactivar el escaneo antivirus durante una inundación de spam?

A veces, parcialmente. Si la inundación es alto volumen y baja sofisticación, el AV puede estar desperdiciando CPU en basura que deberías rechazar antes.
Pero apagar AV por completo puede ser riesgoso si también recibes malware dirigido. Un enfoque más seguro es el gating: ejecutar AV solo después de comprobaciones de reputación/protocolo.

8) ¿Cómo sé si estoy rechazando demasiado correo legítimo?

Rastrea falsos positivos deliberadamente: muestrea logs de correo rechazado, pon en cuarentena decisiones dudosas en vez de rechazarlas con dureza,
y vigila señales del negocio (tickets de soporte, quejas de socios, restablecimientos de contraseña faltantes). Si no mides, adivinarás—y adivinar sale caro.

9) ¿Necesito múltiples registros MX y múltiples gateways?

Para la mayoría de organizaciones que cuidan la disponibilidad, sí. La redundancia no es solo para fallos de hardware; es para absorber abuso.
Dos gateways te permiten hacer mantenimiento, aislar problemas y aplicar políticas diferentes para distintos flujos de correo.

10) ¿Por qué mis remitentes legítimos siguen siendo castigados por RBLs?

Porque “legítimo” no significa “bien gestionado.” Hosting compartido, VPS baratos y mailers SaaS mal configurados pueden acabar en listas por el comportamiento de vecinos.
La solución es crear un proceso: verificar al remitente, allowlist con restricciones y presionar al socio para que mejore su infraestructura de envío.

Conclusión: próximos pasos que puedes hacer hoy

Sobrevivir a una inundación de spam entrante sin bloquear usuarios reales es un problema de sistemas. Ganas siendo barato para los atacantes y predecible para todos los demás.
No persigas cada muestra de spam. Controla tus cuellos de botella, rechaza temprano y mantén un carril protegido para el correo crítico.

Haz esto en la próxima semana

• Escribe y prueba una configuración “modo tormenta”: límites de conexión, política postscreen/greylisting y una canalización de filtrado de coste reducido.
• Pon la cola en almacenamiento local rápido y añade alertas de inodos. Las alertas de espacio en disco por sí solas son una mentira reconfortante.
• Levanta un resolvedor con caché local con métricas y timeouts sensatos; mide la latencia DNS bajo carga.
• Define flujos entrantes críticos (restablecimientos de contraseña, facturación, correo de socios) y asegúrate de que tengan excepciones y monitorización explícitas.
• Practica la triage de colas: muestrea cabeceras, identifica principales fuentes/destinatarios y ensaya un procedimiento seguro de limpieza.

El mejor momento para descubrir el verdadero rendimiento de tu gateway de correo no es durante una inundación.
El segundo mejor momento es antes de la siguiente, que está programada para un momento inconveniente que no has elegido todavía.