Articulo de referencia

Validación de la etiqueta de dirección de rebote

En informática , la validación de etiquetas de direcciones de rebote ( BATV , por sus siglas en inglés) es un método, definido en un borrador de Internet , para determinar si la...

En informática , la validación de etiquetas de direcciones de rebote ( BATV , por sus siglas en inglés) es un método, definido en un borrador de Internet , para determinar si la dirección de rebote especificada en un mensaje de correo electrónico es válida. Está diseñado para rechazar el backscatter , es decir, los mensajes de rebote enviados a direcciones de retorno falsificadas.

Descripción general

La idea básica es enviar todos los correos electrónicos con una dirección de remitente que incluya una marca de tiempo y un token criptográfico imposible de falsificar. Cualquier correo electrónico que sea devuelto como rebote sin una firma válida puede ser rechazado. Los correos electrónicos que rebotan deben tener una dirección de remitente vacía (nula) para evitar que se generen rebotes y, por lo tanto, que los mensajes reboten indefinidamente.

BATV reemplaza un remitente de sobre como mailbox@example.comcon , donde , llamado "Firma Privada Simple", es solo uno de los posibles esquemas de etiquetado; de hecho, el único completamente especificado en el borrador. El borrador de BATV proporciona un marco en el que pueden encajar otras posibles técnicas. Se mencionan otros tipos de implementaciones, como el uso de firmas de clave pública que pueden ser verificadas por terceros, pero no se definen. El marco general es lo suficientemente vago/flexible como para que sistemas similares como Sender Rewriting Scheme puedan encajar en este marco.prvs=tag-value=mailbox@example.comprvs

Historia

Sami Farin propuso un Sistema Anti-Rebote Falso en 2003 en news.admin.net-abuse.email , [ 1 ] que utilizaba la misma idea básica de colocar un hash difícil de falsificar en la dirección de rebote de un mensaje. A finales de 2004, Goodman et al. propusieron un "Remitente de Sobre Firmado" mucho más complejo [ 2 ] que incluía un hash del cuerpo del mensaje y estaba destinado a abordar una amplia variedad de amenazas de falsificación, incluidos los rebotes de correo falsificado. Varios meses después, Levine y Crocker propusieron BATV con su nombre actual y muy similar a su forma actual.

Problemas

El borrador prevé algunos problemas en la gestión de BATV.

  • Algunos gestores de listas de correo (por ejemplo, ezmlm ) siguen basándose en la dirección de rebote y no la reconocerán después de la modificación mediante BATV.
  • El sistema de greylisting requiere que las implementaciones de BATV mantengan la misma etiqueta durante las retransmisiones durante un tiempo razonable. Esto también puede provocar retrasos en cada correo electrónico, a menos que el sistema de greylisting ignore la etiqueta o incluya en la lista blanca a los hosts remitentes que reintenten el envío correctamente.
  • Los sistemas de filtrado de correo no deseado basados ​​en el método de desafío-respuesta y los sistemas que clasifican el correo según la dirección de rebote (por ejemplo, para eliminar duplicados) pueden funcionar de forma menos fluida con las direcciones etiquetadas con BATV.

También existen problemas que impiden que los sistemas BATV eliminen toda la retrodispersión.

  • Algunos correos electrónicos legítimos se envían con una dirección de retorno vacía, lo que no constituye un rebote y, por lo tanto, no contendrá los tokens especiales. Por ejemplo, la extensión de notificación de estado de entrega definida en RFC 3461 requiere una ruta de retorno nula al enviar correos electrónicos con la opción "NOTIFY=NEVER" a un servidor que no cumple con los estándares. 
  • Algunos correos electrónicos rebotados se envían (incorrectamente) no a la dirección del remitente, sino a la dirección de correo electrónico que aparece en el encabezado "De:".
  • Algunos sistemas de correo que implementan la verificación de devolución de llamada utilizan "postmaster" en lugar de la dirección de retorno nula.

Véase también

Referencias

  1. "Safari" (10-12-2003). "Re: Bloqueo de spam sin esfuerzo" . Grupo de noticias : news.admin.net-abuse.email . Usenet: slrnbtcrap.lis.y7pt9001@safari.homelinux.net . Consultado el 3-06-2009 .  
  2. Microsoft Word - Working_SES_Format_Definition_16.doc
  • Borrador de BATV
  • Página web de BATV
  • Greylisting y BATV Archivado el 23/03/2010 en Wayback Machine Implementación de BATV (con un probador de BATV) para qmail / netqmail
Obtenido de " https://en.wikipedia.org/w/index.php?title=Bounce_Address_Tag_Validation&oldid=1357530987 "