Zusammenfassung

  • RFC 2076 war ein informatorischer Katalog, keine pauschale Normung. Mail, Usenet, X.400-Gateways und nicht standardisierte Praxis behielten verschiedene Geltungsbereiche.
  • SMTP-, UUCP- und NNTP-Umschlagdaten sowie interne PEM- und MOSS-Felder waren ausgeschlossen. Der Headerblock war nie die gesamte Transaktion.
  • Die Beweiskette führt von Vorkommen über Definition, Protokoll und Status zur lokalen Entscheidung und zum beobachteten Ergebnis. Keine Stufe beweist die nächste.

RFC 2076 erfand 1997 keinen weiteren Header. Es ordnete Namen, die reale Systeme bereits sahen, ohne ihre Unterschiede zu glätten: standardisiert, experimentell, umstritten, nicht empfohlen, nur für Netnews, nur für X.400-Übergänge oder lediglich verbreitet.

Gleiche Syntax bedeutete keine gleiche Zuständigkeit

Der Katalog bezog RFC 822 für Mail, RFC 1036 für Usenet und RFC 1327 für X.400-Abbildungen ein. Ein Netnews-Feld wurde durch sein Auftauchen in einer Mail nicht dort standardisiert. X400-Received und Alternate-Recipient brachten ihren Gateway-Kontext mit.

RFC 3864 überführte diese Vorsicht in permanente und provisorische Register. Derselbe Name kann Protokolleinträge mit verschiedenen Status haben; provisorische Registrierung ist keine Billigung. RFC 4021 und das heutige IANA-Register halten Protokoll, Status und Referenz weiterhin getrennt.

Ausschlüsse schützten die Schichtgrenzen

Transportumschläge, Felder im PEM- oder MOSS-Nachrichtenkörper und reine HTTP-Header lagen außerhalb. Eine sichtbare Zeile ersetzte deshalb weder tatsächliche Empfänger noch Rückweg oder inhaltsinterne Sicherheitsangaben.

Eine Untersuchung bewahrt Rohmessage, Umschlag, Relaypfad, Gateway-Umformungen und Cliententscheidung getrennt. Ein früh normalisiertes Headerobjekt löscht Herkunft und Verantwortung.

Apparently-To machte Ableitung zum Datenschutzproblem

Manche sendmail-Versionen fügten das Feld aus Umschlagempfängern ein, wenn To fehlte. RFC 2076 nannte es nicht standardisiert und nicht empfohlen, weil Blindkopie-Empfänger sichtbar werden konnten. Private Transportkenntnis wurde zu Leserinhalt.

Reply-To war zwar standardisiert, blieb aber umstritten: persönliche Antwort, Gruppenreaktion und Listenpolitik sind verschiedene Absichten. Errors-To und Return-Receipt-To waren nicht standardisiert und nicht empfohlen. Eine Anforderung beweist weder Zustellung noch Lesen noch Wirkung.

Belastbar ist nur: Vorkommen → Referenz → Kontext → Status → Behandlung → Ergebnis.

Quellen