Un mensaje puede mostrar un fallo temporal antes de una entrega posterior. El greylisting es una causa posible. La limitación de solicitudes y otros problemas temporales pueden producir la misma clase de estado.
¿Cómo funciona el greylisting?
Un receptor aplaza temporalmente a un cliente de envío desconocido y comprueba si un intento posterior califica como reintento.
RFC 6647 describe esta técnica contra el abuso. El software que nunca reintenta no puede completar la entrega a través de esa verificación.
El receptor devuelve un fallo temporal SMTP, dejando al sistema de envío la responsabilidad de conservar y reintentar el mensaje. Pasar la prueba de reintento elimina ese obstáculo. Las demás reglas de filtrado del receptor siguen aplicándose.
¿Cómo reconoce el receptor un reintento?
El receptor compara la información del nuevo intento con un registro del anterior.
RFC 6647 recomienda rastrear la IP de envío, el remitente del sobre y el primer destinatario. El remitente del sobre es la dirección utilizada para las notificaciones de fallos de entrega.
Un cambio en esos identificadores puede hacer que un reintento parezca un mensaje nuevo. Enviar desde varios servidores puede complicar la coincidencia, dependiendo de la política del receptor.
La RFC recomienda permitir tráfico adicional desde la IP tras un reintento exitoso. También recomienda que los registros inactivos expiren, para que el permiso no dure indefinidamente.
¿Por qué el greylisting puede detener parte del correo no deseado?
Detiene al software de envío que realiza un solo intento y abandona ante un fallo temporal.
La técnica prueba el comportamiento de reintento. No determina si el contenido del mensaje es seguro o deseado. El software abusivo que reintenta también puede pasarla.
Un receptor necesita por lo tanto otras señales de filtrado. Pasar el greylisting con éxito no establece autenticación, consentimiento ni una buena reputación de envío.
¿Cuánto puede durar el retraso?
El retraso depende de cuándo reintenta el remitente y qué intentos acepta el receptor como oportunos.
RFC 6647 recomienda una ventana de reintento predeterminada de un minuto a 24 horas para acomodar los calendarios de reintento habituales. Es un rango del lado del receptor para reconocer reintentos. No promete la entrega dentro de ese período.
Por ejemplo, un reintento a los 30 segundos es demasiado pronto para esa ventana predeterminada. Un reintento a las 30 horas puede tratarse como un intento nuevo. Un reintento que califica aún enfrenta las demás verificaciones del receptor.
Un remitente que reintenta solo después de una hora no puede entregar a través de la verificación antes. Para un código de verificación que expira a los diez minutos, esa entrega llega después de que el código deje de ser utilizable.
¿Cómo distingues el greylisting de otro fallo?
Usa los detalles de respuesta y el historial de reintentos. Un código de estado temporal por sí solo no demuestra greylisting.
| Observación | Qué establece |
|---|---|
4xx, luego entrega exitosa | Un fallo temporal se resolvió. El greylisting es una causa posible |
Respuestas 4xx repetidas hasta la expiración | La entrega nunca se completó. El texto de respuesta y el patrón de reintentos pueden ayudar a identificar la causa |
Respuesta 5xx | Un fallo permanente para esa solicitud SMTP |
RFC 6647 analiza 421 al terminar la conexión y 450 en los demás casos. No prescribe la redacción de la respuesta, por lo que el texto no necesita nombrar explícitamente el greylisting.
Correo aplazado y rebotes describen los resultados temporal y definitivo.
¿Qué debe investigar el operador de envío?
Confirma que el mensaje se reintenta y que su información de identificación sigue siendo adecuada para la política de coincidencia del receptor.
Comprueba si los reintentos cambian el remitente del sobre o alternan entre IPs de envío. Comprueba también si distintos servidores MX receptores reconocen el mismo historial de reintentos.
RFC 6647 recomienda que los servidores receptores compartan una base de datos de greylisting, porque un reintento puede llegar a un destino diferente. Una discrepancia puede retrasar repetidamente el correo legítimo.
Proporciona al operador receptor los horarios de intentos, las IPs y el texto de respuesta cuando el retraso persista. La RFC respalda excepciones gestionadas por el receptor para remitentes legítimos que no funcionan bien con el greylisting.
¿Debería un receptor aplicar greylisting a los envíos autenticados?
RFC 6647 recomienda que los operadores excluyan del greylisting a los clientes autenticados de su propio servicio de envío. Esos clientes ya se han autenticado para enviar correo, por lo que comprobar si un remitente desconocido reintenta añade un retraso evitable. Aplica la regla en el servicio de recepción o envío que la controla.
Para una aplicación que utiliza una plataforma de envío, revisa el resultado de entrega del mensaje. Crear otro envío desde la aplicación no repara la coincidencia de greylisting del primer intento. Puede producir duplicados.
En resumen
El greylisting prueba el comportamiento de reintento.
Un fallo temporal pide al servidor de envío que vuelva a intentarlo. No establece un rechazo permanente.
Un reintento no garantiza la aceptación.
El intento debe cumplir las verificaciones de tiempo e identidad del receptor, junto con sus demás políticas de correo.
El tiempo depende de ambos servidores.
La ventana de reintento del receptor y el calendario del remitente determinan juntos el retraso.
Los aplazamientos repetidos requieren investigación.
Revisa los detalles de respuesta, los reintentos y los cambios en los identificadores del remitente antes de concluir que la causa es el greylisting.