Verificación de devolución de llamada

La verificación de devolución de llamada , también conocida como verificación de llamada o verificación de la dirección del remitente , es una técnica utilizada por el software SMTP para validar las direcciones de correo electrónico . El objetivo más común de la verificación es la dirección del remitente que aparece en el encabezado del mensaje (la dirección especificada durante el diálogo SMTP como " MAIL FROM "). Se utiliza principalmente como medida antispam .

Dado que un gran porcentaje del correo basura se genera a partir de direcciones de remitente ("mfrom") falsificadas , parte del correo basura se puede detectar comprobando si la falsificación dio como resultado una dirección no válida, utilizando este método.

Una técnica relacionada es el "reenvío de llamadas", mediante el cual un servidor de correo secundario o un servidor de correo con firewall puede verificar a los destinatarios en el servidor de correo principal del dominio para decidir si la dirección es entregable.

El servidor de correo receptor verifica la dirección del remitente, comprobando ambas partes: el nombre de dominio (la parte posterior al carácter @) y la parte local (la parte anterior al carácter @). El primer paso consiste en establecer una conexión SMTP exitosa con el servidor de correo del remitente. Este servidor se encuentra consultando los registros MX en la zona DNS del dominio . El segundo paso consiste en consultar al servidor de correo y asegurarse de que acepta la dirección como válida. Esto se realiza de la misma manera que al enviar un correo electrónico a la dirección; sin embargo, el proceso se detiene una vez que el servidor de correo acepta o rechaza la dirección del destinatario. Estos son los mismos pasos que seguiría el servidor de correo receptor para devolver el correo al remitente; sin embargo, en este caso no se envía ningún correo. Los comandos SMTP enviados son:

nombre de host del verificador HELO CORREO ELECTRÓNICO DE:<> RCPT TO:< la dirección que se va a probar > ABANDONAR

De forma equivalente, los comandos MAIL FROM y RCPT TO pueden sustituirse por el comando VRFY; sin embargo, no es obligatorio que el comando VRFY sea compatible y, por lo general, está deshabilitado en los MTA modernos.

Ambas técnicas cumplen técnicamente con los RFC SMTP pertinentes (RFC 5321); sin embargo, el RFC 2505 (una buena práctica actual ) recomienda, por defecto, deshabilitar el comando VRFY para prevenir ataques de recolección de directorios . (Una interpretación común implica que el par de comandos MAIL FROM/RCPT TO también debería responder de la misma manera, pero esto no se especifica en los RFC).

La verificación de devolución de llamada es abusiva ^{[ 1 ]} y puede llevar al bloqueo del servidor, el dominio o el bloque de IP.

Si el administrador del servidor de correo ha deshabilitado VRFY, utilizar RCPT TO para eludir esta restricción constituye un acceso no autorizado y un intento de evadir los controles de acceso. Por lo tanto, el operador puede ser objeto de acciones legales civiles o penales, según la jurisdicción.

La documentación de postfix y exim advierte sobre el uso ^{[ 2 ] [ 3 ]} de esta técnica y menciona muchas limitaciones de las devoluciones de llamada SMTP. En particular, existen muchas situaciones en las que resulta ineficaz o causa problemas a los sistemas que reciben las devoluciones de llamada.

• Algunos sistemas de intercambio de correo electrónico habituales no proporcionan resultados útiles a las llamadas de retorno:
  • Servidores que rechazan todos los correos de rebote (contrario a la RFC 1123, parte de STD 3 ^{[ 4 ]} ). Para solucionar este problema, Postfix, por ejemplo, utiliza la dirección del administrador de correo local o una dirección de "doble rebote" en la parte MAIL FROM de la llamada. Sin embargo, esta solución alternativa tiene dos problemas: primero, puede causar un bucle de verificación; segundo, fallará si se utiliza la validación de la etiqueta de dirección de rebote para reducir la retrodispersión . ^{[ 1 ]} Por lo tanto, no se debe utilizar esta solución alternativa. La verificación de devolución de llamada aún puede funcionar si el rechazo de todos los rebotes ocurre en la etapa DATA en lugar de la etapa anterior MAIL FROM, mientras que el rechazo de direcciones de correo electrónico no válidas permanece en la etapa RCPT TO en lugar de también ser movido a la etapa DATA. ^{[ 2 ] [ 3 ]}
  • Servidores que aceptan todas las direcciones de correo electrónico en la etapa RCPT TO pero rechazan las no válidas en la etapa DATA. Esto se hace comúnmente para prevenir ataques de recolección de directorios y, por diseño, no proporciona información sobre si una dirección de correo electrónico es válida y, por lo tanto, impide que funcione la verificación de devolución de llamada. ^{[ 2 ] [ 1 ]}
  • Servidores que aceptan todos los correos durante el diálogo SMTP (y generan sus propios rebotes posteriormente). ^{[ 2 ]} Este problema puede mitigarse probando una dirección aleatoria inexistente, así como la dirección deseada (si la prueba tiene éxito, la verificación posterior es inútil).
  • Los servidores que implementan el correo electrónico comodín , por definición, consideran válidas todas las direcciones de correo electrónico y las aceptan. Al igual que los sistemas que aceptan y luego rechazan los correos, una dirección inexistente aleatoria puede detectar esto.
