Resumen

  • Desde RFC 733, el sistema que generaba un identificador debía garantizar su unicidad. Una revisión recibía otro ID; añadir trazas durante el transporte no tenía por qué cambiar la identidad original.
  • In-Reply-To y References convirtieron el ID en una arista de conversación. Netnews lo volvió memoria local: cada servidor descartaba un identificador ya visto y terminaba así los ciclos de distribución.
  • El nombre nunca fue firma ni huella del contenido. Netnews trataba como un mismo artículo dos cuerpos distintos con igual ID, de modo que un valor predecible podía ocuparse primero y excluir el artículo esperado.

Cambiaron los bytes, no el mensaje

Cuando un correo entra en transporte, el siguiente relé puede anteponer Received. La copia almacenada ya no coincide byte por byte con la enviada. Sin embargo, el relé no ha creado una revisión del argumento y conserva el Message-ID original.

Si el autor modifica lo que quiere expresar y publica esa revisión como otra versión, necesita un identificador nuevo aunque cambie poco texto. RFC 733 ya separaba ambos casos en 1977: un ID se refiere a una sola versión o instancia, las revisiones posteriores reciben IDs nuevos y el host generador garantiza la unicidad.

RFC 822 mantuvo la regla en 1982. El valor era legible por máquinas y no necesitaba tener significado humano. No resumía el asunto ni certificaba a una persona; ofrecía un asa estable para una versión declarada.

Un nombre global armado con trabajo local

RFC 5322 exige que el msg-id sea globalmente único y que el generador lo garantice. No crea, en cambio, una oficina que asigne números mensaje a mensaje.

La recomendación divide el espacio. A la derecha de @, un identificador de dominio delimita el ámbito; a la izquierda, el generador coloca un valor que puede mantener único allí, quizá tiempo combinado con secuencia o dato de proceso. Un ámbito distinguible globalmente más contabilidad local producen un nombre global sin una transacción global.

Su forma recuerda una dirección, pero no lo es. La derecha no constituye un buzón, no debe resolver hoy y no prueba que el emisor controle el dominio. La izquierda tampoco autoriza a terceros a deducir significado empresarial.

El mismo RFC sitúa la identidad en la intención. Agregar campos de traza o reenvío cambia la sintaxis sin crear necesariamente otro mensaje. Que el ID cambie depende de si el remitente considera que comunica el mismo mensaje u otro, no de una diferencia concreta de bytes. Message-ID no es checksum ni identificador de una transacción SMTP.

La respuesta se volvió una relación portable

In-Reply-To lleva el ID del mensaje padre. References hereda los antepasados declarados por ese padre y añade su ID. El software puede reconstruir una conversación aunque sus piezas hayan seguido rutas y horarios distintos.

El uso precede a los clientes modernos. RFC 850, en 1983, requería que un follow-up de Usenet prolongara References. Su finalidad declarada era agrupar artículos en conversaciones y permitir que un lector ocultara una conversación entera sin abandonar el grupo. RFC 1036 conservó el mecanismo.

La arista sigue siendo una declaración. RFC 5322 advierte que muchas interfaces recorren la cadena suponiendo un único padre y que la composición con varios padres no está definida por completo. References no autentica al autor ni demuestra comprensión o causalidad.

Cada servidor convirtió el ID en memoria

En la inundación entre pares de Usenet, un artículo podía llegar desde varios vecinos. Reenviarlo tras cada llegada mantendría vivo un ciclo. RFC 1036 describe el historial: cada host anota por Message-ID los artículos que ya vio y descarta inmediatamente otra llegada con igual ID. Path evita además envíos inútiles, pero el historial local basta para romper el bucle.

Ningún servidor maestro declara completada la distribución. Cada sitio contrasta el nombre con su propia memoria y decide que ya admitió ese artículo lógico. La misma referencia que ordenaba la conversación humana pasa a ser clave de deduplicación distribuida.

El nombre igual pesó más que los cuerpos distintos

RFC 5536 hace explícito el precio: Netnews considera iguales los artículos con el mismo Message-ID aunque difieran sus cabeceras o cuerpos. Restringe la sintaxis, limita la longitud y preserva mayúsculas para que baste una comparación de octetos. La unicidad abarca los protocolos que usan estos IDs, en especial correo y Netnews.

La comparación rápida otorga poder a una colisión. Si un atacante predice el ID de un futuro artículo y publica otro objeto primero, el esperado puede rechazarse como ya visto. RFC 5536 recomienda por eso identificadores impredecibles. No falló un hash del contenido; nunca hubo tal hash. Falló el orden de llegada a un libro distribuido de nombres.

Lo que el nombre nunca probó

Message-ID resuelve referencia, no confianza. No firma el cuerpo, no autentica From, no identifica la transacción del sobre SMTP, no prueba lectura ni garantiza bytes iguales. Un mismo ID puede ocultar colisión; IDs diferentes pueden portar el mismo texto.

La modestia sostuvo el diseño. El origen nombra; el transporte añade custodia sin renombrar; el cliente crea relaciones; cada servidor de noticias gestiona historial y colisiones locales. La prueba criptográfica pertenece a otra capa.

Fuentes y límites

La cadena cerrada reúne RFC 733, RFC 822, RFC 850, RFC 1036, RFC 2822, RFC 5322 y RFC 5536. Establece contratos y riesgos reconocidos, no tasas actuales de colisión, algoritmos de proveedores, despliegue mundial ni plazos de historial.