Resumen

  • RFC 2076 fue un catálogo informativo, no una homologación: correo, Usenet, pasarelas X.400 y prácticas no estándar conservaron ámbitos y estados distintos.
  • Excluyó el sobre de transporte de SMTP, UUCP y NNTP, además de atributos internos de cuerpos PEM o MOSS. El bloque de encabezados nunca fue toda la transacción.
  • La ruta de prueba es aparición, definición, protocolo, estado, decisión local y resultado observado; ningún eslabón sustituye al siguiente.

Publicado en febrero de 1997, RFC 2076 no inventó otro campo. Ordenó el vocabulario que programas y operadores ya encontraban, y puso advertencias donde la forma uniforme podía engañar. Un nombre podía estar normalizado, ser experimental, controvertido o desaconsejado, pertenecer a noticias o existir sólo en el trabajo de una pasarela X.400.

La sintaxis no borraba la procedencia

El catálogo reunía referencias de RFC 822, RFC 1036 y RFC 1327, entre otras. Advertía que un campo de Usenet podía circular en correo sin quedar estandarizado allí. X400-Received y Alternate-Recipient describían conversiones de pasarela; no adquirían autoridad general por llegar a una bandeja.

RFC 3864 convirtió después esa disciplina en registros permanentes y provisionales. El mismo nombre puede tener entradas para protocolos distintos y una inscripción provisional no es aprobación de IETF o IANA. RFC 4021 y el registro vigente de IANA siguieron mostrando protocolo, estado y referencia por separado.

Lo excluido trazaba una frontera operativa

RFC 2076 no incluía los atributos del sobre de SMTP, UUCP o NNTP, ni campos incrustados en cuerpos PEM o MOSS, ni encabezados exclusivos de HTTP. Por eso un campo visible no podía sustituir la dirección de retorno del transporte, la lista real de destinatarios o una afirmación de seguridad del cuerpo.

Una investigación necesita conservar mensaje bruto, sobre, trazas de relé, transformaciones de pasarela y decisiones del cliente. Reducirlos a un único mapa de nombres borra al actor que tomó cada decisión.

Apparently-To mostró un riesgo de privacidad

Algunas versiones de sendmail añadían Apparently-To desde el sobre cuando faltaba To. RFC 2076 lo marcaba como no estándar y desaconsejado porque podía revelar destinatarios ocultos. La generación automática convertía conocimiento privado del transporte en contenido para el lector.

Un campo estándar tampoco resolvía la intención

Reply-To tenía definición estándar, pero su uso era controvertido. Responder a una persona, al grupo o según la política de una lista son acciones diferentes. La reescritura del servidor y la elección del cliente siguen siendo decisiones locales.

Errors-To y Return-Receipt-To eran no estándar y desaconsejados. Solicitar un aviso no prueba entrega, lectura ni efecto. La evidencia sólida enlaza ocurrencia → documento definitorio → contexto → estado → tratamiento → resultado, sin saltos.

Fuentes