El problema: Estás de guardia. Un cliente dice: “Su sistema nunca envió mi restablecimiento de contraseña.” Los registros de tu aplicación dicen que sí. Los registros de tu MTA muestran un 451. Y en algún punto entre “seguridad” y “correo electrónico”, el greylisting está haciendo en silencio lo que fue diseñado para hacer: ralentizar las cosas—a veces el correo malo, a veces el correo que paga tu salario.
El greylisting es una de esas herramientas operativas que se siente deliciosamente de baja tecnología: pide a remitentes desconocidos que vuelvan más tarde. La mayoría del spam no lo hace. Los MTAs legítimos sí. Perfecto. Hasta que tu equipo de finanzas pierde facturas, tus alertas de monitorización llegan después del incidente y tu proveedor de marketing te envía una captura de pantalla de su ajuste “reintentos desactivados” como si fuera tu problema.
Qué hace realmente el greylisting en la conexión
El greylisting no es detección de spam. Es una apuesta sobre el comportamiento del remitente.
La apuesta: los servidores de correo legítimos reintentará la entrega tras un fallo temporal; muchas infraestructuras de spam históricamente no lo hacían. Así que tratas a remitentes desconocidos como “posibles”, devuelves un error temporal (normalmente 451 4.7.1 o similar) y esperas a que el remitente lo intente de nuevo. En el reintento, aceptas.
El mecanismo: un triplete y un temporizador
El greylisting clásico rastrea un “triplete”:
- Dirección IP del remitente
- MAIL FROM (remitente de sobre)
- RCPT TO (destinatario de sobre)
La primera vez que ves un triplete, lo rechazas temporalmente. Si vuelve después de un “retraso mínimo” (por ejemplo 5–15 minutos), aceptas y a menudo lo añades a una lista blanca por un período (“auto-whitelist”).
Las variantes modernas ajustan la clave. Algunas usan solo IP del remitente, o IP + dominio del remitente, o incluyen HELO, o aprovechan reputación. Eso importa porque la entrega de correo en 2026 incluye pools de salida compartidos, NATs, relés SaaS, IPv6 y “dominios emisores” que no se mapean limpiamente a IPs estables.
Semántica SMTP: lo que puedes hacer
El greylisting se basa en el contrato SMTP: una respuesta 4xx es temporal; el remitente debe reintentar. Un 5xx es permanente; el remitente debe devolver el mensaje. El greylisting vive en el rango 4xx.
Una respuesta de greylist adecuada es específica pero no extensa:
451 4.7.1 Try again later450 4.2.0 Temporarily deferred
Quieres que el MTA del remitente reintente, no que decida que estás roto.
Dónde se sitúa en la canalización de correo
El greylisting suele aplicarse durante el tiempo de conexión SMTP, antes de aceptar los datos del mensaje. En Postfix, se implementa comúnmente como un servicio de política en smtpd_recipient_restrictions o smtpd_data_restrictions, según el demonio y el complemento. En Exim, puede hacerse mediante ACLs. En appliances, suele estar enterrado detrás de una casilla llamada “Aggressive anti-spam”, que es como sabes que será divertido.
La posición importa. Si aplicas greylisting demasiado pronto y de forma demasiado amplia, retrasarás mucho correo que de otro modo pasaría los filtros de contenido. Si lo haces demasiado tarde (después de DATA), ya habrás gastado ancho de banda y CPU en el spam que intentabas disuadir de forma barata.
Por qué funcionó (y por qué funciona menos ahora)
El atractivo original del greylisting era su asimetría: te costaba casi nada y costaba tiempo al remitente. Los motores de spam solían optimizarse para volumen y velocidad, no para persistencia. Muchos no reintentaban. Los MTAs legítimos sí. Boom: el spam bajaba.
Pero los atacantes leen los mismos RFC que tú. Hoy en día, mucho spam se envía desde infraestructuras “reales” (hosts comprometidos, IPs en la nube, cuentas de ESP abusadas) que reintentan correctamente. El greylisting sigue siendo útil, pero no es la guillotina del spam que fue a mediados de los 2000.
En otras palabras: el greylisting envejecería como un portero que era excelente identificando documentos falsos, pero menos efectivo cuando las identificaciones falsas empiezan a parecer reales. Sigue siendo útil en la puerta, no es un programa de seguridad completo.
Cuándo ayuda el greylisting en 2026
El greylisting ayuda cuando tu modelo de amenazas incluye una proporción significativa de remitentes que no reintentan o reintentan mal, y cuando un retraso de entrega de unos minutos es aceptable para la mayoría del correo entrante.
1) Organizaciones pequeñas y medianas con spam entrante abundante
Si tu dominio recibe mucho junk directo a MX, el greylisting todavía puede recortar a los emisores de bajo nivel. Especialmente si no tienes una pila de filtrado de gran presupuesto. La mejor parte no es el “bloqueo perfecto”. Es la reducción en lo que el resto de tu canal debe procesar.
2) Servidores de correo con CPU limitada para escaneo de contenido
Si ejecutas SpamAssassin, Rspamd, antivirus, análisis de adjuntos en sandbox o DLP, cualquier cosa que reduzca los mensajes que alcanzan esas etapas puede ser una ventaja. El greylisting pospone remitentes desconocidos antes de que gastes ciclos.
3) MX de solo entrada con remitentes legítimos predecibles
Algunos dominios reciben correo principalmente de grandes proveedores y un conjunto conocido de socios. El greylisting con una lista blanca sensata (grandes proveedores, socios, tu proveedor de tickets, tu proveedor de nómina, etc.) puede dar beneficios con menos tickets de “por qué llega tarde el itinerario del CEO”.
4) Como freno temporal durante un pico de abuso
El greylisting puede ser un estrangulador a corto plazo. Si estás bajo una avalancha de spam, habilitar o endurecer el greylisting puede ganar tiempo mientras implementas controles mejores (ajuste de DNSBL, límites de tasa, decisiones sobre alineación DMARC, etc.). No es bonito, pero tampoco lo es un buzón lleno de malware.
Broma #1: El greylisting es como decirle a tu correo “Deja un mensaje después del tono”, excepto que el tono es un RFC y el mensaje son 40.000 estafas cripto idénticas.
Cuándo perjudica el greylisting (y cómo falla)
El greylisting perjudica cuando el correo que te importa es sensible al tiempo, cuando los remitentes no reintentan como esperas, o cuando tu propia configuración hace que “primera vez” ocurra una y otra vez por accidente.
El correo sensible al tiempo ya no es opcional
Restablecimientos de contraseña, códigos MFA, enlaces de verificación de cuenta, alertas de fraude, notificaciones de pager, escalados de guardia, confirmaciones de compra, invitaciones de calendario—estos a menudo se usan en flujos donde humanos miran la pantalla esperando.
Un retraso de 10 minutos no es “una pequeña molestia”. Es un flujo roto. Los usuarios no lo interpretan como “el antispam está funcionando”. Lo interpretan como “tu producto es poco fiable”. No están equivocados.
El comportamiento de reintento es menos uniforme de lo que piensas
SMTP dice reintentar. No dice qué tan rápido, con qué frecuencia o desde qué IP.
- Algunos sistemas reintentan tras 1 minuto; otros tras 30.
- Algunos reintentan desde una IP saliente diferente (pools grandes).
- Algunos usan un remitente de sobre distinto (patrones VERP de bounce).
- Algunas plataformas SaaS ponen SMTP detrás de APIs HTTP y luego entregan vía un relé que se comporta “más o menos como SMTP” pero con peculiaridades de política.
Si la clave de tu greylisting es demasiado estricta (por ejemplo, IP + MAIL FROM completo + RCPT TO), un remitente que reintenta desde una IP distinta o con una dirección de bounce diferente puede nunca coincidir con el triplete original. Acabas de inventar una máquina de aplazamientos infinita.
NAT, direcciones de privacidad IPv6 y pools de salida
El greylisting asume cierta estabilidad en la identidad del remitente. Los pools de salida están diseñados para lo contrario: distribuir tráfico y conmutar por error de forma suave. IPv6 a menudo rota direcciones (extensiones de privacidad) y los grandes proveedores pueden usar subredes masivas.
Como resultado, “primera vez que vemos esta IP” puede convertirse en “primera vez cada vez”. Si greylisteas solo por IP, castigarás a remitentes con pools grandes. Si greylisteas por demasiados campos, castigarás a remitentes que varían esos campos.
El greylisting rompe la monitorización y la respuesta a incidentes
El correo de alertas suele ser el más sensible a la latencia que tienes. Y es el correo que más probablemente provenga de IPs con aspecto aleatorio (proveedores de monitorización en la nube, sistemas multi-tenant). El greylisting empeora la respuesta a incidentes de una manera que solo se muestra durante los incidentes. Que es cuando tu paciencia está en su punto más bajo y las expectativas de tus stakeholders en su punto más alto.
El greylisting en la capa de política puede enmascarar problemas reales de entregabilidad
Si un socio se queja “nos siguen dando 451”, podrías culpar al greylisting y añadirlo a la lista blanca. A veces eso es correcto. A veces tu propio MX está limitando por tasa, tu DNS es lento, tu política TLS es demasiado estricta o tus comprobaciones de rDNS están rechazando. El greylisting puede ser el síntoma más ruidoso mientras el cuello de botella real está en otro sitio.
Broma #2: Nada te hace sentir vivo como explicar “el rechazo temporal es normal” a un ejecutivo que solo entiende “perdimos dinero”.
Datos interesantes y contexto histórico
- El greylisting se popularizó a principios y mediados de los 2000 como una contra medida ligera cuando los motores de spam a menudo no reintentaban tras respuestas
4xx. - Se basa en el diseño original SMTP de store-and-forward: se esperan fallos temporales y las colas son parte de la operación “normal” del correo.
- RFC 5321 no dicta tiempos de reintento; los remitentes eligen sus propios calendarios de backoff, por eso el retraso del greylisting es impredecible entre proveedores.
- El auto-whitelist se introdujo para reducir retrasos repetidos, almacenando tripletes exitosos por días o semanas para que remitentes conocidos no vuelvan a ser greylisteados.
- Los grandes emisores usan pools de IP salientes para capacidad y gestión de reputación; el greylisting estricto por IP choca con ese diseño.
- Algunas operaciones de spam se adaptaron implementando reintentos, reduciendo la efectividad del greylisting como único control antispam.
- El greylisting puede actuar como un limitador de tasa primitivo, reduciendo indirectamente la churn de conexiones entrantes durante picos de spam al forzar reintentos.
- Un greylisting mal claveado puede crear bucles de “nunca aceptar” cuando los remitentes reintentan con un remitente de sobre diferente (VERP) o diferente IP en cada intento.
- Los grandes proveedores a veces pre-calientan o pre-validan flujos (como entregas “probe”); el greylisting puede retrasar o complicar estas comprobaciones de saneamiento.
Guion rápido de diagnóstico
Este es el guion que ejecutas cuando alguien dice “el correo está retrasado” y necesitas encontrar el cuello de botella antes de que expire la invitación a la reunión.
Primero: confirma que realmente es greylisting, no una cola o un problema DNS
- Busca deferrals
4xxcon marcadores de “greylist” en los logs del MTA (servicio de política Postfix, mensaje ACL Exim, etiqueta del appliance). - Comprueba si el remitente reintentó y si el reintento coincidió con la clave del greylist (¿misma IP? ¿mismo remitente de sobre?).
- Revisa la distribución de antigüedad de la cola de correo: si todo está diferido, podrías tener un bloqueo general saliente/entrante no relacionado con greylisting.
Segundo: determina el alcance e impacto
- ¿Es un solo dominio remitente (socio/proveedor) o muchos?
- ¿Es correo sensible al tiempo (auth, monitorización, facturación) o de baja prioridad (boletines)?
- ¿Solo algunos destinatarios se ven afectados (p. ej., alias específicos con ruteos distintos)?
Tercero: realiza un cambio inmediato seguro
- Añade a la lista blanca al remitente conocido y bueno temporalmente (dominio/rango IP, con expiración si tu herramienta lo soporta).
- Reduce la ventana de retraso mínima si te está perjudicando globalmente (pero no la pongas casi a cero; solo enfadarás a remitentes sin filtrar mucho).
- Corrige la clave si detectas desajuste por pool de IP: usa un tuple menos frágil (a menudo IP + dominio remitente, o aprovecha SPF/HELO con cuidado).
Cuarto: captura evidencia para el postmortem
- Extrae una línea temporal: primer intento, rechazo por greylist, intentos de reintento, tiempo de aceptación.
- Registra las IPs del remitente usadas en los reintentos.
- Anota si tu MX usa múltiples frontends y si el estado de greylist se comparte.
Una cita de fiabilidad pertenece aquí porque es el punto entero de operar correo: “La esperanza no es una estrategia.”
— idea parafraseada usada con frecuencia en operaciones e ingeniería.
Tareas prácticas: comandos, salidas y decisiones
Estas son tareas prácticas que puedes ejecutar en un MX Linux basado en Postfix (o adaptar a tu pila). Cada una incluye: comando, salida realista, qué significa y qué decides a continuación.
Task 1: Find greylisting deferrals in Postfix logs
cr0x@server:~$ sudo grep -E "greylist|Greylist|4\.7\.1|temporar" /var/log/mail.log | tail -n 6
Jan 03 09:41:12 mx1 postfix/smtpd[22107]: NOQUEUE: reject: RCPT from mail-ot1-f45.google.com[209.85.210.45]: 451 4.7.1 Service unavailable - try again later; from=<alerts@partner.example> to=<oncall@example.com> proto=ESMTP helo=<mail-ot1-f45.google.com>
Jan 03 09:41:12 mx1 postfix/smtpd[22107]: warning: greylist: triplet blocked (209.85.210.45, alerts@partner.example, oncall@example.com)
Jan 03 09:48:58 mx1 postfix/smtpd[22301]: NOQUEUE: accept: RCPT from mail-ot1-f45.google.com[209.85.210.45]: 250 2.1.5 Ok; from=<alerts@partner.example> to=<oncall@example.com> proto=ESMTP helo=<mail-ot1-f45.google.com>
Significado: Esto es greylisting clásico: primer intento rechazado con 451, luego aceptado.
Decisión: Si el retraso es aceptable y limitado a remitentes desconocidos, mantenerlo. Si afecta a correo de alertas o autenticación, añade a la whitelist ese remitente o evita greylisting para ese grupo de destinatarios.
Task 2: Confirm what policy services are active (Postfix)
cr0x@server:~$ sudo postconf -n | grep -E "smtpd_(recipient|data)_restrictions|check_policy_service"
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, permit
Significado: Se consulta un servicio de política en la etapa de destinatario; ahí es donde probablemente está implementado el greylisting.
Decisión: Si haces troubleshooting, mueve temporalmente la política más tarde/antes o añade excepciones (p. ej., omitir para ciertos clientes) en lugar de eliminarla a ciegas.
Task 3: Test the greylist policy response directly (netcat to policy port)
cr0x@server:~$ printf "request=smtpd_access_policy\nprotocol_state=RCPT\nprotocol_name=SMTP\nclient_address=209.85.210.45\nsender=alerts@partner.example\nrecipient=oncall@example.com\n\n" | nc -w 2 127.0.0.1 10023
action=defer_if_permit 451 4.7.1 Greylisted, please try again later
Significado: El servicio de política está efectivamente greylisteando y diferiría ese triplete ahora mismo.
Decisión: Si ese remitente es crítico para el negocio, añádelo al mecanismo de whitelist del servicio de política (dominio/IP) y vuelve a probar.
Task 4: Check if greylist state is shared across MX frontends
cr0x@server:~$ sudo postconf -n | grep -E "proxy_read_maps|smtpd_policy_service"
proxy_read_maps =
Significado: Esto no prueba que el estado se comparta, pero sugiere que podrías no estar proxyeando búsquedas. Muchos demonios de greylist usan SQLite local. Si tienes varios nodos MX detrás de un balanceador, cada nodo puede “aprender” por separado.
Decisión: Si tienes múltiples MX, confirma que el backend de greylist está centralizado (Redis/SQL) o usa hashing consistente / stickiness basada en remitente. De lo contrario obtendrás deferrals repetidos cuando los reintentos lleguen a un nodo distinto.
Task 5: Inspect mail queue for deferred messages (Postfix)
cr0x@server:~$ sudo postqueue -p | head -n 18
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C21A0B7* 2190 Fri Jan 3 09:38:02 alerts@partner.example
oncall@example.com
(host mx1[127.0.0.1] said: 451 4.7.1 Greylisted, please try again later (in reply to RCPT TO command))
9A77F1B9CC 1046 Fri Jan 3 09:37:11 billing@vendor.example
ap@corp.example
(connect to mx.remote.example[203.0.113.40]:25: Connection timed out)
Significado: Tienes al menos un diferido debido a greylisting y otro por problemas de red saliente. No todo el retraso es greylisting.
Decisión: Divide el incidente: arregla la política de greylisting para diferidos entrantes; arregla red/DNS/ruteo para timeouts salientes. No culpes a un solo mecanismo por todo.
Task 6: Identify the oldest deferred messages to gauge user impact
cr0x@server:~$ sudo postqueue -p | awk 'BEGIN{RS="";FS="\n"} {print $0 "\n---"}' | grep -E "Arrival Time|Greylist|Queue ID" | head -n 30
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C21A0B7* 2190 Fri Jan 3 09:38:02 alerts@partner.example
(host mx1[127.0.0.1] said: 451 4.7.1 Greylisted, please try again later (in reply to RCPT TO command))
---
Significado: Las marcas de tiempo de la cola te dicen si esto es una molestia de 5 minutos o una caída de una hora.
Decisión: Si las edades de los diferidos exceden tu latencia aceptable (para alertas/auth eso podría ser 1–2 minutos), debes omitir greylisting para esos flujos inmediatamente.
Task 7: Verify DNS resolution latency (slow DNS looks like mail delay)
cr0x@server:~$ time dig +tries=1 +timeout=2 mx partner.example
;; ANSWER SECTION:
partner.example. 300 IN MX 10 mx.partner.example.
real 0m0.412s
user 0m0.018s
sys 0m0.010s
Significado: La resolución DNS es rápida aquí. Si ves tiempos de varios segundos o timeouts, podrías estar bloqueando sesiones SMTP, lo que puede combinarse mal con greylisting y límites de conexión.
Decisión: Si el DNS es lento, arregla la ruta del resolvedor/caching antes de ajustar el greylisting. Si no, atribuirás retrasos por error.
Task 8: Check whether postscreeen or connection throttling is also in play
cr0x@server:~$ sudo postconf -n | grep -E "^postscreen|smtpd_client_connection_rate_limit"
postscreen_greet_action = enforce
smtpd_client_connection_rate_limit = 30
Significado: Estás usando controles a nivel de conexión además de greylisting. Bien. Pero el efecto combinado puede ser “el remitente legítimo se ralentiza dos veces”.
Decisión: Si el correo legítimo se retrasa, considera eximir a remitentes conocidos del postscreen/greeting delay y del greylisting, en lugar de aflojar todo globalmente.
Task 9: Confirm your greylisting exception/whitelist files are actually loaded
cr0x@server:~$ sudo grep -R "whitelist" /etc/postfix | head -n 8
/etc/postfix/main.cf:smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, permit
/etc/postfix/greylist-whitelist:partner.example
/etc/postfix/greylist-whitelist:203.0.113.0/24
Significado: Tienes un archivo de lista blanca, pero eso no prueba que el demonio de greylist lo lea.
Decisión: Encuentra la configuración del servicio de greylist y asegúrate de que referencia ese archivo; de lo contrario estás editando un placebo reconfortante.
Task 10: Inspect systemd service status for the greylist daemon
cr0x@server:~$ sudo systemctl status postgrey --no-pager
● postgrey.service - Postgrey greylisting policy server
Loaded: loaded (/lib/systemd/system/postgrey.service; enabled)
Active: active (running) since Fri 2026-01-03 07:12:11 UTC; 2h 34min ago
Main PID: 1189 (postgrey)
Memory: 42.1M
CGroup: /system.slice/postgrey.service
└─1189 /usr/sbin/postgrey --inet=127.0.0.1:10023 --delay=300
Significado: El retraso de greylisting es 300 segundos (5 minutos). El servicio está en ejecución.
Decisión: Si tu negocio requiere correo casi instantáneo, 5 minutos puede ser ya demasiado a menos que tengas listas blancas estrictas para flujos sensibles.
Task 11: Validate the sender’s retry pattern from logs (did they retry? from where?)
cr0x@server:~$ sudo grep -E "from=.*vendor\.example|client=.*203\.0\.113" /var/log/mail.log | tail -n 8
Jan 03 09:10:01 mx1 postfix/smtpd[21001]: NOQUEUE: reject: RCPT from relay1.vendor.example[203.0.113.10]: 451 4.7.1 Greylisted, please try again later; from=<bounce+ab12@vendor.example> to=<ap@corp.example>
Jan 03 09:25:44 mx1 postfix/smtpd[21477]: NOQUEUE: reject: RCPT from relay2.vendor.example[203.0.113.22]: 451 4.7.1 Greylisted, please try again later; from=<bounce+cd34@vendor.example> to=<ap@corp.example>
Jan 03 09:41:05 mx1 postfix/smtpd[22192]: NOQUEUE: reject: RCPT from relay3.vendor.example[203.0.113.35]: 451 4.7.1 Greylisted, please try again later; from=<bounce+ef56@vendor.example> to=<ap@corp.example>
Significado: El remitente está reintentando, pero cada reintento proviene de una IP diferente y de una dirección de bounce distinta (VERP). Si la clave de tu greylist incluye IP y MAIL FROM completo, nunca pasarán.
Decisión: Afloja la clave (por ejemplo, dominio remitente + destinatario) o añade a la lista blanca los dominios/rangos IP del proveedor. Esto es un desajuste estructural, no “dale más tiempo”.
Task 12: Measure whether your greylist database is growing out of control
cr0x@server:~$ sudo ls -lh /var/lib/postgrey
total 96M
-rw------- 1 postgrey postgrey 95M Jan 3 09:30 postgrey.sqlite
-rw-r--r-- 1 root root 1.2K Dec 12 14:02 whitelist_clients.local
Significado: La BD tiene 95MB. Eso no es intrínsecamente malo, pero el crecimiento puede afectar el rendimiento si el host es limitado en recursos o el almacenamiento es lento.
Decisión: Si ves gran crecimiento más alto I/O wait, considera podar/configurar aging, mover a un disco más rápido o cambiar el backend a Redis/SQL si necesitas estado compartido.
Task 13: Check I/O wait and disk latency (because policy lookups hit disk)
cr0x@server:~$ iostat -xz 1 2
Linux 6.6.0 (mx1) 01/03/2026 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
3.21 0.00 1.12 18.44 0.00 77.23
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
nvme0n1 2.10 64.0 0.00 0.00 1.21 30.5 58.2 2200.0 19.80 1.15 92.4
Significado: Alto iowait y alta utilización del dispositivo. Si tu política de greylist usa SQLite en este disco, las decisiones de política pueden ralentizar las sesiones SMTP, aumentando timeouts y churn de conexiones.
Decisión: Arregla el rendimiento del almacenamiento (mueve la BD a disco más rápido, ajusta retención o cambia backend). Greylisting que hace lento tu servidor SMTP es autolesión.
Task 14: Confirm the actual SMTP response with a live session
cr0x@server:~$ nc -w 3 mx1.example.com 25
220 mx1.example.com ESMTP Postfix
EHLO test.example
250-mx1.example.com
250-PIPELINING
MAIL FROM:<alerts@partner.example>
250 2.1.0 Ok
RCPT TO:<oncall@example.com>
451 4.7.1 Service unavailable - try again later
QUIT
221 2.0.0 Bye
Significado: La etapa RCPT es donde ocurre el rechazo temporal. Esto concuerda con la ubicación de la restricción de política.
Decisión: Si necesitas excepciones, impleméntalas en la misma etapa (restricciones de destinatario) para evitar interacciones sorprendentes.
Tres microhistorias del mundo corporativo
Microhistoria 1: El incidente causado por una suposición errónea
La empresa operaba un portal de clientes con restablecimientos de contraseña por correo. El equipo SRE heredó un MX on-prem, y un viejo playbook anti-spam recomendaba greylisting porque “corta el spam en un 80%”. Esa frase se volvió un talismán. Nadie hizo la segunda pregunta: “¿80% de qué, y a qué coste?”
Durante un pico de tráfico un lunes por la mañana—anuncio de producto, muchas inscripciones—el flujo de restablecimientos de contraseña empezó a “fallar aleatoriamente”. Soporte vio tickets: usuarios solicitaron un restablecimiento, no lo recibieron, solicitaron otra vez, nada. Ingeniería comprobó los logs de la app: los restablecimientos se generaron y se enviaron al MTA. Culparon al proveedor de correo. Tenían media razón, en la forma que mantiene los incidentes vivos.
En los logs de correo, cada restablecimiento fue greylisteado en el primer contacto. Eso era esperado. La suposición errónea fue que los reintentos vendrían desde la misma identidad remitente. El correo de restablecimiento provenía en realidad de un relé SaaS con un gran pool de IPs y remitentes de sobre variables. Cada reintento parecía nuevo. El greylisting no estaba retrasando la entrega; la estaba impidiendo indefinidamente.
El daño operativo del incidente vino por el ciclo lento de darse cuenta. La gente esperaba “unos minutos más” porque eso hace el greylisting. Cuando diseñas un sistema donde la falla parece un retraso normal, has construido un mentiroso. Para cuando añadieron a la whitelist el rango de relés del proveedor y relajaron el tuple a coincidencia por dominio, la ventana de inscripciones había pasado y el equipo de marketing ya culpaba a “infra”.
La solución fue poco glamorosa: un bypass específico para los dominios remitentes de restablecimiento de contraseña y una regla de que cualquier correo ligado a flujos de autenticación no debe ser greylisteado. Además, un harness de pruebas que hace una inyección SMTP real desde el pool del proveedor en staging. La lección real: nunca trates las propiedades de entrega de correo como estables entre proveedores.
Microhistoria 2: La optimización que salió mal
Otra organización tuvo un clásico proyecto de “podemos ahorrar dinero”: consolidar dos nodos MX en una VM más grande con CPU más rápida, mantener los mismos controles anti-spam y listo. El greylisting se quedó. Incluso lo endurecieron: ventana de retraso más larga, auto-whitelist más prolongada, tuple más estricta. “Reduciremos el junk y la CPU de escaneo,” dijeron.
Durante una semana pareció genial. El volumen de spam bajó. La CPU bajó. El informe semanal parecía un triunfo.
Entonces llegó el cierre trimestral. Cuentas por pagar se quejaron de que las facturas de algunos proveedores llegaban horas tarde. No rebotadas. No desaparecidas. Simplemente lo suficientemente tarde como para causar fricción en el flujo de pagos y llamadas que justificaban una escalación.
La optimización tenía dos costes ocultos. Primero, la VM más grande corría sobre almacenamiento compartido con vecinos ruidosos; la base de datos de greylist vivía en ese almacenamiento y las consultas de política empezaron a bloquearse bajo carga. Segundo, el tuple más estricto significaba que proveedores que usan direcciones VERP nunca coincidían con intentos previos. El correo llegaba eventualmente, pero solo después de suficientes reintentos que coincidieran con una combinación estable de IP y remitente de sobre. No era determinista; era ruleta.
Revirtieron el tuple más estricto y movieron el backend de greylist a Redis en NVMe local. El CPU de escaneo de spam subió un poco, pero la latencia de facturas volvió a ser aburrida. Ese es el intercambio correcto en la mayoría de entornos corporativos: gasta cómputo para mantener el correo de negocio puntual. El cómputo es más barato que la confianza.
Microhistoria 3: La práctica aburrida pero correcta que salvó el día
Una tercera empresa operaba su propio MX como gateway de entrada delante de un proveedor de buzones alojado. Tenían greylisting habilitado, pero lo trataban como un componente controlado por cambios, no como una configuración folclórica. El equipo de correo mantenía una pequeña “lista de remitentes críticos”: monitorización, RRHH/nómina, proveedor SSO, sistema de tickets y principales proveedores. Cada entrada tenía un propietario, una razón y una fecha de revisión. Aburrido. Eficaz.
Una tarde, un evento regional de red causó pérdida de paquetes intermitente a uno de sus nodos MX. El balanceador siguió enviando algo de tráfico al nodo defectuoso. Normalmente, eso ya es bastante malo. Con greylisting, puede ser peor: el primer intento llega al nodo roto y es diferido por timeouts, el reintento llega al nodo sano y se trata como “nuevo”, es greylisteado, luego los reintentos rebotan entre nodos. De repente, has construido un amplificador de retrasos.
Pero como centralizaron el estado de greylist (backend compartido) y tenían checks de salud que sacaban el nodo roto rápido, el radio del impacto se mantuvo pequeño. Su diagnóstico rápido no fue conjetura: la edad de la cola se mantuvo dentro de su SLA; los logs mostraron un patrón limpio; los remitentes críticos evitaban el greylisting por completo. Incidente resuelto antes de que alguien fuera de TI lo notara.
La práctica que “salvó el día” no fue un filtro ML elegante. Fue: estado compartido, listas blancas con propiedad y un check de salud del balanceador que representara realmente la usabilidad SMTP, no solo “puerto 25 abierto”. Lo aburrido es una característica.
Errores comunes (síntomas → causa raíz → solución)
1) Síntoma: Los correos de restablecimiento de contraseña llegan con 10–30 minutos de retraso (o nunca)
Causa raíz: Greylisting aplicado al correo transaccional desde relés SaaS con grandes pools de IP y remitentes de sobre variables; el tuple nunca coincide.
Solución: Omitir greylisting para dominios/IPs remitentes transaccionales; aflojar la clave (por dominio) si tu herramienta lo soporta; o deshabilitar greylisting en el MX que maneja flujos transaccionales.
2) Síntoma: El socio dice “nos siguen dando 451” y aporta logs de intentos repetidos
Causa raíz: La ventana mínima de retraso es más larga que su calendario de reintentos, o reintentan desde IPs distintas cada vez y tú claveas estrictamente.
Solución: Reduce el retraso mínimo a 60–180 segundos para desconocidos; añade al socio a la whitelist; ajusta el tuple.
3) Síntoma: Retrasos repetidos de “primera vez” desde grandes proveedores (Gmail, Microsoft)
Causa raíz: El greylisting basado en IP penaliza pools de salida; cada mensaje viene de una IP “nueva”.
Solución: Añade a la whitelist rangos IP de grandes proveedores con cautela (o permite autenticación si tu gateway lo soporta). Alternativamente, no greylistees a estos proveedores y confía en otras capas de filtrado/reputación.
4) Síntoma: El correo a veces pasa inmediatamente, a veces se retrasa, con múltiples nodos MX
Causa raíz: El estado de greylist es local por nodo; los reintentos aterrizan en un nodo distinto y se tratan como nuevos.
Solución: Centraliza el estado de greylist (DB/Redis compartido) o usa stickiness del balanceador por IP remitente. Mejor: centraliza el estado.
5) Síntoma: Los picos de conexiones entrantes hacen que los MTAs remotos hagan timeout
Causa raíz: Greylisting más backend de política lento causa sesiones SMTP largas; los MTAs remotos abren más conexiones paralelas; tu servidor alcanza límites de conexión; caos.
Solución: Arregla el rendimiento del backend (disco/I/O), reduce el coste de las búsquedas de política, ajusta límites de concurrencia y acorta el tiempo SMTP por sesión.
6) Síntoma: El volumen de spam baja, pero aumentan las quejas por facturas tardías
Causa raíz: El greylisting está haciendo su trabajo, pero no eximiste remitentes críticos; además, los proveedores de AP a menudo usan relés peculiares.
Solución: Mantén una whitelist “crítica para el negocio” con propiedad y mide la latencia de entrega para esos dominios.
7) Síntoma: El greylisting parece inefectivo; el spam sigue llegando
Causa raíz: Los spammers modernos reintentan correctamente; tu greylisting solo añade retraso a todos.
Solución: Reduce la dependencia del greylisting; invierte en comprobaciones de reputación, filtrado de contenido, decisiones sobre DMARC y límites de tasa.
Listas de verificación / plan paso a paso
Checklist A: Decide si deberías usar greylisting
- Inventaria los flujos de correo sensibles al tiempo: auth, monitorización, tickets, finanzas, legal. Si no puedes listarlos, asume que existen y que importan.
- Mide la composición del spam entrante: directo a MX vs reenviado; cuánto se detiene por otros controles.
- Estima la latencia aceptable: define objetivos por clases (alertas: <2 minutos; restablecimiento contraseña: <1 minuto; boletines: lo que sea).
- Evalúa la diversidad de remitentes: ¿muchos remitentes pequeños con MTAs estables? El greylisting podría ayudar. ¿Mayormente grandes proveedores y SaaS? El greylisting probablemente te molestará.
- Decide tu política: “greylistea remitentes desconocidos directos a MX excepto categorías en lista blanca” es un punto medio razonable.
Checklist B: Implementa greylisting sin dispararte en el pie
- Elige un retraso mínimo conservador: 60–180 segundos si tienes un entorno moderno; 300 segundos suele ser demasiado para flujos transaccionales.
- Habilita auto-whitelisting con TTL sensato (días a semanas), para que los corresponsales normales no se retrasen repetidamente.
- Centraliza el estado si tienes más de un MX.
- Listas blancas con propiedad: cada entrada tiene un propietario y una fecha de revisión. Si no, se convertirá en un vertedero.
- Omisión para flujos críticos: remitentes de monitorización, SSO, proveedores de restablecimiento, proveedores de finanzas. Regla dura: el correo de autenticación no debe ser greylisteado.
- Instrumenta la latencia: registra y grafica “primera vez visto” → “aceptado”. Si no mides, discutirás anécdotas.
Checklist C: Responde a un incidente relacionado con greylisting
- Confirma: busca
451en logs con etiqueta de greylist. - Revisa el comportamiento de reintentos del remitente: ¿misma IP? ¿mismo remitente de sobre? ¿mismo nodo MX?
- Añade inmediatamente a la lista blanca al remitente crítico para el negocio.
- Reduce la ventana de retraso si el impacto es amplio.
- Arregla perpetuamente la clave/compartición de estado.
- Escribe: qué correo se retrasó, para quién y cuánto tiempo.
Preguntas frecuentes
1) ¿El greylisting es “seguro” desde la perspectiva de seguridad?
No es un control de seguridad en el sentido clásico. Es un mecanismo de modelado de tráfico. Puede reducir la exposición a spam de bajo esfuerzo, pero no detendrá phishing dirigido o remitentes legítimos comprometidos.
2) ¿Cuánto debe ser el retraso de greylisting?
Para la mayoría de entornos modernos: 60–180 segundos es el rango práctico. Retrasos más largos perjudican los flujos de usuarios y no aumentan de forma fiable la efectividad contra el spam moderno.
3) ¿Por qué algunos remitentes legítimos nunca pasan?
Porque tu clave es demasiado estricta o tu estado no está compartido. Si el remitente reintenta desde IPs diferentes o cambia el remitente de sobre, el “mismo triplete” nunca se repite y tu sistema los tratará siempre como nuevos.
4) ¿Debo greylistear Gmail/Microsoft?
Normalmente no. Reintentan correctamente, pero usan pools de salida. Principalmente introducirás retraso sin reducción significativa de spam. Ponlos en la whitelist o confía en otras capas de filtrado.
5) ¿El greylisting ayuda contra botnets?
A veces. Remitentes de botnets de baja calidad podrían no reintentar. Pero muchos sí lo hacen ahora. Considera el greylisting como una capa menor, no como la base.
6) ¿Dónde en Postfix debería aplicarse el greylisting?
Típicamente vía check_policy_service en smtpd_recipient_restrictions. Eso rechaza antes de DATA, ahorrando recursos. Pero aplica excepciones con cuidado, especialmente para redes confiables y dominios remitentes críticos.
7) ¿El greylisting puede causar correos duplicados?
Indirectamente, sí. Si un remitente agota el timeout, reintenta agresivamente o la aplicación reenvía porque no obtuvo una señal rápida de “entregado”, puedes ver duplicados. El greylisting no es la única causa, pero puede contribuir.
8) ¿Qué métricas debo monitorizar si habilito greylisting?
Monitorea: número de diferidos 4xx por motivo, conteo de aceptados tras greylist, mediana y p95 del retraso desde primer intento hasta aceptación, y concurrencia de conexiones entrantes. También vigila latencia del backend de políticas y I/O de disco.
9) ¿Es apropiado el greylisting para correo saliente?
No. El greylisting es una política entrante para tu MX. La entregabilidad saliente depende de tu reputación, autenticación (SPF/DKIM/DMARC) y manejo de errores—es otro juego.
10) ¿Cuál es la forma más limpia de eximir “correo crítico”?
Sepáralo por dominio/IP remitente, por grupo de destinatarios o enrutando flujos críticos por un camino de política MX distinto. La clave es: las exenciones deben ser explícitas, revisadas y probadas.
Siguientes pasos que puedes realizar esta semana
- Clasifica tu correo: lista los 20 dominios remitentes principales por impacto en el negocio, no por volumen. Alertas, auth, finanzas, tickets, viajes ejecutivos—sí, de verdad.
- Ejecuta la búsqueda en logs de
451y calcula retrasos para esos remitentes críticos. Si no puedes calcularlo, muestrea manualmente por marcas de tiempo. - Arregla problemas estructurales primero: si tienes múltiples nodos MX y estado local de greylist, centralízalo. Si tu backend de política está en disco lento, muévelo.
- Configura un retraso sensato: si estás en 300 segundos, considera 120 segundos y compensa con capas de filtrado mejores.
- Crea un proceso de lista blanca: propietario + razón + fecha de revisión. Esto no es burocracia; es evitar que tu yo futuro explore un archivo de configuración de hace una década a las 3 a.m.
- Prueba con reintentos reales: elige un proveedor con comportamiento conocido de pool de IP y valida la aceptación en reintento a través de nodos MX. Si falla, ajusta el tuple o añade a la whitelist.
El greylisting no es ni héroe ni villano. Es un instrumento contundente que aún puede ser útil cuando entiendes lo que cuesta: tiempo, predictibilidad y la ocasional reunión acalorada. Úsalo donde el retraso sea aceptable, evítalo donde el retraso cause daño y mídelo como si realmente importara.