Mensaje de rebote

Los rebotes permanentes son definitivos y causan un mayor daño a la IP del remitente. Se producen cuando el servidor de correo del remitente determina que es muy probable que el destinatario no esté disponible y que siga estándolo. Algunos ejemplos de rebotes permanentes son cuando los destinatarios se encuentran en alguna de las siguientes situaciones: identificador o dominio incorrectos (por ejemplo, un error tipográfico en la dirección de correo electrónico o en el dominio) o cuando su servidor ya no acepta correos electrónicos. En este caso, es obligatorio eliminar las direcciones de correo electrónico que generan rebotes.

Los rebotes suaves son temporales. Un mensaje rebotado que experimenta un rebote suave puede intentarse entregar nuevamente en otro momento. ^{[ 5 ]} Los rebotes suaves ocurren cuando el destinatario del correo electrónico tiene la bandeja de entrada llena y, por lo tanto, no hay espacio disponible para almacenar otro correo electrónico, o cuando se ha alcanzado el límite de tamaño de los correos electrónicos que puede recibir. Otras situaciones en las que aparece un rebote suave son un bloqueo configurado en el correo electrónico del destinatario para marcar a un remitente determinado como remitente de "spam" o para incluir a un remitente determinado en la lista negra. Además, una suspensión temporal del correo electrónico del destinatario o un error temporal en el servidor también pueden causar un rebote suave.

Cuando un correo electrónico llega al servidor de destino para una dirección (como mymail.example, al enviarlo a alice@mymail.example ), puede ocurrir que el demonio de correo no pueda depositar el mensaje en el buzón del usuario especificado si el disco duro subyacente del servidor no tiene suficiente espacio.

Al enviar un correo electrónico, es posible que el servidor desde el que se envía no pueda alcanzar la dirección de destino. En tal caso, el remitente recibiría un mensaje de error de su propio servidor de correo. Causas comunes por las que los servidores de correo no pueden alcanzar un destino:

• No se pudo resolver la dirección de destino. Por ejemplo, si el nombre de dominio no existe.
• No se pudo establecer una conexión con la dirección de destino. Por ejemplo, si la dirección IP no está asignada a un servidor o si el servidor está fuera de línea .

Los usuarios pueden recibir mensajes de rebote erróneos sobre mensajes que nunca enviaron. Esto puede ocurrir, en particular, en el contexto del correo basura o los virus informáticos , donde un remitente falsifica un mensaje dirigido a otro usuario (destinatario previsto del correo basura) y lo hace parecer enviado por un tercero. Si el mensaje no puede entregarse al destinatario previsto, el mensaje de rebote se devuelve al tercero en lugar de al remitente. Esto se conoce como retroceso .

Si el servidor de correo library.example hubiera sabido que el mensaje no se podía entregar (por ejemplo, si Jill no tenía una cuenta de usuario allí), no lo habría aceptado y, por lo tanto, no habría enviado el rebote. En su lugar, lo habría rechazado con un código de error SMTP. Esto obligaría al servidor de correo de Jack (en store.example ) a crear y enviar el rebote.

Los rebotes son una forma especial de respuesta automática . Las respuestas automáticas son correos enviados por un programa —a diferencia de un usuario humano— en respuesta a un correo recibido y enviados a la dirección de rebote .

Otros ejemplos de respuestas automáticas son los correos de vacaciones , los desafíos de los filtros de spam de desafío-respuesta , las respuestas de los servidores de listas y los informes de comentarios . Estas otras respuestas automáticas se analizan en la RFC 3834: las respuestas automáticas deben enviarse a la Return-Pathdirección indicada en el correo recibido que las activó, y esta respuesta normalmente se envía con una ruta de retorno vacía; de lo contrario, los sistemas de respuesta automática podrían quedar atrapados en un intercambio constante de respuestas automáticas.

El Return-Pathcampo de encabezado es visible en el correo entregado, Return-Pathinsertado por el agente de entrega de correo SMTP ( MDA ) (que generalmente se combina con un agente de transferencia de correo o MTA ). El MDA simplemente copia la ruta inversa del MAIL FROMcomando SMTP en el campo de encabezado Return-Path. El MDA también elimina Return-Pathlos campos de encabezado falsos insertados por otros MTA; este campo de encabezado generalmente garantiza que refleje la última ruta inversa vista en el MAIL FROMcomando.

Actualmente, estas rutas se reducen normalmente a direcciones de correo electrónico comunes, ya que el antiguo enrutamiento de origen SMTP quedó obsoleto en 1989; para obtener información histórica, consulte el Esquema de reescritura del remitente . Aún existe una forma especial de ruta: la ruta vacía , utilizada para muchas respuestas automáticas y, sobre todo, para todos los mensajes de rebote.MAIL FROM:<>

En sentido estricto, los rebotes enviados con un no vacío Return-Pathson incorrectos. RFC 3834 ofrece algunas heurísticas para identificar rebotes incorrectos basados ​​en la parte local (lado izquierdo antes del "@") de la dirección en un no vacío Return-Path, e incluso define un campo de encabezado de correo, Auto-Submitted, para identificar respuestas automáticas. Pero el encabezado de correo es parte de los datos del correo (comando SMTP DATA), y los MTA normalmente no miran el correo. Se ocupan del sobre , que incluye la MAIL FROMdirección (también conocida como Return-Path, Envelope-FROM, o "ruta inversa") pero no, por ejemplo, el RFC 2822- Fromen el campo de encabezado de correo From. Estos detalles son importantes para esquemas como BATV .

Los rebotes restantes con un valor vacío Return-Pathson informes de no entrega ( NDR ) o notificaciones de estado de entrega (DSN). Las DSN se pueden solicitar explícitamente con una extensión de servicio SMTP, aunque no se utiliza ampliamente. Las solicitudes explícitas de detalles de fallos de entrega se implementan con mucha más frecuencia con la ruta de retorno de sobre variable (VERP), mientras que las solicitudes explícitas para estos detalles rara vez se implementan. ^{[ 6 ]}

Los NDR son una función básica de SMTP. Tan pronto como un MTA acepta un correo para su reenvío o entrega, no puede eliminarlo silenciosamente ("descartar"); debe crear y enviar un mensaje de rebote al remitente si el reenvío o la entrega fallan.