Limitación de tasas en Postfix: prevenir abusos sin bloquear a usuarios reales

Qué significa realmente la limitación de tasas en Postfix (y qué no)

La limitación de tasas en Postfix no es una sola función. Es un conjunto de válvulas de alivio en diferentes capas:

• Controles a nivel de conexión: cuántas sesiones TCP puede abrir un cliente, con qué rapidez puede abrirlas y cuánto tolerarás que estén inactivas.
• Controles a nivel de protocolo: cuántos destinatarios por mensaje, cuántos comandos por sesión y qué tan rápido puede hacer pipeline un cliente.
• Controles a nivel de autenticación: limitar el envío autenticado por SASL para que una cuenta comprometida no envíe 50.000 mensajes antes de que te des cuenta.
• Controles de cola y entrega: evitar que un solo dominio o destino consuma todos los slots de entrega y te haga recibir throttling de los grandes proveedores.
• Controles de política: “cerebros” externos que aplican reglas por usuario/remitente/cliente basadas en estado, reputación o contexto de negocio.

La limitación de tasas no es un filtro anti-spam. No decidirá si un mensaje es spam. Decide cuánto daño puede causar cualquier fuente por unidad de tiempo. Te compra tiempo y preserva el servicio para los demás.

Además, la limitación de tasas no es “bloquear”. La mejor limitación de tasas es deferir primero: ralentiza comportamientos sospechosos mientras permite el tráfico normal. Las rechazos son para violaciones claras de política, no para “mi servidor está ocupado”. Cuando rechazas porque estás sobrecargado, estás exportando tu incidente a otro, y lo recordarán.

Verdad irónica #1: SMTP permite alegremente que un portátil en una cafetería intente convertirse en tu “plataforma de correo masivo”. Tiene la confianza de un niño con un rotulador permanente.

Tres principios que te evitan outages autoinfligidos

1. Modela el tráfico, no adivines. Usa límites medibles (por IP, por usuario, por destino) en lugar de intuiciones.
2. Prefiere “fallo temporal” sobre “fallo permanente”. Las respuestas 4xx preservan los patrones de entrega y reducen tickets de soporte.
3. Haz las excepciones explícitas. Si necesitas permitir a un socio relay o a un remitente masivo, ponlos en un carril controlado en vez de subir límites globales.

Una cita para pegar en un post-it

La esperanza no es una estrategia. — General Gordon R. Sullivan

La limitación de tasas es dónde cambias la esperanza por controles.

Hechos y contexto: por qué los límites de Postfix son así

Un poco de contexto ayuda a explicar por qué Postfix te ofrece un surtido de controles en vez de un único botón “limitar spam”:

1. SMTP existía antes de la internet comercial. Fue diseñado para hosts cooperativos, no para clientes hostiles, así que la limitación de tasas se convirtió en una habilidad añadida de supervivencia.
2. Postfix se creó como alternativa a Sendmail con seguridad y rendimiento como objetivos principales, incluyendo una arquitectura multiproceso que puede seguir funcionando aun cuando partes están bajo presión.
3. anvil existe porque contar conexiones es caro. Postfix añadió el servicio anvil(8) para rastrear tasas por cliente de forma eficiente sin que cada proceso lo reinventara.
4. La greylisting popularizó la idea de “ralentizar al malo”. La limitación de tasas es su pariente: hacer que la automatización abusiva pague costos de tiempo.
5. Los grandes receptores empezaron a aplicar reputación del remitente a escala (tasa, quejas, rebotes), transformando la limitación saliente en una función de entregabilidad, no solo de seguridad.
6. Los botnets cambiaron el juego entrante. Antes una IP única era “la fuente”. Ahora el abuso viene de enjambres, lo que hace que los límites por IP sean necesarios pero no suficientes.
7. La reutilización de credenciales migró a la entrega de correo porque el reuso de contraseñas es eterno. Limitar intentos de autenticación es ahora higiene básica.
8. Cloud NAT complicó la “equidad por IP”. Cientos de usuarios legítimos pueden aparecer como una sola IP, así que necesitas límites que consideren identidad autenticada, no solo dirección cliente.

