La ruta de devolución de sobre variable ( VERP ) es una técnica utilizada por algunos programas de listas de correo electrónico para permitir la detección y eliminación automática de direcciones de correo electrónico que no se pueden entregar . Funciona mediante el uso de una ruta de retorno diferente (también llamada "remitente del sobre") para cada destinatario de un mensaje.
Motivación
Cualquier lista de correo de larga duración eventualmente contendrá direcciones a las que no se puede acceder. Las direcciones que alguna vez fueron válidas pueden volverse inutilizables porque la persona que recibe el correo se ha cambiado a otro proveedor . En otro escenario, es posible que la dirección aún exista, pero que se abandone, y que el correo no leído se acumule hasta que no quede suficiente espacio para aceptar más.
Cuando se envía un mensaje a una lista de correo, el software de la lista de correo lo reenvía a todas las direcciones de la lista. La presencia de direcciones no válidas en la lista hace que los mensajes de devolución se envíen al propietario de la lista. Si la lista de correo es pequeña, el propietario puede leer los mensajes de devolución y eliminar manualmente las direcciones no válidas de la lista. Con una lista de correo más grande, este es un trabajo tedioso y desagradable, por lo que es conveniente automatizar el proceso.
Sin embargo, la mayoría de los mensajes de rebote han sido diseñados históricamente para ser leídos por usuarios humanos, no para ser manejados automáticamente por software. Todos transmiten la misma idea básica ("el mensaje de X a Y no se pudo entregar debido a la razón Z") pero con tantas variaciones que sería casi imposible escribir un programa para interpretar de manera confiable el significado de cada mensaje de rebote. RFC 1894 (obsoleto por RFC 3464) define un formato estándar para solucionar este problema, pero la compatibilidad con el estándar está lejos de ser universal. Sin embargo, existen varios formatos comunes (por ejemplo, RFC 3464, qsbmf de qmail y formato DSN de Microsoft para Exchange ) que cubren una gran proporción de rebotes.
En ocasiones, Microsoft Exchange puede devolver un mensaje sin proporcionar ninguna indicación de la dirección a la que se envió el mensaje original. Cuando Exchange conoce al destinatario previsto, pero no está dispuesto a aceptar correo electrónico por él, omite su dirección. Si se envía un mensaje a [email protected]
y el servidor sabe que se trata de "Usuario Joe", devolverá el mensaje diciendo que no se pudo entregar el mensaje a "Usuario Joe", omitiendo la [email protected]
dirección por completo. VERP es la única forma viable de manejar estos rebotes correctamente.
Cómo VERP resuelve el problema de manejo de rebotes
La parte difícil del manejo de rebotes es hacer coincidir un mensaje de rebote con la dirección que no se pudo entregar que causó el rebote. Si el software de la lista de correo puede ver que un rebote resultó de un intento de enviar un mensaje a [email protected] , entonces no necesita comprender el resto de la información en el rebote. Simplemente puede contar cuántos mensajes se enviaron recientemente a [email protected] y cuántos rebotes resultaron, y si la proporción de mensajes rebotados es demasiado alta, la dirección se elimina de la lista.
Si bien los formatos de mensajes de devolución en general varían enormemente, hay un aspecto de un mensaje de devolución que es altamente predecible: la dirección a la que se enviará . VERP aprovecha al máximo esto. En una lista de correo que usa 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 devolución en la dirección X, solo puede ser porque la dirección Y no se pudo entregar, porque 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 entender su contenido, por lo que el responsable de la lista no necesita tratarlo manualmente.
Origen
El primer defensor serio de esta solución, y el creador del término VERP para describirlo, fue Daniel J. Bernstein , quien primero puso la idea en práctica en su administrador de listas de correo qmail MTA y ezmlm . [1]
Ejemplo
Suponga que hay una lista de correo llamada [email protected]
y que una persona se [email protected]
ha suscrito a ella, pero más tarde, Bob abandonó example.org, por lo que su dirección ya no es válida. Piense en lo que sucede cuando alguien envía un mensaje a la lista.
Sin VERP
Sin VERP, el administrador de la lista de correo podría enviar un mensaje con las siguientes características:
- remitente del sobre:
[email protected]
- recipiente:
[email protected]
Esto daría como resultado un rebote, generado por el MTA de example.net o example.org, con las siguientes características:
- remitente del sobre: vacío
- recipiente:
[email protected]
- contenido: example.org no pudo entregar el siguiente mensaje a Bob: ...
No se puede esperar que el administrador de la lista de correo comprenda el contenido de este rebote y no puede deducir nada de la dirección del destinatario porque también se enviaron mensajes de cientos de personas además de Bob [email protected]
.
Con VERP
Con VERP, el mensaje original sería diferente:
- remitente del sobre:
[email protected]
- recipiente:
[email protected]
El rebote, entonces, será más útil:
- remitente del sobre: vacío
- recipiente:
[email protected]
- contenido: example.org no pudo entregar el siguiente mensaje a Bob: ...
A partir de este mensaje de devolución, el administrador de la lista de correo puede deducir que un mensaje [email protected]
debe haber fallado.
Este ejemplo muestra el método más simple posible para hacer coincidir un VERP con un suscriptor de la lista: la dirección completa del destinatario se incluye en la ruta de retorno, con el signo arroba reemplazado por un signo igual porque una ruta de retorno con dos signos arroyos no sería válida. Son posibles otros esquemas de codificación.
Software compatible con VERP
- CiviCRM
- Servidor de correo de mensajería
- Discurso [2]
- exim , usando una combinación especializada de enrutador / transporte
- ezmlm
- GNU Mailman
- G Suite
- Inxmail
- Sistema de transporte de correo Mercury
- mlmmj
- Mahara
- Mailchimp [3]
- Maileon
- MediaWiki aunque mw: Extensión: BounceHandler
- Moodle
- sufijo
- qmail
- Sendmail , con un conjunto de reglas [4]
- STEdb
- StrongMail
- Simpa
- Thexyz
- Zimbra
- Cuadro de destino
- Notificar BC
- AWS SES (servicio de correo electrónico simple)
Desventajas
El uso de VERP requiere que cada mensaje se envíe una vez para cada destinatario, en lugar de una vez para cada servidor SMTP receptor . Esto se debe a una limitación de SMTP, que permite especificar varias direcciones de destinatarios 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 usa VERP puede combinar múltiples entregas en una sola transacción. Se conecta al servidor apropiado para el dominio, proporciona la dirección del remitente único, las direcciones de los destinatarios y luego envía el contenido del mensaje solo una vez.
Una lista de correo que usa VERP, por otro lado, debe enviar todo el cuerpo del mensaje repetidamente, lo que conduce a un aumento general en el uso del ancho de banda . Esta ineficiencia generalmente no se considera un gran problema, especialmente para los usuarios de qmail , ya que qmail siempre envía mensajes una vez por destinatario, incluso cuando no se utiliza VERP. Algunos paquetes mitigan el impacto de VERP aplicándolo de forma selectiva, por ejemplo, un administrador de listas de correo solo puede usar VERP en 1 de cada 10 correos. De esta manera, puede obtener gran parte del estricto control de rebote de VERP y la retroalimentación precisa sin incurrir en el procesamiento y la sobrecarga de la red cada vez.
Otro problema con VERP (y con cualquier esquema de manejo de rebotes automático) es que hay MTA en Internet que no siguen los estándares básicos de SMTP. VERP depende de que los MTA de los destinatarios sigan la regla de que los rebotes se envían al remitente del sobre . Este ha sido un requisito estándar desde los albores de SMTP en 1982 (consulte RFC 821), pero todavía hay MTA que se equivocan, generalmente rebotando a la dirección en el From:
encabezado .
Los sistemas que implementan greylisting funcionan bien con VERP si el remitente del sobre se ajusta al formato antes mencionado. Sin embargo, algunas implementaciones de VERP usan un número de mensaje o una clave aleatoria como parte de VERP, lo que hace que cada publicación en la lista de correo se retrase a menos que el sistema de listas grises trate las direcciones de remitente "similares" como equivalentes.
Ver también
- Validación de etiqueta de dirección de rebote (BATV): para rebotes de retrodispersión
- Esquema de reescritura del remitente (SRS): para rebotes del reenvío de correo electrónico y SPF
- Protocolo simple de transferencia de correo (SMTP)
- borrador de extensión SMTP para simplificar VERP
Referencias
- ^ DJ Bernstein qmail , 1 de febrero de 1997
- ^ https://meta.discourse.org/t/handling-bouncing-e-mails/45343
- ^ "Entrega de correo electrónico para profesionales de TI. Una guía de MailChimp" (PDF) . Mailchimp .
- ^ http://compgroups.net/comp.mail.sendmail/sendmail-verp-ruleset/1311680