Resumen

  • RFC 1036 exigió una línea Approved: para los artículos enviados a grupos moderados y recomendó que el moderador añadiera su dirección de correo.
  • Era una señal de admisión, no una credencial criptográfica: un documento histórico posterior dijo expresamente que no se podía autenticar la aprobación declarada.

La decisión tenía que viajar con el artículo

Usenet no recibía cada texto en una base central donde una autoridad única aprobara la copia definitiva. Los artículos pasaban entre sitios que intercambiaban ciertos grupos y guardaban copias locales. Para que la moderación funcionara a través de ese recorrido, el mensaje necesitaba una indicación legible por el software: ¿podía seguir hacia la distribución normal o todavía debía pasar por revisión?

La RFC 1036, publicada en diciembre de 1987 como norma para intercambiar mensajes de Usenet, dio a esa indicación un nombre corto: Approved. El campo figuraba entre las cabeceras generalmente opcionales, pero era obligatorio para cualquier artículo de un grupo moderado. El moderador debía añadirlo con su dirección de correo. Esa dirección ofrecía una vía concreta de contacto y permitía que los programas reconocieran un estado. La norma no describía una firma, una clave ni un directorio confiable para comprobar que la dirección pertenecía al moderador reconocido.

Así podían confundirse dos cosas. La regla suponía que había ocurrido una decisión humana; la cabecera permitía que el software detectara que esa decisión se declaraba en el artículo. No mostraba la revisión, sus criterios ni quién la había realizado. La palabra expresaba un estado y la dirección señalaba un contacto. Ninguna equivalía a un recibo autenticado de la aprobación.

El mismo campo acompañaba órdenes sobre los grupos

El ejemplo de la RFC 1036 muestra el aspecto del campo. Un informe de lectura fechado el 1 de octubre de 1986 aparece cruzado en news.lists y news.groups, con un campo Approved que identifica la dirección del moderador. Su cabecera Xref indica números locales en el sistema seismo. El ejemplo permite ver una dirección dentro de un artículo que circulaba por la red; no mide la frecuencia de uso ni cómo verificaba cada sitio el remitente.

La cabecera también intervenía en un contexto de mayor alcance. La RFC describe el mensaje de control newgroup, que solicitaba crear un grupo y podía pedir que se estableciera como moderado. Los sitios debían ignorar el mensaje si no incluía Approved. La instrucción rmgroup, que solicitaba retirar un grupo de todos los hosts, tenía el mismo requisito. El documento pedía cuidado porque la eliminación afectaba a toda la red. El campo ayudaba al software a diferenciar una instrucción común de otra que afirmaba contar con aprobación, pero no autenticaba a la autoridad invocada.

Esa reutilización muestra una tensión de los sistemas distribuidos: un protocolo puede hacer visible una decisión en todos los nodos sin hacer verificable su origen. Cada sitio podía comprobar si el campo existía, pero eso no demostraba que el buzón perteneciera al moderador o administrador legítimo. La norma ofrecía un punto de control común; los acuerdos locales aportaban la confianza.

El borrador posterior describió la brecha de confianza

La cronología de “Son of 1036” debe contarse con precisión. La RFC 1849 se publicó como documento histórico en marzo de 2010 para conservar un borrador que había circulado ampliamente a comienzos de los años noventa y que, según su autor, se convirtió en referencia de facto para quienes implementaban software de noticias. El propio documento explica que es contexto histórico, no una guía vigente de implementación.

Ese texto separó mejor las funciones del software. Un agente de publicación atendía el envío de un usuario local: podía preparar el artículo, revisar su conformidad y remitirlo para su distribución. Un relayer recibía artículos ya preparados de otros relayers y los reenviaba. En un grupo moderado, la ausencia de Approved indicaba al agente de publicación que debía enviar la contribución del lector al moderador. El relayer debía descartar el artículo no aprobado, en lugar de convertirlo en un correo de solicitud. Un mismo programa podía cumplir ambos papeles, pero sus responsabilidades eran distintas.

La RFC histórica enuncia la limitación sin rodeos: no había forma de autenticar Approved para demostrar que la aprobación declarada se hubiera concedido, ni un mecanismo mantenido para saber quiénes eran los aprobadores legítimos. La autenticación criptográfica aparecía como una posible ampliación, aunque el documento advertía que muchos sistemas no tenían acceso en tiempo real a servidores de claves. Esto prueba que el diseño reconocía un límite; no prueba que hubiera ocurrido un fraude específico ni que todos los sitios aceptaran cabeceras falsificadas.

La RFC 5537, posterior, formalizó el recorrido: un agente de inyección remite el artículo sin aprobación al moderador del primer grupo moderado de la lista, normalmente por correo electrónico. La aprobación y la inyección se mantienen separadas del relaying habitual. Esta norma posterior ayuda a ver la división de funciones, pero no debe proyectarse sin matices sobre cada instalación de los años ochenta.

Lo que hacía la línea y lo que dejaba pendiente

Approved: no carecía de valor por no incluir prueba criptográfica. Daba a los programas de noticias una condición compartida para procesar artículos y una dirección práctica para la moderación. Permitía que una decisión editorial viajara con una publicación distribuida. Pero esa portabilidad terminaba donde empezaban los acuerdos de confianza alrededor del campo.

La red podía transportar una declaración de aprobación; el texto por sí solo no demostraba la autoridad que la respaldaba. La revisión humana, la administración de direcciones, la política local y el tratamiento del software seguían siendo partes separadas del proceso. La norma reservó un lugar visible a la decisión, pero no creó un método universal para demostrar quién la había tomado.

Fuentes