Elige un modelo de amenaza antes de tocar un control

Si no decides contra qué te proteges, implementarás “límites” que castiguen a las personas equivocadas.

Amenazas entrantes (rol de servidor SMTP)

• Inundaciones de conexiones (colas SYN/accept, agotamiento de procesos, CPU por TLS): se resuelven con postscreen, límites de anvil y afinamiento a nivel OS.
• Ataques de recolección de directorios (muchas pruebas RCPT TO): se resuelven con límites de destinatarios, tarpitting y restricciones de política.
• SMTP estilo Slowloris (mantener sesiones abiertas, gotear comandos): se resuelve con timeouts y mínima concurrencia por cliente.

Amenazas salientes (rol de submission/relay)

• Buzón comprometido: limita tasas por usuario/SASL y alerta sobre anomalías.
• Remitente masivo “accidental” usando tu sistema: aplica políticas por cliente y remitente; dedica una instancia o transporte separado.
• Throttling de destino (grandes proveedores): limita la concurrencia por destino y suaviza picos para proteger la reputación.

Decide cómo es el “correo bueno”

Los usuarios reales tienden a tener patrones: pocos destinatarios, tasas moderadas, destinos consistentes. El abuso suele ser brusco, amplio e impaciente. Tu configuración debe codificar esa diferencia.

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

Cuando alguien dice “el correo va lento” o “algunos usuarios no pueden enviar”, no edites main.cf inmediatamente. Primero, determina qué limitador está activo: red, smtpd, política, cola o receptores aguas abajo.

Primero: ¿es aceptación entrante o entrega saliente?

• Si los usuarios informan “no puedo enviar” desde clientes: revisa el servicio de submission, SASL, el demonio de políticas y los topes de envío saliente.
• Si remitentes remotos reportan “no pueden alcanzarte”: revisa listeners entrantes, postscreen, límites de conexión y DNS.

Segundo: mira la cola y las razones de defer

Una cola diferida creciente es un throttle aguas abajo o un problema de concurrencia de entrega. Una cola activa creciente sugiere contención local o concurrencia demasiado baja.

Tercero: confirma qué está haciendo Postfix con los clientes

Los logs te dicen si estás rechazando (5xx), deferiendo (4xx) o simplemente lento. La limitación de tasas suele aparecer como “too many connections”, “policyd: … action=defer” o drops de postscreen.

Cuarto: identifica los mayores emisores

Encuentra qué IPs, usuarios SASL o direcciones remitentes dominan el tráfico. Aplica límites de forma quirúrgica.

Caja de herramientas de limitación: anvil, postscreen, policyd y aliados

1) anvil(8): seguimiento de conexiones y tasas por cliente

anvil mantiene contadores como “conexiones por cliente por unidad de tiempo” y “conexiones simultáneas por cliente”. Soporta parámetros de Postfix como:

• smtpd_client_connection_count_limit
• smtpd_client_connection_rate_limit
• smtpd_client_message_rate_limit
• smtpd_client_recipient_rate_limit

Son herramientas contundentes pero efectivas. También son fáciles de aplicar mal a poblaciones detrás de NAT (universidades, empresas, operadores móviles) donde muchos usuarios legítimos comparten una IP.

2) postscreen: detener basura antes de que se convierta en carga SMTP

postscreen gestiona la etapa inicial de la conexión y puede descartar basura obvia de forma barata. Es tu “portero de la entrada”. Úsalo cuando el SMTP entrante reciba grandes volúmenes de spam o tráfico de bots.

postscreen es especialmente útil cuando los handshakes TLS y las negociaciones SMTP consumen CPU. Es mejor evitar la negociación que limitar después de que ya la pagaste.

3) Servicios de política: límites más inteligentes por identidad y contexto

La delegación de políticas de Postfix (check_policy_service) permite que un servicio externo decida aceptar/deferir/rechazar basándose en:

