Un mensaje de rebote o simplemente "rebote" es un mensaje automatizado de un sistema de correo electrónico, que informa al remitente de un mensaje anterior que el mensaje no ha sido entregado (o que ha ocurrido algún otro problema de entrega). Se dice que el mensaje original "rebotó".
Esta retroalimentación puede ser inmediata (algunas de las causas que se describen aquí) o, si el sistema emisor puede volver a intentarlo, 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 [fallido] "Notificación de estado de entrega" (DSN) o "Notificación de no entrega" (NDN). [1]
Aunque SMTP es una tecnología madura, con más de treinta años, su arquitectura está cada vez más sobrecargada tanto por la carga normal como por la 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 falsificado en el protocolo. [3]
Por ello, se han creado dos tipos de rebotes de correo electrónico: rebotes duros y rebotes suaves . [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 suave.
Los rebotes duros son permanentes y obtienen una puntuación más alta en términos de daño a la propiedad intelectual 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 permanezca 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 no acepta correos electrónicos más. En este caso, es obligatoria la eliminación de las direcciones de correo electrónico que rebotan.
Los rebotes suaves son temporales. Se puede intentar volver a entregar un mensaje devuelto que experimente un rebote suave en otro momento. [5] Los rebotes suaves ocurren cuando el destinatario del correo electrónico tiene una 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 puede recibir. Las situaciones adicionales en las que aparece un rebote suave son un bloqueo configurado 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.
Pueden ocurrir errores en varios lugares durante la entrega del correo. En ocasiones, un remitente puede recibir un mensaje rebotado de su propio servidor de correo, informándole que no ha podido enviar un mensaje, o alternativamente, de un servidor de correo del destinatario informando que aunque aceptó el mensaje, no puede entregarlo a la dirección especificada. usuario. Cuando un servidor acepta un mensaje para su entrega, también acepta la responsabilidad de entregar un mensaje devuelto en caso de que la entrega falle.
Cuando llega un correo electrónico al servidor de destino para una dirección (como micorreo.ejemplo, 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 El disco duro subyacente del servidor no tiene espacio suficiente.
Al enviar un correo electrónico, es posible que el servicio desde el que se envía el correo electrónico no pueda llegar a la dirección de destino. En tal 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 llegar a 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 spam de correo electrónico o de los virus del correo electrónico , donde un spammer (remitente) puede falsificar un mensaje para otro usuario (destinatario previsto del spam) y falsificar el mensaje para que aparezca de otro usuario (un tercero). . Si el mensaje no se puede entregar al destinatario previsto, entonces el mensaje devuelto se "devolverá" al tercero en lugar del spammer. Esto se llama retrodispersión .
Si el servidor de correo biblioteca.ejemplo hubiera sabido que el mensaje no se podría entregar (por ejemplo, si Jill no tenía una cuenta de usuario allí), entonces 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 ) la obligación de crear y entregar un rebote.
Los rebotes son una forma especial de respuesta automática . Las respuestas automáticas (respuestas automáticas) son correos electrónicos enviados por un programa, a diferencia de un usuario humano, en respuesta a un correo recibido y enviado a la dirección de rebote .
Ejemplos de otras respuestas automáticas son los correos electrónicos de vacaciones , los desafíos del filtrado de spam de respuesta a desafío , 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 persona Return-Pathindicada en el correo recibido que ha activado la respuesta automática, y esta respuesta generalmente se envía con una ruta de retorno vacía; de lo contrario, los respondedores automáticos podrían quedar atrapados en el envío de respuestas automáticas de un lado a otro. [ cita necesaria ]
Es Return-Pathvisible en el correo entregado como campo de encabezado insertado por el agente de entrega de correoReturn-Path SMTP ( MDA ) (que generalmente se combina con un agente de transferencia de correo o MTA ). El MDA simplemente copia la ruta inversa del comando SMTP en el archivo . La MDA también elimina campos de encabezado falsos insertados por otros MTA; Generalmente se garantiza que este campo de encabezado reflejará la última ruta inversa vista en el comando.MAIL FROMReturn-PathReturn-PathMAIL FROM
Hoy en día, estas rutas normalmente se reducen a direcciones de correo electrónico ordinarias , ya que el antiguo ' enrutamiento de origen ' SMTP quedó obsoleto en 1989; para obtener información histórica, consulte Esquema de reescritura del remitente . Todavía existe una forma especial de ruta: la ruta vacía MAIL FROM:<>, utilizada para muchas respuestas automáticas y especialmente para todos los rebotes.
En sentido estricto, los rebotes enviados con un mensaje no vacío Return-Pathson incorrectos. RFC 3834 ofrece algunas heurísticas para identificar rebotes incorrectos basados en la parte local (lado izquierdo antes de "@") de la dirección en un correo no vacío Return-Path, e incluso define un campo de encabezado de correo, Auto-Submittedpara identificar respuestas automáticas. Pero el encabezado del correo es parte de los datos del correo (comando SMTP DATA) y los MTA normalmente no examinan el correo. Se ocupan del sobre , que incluye la MAIL FROMdirección (también conocida Return-Pathcomo Envelope-FROM"ruta inversa") pero no, por ejemplo, el RFC 2822 Fromen el campo del encabezado del correo From. Estos detalles son importantes para esquemas como BATV .
Los rebotes restantes con un 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, aunque no se utiliza mucho. Las solicitudes explícitas de detalles de errores de entrega se implementan mucho más comúnmente con la ruta de retorno de sobre variable (VERP), mientras que las solicitudes explícitas rara vez se implementan. [6]
Los NDR son una función SMTP básica. Tan pronto como un MTA ha aceptado un correo para su reenvío o entrega, no puede eliminarlo ("eliminarlo") silenciosamente; tiene que crear y enviar un mensaje de rebote al autor si falla el reenvío o la entrega.
Excluyendo a los MDA, todos los MTA reenvían correos a otro MTA. El próximo MTA es libre de rechazar el correo con un mensaje de error SMTP como "usuario desconocido" , "sobre cuota" , etc. En este punto, el MTA emisor tiene que rebotar el mensaje , es decir, informar a su autor. También puede surgir un rebote sin un MTA que lo rechace, o como lo expresa el 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 puede entregarse por algún otro motivo, DEBE crear un mensaje de notificación de "correo no entregado" y enviarlo al autor. del correo que no se pudo entregar (como lo indica la ruta inversa)".
Esta regla es esencial para SMTP: como su nombre lo indica, es un protocolo "simple", 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.
Hoy en día, sin embargo, puede ser común recibir principalmente correos electrónicos no deseados , que generalmente utilizan Return-Pathcorreos electrónicos falsificados. Entonces, a menudo resulta imposible para la MTA informar al autor, y enviar un rebote al falsificado Return-Pathperjudicaría a un tercero inocente. Además, existen razones específicas por las que es preferible dejar un mensaje en silencio en lugar de rechazarlo (y mucho menos rebotarlo ):
Citando nuevamente RFC 5321, sección 6.2:
"Como se analiza en la Sección 7.8 y la Sección 7.9 a continuación, en la práctica se permite dejar el correo sin notificar al remitente. Sin embargo, es extremadamente peligroso y viola una larga tradición y expectativas de la comunidad de que el correo se entrega o se devuelve. Si el envío de mensajes es silencioso Si se utiliza indebidamente, fácilmente podría socavar la confianza en la confiabilidad de los sistemas de correo de Internet, por lo que la eliminación silenciosa de mensajes debe considerarse sólo en aquellos casos en los que existe una confianza muy alta de que los mensajes son gravemente fraudulentos o inapropiados de alguna otra manera".
No validar el remitente es una falla inherente al SMTP actual, que carece de las rutas de origen obsoletas mencionadas anteriormente. Esto se aborda en varias propuestas, la mayoría directamente de BATV y SPF .
Hay muchas razones por las que un correo electrónico puede rebotar. Una razón es si la dirección del destinatario está mal escrita o simplemente no existe 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 está automatizado y lo emite un MTA o MDA.
Los mensajes devueltos en SMTP se envían con la dirección del remitente del sobre <>, conocida como dirección del remitente nula . Con frecuencia se envían con una From:dirección de encabezado MAILER-DAEMONen el sitio del destinatario.
Normalmente, un mensaje devuelto contendrá varios datos para ayudar al remitente original a comprender el motivo por el que no se entregó su mensaje:
RFC 3463 describe los códigos utilizados para indicar el motivo del rebote. Los códigos comunes son 5.1.1 (usuario desconocido), 5.2.2 (buzón lleno) y 5.7.1 (rechazado por la política de seguridad/filtro de correo).
El formato para el informe de mensajes administrativos está definido por RFC 6522. Un DSN puede ser un mensaje MIME multiparte/informe compuesto de tres partes:
La segunda parte de un DSN también es bastante legible. Es esencial entender qué MTA jugó qué papel. El Reporting-MTA 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 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 por humanos. La información
MTA remoto: dns; smtp.store.example [ 192.0.2.3 ] Código de diagnóstico: smtp; 550 No existe tal usuario aquí mientras habla con smtp.store.example [192.0.2.3]>>> RCPT A:<[email protected]><<< 550 No existe tal usuario aquí
{{cite journal}}: Citar diario requiere |journal=( ayuda )Otro método para combatir el spam es devolverles el correo. Esto crea la apariencia de que su cuenta no existe y, si tiene suerte, eliminará su nombre de sus listas.y Breen, Christopher (27 de enero de 2006). "Haciendo rebotar los pelos de punta". Macmundo . Consultado el 2 de octubre de 2008 .
Como probablemente sepa, usar el comando Rebotar de Mail (Mensaje > Rebotar) no es efectivo contra los spammers porque casi todo el spam que recibe lleva una dirección "de" falsificada.