SMTP "421 Too many connections" o límite de envío: cómo solucionarlo

Qué significa

Una respuesta 421 significa "ahora no, inténtalo más tarde". El servidor receptor cierra la conexión porque abriste demasiadas a la vez o enviaste demasiado rápido. Es un error temporal: un servidor de correo normal conserva el mensaje y vuelve a intentarlo. En los servidores Postfix, el mensaje suele tener este aspecto:

421 4.7.0 mx.example.com Error: too many connections from 203.0.113.10

Otros servidores lo dicen de otra forma ("Too many concurrent SMTP connections", "Try again later, closing connection", "rate limited"). Un mensaje relacionado de Postfix es 450 4.7.1 Error: too much mail from 203.0.113.10 (límite de mensajes).

Algunos grandes proveedores tienen sus propios códigos, con sus propias guías: Gmail 421 4.7.28 y Microsoft 451 4.7.500; Yahoo tiene sus propios códigos TSS.

Por qué ocurre

• Demasiadas conexiones en paralelo. Tu aplicación o tu servidor abre muchas conexiones a la vez (una newsletter o un script que envía cada email en su propia conexión).
• Demasiados mensajes por minuto desde una misma IP o una misma cuenta.
• Reputación baja o nueva. Los receptores aceptan menos de las IP que no conocen, así que un volumen que no plantea problemas para una IP antigua activa los límites en una nueva.
• IP compartida. Otros clientes de la misma IP consumen parte del margen.
• Los límites de tu propio servidor, si es tu servidor el que responde 421 a tus aplicaciones o a un socio.
• Límites de la cuenta de envío. Los proveedores de buzones limitan las sesiones SMTP y los mensajes por cuenta; un 421 o 4.7.0 durante un envío grande desde un buzón normal es frecuente.

Cómo comprobarlo

1. Averigua quién responde. El nombre de host de la línea 421 te dice si es el servidor del destinatario, el relay de tu proveedor o tu propio servidor.
2. En tu Postfix emisor, mira los aplazamientos:

   postqueue -p | grep -i "too many" | sort | uniq -c
   grep "421" /var/log/mail.log | tail

3. En tu Postfix receptor, el servicio anvil registra los picos:

   grep "anvil" /var/log/mail.log | tail
   postconf smtpd_client_connection_count_limit smtpd_client_connection_rate_limit smtpd_client_message_rate_limit anvil_rate_time_unit

4. Comprueba la reputación: busca tu IP de envío en las listas negras y envía una prueba a la dirección única de la página de inicio de Delivmail. Un informe limpio significa que el límite tiene que ver con el volumen, no con un bloqueo.

Cómo solucionarlo

Si eres el remitente: envía más despacio

En una aplicación con nodemailer, reutiliza unas pocas conexiones en lugar de abrir una por mensaje:

const transporter = nodemailer.createTransport({
  host: 'smtp.example.com',
  port: 587,
  pool: true,          // reuse connections
  maxConnections: 2,   // parallel connections
  maxMessages: 100,    // messages per connection
  rateDelta: 1000,     // time window in ms
  rateLimit: 5,        // messages per window
  auth: { user: 'you@yourdomain.com', pass: process.env.SMTP_PASS }
});

Con Postfix, ralentiza solo el destino que se queja, con un transporte dedicado. En master.cf:

slow      unix  -       -       n       -       2       smtp

En main.cf:

transport_maps = hash:/etc/postfix/transport
slow_destination_concurrency_limit = 2
slow_destination_rate_delay = 1s

Y en /etc/postfix/transport, y después postmap /etc/postfix/transport y systemctl reload postfix:

example.com    slow:

Reparte las campañas grandes en el tiempo y, si tu IP o tu dominio son nuevos, aumenta el volumen poco a poco (consulta calentar un dominio o una IP nuevos). No vayas rotando IP o cuentas para saltarte los límites: los receptores lo detectan y perjudica tu reputación.

Si es tu propio servidor el que responde 421

Los valores por defecto (smtpd_client_connection_count_limit = 50 por cliente, límites de ritmo desactivados) sirven para la mayoría de los servidores. Si pusiste límites más estrictos, súbelos o excluye a los remitentes de confianza, como tus propias aplicaciones:

smtpd_client_event_limit_exceptions = $mynetworks, 203.0.113.10

Para las aplicaciones, una solución mejor es enviar por el puerto de submission con un grupo de unas pocas conexiones, como arriba.

Comprueba que está solucionado

Vigila el registro durante el siguiente envío: los mensajes aplazados deben salir de la cola con status=sent, y no deben aparecer nuevas líneas 421. Haz una nueva prueba en Delivmail para confirmar que la autenticación y la reputación están limpias, y reenvía a la dirección aplazada si al final rebotó.