• Nombre de usuario SASL
• Dirección del remitente
• IP del cliente y HELO
• Destinatario, dominio y metadatos del mensaje

Aquí implementas “mensajes por hora por usuario”, “límites por plan de cliente” y “carril especial para sistemas de confianza” sin convertir tu daemon SMTP en una hoja de cálculo.

4) Moldeo de entrega: no te hagan throttlear los grandes receptores

Postfix puede limitar concurrencia y tasa por destino, mediante transportes y ajustes por destino (por ejemplo, afinando concurrencia y retardos). Esto tiene menos que ver con detener abuso y más con mantenerte bienvenido.

5) Separación del servicio de submission: proteger entrantes de salientes

Si ejecutas MX entrante y submission saliente en el mismo host, aisla los servicios. Diferentes puertos, restricciones distintas, límites distintos. El mismo binario, comportamiento distinto. La configuración correcta se siente aburrida. Mantenla así.

Puntos de partida sensatos: valores iniciales que no arruinan tu día

No hay un número universal. Pero hay errores universales: poner límites tan bajos que los reintentos legítimos se conviertan en una avalancha de soporte, o tan altos que una cuenta comprometida se convierta en un evento de RRPP.

Sugerencias base para entrantes (MX)

• Usa postscreen si recibes volumen significativo de bots.
• Establece concurrencia por cliente conservadora (smtpd_client_connection_count_limit) para evitar que una IP acapare recursos.
• Usa timeouts para cerrar sesiones lentas: smtpd_timeout, smtpd_helo_timeout, smtpd_recipient_limit (el límite de destinatarios no es un timeout, pero frena un patrón de abuso común).

Sugerencias base para salientes (submission/relay)

• Limita por usuario SASL, no por IP, si tienes clientes detrás de NAT.
• Prefiere defer sobre reject por exceso de tasa. Los usuarios reintentan; el malware también reintenta, pero te da tiempo de detección.
• Impón límites duros en destinatarios por mensaje para submission y así evitar desastres de “un mensaje a 10.000 destinatarios”.

Verdad irónica #2: Todo servidor de correo termina convirtiéndose en servidor de correo masivo. La única pregunta es si sucede con tu permiso.

Tareas prácticas (comandos, salidas, decisiones)

Estos son los movimientos que realizas en incidentes reales y en trabajo de afinamiento. Cada tarea incluye: el comando, qué significa una salida típica y la decisión a tomar a continuación.

Tarea 1: Confirmar que Postfix está activo y qué servicios escuchan

cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (running) since Fri 2026-01-02 08:14:03 UTC; 1 day ago

Significado: Postfix está en ejecución. Si no lo está, los límites de tasa no son tu problema; es disponibilidad del servicio, sintaxis de configuración o dependencias.

Decisión: Si está inactivo/failed, inspecciona journalctl -u postfix y ejecuta postfix check antes de tocar la afinación.

Tarea 2: Inspeccionar parámetros clave de limitación actualmente en efecto

cr0x@server:~$ postconf -n | egrep 'anvil|client_.*rate|client_.*count|recipient_limit|smtpd_timeout|postscreen'
smtpd_client_connection_count_limit = 20
smtpd_client_connection_rate_limit = 60
smtpd_client_message_rate_limit = 120
smtpd_client_recipient_rate_limit = 600
smtpd_recipient_limit = 200
smtpd_timeout = 60s

Significado: Estos son ajustes no por defecto en tu configuración en vivo. Muchos incidentes empiezan con “alguien afinó esto hace meses”.

Decisión: Registra estos valores. Si estás en una caída, trata los cambios como rollback con un plan, no como experimentos.

Tarea 3: Verificar que anvil está habilitado (porque esos límites dependen de él)

cr0x@server:~$ postconf anvil
anvil = unix - - n - 1 anvil

Significado: El servicio anvil está disponible para rastrear tasas. Si falta, algunos ajustes de limitación no se comportarán como esperas.

Decisión: Si anvil está deshabilitado o falla, arregla eso primero; de lo contrario perseguirás “límites” fantasma.

