Analizador de cabeceras de correo

Qué puede mostrar una cabecera de correo y qué no

El correo de Internet utiliza campos de cabecera con nombre, seguidos de una línea en blanco y el cuerpo del mensaje. RFC 5322 define este formato, incluido el plegado de campos: una línea que comienza con un espacio continúa el campo anterior. El analizador despliega esas continuaciones antes de interpretar los datos. Se detiene en la primera línea en blanco, por lo que no analiza ni el cuerpo ni los adjuntos.

Los agentes de transferencia de correo suelen añadir al principio un campo Received cada vez que el mensaje atraviesa un servidor. Por eso aparecen del más reciente al más antiguo en el código fuente. El informe los invierte y presenta una cronología que comienza en el origen. Solo muestra una diferencia temporal cuando puede interpretar los dos sellos de tiempo contiguos. Una diferencia negativa se señala como posible desfase de reloj e impide calcular el tiempo total de tránsito; nunca se cambia silenciosamente por cero.

Cómo leer la sección de autenticación

RFC 8601 define Authentication-Results, un campo que añade el sistema receptor para registrar resultados como spf=pass, dkim=pass o dmarc=fail. El analizador conserva los Authentication-Results repetidos porque un mensaje puede atravesar más de un dominio administrativo. También mantiene propiedades asociadas como smtp.mailfrom, header.d y header.from tal como se declararon.

Una DKIM-Signature contiene metadatos como el dominio firmante (d=), el selector (s=), el algoritmo (a=), la identidad (i=) y valores criptográficos extensos (b= y bh=). El informe registra etiquetas útiles y si existen valores de firma, pero excluye deliberadamente los bloques de firma de las exportaciones JSON. No consulta DNS ni realiza verificación criptográfica.

RFC 8617 define Authenticated Received Chain (ARC). Una instancia ARC está estructuralmente completa cuando contiene un elemento ARC-Seal, otro ARC-Message-Signature y otro ARC-Authentication-Results con el mismo valor i=. «Completa» solo describe la presencia de esos tres elementos; no significa que la cadena sea válida o fiable.

Ejemplo práctico de ruta

Supongamos que el código fuente contiene dos campos Received. El inferior indica que un origen entregó el mensaje a un relé a las 10:00:03 +0000; el superior, que el relé llegó al destinatario a las 10:00:10 +0000. El informe muestra primero el evento de origen y calcula un intervalo observado de 7 segundos. Se respetan los husos horarios: entre 10:00:03 +0000 y 12:00:06 +0200 hay 3 segundos, no dos horas. Si el segundo sello normalizado es cinco segundos anterior, el informe avisa de un desfase de reloj y deja el total como no disponible.

Límites de confianza y errores habituales

RFC 5321 describe el transporte SMTP y la información de trazado que añaden los servidores. Las cabeceras recibidas desde fuera de un sistema de correo de confianza pueden inventarse. Comienza a confiar en un receptor que controles y retrocede solo hasta donde sus registros y políticas lo justifiquen. Una diferencia entre los dominios del From visible y del Return-Path es habitual en listas de correo, servicios de reenvío y plataformas transaccionales: es una observación, no una prueba de suplantación.

Los asuntos y nombres visibles codificados pueden usar palabras codificadas según RFC 2047. El analizador descodifica formatos Base64 o quoted-printable habituales en UTF-8, ISO-8859-1 y Windows-1252; las codificaciones no compatibles quedan visibles con un aviso. Para mantener el navegador ágil, limita las colecciones de campos y saltos muy grandes. En una respuesta a incidentes, conserva aparte el mensaje original: las exportaciones son informes concisos y no incluyen la entrada original, el cuerpo, los adjuntos ni los bloques de firma DKIM.

Privacidad y exportaciones

La interpretación, selección, copia y creación de exportaciones se realizan localmente en la pestaña actual. Los pasos del embudo usan almacenamiento de sesión asociado a la pestaña, no una URL, por lo que la cabecera en bruto no se envía mediante Livewire ni se expone en parámetros de navegación. El límite de entrada es 512 KiB. El CSV de la cronología usa UTF-8 con marca de orden de bytes y filas CRLF; se neutralizan las celdas que empiezan por caracteres de fórmula de hoja de cálculo. El JSON incluye las observaciones interpretadas y la advertencia del informe, no la cabecera original.