Un mensaje de rebote o simplemente "rebote" es un mensaje automático de un sistema de correo electrónico que informa al remitente de un mensaje anterior que el mensaje no se ha entregado (o que se ha producido algún otro problema de entrega). Se dice que el mensaje original ha "rebotado".
Esta retroalimentación puede ser inmediata (algunas de las causas descritas aquí) o, si el sistema de envío puede reintentar, puede llegar días después de que finalicen estos reintentos.
Los términos más formales para un mensaje de rebote incluyen "Informe de no entrega" o "Recibo de no entrega" (NDR), mensaje de "Notificación de estado de entrega" (DSN) [Error] o "Notificación de no entrega" (NDN). [1]
Aunque el SMTP es una tecnología madura, con más de treinta años de existencia, su arquitectura se ve cada vez más sometida a una carga de trabajo normal y no solicitada. [2] Los sistemas de correo electrónico se han mejorado con sistemas de reputación vinculados al remitente real del correo electrónico, con la idea de que los servidores de correo electrónico del destinatario rechacen el correo electrónico cuando se utiliza un remitente falso en el protocolo. [3]
Por lo tanto, se han creado dos tipos de rebotes de correo electrónico: rebotes duros y rebotes blandos . [4] Ambos afectan la reputación de IP del remitente porque los proveedores de servicios de correo electrónico (ESP) consideran la tasa de rebote total como un factor de decisión al dirigir el correo electrónico a la bandeja de entrada de un usuario. Brevemente, la tasa de rebote total se calcula como la suma de la tasa de rebote duro y la tasa de rebote blando.
Los rebotes duros son permanentes y tienen una puntuación más alta en términos de daño a la dirección IP del remitente. Los rebotes duros ocurren cuando el servidor de correo del remitente determina que existe una alta probabilidad de que el destinatario no esté disponible y es probable que siga estando así. Algunas de las ocasiones en las que se producen rebotes duros son cuando los destinatarios del correo electrónico se encuentran en una de las siguientes situaciones: identificador incorrecto/dominio incorrecto (como un error tipográfico en la dirección de correo electrónico o en el dominio) o su servidor ya no acepta correos electrónicos. En este caso, es obligatorio eliminar las direcciones de correo electrónico que rebotan.
Los rebotes suaves son temporales. Es posible que se intente volver a enviar un mensaje que rebota 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 se ha alcanzado un límite en el tamaño de los correos electrónicos que se le permite recibir. Otras situaciones en las que aparece un rebote suave son cuando se configura un bloqueo en el correo electrónico del destinatario para marcar a un determinado remitente como remitente de "spam" o para incluir en la lista negra a un determinado remitente. Además, una suspensión temporal del correo electrónico del destinatario o un error temporal en el servidor también son causas de un rebote suave.
Los errores pueden ocurrir en varios lugares durante la entrega de correo. A veces, un remitente puede recibir un mensaje de rebote de su propio servidor de correo, informando que no ha podido enviar un mensaje, o bien, del servidor de correo de un destinatario informando que, aunque había aceptado el mensaje, no puede entregarlo al usuario especificado. Cuando un servidor acepta un mensaje para su entrega, también acepta la responsabilidad de entregar un mensaje de rebote en caso de que la entrega falle.
Cuando un correo electrónico llega al servidor de destino para una dirección (como mymail.example, cuando se envía a [email protected] ), es posible 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 servicio desde el que se envía el correo electrónico no pueda comunicarse con la dirección de destino. En ese caso, el remitente recibiría un mensaje de rebote de su propio servidor de correo. Causas comunes por las que los servidores de correo no pueden comunicarse con un destino:
Los usuarios pueden recibir mensajes de rebote erróneos sobre mensajes que en realidad nunca enviaron. Esto puede suceder en particular en el contexto del correo no deseado o de los virus de correo electrónico , donde un spammer (remitente) puede falsificar un mensaje para otro usuario (destinatario previsto del correo no deseado) y falsificar el mensaje para que parezca de otro usuario (un tercero). Si el mensaje no puede entregarse al destinatario previsto, entonces el mensaje de rebote se "devolvería" al tercero en lugar del spammer. Esto se llama retrodispersión .
Si el servidor de correo library.example hubiera sabido que el mensaje no se podría entregar (por ejemplo, si Jill no tenía una cuenta de usuario allí), no habría aceptado el mensaje en primer lugar y, por lo tanto, no habría enviado el rebote. En cambio, habría rechazado el mensaje con un código de error SMTP. Esto dejaría al servidor de correo de Jack (en store.example ) con la obligación de crear y entregar un rebote.
Los rebotes son una forma especial de respuesta automática . Las respuestas automáticas son correos electrónicos enviados por un programa (en lugar de un usuario humano) en respuesta a un correo electrónico recibido y enviados a la dirección de rebote .
Ejemplos de otras respuestas automáticas son los correos electrónicos 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 RFC 3834: las respuestas automáticas deben enviarse a la Return-Pathdirección indicada en el correo electrónico recibido que ha activado la respuesta automática, y esta respuesta normalmente se envía con una ruta de retorno vacía; de lo contrario, los respondedores automáticos podrían verse atrapados enviando respuestas automáticas de ida y vuelta. [ cita requerida ]
El Return-Pathes visible en el correo entregado como un campo de encabezado Return-Pathinsertado por el agente de entrega de correo SMTP ( MDA ) (que normalmente se combina con un agente de transferencia de correo o MTA ). El MDA simplemente copia la ruta inversa en el comando SMTP MAIL FROMen el Return-Path. El MDA también elimina los campos de encabezado falsos Return-Pathinsertados por otros MTA; generalmente se garantiza que este campo de encabezado refleja la última ruta inversa vista en el MAIL FROMcomando.
En la actualidad, 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 Sender Rewriting Scheme . Todavía existe una forma especial de ruta: la ruta vacía MAIL FROM:<>, que se utiliza para muchas respuestas automáticas y, especialmente, para todos los rebotes.
En sentido estricto, los rebotes enviados con un campo que no esté vacío Return-Pathson incorrectos. El RFC 3834 ofrece algunas heurísticas para identificar rebotes incorrectos en función de la parte local (lado izquierdo antes del "@") de la dirección en un campo que no esté 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 una parte de los datos de 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-FROMo "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 espacio vacío Return-Pathson informes de no entrega ( NDR ) o notificaciones de estado de entrega (DSN). Los DSN se pueden solicitar explícitamente con una extensión de servicio SMTP, sin embargo, no se usa ampliamente. Las solicitudes explícitas de detalles de fallas de entrega se implementan mucho más comúnmente con la ruta de retorno de sobre variable (VERP), mientras que las solicitudes explícitas para ellos rara vez se implementan. [6]
Los NDR son una función básica de SMTP. Una vez que un MTA ha aceptado un correo para reenviarlo o entregarlo, no puede eliminarlo ("descartarlo") silenciosamente; debe crear y enviar un mensaje de rebote al remitente si el reenvío o la entrega fallan.
Excluyendo a los MDA, todos los MTA reenvían correos a otro MTA. Este siguiente MTA es libre de rechazar el correo con un mensaje de error SMTP como "usuario desconocido" , "cuota excedida" , etc. En este punto, el MTA que envía el mensaje debe rebotar el mensaje , es decir, informar a su originador. Un rebote también puede ocurrir sin un MTA que lo rechace, o como dice RFC 5321:
"Si un servidor SMTP ha aceptado la tarea de retransmitir el correo y luego descubre que el destino es incorrecto o que el correo no se puede entregar por alguna otra razón, entonces DEBE construir un mensaje de notificación de "correo no entregable" y enviarlo al originador del correo no entregable (como lo indica la ruta inversa)."
Esta regla es esencial para SMTP: como lo dice el nombre, es un protocolo "simple" y no puede funcionar de manera confiable si el correo desaparece silenciosamente en agujeros negros, por lo que se requieren rebotes para detectar y solucionar problemas.
Sin embargo, hoy en día es habitual recibir correos electrónicos en su mayoría spam , que suelen utilizar Return-Pathdirecciones de correo falsificadas. En este caso, suele ser imposible para el MTA informar al remitente y enviar un rebote a la dirección falsificada Return-Pathafectaría a un tercero inocente. Además, existen razones específicas por las que es preferible descartar un mensaje en silencio en lugar de rechazarlo (y mucho menos rebotarlo ):
Citando nuevamente el RFC 5321, sección 6.2:
"Como se explica en las secciones 7.8 y 7.9, en la práctica se permite descartar mensajes sin notificar al remitente. Sin embargo, es extremadamente peligroso y viola una larga tradición y las expectativas de la comunidad de que el correo se entregue o se devuelva. Si se hace un mal uso de la técnica de descartar mensajes sin aviso, se podría fácilmente socavar la confianza en la fiabilidad de los sistemas de correo de Internet. Por lo tanto, la técnica de descartar mensajes sin aviso debería considerarse sólo en aquellos casos en los que haya una gran confianza en que los mensajes sean seriamente fraudulentos o inapropiados de alguna otra manera".
No validar al remitente es una falla inherente del SMTP actual, que no cuenta con las rutas de origen obsoletas mencionadas anteriormente. Esto se soluciona con varias propuestas, las más directas de BATV y SPF .
Existen muchas razones por las que un correo electrónico puede rebotar. Una de ellas es que la dirección del destinatario esté mal escrita o simplemente no exista en el sistema receptor. Esta es una condición desconocida para el usuario . Otras razones incluyen el agotamiento de los recursos (como un disco lleno) o el rechazo del mensaje debido a los filtros de spam . Además, existen MUA que permiten a los usuarios "rebotar" un mensaje a pedido. [7] Estos rebotes iniciados por el usuario son rebotes falsos; por definición, un rebote real es automático y lo emite un MTA o MDA.
Los mensajes de rebote en SMTP se envían con la dirección del remitente del sobre <>, conocida como dirección de remitente nula . Con frecuencia se envían con una From:dirección de encabezado MAILER-DAEMONen el sitio del destinatario.
Normalmente, un mensaje de rebote contendrá varios datos para ayudar al remitente original a comprender el motivo por el cual su mensaje no fue entregado:
RFC 3463 describe los códigos que se utilizan para indicar el motivo del rebote. Los códigos más comunes son 5.1.1 (Usuario desconocido), 5.2.2 (Buzón lleno) y 5.7.1 (Rechazado por política de seguridad/filtro de correo).
El formato para la notificación de mensajes administrativos está definido en RFC 6522. Un DSN puede ser un mensaje multiparte/informe MIME compuesto de tres partes:
La segunda parte de un DSN también es bastante legible. Es esencial entender qué MTA desempeñó qué función. El MTA de informes es responsable de redactar y enviar el DSN.
Cuando un MTA remoto rechaza un mensaje durante una transacción SMTP, se puede utilizar un campo de código de diagnóstico de tipo smtp para informar ese valor. Tenga en cuenta que, además del valor numérico de 3 dígitos, la respuesta SMTP contiene una parte legible para humanos. La información
MTA remoto: dns; smtp.store.example [ 192.0.2.3 ] Código de diagnóstico: smtp; 550 No existe ese usuario aquí mientras habla con smtp.store.example [192.0.2.3]>>> RCPT A:<[email protected]><<< 550 No existe ese usuario aquí
{{cite journal}}: Requiere citar revista |journal=( ayuda )Otro método para derrotar al correo no deseado es rebotar el correo hacia ellos. Esto crea la apariencia de que su cuenta no existe y, si tiene suerte, hace que su nombre sea eliminado de sus listas., y Breen, Christopher (27 de enero de 2006). "Rebotando a los espeluznantes". Macworld . Consultado el 2 de octubre de 2008 .
Como probablemente sepa, el uso del comando Rebotar de Mail (Mensaje > Rebotar) no es eficaz contra los spammers porque casi todo el spam que recibe lleva una dirección "de" falsificada.