Tarea 4: Revisar tamaño y composición de la cola de correo

cr0x@server:~$ mailq | tail -n 20
-- 12 Kbytes in 23 Requests.

Significado: Cola pequeña. Tu problema probablemente es aceptación (clientes bloqueados) en lugar de backlog de entrega.

Decisión: Si la cola es enorme, pivota a las razones de defer y al throttling por destino (Tareas 5–7).

Tarea 5: Resumir razones de diferido desde los logs (qué está fallando realmente)

cr0x@server:~$ grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 5
Jan 03 09:12:44 mx postfix/smtp[22184]: 8A3C73C2F: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.140.27]:25, delay=12, delays=0.2/0.1/9.6/2.1, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[74.125.140.27] said: 421-4.7.0 Try again later, closing connection. (in reply to end of DATA command))

Significado: Un downstream te está limitando (421 4.7.0). Esto no se arregla subiendo tus límites de cliente entrante. Se arregla suavizando salientes y reduciendo volumen sospechoso.

Decisión: Implementa modelado por destino (concurrencia/retardo) y verifica que no estés enviando spam o rebotes.

Tarea 6: Identificar los principales usuarios SASL que envían (quién genera volumen)

cr0x@server:~$ grep "sasl_username=" /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  842 sales.bot@example.com
  113 j.smith@example.com
   77 alerts@example.com

Significado: Una identidad domina. Podría ser automatización legítima o una cuenta comprometida.

Decisión: Si es inesperado: deshabilita credenciales, fuerza reinicio de contraseña y añade límites por usuario vía política. Si es esperado: muévelo a un relay/instancia dedicada.

Tarea 7: Identificar las principales IPs cliente en SMTP entrante (quién se conecta)

cr0x@server:~$ grep "connect from" /var/log/mail.log | awk '{print $NF}' | sed 's/[][]//g' | sort | uniq -c | sort -nr | head
  502 203.0.113.44
  311 198.51.100.77
  148 192.0.2.10

Significado: Unas pocas IPs te martillan. Si son redes desconocidas, estás bajo tráfico de bots/abuso o relays upstream mal configurados.

Decisión: Usa postscreen/límites de anvil o rate limiting a nivel de firewall; pon en whitelist solo si puedes probar legitimidad.

Tarea 8: Verificar si los clientes están siendo limitados por Postfix

cr0x@server:~$ grep -E "too many (connections|commands|messages)|rate limit" /var/log/mail.log | tail -n 8
Jan 03 09:10:02 mx postfix/smtpd[21901]: warning: too many connections from 203.0.113.44
Jan 03 09:10:03 mx postfix/smtpd[21902]: warning: 203.0.113.44: SMTP command rate limit exceeded

Significado: Tu servidor está activamente limitando. Eso puede ser correcto (bots) o incorrecto (oficina detrás de NAT, balanceador, sistema de monitorización).

Decisión: Si es un upstream legítimo, crea una excepción controlada. Si no, aprieta y añade postscreen.

Tarea 9: Validar el estado de postscreen (si está habilitado)

cr0x@server:~$ systemctl status postfix@postscreen --no-pager
● postfix@postscreen.service - Postfix postscreen
     Loaded: loaded (/lib/systemd/system/postfix@.service; enabled)
     Active: active (running) since Fri 2026-01-02 08:14:03 UTC; 1 day ago

Significado: postscreen está en ejecución. Si tienes síntomas de inundación entrante y postscreen está caído, estás pagando el coste SMTP completo por cada bot.

Decisión: Si no está en ejecución, arregla la habilitación en master.cf y verifica que el puerto 25 esté enrutado hacia postscreen como corresponde.

Tarea 10: Inspeccionar límites de concurrencia actuales para entrega

cr0x@server:~$ postconf | egrep 'default_process_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_destination_recipient_limit'
default_process_limit = 100
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s
smtp_destination_recipient_limit = 50

Significado: Puedes estar topando con throttles de grandes proveedores porque entregas demasiado agresivo (rate_delay=0s) o con demasiada concurrencia.

