Summary

  • RFC 2076 was an Informational catalogue, not a standards grant. It recorded fields from Internet mail, Usenet, X.400 gateways and common non-standard practice while preserving their different status.
  • Its exclusions were as important as its entries: SMTP, UUCP and NNTP envelope attributes and body-internal PEM or MOSS fields were outside the message-header layer.
  • A sound investigation must move from occurrence to definition, protocol, status, local handling and observed outcome. No earlier receipt proves a later one.

In February 1997, RFC 2076 offered something less dramatic and more useful than a new mail protocol: a map of the headers operators were already likely to encounter. The map did not make every road public. Its table could call a field standardized, experimental, controversial, discouraged, specific to Usenet, or suitable only for an X.400 gateway. Some entries merely described common behaviour with no standard behind it.

That distinction matters because header syntax is deceptively uniform. A colon after a familiar name makes a line easy to parse. It does not identify the institution that defined it, the protocol in which the definition applies, or the consequence an implementation should produce.

The catalogue kept context attached to the name

RFC 2076 drew from RFC 822 mail, RFC 1036 netnews and RFC 1327's X.400 gateway mapping, among other documents. It warned that Usenet fields sometimes appeared in email without becoming standardized there. X.400-derived fields such as X400-Received and Alternate-Recipient belonged to gateway work, not automatically to general Internet mail.

The same discipline later became structural. RFC 3864 created permanent and provisional message-header registries and allowed one field name to have separate protocol entries. It also stated that provisional registration was not IETF or IANA endorsement. RFC 4021 seeded the permanent mail registry while retaining notes such as obsolete or not for general use. The current IANA registry still presents protocol, status and reference as separate columns.

The boundary excluded other evidence layers

The catalogue explicitly excluded transport-envelope attributes carried by SMTP, UUCP or NNTP. It also excluded fields embedded inside PEM or MOSS bodies and headers used only by HTTP. Those omissions prevent a message header from impersonating a delivery command or a body-level security assertion.

An investigator therefore needs several records. The raw message proves what crossed the message boundary. The SMTP transcript or queue record may prove envelope sender and recipients. A gateway log may show a mapping. A delivery-status record may show an attempted result. Flattening them into one header dictionary destroys both provenance and responsibility.

Apparently-To demonstrated the privacy cost of inference

Some sendmail implementations inserted Apparently-To from envelope recipients when a message lacked To. RFC 2076 marked the field non-standard and discouraged, and warned that it could expose blind-copy recipients. The generated line transformed private transport knowledge into reader-visible content.

The parser could accurately report the line. The implementation still had to answer who created it, from which envelope state, under what policy, and whether disclosure was permitted. Presence did not supply those answers.

Reply-To showed that standard syntax did not settle intention

Reply-To had a standards basis, yet RFC 2076 called its use controversial. Personal replies, group replies and mailing-list replies can reflect different intentions. A list manager that rewrites the field is making a policy decision; a client that chooses one reply action is making another. Neither can borrow certainty from the field's standardized spelling.

This is why a standards reference is a definition receipt rather than an outcome receipt. It tells an implementation what a field can mean within scope. It does not prove that the sender was authorized, that intermediaries preserved it, or that the chosen user action matched the author's social intention.

Request headers were not delivery proof

Errors-To and Return-Receipt-To were catalogued as non-standard and discouraged. RFC 2076 pointed delivery notifications back toward the transport envelope and standardized mechanisms. A request header could be ignored, filtered, forged or interpreted differently. Even a later disposition notification would describe one agent's action, not necessarily human reading or final business effect.

The disciplined chain is therefore: field occurrence → defining record → protocol and context → registration or policy status → implementation decision → observed outcome. Each arrow needs its own evidence.

Sources