Ruta de retorno de sobre variable

La ruta de retorno de sobre variable ( VERP , por sus siglas en inglés) es una técnica utilizada por algunos programas de listas de correo electrónico para permitir la detección y eliminación automáticas de direcciones de correo electrónico no entregables . Funciona utilizando una ruta de retorno diferente (también llamada "remitente del sobre") para cada destinatario de un mensaje.

Cualquier lista de correo de larga duración acaba conteniendo direcciones a las que ya no se puede acceder. Direcciones que antes eran válidas pueden volverse inutilizables porque el destinatario cambió de proveedor . En otro caso, la dirección puede seguir existiendo pero estar abandonada, acumulándose correos sin leer hasta que no quede espacio para recibir más.

Cuando se envía un mensaje a una lista de correo, el software de la lista lo reenvía a todas las direcciones. Si hay direcciones no válidas, se envían mensajes de rebote al propietario de la lista. Si la lista es pequeña, el propietario puede leer los mensajes de rebote y eliminar manualmente las direcciones no válidas. Con una lista más grande, esta tarea resulta tediosa y desagradable, por lo que conviene automatizar el proceso.

Sin embargo, la mayoría de los mensajes de rebote se han diseñado históricamente para ser leídos por usuarios humanos, no para ser gestionados automáticamente por software. Todos transmiten la misma idea básica ("el mensaje de X a Y no se pudo entregar por la razón Z"), pero con tantas variaciones que sería casi imposible escribir un programa que interprete de forma fiable el significado de cada mensaje de rebote. El RFC 1894 (obsoleto por el RFC 3464) define un formato estándar para solucionar este problema, pero la compatibilidad con dicho estándar dista mucho de ser universal. No obstante, existen varios formatos comunes (por ejemplo, RFC 3464, qsbmf de qmail y el formato DSN de Microsoft para Exchange ) que abarcan una gran proporción de los rebotes.

En ocasiones, Microsoft Exchange puede rechazar un mensaje sin indicar la dirección de correo electrónico original. Cuando Exchange conoce al destinatario, pero no acepta recibir correos electrónicos en su nombre, omite su dirección. Si se envía un mensaje a una dirección específica joe@example.comy el servidor sabe que se trata de "Joe User", el mensaje será rechazado indicando que no se pudo entregar, omitiendo por completo la joe@example.comdirección. VERP es la única solución viable para gestionar correctamente estos rechazos.

La parte más difícil de gestionar los rebotes es relacionar un mensaje de rebote con la dirección de correo electrónico que lo provocó. Si el software de la lista de correo puede ver que un rebote se produjo al intentar enviar un mensaje a user@example.com , no necesita comprender el resto de la información del rebote. Simplemente puede contar cuántos mensajes se enviaron recientemente a user@example.com y cuántos rebotes se produjeron; y si la proporción de mensajes rebotados es demasiado alta, la dirección se elimina de la lista.

Aunque los formatos de los mensajes de rebote varían enormemente, hay un aspecto que es altamente predecible: la dirección a la que se enviarán . VERP aprovecha al máximo esta característica. En una lista de correo que utiliza VERP, se usa una dirección de remitente diferente para cada destinatario.

El administrador de la lista de correo sabe que envió un mensaje de X a Y, por lo que si se recibe un mensaje de rebote en la dirección X, solo puede deberse a que la dirección Y no se pudo entregar, ya que no se envió nada de X a ninguna otra dirección. De esta forma, se ha extraído la información importante del mensaje de rebote, sin necesidad de comprender su contenido, lo que significa que la persona encargada de la lista no necesita gestionarlo manualmente.

El primer defensor serio de esta solución, y el creador del término VERP para describirla, fue Daniel J. Bernstein , quien puso en práctica la idea por primera vez en su MTA qmail y en el gestor de listas de correo ezmlm . ^{[ 1 ]}

Supongamos que existe una lista de correo llamada wikipedians@example.nety que una persona con la dirección bob@example.orgestá suscrita a ella. Pero desde entonces, Bob ha dejado example.org, por lo que su dirección ya no es válida. Consideremos qué sucede cuando alguien envía un mensaje a la lista.

• CiviCRM
• EspoCRM
• Servidor de correo Courier
• Discurso ^{[ 2 ]}
• exim , utilizando una combinación especializada de enrutador/transporte
• ezmlm
• GNU Mailman
• Espacio de trabajo de Google
• Correo electrónico
• Sistema de transporte de correo Mercury
• mlmmj ^{[ 3 ]}
• Mahara
• Mailchimp ^{[ 4 ]}
• Maileon
• MediaWiki , utilizando la extensión BounceHandler
• Moodle
• Plesk ^{[ 5 ]}
• sufijo
• correo electrónico
• Sendmail , con un conjunto de reglas ^{[ 6 ]}
• STEdb
• Correo fuerte
• Simpa
• Thexyz
• Zimbra
• Caja Target
• NotificarBC
• AWS SES (Servicio de correo electrónico simple)

El uso de VERP requiere que cada mensaje se envíe una sola vez a cada destinatario, en lugar de una sola vez a cada servidor SMTP receptor . Esto se debe a una limitación de SMTP, que permite especificar varias direcciones de destinatario en una sola transacción, pero solo una dirección de remitente. Cuando hay muchos suscriptores en el mismo dominio , una lista de correo que no utiliza VERP puede combinar varios envíos en una sola transacción. Se conecta al servidor apropiado para el dominio, proporciona la dirección de remitente única, las direcciones de los destinatarios y luego envía el contenido del mensaje solo una vez.

Por otro lado, una lista de correo que utiliza VERP debe enviar el cuerpo completo del mensaje repetidamente, lo que conlleva un aumento general del consumo de ancho de banda . Esta ineficiencia no suele considerarse un gran problema, especialmente para los usuarios de qmail , ya que qmail siempre envía los mensajes una vez por destinatario, incluso cuando no se utiliza VERP. Algunos paquetes mitigan el impacto de VERP aplicándolo selectivamente; por ejemplo, un gestor de listas de correo podría utilizar VERP solo en 1 de cada 10 envíos. De esta forma, se puede obtener gran parte del control estricto de rebotes y la retroalimentación precisa de VERP sin incurrir en la sobrecarga de procesamiento y red cada vez.

Otro problema con VERP (y con cualquier esquema de manejo automático de rebotes) es que hay MTA en Internet que no siguen los estándares SMTP básicos. VERP depende de que los MTA de los destinatarios sigan la regla de que los rebotes se envíen al remitente del sobre . Este ha sido un requisito estándar desde los inicios de SMTP en 1982 (ver RFC 821), pero aún hay MTA que no lo hacen correctamente, generalmente rebotando a la dirección en el From:encabezado .

Los sistemas que implementan la función greylisting funcionan correctamente con VERP si el remitente del sobre sigue el formato mencionado anteriormente. Sin embargo, algunas implementaciones de VERP utilizan un número de mensaje o una clave aleatoria, lo que provoca retrasos en cada publicación a la lista de correo, a menos que el sistema greylisting considere equivalentes las direcciones de remitente "similares".

• Validación de etiquetas de direcciones de rebote (BATV): para rebotes provenientes de retrodispersión.
• Esquema de reescritura del remitente (SRS): para rebotes de correo electrónico y SPF.
• Protocolo simple de transferencia de correo (SMTP)
• Borrador de extensión SMTP para optimizar VERP