Decisión: Si ves defer 421 desde un dominio, añade rate delay y reduce concurrencia para ese destino mediante transport maps.

Tarea 11: Detectar presión de CPU por TLS (un limitador oculto común)

cr0x@server:~$ top -b -n 1 | head -n 12
top - 09:13:01 up 12 days,  2:41,  1 user,  load average: 7.82, 6.90, 5.11
Tasks: 212 total,   3 running, 209 sleeping,   0 stopped,   0 zombie
%Cpu(s): 78.2 us,  3.1 sy,  0.0 ni, 18.3 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st

Significado: CPU alta con bajo IO wait sugiere trabajo compute-bound (handshakes TLS, filtros de contenido, llamadas a políticas). Limitar en SMTP puede ser el alivio más barato.

Decisión: Habilita postscreen y reduce trabajo costoso para clientes desconocidos; considera reutilización de sesiones TLS y cifrados sensatos más adelante.

Tarea 12: Confirmar que no te estás bloqueando con timeouts demasiado bajos

cr0x@server:~$ postconf | egrep 'smtpd_.*timeout|smtp_.*timeout'
smtpd_timeout = 60s
smtpd_helo_timeout = 30s
smtpd_client_connection_timeout = 10s
smtp_connect_timeout = 30s
smtp_data_done_timeout = 600s

Significado: Timeouts agresivos del servidor pueden matar remitentes legítimos lentos (especialmente sobre enlaces de alta latencia).

Decisión: Si ves muchos “lost connection after CONNECT/HELO” desde socios legítimos, sube los timeouts modestamente y confía en límites de concurrencia en su lugar.

Tarea 13: Verificar llamadas al servicio de política (y latencia) en logs

cr0x@server:~$ grep -E "check_policy_service|policy.*timeout|policyd" /var/log/mail.log | tail -n 6
Jan 03 09:11:22 mx postfix/smtpd[22010]: warning: problem talking to server 127.0.0.1:10031: Connection timed out
Jan 03 09:11:22 mx postfix/smtpd[22010]: NOQUEUE: reject: RCPT from mail.example.net[192.0.2.10]: 451 4.3.0 <127.0.0.1:10031>: Temporary lookup failure; from=<a@b> to=<c@d> proto=ESMTP helo=<mail.example.net>

Significado: Tu demonio de políticas es el cuello de botella; Postfix está deferiendo porque no puede obtener una decisión.

Decisión: Mejora rendimiento/disponibilidad del demonio de políticas o dispénsalo temporalmente para flujos críticos. No “resuelvas” esto subiendo límites de procesos smtpd; solo crearás un atasco mayor.

Tarea 14: Confirmar separación de servicios en master.cf (submission vs smtp)

cr0x@server:~$ postconf -Mf | egrep '^(smtp|submission|smtps)'
smtp/inet=smtp inet n - y - - smtpd
submission/inet=submission inet n - y - - smtpd
smtps/inet=smtps inet n - y - - smtpd

Significado: Los servicios existen. Pero la separación importa por las opciones por servicio, no solo por tener puertos abiertos.

Decisión: Aplica requisitos de auth más estrictos y límites por usuario en submission, y postscreen/anti-abuso más fuertes en smtp entrante.

Tres microhistorias corporativas desde el frente

Incidente #1: La suposición errónea (NAT es “un usuario”)

Una empresa mediana ejecutaba Postfix para correo saliente de empleados y MX entrante en la misma VM. Acababan de mudarse de oficina y, como muchas mudanzas, el equipo de red hizo un NAT “temporal” que se volvió permanente. Cientos de usuarios compartían una IP pública para submission.

El admin de correo notó un pequeño aumento en intentos de spam saliente (reales, pero no masivos). Reaccionaron rápido: ajustaron smtpd_client_message_rate_limit y smtpd_client_connection_rate_limit en el servicio de submission. Los números parecían generosos—si imaginas una persona por IP.