• El proceso de devolución de llamada puede causar retrasos en la entrega porque el servidor de correo donde se verifica una dirección puede utilizar técnicas antispam lentas, incluidos los "retrasos de saludo" (que causan un retraso en la conexión) y el greylisting (que causa un aplazamiento de la verificación). ^{[ 2 ]}
• Si el sistema al que se llama utiliza la función greylisting, es posible que la llamada no devuelva información útil hasta que expire el tiempo de greylisting. Greylisting funciona devolviendo un "fallo temporal" (un código de respuesta 4xx) cuando detecta un par de direcciones de correo electrónico desconocidas (MAIL FROM/RCPT TO). Un sistema greylisting puede no generar un "fallo permanente" (un código de respuesta 5xx) cuando se le proporciona una dirección de correo electrónico no válida para RCPT TO, y en su lugar puede seguir devolviendo un código de respuesta 4xx. ^{[ 5 ]}
• Algunos correos electrónicos pueden ser legítimos, pero no tener una dirección de remitente válida debido a un error del usuario o a una configuración incorrecta. Lo positivo es que el proceso de verificación suele resultar en un rechazo directo, por lo que si el remitente no era un spammer sino un usuario real, se le notificará del problema.
• Si un servidor recibe mucho spam, puede realizar muchas devoluciones de llamada. Si esas direcciones son inválidas o trampas de spam , el servidor se parecerá mucho a un remitente de spam que realiza un ataque de diccionario para obtener direcciones. Esto, a su vez, podría provocar que el servidor sea incluido en listas negras en otros lugares. ^{[ 2 ] [ 1 ] [ 6 ]}
• Algunos administradores consideran que cualquier verificación de devolución de llamada es correo electrónico masivo no solicitado (UBE, por sus siglas en inglés) y pueden bloquear el cliente SMTP de origen, reportarlo como spam o agregarlo a las listas negras de DNS (DNSBL , por sus siglas en inglés) , incluso si el volumen de backscatter es bajo.
• Cada devolución de llamada impone una carga no solicitada al sistema que la recibe, con muy pocas maneras efectivas para que dicho sistema evite esa carga. En casos extremos, si un remitente de spam abusa de la misma dirección de remitente y la utiliza en un conjunto suficientemente diverso de servidores MX receptores, todos los cuales utilizan este método, podrían intentar la devolución de llamada, sobrecargando el servidor MX de la dirección falsificada con solicitudes (lo que constituye, en efecto, un ataque de denegación de servicio distribuido ). ^{[ 1 ]}
• La verificación de devolución de llamada no tiene efecto si los spammers falsifican direcciones de correo electrónico reales ^{[ 1 ] [ 7 ]} o utilizan la dirección de rebote nula.

Algunos de estos problemas se deben a que los sistemas de origen infringen o sobrepasan los límites de las RFC; los problemas de verificación simplemente reflejan estos problemas a los remitentes, como el uso involuntario de direcciones no válidas, el rechazo del remitente nulo o el greylisting (donde, por ejemplo, el retraso causado por el destinatario que verifica está estrechamente relacionado con el retraso causado por el originador). En muchos casos, esto a su vez ayuda al sistema de origen a detectar los problemas y solucionarlos (como no poder recibir rebotes válidos de forma involuntaria).

Varios de los problemas mencionados se reducen mediante el almacenamiento en caché de los resultados de verificación. En particular, los sistemas que no proporcionan información útil (que no rechazan en el momento de la recepción, que utilizan un correo electrónico genérico , etc.) pueden recordarse y no es necesario realizar futuras llamadas a dichos sistemas. Además, los resultados (positivos o negativos) para direcciones de correo electrónico específicas pueden recordarse. Los MTA como Exim incorporan el almacenamiento en caché. ^{[ 3 ]}

• Enlaces de spam: Verificación de la identidad del remitente
• Verificación del remitente — Fundación del Software Libre