🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónLectura de cabeceras de un mensaje
5 tareas · 38 min · Principiante
Las cabeceras de un mensaje son el rastro de su viaje, pero no todas dicen la verdad: unas las escribieron los servidores de la empresa y otras las escribió quien envió. Aprender a separarlas es la base de cualquier análisis de correo sospechoso. Tienes las cabeceras completas de un mensaje ficticio recibido por Curtiembres Piedra Larga el 14 de agosto de 2028 y la lista de sus servidores propios. Es evidencia de ejemplo: se lee y no se envía nada.
Objetivo de la sala
Las cabeceras de un mensaje son el rastro de su viaje, pero no todas dicen la verdad: unas las escribieron los servidores de la empresa y otras las escribió quien envió. Aprender a separarlas es la base de cualquier análisis de correo sospechoso. Tienes las cabeceras completas de un mensaje ficticio recibido por Curtiembres Piedra Larga el 14 de agosto de 2028 y la lista de sus servidores propios. Es evidencia de ejemplo: se lee y no se envía nada.Cada servidor que maneja el mensaje añade una cabecera Received arriba de las existentes (RFC 5321). Por eso la primera línea es el último salto y la última es el más antiguo: la historia se lee de abajo hacia arriba.
Hay un límite de confianza. Una línea Received solo es fiable si la añadió un sistema propio, porque solo ese sistema es el que la escribió. Las líneas de abajo, anteriores a la llegada a tu primer servidor, las escribió el emisor o sus intermediarios y pueden contener nombres, direcciones y horas inventados. Lo único sólido es lo que tu primer servidor vio y anotó: la dirección desde la que se conectó.
Responde para continuar
¿Cómo se lee la cadena de cabeceras Received y cuáles se pueden creer?
Ver pista de ayuda
Cada servidor añade su línea encima de las que ya estaban; la confianza se corta donde empieza lo ajeno.
Tu primera línea fiable es la que añadió la pasarela de la empresa: su fragmento from nombra al sistema que se le conectó y entre corchetes lleva la dirección IP que la pasarela vio en la conexión. Esa dirección sí es evidencia; el nombre que el otro servidor dijo ser es solo lo que declaró.
Consulta cabeceras y servidores_propios para saber qué línea añadió la pasarela.
Responde para continuar
¿Qué dirección IP anotó la pasarela como la del servidor que le entregó el mensaje? Escribe la dirección.
La cabecera From es la que ve la persona y se puede escribir con cualquier valor. Reply-To indica a dónde irá la respuesta si la persona pulsa «responder», y Return-Path indica a dónde irían los rebotes. Cuando difieren del From, hay que preguntar por qué: es una señal habitual de suplantación (no una prueba, hay envíos legítimos con otro Reply-To).
Responde para continuar
¿A qué dirección iría la respuesta si el destinatario pulsa «responder»? Escribe la dirección completa.
Las líneas Received llevan fecha y hora con zona horaria. Restar las horas de dos saltos propios dice cuánto tiempo estuvo el mensaje en el medio, y un retraso largo puede ser análisis de adjuntos, una cola o una retención. Los saltos ajenos no sirven para esto, porque sus horas no son fiables.
Usa las líneas Received que añadieron sistemas propios; ambas están en la misma zona horaria.
Responde para continuar
¿Cuántos segundos pasaron entre que la pasarela recibió el mensaje y que el servidor de buzones lo recibió de ella? Escribe solo el número.
La cabecera Authentication-Results (RFC 8601) la añade el sistema que evaluó el mensaje y resume SPF, DKIM y DMARC. Léela con el nombre del sistema que la escribió: si lo escribió tu pasarela, es evidencia; si venía del emisor, no lo es.
Aquí el resultado de DMARC es fail y el mensaje llegó a la bandeja. Eso no es necesariamente un error de la pasarela: depende de lo que el dominio publica y de las reglas que la propia pasarela tenga.
Responde para continuar
El mensaje trae dmarc=fail en Authentication-Results y se entregó. ¿Qué lo explica, si el dominio publica p=none?
Ver pista de ayuda
Un receptor aplica lo que el dominio pide, salvo que tenga reglas propias que lo endurezcan.
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.