A las 09:00 del día siguiente, el helpdesk ardió. Clientes Outlook mostraban fallos intermitentes al enviar. Usuarios móviles vieron retrasos. La asistente del CEO descubrió que “reintentar más tarde” no es un mensaje satisfactorio para reservar vuelos.

Los logs fueron claros: “too many connections from [office public IP]”. El sistema no estaba bajo ataque. Estaba siendo usado normalmente, pero el limitador miraba la dimensión equivocada. Asumieron IP == usuario; la red demostró lo contrario.

La solución no fue “subir el límite hasta que paren las quejas”. Movieron controles de submission a identidad por SASL vía un servicio de políticas y añadieron un pequeño tope de concurrencia por IP como red de seguridad. El abuso se contuvo y los usuarios reales dejaron de tropezar entre sí.

Incidente #2: La optimización que salió mal (más concurrencia, más throttling)

Un proveedor SaaS enviaba correo transaccional—restauración de contraseñas, recibos, alertas—vía Postfix. La entregabilidad importaba. Alguien notó que la cola saliente se acumulaba en horas pico y hizo un movimiento clásico: aumentar default_process_limit y la concurrencia por destino para que la entrega “fuera más rápida”.

Fue más rápida—durante una hora. Luego la cola diferida empezó a llenarse con respuestas 421 de un gran proveedor de mail. Al proveedor no le molestaba el volumen por día; reaccionaba a la ráfaga y al churn de conexiones. Más concurrencia parecía comportamiento agresivo.

Llegaron tickets de soporte: “no recibo mi correo de restablecimiento”. Ingeniería, bajo presión, subió la concurrencia otra vez. Eso hizo que el proveedor aplicara más throttling. Es el equivalente de apretar repetidamente el botón del ascensor.

La solución fue lo aburrido: bajar la concurrencia por destino, introducir un pequeño smtp_destination_rate_delay para el dominio afectado y mantener el correo transaccional en un transporte priorizado. La cola se estabilizó y el proveedor dejó de cerrar la puerta.

La lección: la velocidad de entrega no es solo tu throughput. También es cómo los receptores perciben tu comportamiento. Limitar salientes es a veces la manera más rápida de entregar.

Incidente #3: La práctica correcta y aburrida que salvó el día (carriles separados)

Una compañía de servicios financieros aprendió de la forma dura que “un Postfix para gobernarlos a todos” se vuelve un único dominio de fallo. Ejecutaban instancias separadas de Postfix: una para MX entrante, otra para submission autenticado y otra para relays de aplicaciones internas. Mismos hosts, puertos distintos, políticas distintas, colas separadas.

Un viernes por la noche, una app legacy se volvió loca tras un despliegue. Empezó a generar notificaciones de alto volumen debido a un bucle. No era malintencionado, solo erróneo. Golpeó primero la instancia de relay interna.

Los límites en ese carril eran estrictos: topes por remitente y por credenciales de app, y las asignaciones de ráfaga eran pequeñas. La instancia de relay difirió el exceso y mantuvo su cola bajo control. El mail de la app se ralentizó, saltaron alertas y el on-call encontró el bug.

Mientras tanto, el envío de empleados siguió funcionando y el MX entrante siguió aceptando correo. Sin incidente visible al cliente. Sin decisión de “apagar todo” de emergencia. El sistema degradó en el lugar correcto.

Esto es lo que parece buena ingeniería: nada heroico, nada ingenioso, simplemente diseñado para contener fallos. Puedes llamarlo “exceso” hasta que te ahorre el fin de semana.

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

1) Síntoma: “Demasiadas conexiones” desde una IP, y es tu oficina

Causa raíz: Aplicaste límites de anvil por IP a una población detrás de NAT (tráfico de submission).

Solución: Limita por usuario SASL vía servicio de políticas; mantén un tope per-IP moderado para detener inundaciones reales.

2) Síntoma: Socios aleatorios se quejan de conexiones caídas

Causa raíz: Timeouts demasiado agresivos o tests de postscreen fallando MTAs legítimos (sistemas antiguos, alta latencia).

Solución: Aumenta modestamente los timeouts; haz whitelist de socios conocidos en las tablas de acceso de postscreen; mantén dureza para desconocidos.

3) Síntoma: La cola crece, mayormente diferida con 421/4.7.x de grandes proveedores

Causa raíz: Te están limitando; entregas muy en ráfaga o tu reputación está bajo sospecha.

Solución: Baja concurrencia por destino, añade rate delay y verifica fuentes salientes (cuentas comprometidas, tormentas de rebotes).

4) Síntoma: CPU se dispara durante oleadas de spam, aunque rechaces después

Causa raíz: Trabajo costoso (TLS, políticas, filtros de contenido) ocurre antes de que descartes la basura.

Solución: Usa postscreen para filtrar antes; reduce verificaciones costosas pre-auth; cachea o fortalece servicios de política.

5) Síntoma: Envíos masivos legítimos fallan (boletines, facturas)

Causa raíz: Usaste límites globales de destinatarios/mensajes sin carriles dedicados.

Solución: Crea una identidad/transporte separado para remitentes masivos con límites y monitorización explícita; no subas límites globales.

6) Síntoma: Usuarios ven fallos 451/4.3.0 intermitentes

Causa raíz: Timeouts del demonio de políticas o backend de base de datos sobrecargado.

Solución: Haz el servicio de políticas altamente disponible y rápido; implementa timeouts sensatos y decide intencionalmente fail-open/closed por servicio.

7) Síntoma: Entrega lenta aun con cola pequeña

Causa raíz: Estás limitando la concurrencia demasiado a nivel global (default_process_limit muy bajo), o un destino consume slots.

Solución: Balancea límites de procesos y límites por destino; aisla destinos problemáticos vía transportes.

8) Síntoma: Tras añadir limitación de tasas, recibes más quejas de spam

Causa raíz: Deferiste demasiado suavemente cuentas comprometidas en salientes, permitiendo spam sostenido en el tiempo.

Solución: Para submission autenticado, aplica topes duros por usuario más alertas y flujos de bloqueo automático.

Listas de verificación / plan paso a paso

Paso a paso: implementar límites salientes seguros para submission

1. Separar política del servicio de submission en master.cf (submission en puerto 587) con auth y TLS obligatorios.
2. Establecer topes de destinatarios para submission (proteger contra “un correo a mil”).
3. Implementar límites por SASL usando un demonio de políticas (recomendado) o al menos usar anvil con cautela.
4. Definir carriles de excepción para cuentas de automatización conocidas (alertas, facturación) con límites más altos explícitos.
5. Instrumentar logs: extraer top SASL users, top remitentes y recuentos de rechazo/defer.
6. Alertar sobre anomalías: picos repentinos por usuario, crecimiento repentino de la cola diferida, repetidos fallos de auth.
7. Ejecutar una prueba controlada: un usuario normal, una cuenta de automatización y un remitente sintético abusivo en staging si lo tienes.

Paso a paso: endurecer MX entrante sin bloquear remitentes reales

1. Habilitar postscreen si el volumen entrante lo justifica.
2. Aplicar límites moderados de concurrencia por cliente para evitar que un host acapare workers smtpd.
3. Usar comprobaciones de sanidad de protocolo: limitar destinatarios, requerir HELO correcto si procede y rechazar basura obvia temprano.
4. Preferir fallos temporales para ráfagas sospechosas, especialmente para clientes desconocidos.
5. Mantener una whitelist pequeña para socios conocidos con peculiaridades legítimas, pero revísala trimestralmente.
6. Revisar timeouts para no castigar MTAs legítimos de alta latencia.

Paso a paso: modelar la entrega saliente para evitar throttles de receptores

1. Medir defer por dominio (gmail, outlook, yahoo, partners corporativos).
2. Crear transportes por dominio para receptores problemáticos.
3. Bajar concurrencia y añadir rate delay donde veas deferrals 421/4.7.x.
4. Mantener tráfico transaccional priorizado vía cola/transporte separado si puedes.
5. Detener la hemorragia primero: si hay usuarios comprometidos, deshabilitarlos vence “tunear alrededor” del spam.

Preguntas frecuentes

1) ¿Debo limitar entradas o salidas primero?

Si gestionas submission autenticado, empieza con límites salientes por usuario. Las cuentas comprometidas son de alto impacto y destruyen reputación. Las inundaciones entrantes también son reales, pero suelen mitigarse más fácilmente con postscreen y límites de conexión.

2) ¿Cuál es la diferencia entre límites de conexión y límites de tasa de mensajes?

Los límites de conexión restringen cuántas sesiones puede mantener o abrir un cliente por unidad de tiempo. Los límites de tasa de mensajes restringen cuántos mensajes puede enviar el cliente. Los bots pueden ser eficientes: pocas conexiones, muchos mensajes. Normalmente necesitas ambos, pero aplícalos donde encajen con tu modelo de amenazas.

3) ¿Debería la limitación de tasas rechazar (5xx) o deferir (4xx)?

Para la mayoría de los casos de limitación: deferir (4xx). Ralentiza el abuso preservando la entregabilidad para remitentes legítimos. Usa reject para violaciones de política claras (intentos de open relay, destinatarios inválidos si los rechazas en RCPT, etc.).

4) ¿Por qué mis usuarios se bloquean cuando una IP supera el límite?

NAT. Hoteles, oficinas, redes móviles y algunas VPN concentran muchos usuarios detrás de una IP. No trates la IP como identidad para submission. Limita por nombre de usuario SASL o remitente.

5) ¿Puedo resolver el throttling de Gmail/Microsoft subiendo la concurrencia de Postfix?

No. Normalmente empeora. Cuando un receptor te limita, necesitas entregar con más cortesía: bajar concurrencia, añadir retardos y reducir volumen sospechoso.

6) ¿Es seguro habilitar postscreen en un MX de producción?

Sí, si pruebas y monitorizas. El riesgo son falsos positivos con remitentes inusuales. Empieza con ajustes conservadores y mantén una whitelist pequeña para socios importantes. No pongas en whitelist a Internet porque el MTA de un proveedor sea raro.

7) ¿Cómo limito por buzón sin un demonio de políticas?

Postfix puro es más fuerte en límites por cliente/IP vía anvil. Per-usuario necesita lógica de política. Sin ella, puedes aproximarlo usando servicios de submission separados (puertos distintos) y restricciones de clientes autenticados, pero es torpe. Si necesitas límites por usuario, usa un servicio de políticas.

8) ¿Qué métricas importan más para afinar límites?

Tamaño de la cola (activa vs diferida), razones de defer (especialmente 421/4.7.x), top SASL users por volumen, top IPs cliente y hits de logs de limitación. También monitorea tendencias de quejas/rebotes—el daño a la reputación se refleja ahí primero.

9) ¿Cómo evito romper envíos masivos legítimos?

Da a los remitentes masivos un carril separado con límites y monitorización explícita. No subas límites globales “solo para ellos”. Los límites globales son para Internet; los carriles son para excepciones de negocio.

Conclusión: qué hacer a continuación

Si quieres limitación de tasas que detenga abusos sin bloquear a usuarios reales, hazlo en este orden:

1. Mide: encuentra los mayores emisores (IP, usuario SASL, remitente) y lee las razones de defer/reject.
2. Separa carriles: MX entrante, submission autenticado y relays de aplicaciones no deberían compartir el mismo bucket de políticas.
3. Implementa límites conscientes de identidad: topes por usuario para submission; topes por IP para entrantes; modelado por destino para entrega.
4. Prefiere defer por exceso de tasa, y reserva rejects para violaciones reales de política.
5. Documenta tus excepciones y revísalas. Todo permiso permanente nace como un “temporal”.

La mayoría de incidentes de correo no los causa un atacante sofisticado. Los causan sistemas normales comportándose a escala anormal, más unas pocas suposiciones erróneas. La limitación de tasas es cómo haces que lo anormal sea soportable.