Zusammenfassung

  • RFC 5364 erzeugt aus einer expandierten URI-Liste für jeden Empfänger eine eigene Historie. Fehlendes copyControl wird zu bcc; Blindkopien verschwinden aus fremden Ansichten, anonymisierte Einträge können Platzhalter und Anzahl erhalten.
  • Dieselbe URI soll höchstens eine Anfrage erhalten. Bei konkurrierenden Klassen gilt to vor cc vor bcc; unabhängig davon hat bcc Vorrang vor anonymize. Normalisierung und Offenlegung brauchen getrennte Nachweise.
  • recipient-list-history ist aus Kompatibilitätsgründen optional und beweist weder Existenz noch Erreichbarkeit, Annahme, Teilnahme oder Abrechnung. Geschützter Transport macht die Projektion nicht vollständig oder wahr.

Weglassen und anonym anzeigen sind zwei Entscheidungen

Anonymisierung entfernt die Identität, nicht zwingend die Existenz. Der Platzhalter kann mit count anzeigen, wie viele verdeckte Einträge vertreten sind. Diese Zahl kann in einer sensiblen Besprechung oder Verhandlung selbst bedeutsam sein.

bcc verlangt für die Ansichten anderer Empfänger mehr: Der Eintrag wird weggelassen. Nur in der gesonderten Kopie des blinden Empfängers kann dessen eigene URI erscheinen, damit das Endgerät vor einer entlarvenden Antwort an alle warnen kann.

Stehen beide Attribute am selben Eintrag, gewinnt bcc. Ein anonymer Platzhalter wäre bereits eine Offenlegung, obwohl die Blindkopie die Existenz verbergen sollte.

Die Prüfung muss deshalb Identitäts- und Kardinalitätslecks getrennt messen. Zu speichern sind Ausgangsattribute, Prioritätsregel, vollständig entfernte Einträge, anonymisierte Gruppen, Zählwerte und der tatsächlich erzeugte Textkörper.

Eine Benutzeroberfläche mit nur einem Status „privat“ reicht nicht. Sie kann nicht erklären, welche Information beim Empfänger verblieben ist.

Jede Anfrage trägt eine Beobachtersicht

Der Relay expandiert die Ressourcenliste und baut danach für jede ausgehende Anfrage eine recipient-list-history. Das ist keine Kopie des Masterdokuments.

Sichtbare to- und cc-Einträge können erhalten bleiben. Blindkopien werden entfernt. Der blinde Empfänger kann eine andere Fassung erhalten als alle übrigen.

Unterschiedliche Body-Hashes aus demselben Lauf sind daher nicht automatisch Manipulation. Ob die Differenz korrekt ist, entscheidet sich aus Beobachter, Regelversion und den sichtbaren, entfernten oder ersetzten Einträgen.

Der Nachweis verbindet Hash der Ursprungsliste, Expansionsgraph, aufgelöste Klassifikation, Empfängeridentität, Anfrage-ID und Hash der jeweiligen Historie. Eine gemeinsame flache Empfängertabelle zerstört genau diese Zuordnung.

Der Listenschreiber kontrolliert den Auftrag, der Relay kontrolliert die Offenlegung, und der Empfänger sieht nur seine Projektion. Keine dieser Ebenen ist bereits eine Teilnehmerliste.

Fehlendes copyControl fällt auf bcc zurück

Ist das Attribut nicht vorhanden, schreibt RFC 5364 bcc vor. Alte Listen, unvollständige Produzenten oder Migrationen mit verlorenen Metadaten geben dem Relay damit keine Freiheit zur Veröffentlichung.

Explizites und standardmäßig angewandtes bcc führen zur gleichen Ausgabe, haben aber verschiedene Diagnosewerte. Das eine ist erklärte Absicht, das andere eine sichere Interpretation lückenhafter Eingabe.

Original-XML, Hash, Schema, Attributpräsenz, Parser, Defaultregel und Endklasse müssen erhalten bleiben. Wird beim Import nur ein ausgefüllter Wert gespeichert, verschwindet die Information über die ursprüngliche Lücke.

Beim Austausch einer Parserbibliothek sollte dasselbe Fixture ohne Attribut weiterhin blind bleiben. Eine scheinbar kleine Defaultänderung kann einen langjährigen Datenbestand offenlegen.

Ein Duplikat trägt möglicherweise widersprüchliche Sichtbarkeit

Nach Expansion verschachtelter Listen kann dieselbe URI mehrfach auftreten. Entscheidend sind die Vergleichsregeln des URI-Schemas, nicht bloß identische Zeichenfolgen.

Mehrere Anfragen an dieselbe Identität haben laut Spezifikation keinen vernünftigen Zweck. Es soll höchstens eine geben; bei unterschiedlichen Klassen gewinnt to, dann cc, dann bcc.

Ein „erste Zeile gewinnt“-Verfahren macht die Bedeutung von der Reihenfolge abhängig. Zweimaliges Senden kann demselben Endgerät widersprüchliche Historien geben. Zu weite Normalisierung kann getrennte Ziele verschlucken.

Der Beleg umfasst Originalformen, Vergleichsalgorithmus, Kollisionsgruppe, Herkunftspfade, alle Attribute, Gewinnerklasse und einzige Anfrage. Duplikatbereinigung ist hier eine Offenlegungsentscheidung, keine neutrale Aufräumarbeit.

Der veröffentlichte Bericht zu RFC 5363 behandelt allgemeinen Fan-out und Teilergebnisse. Dieser Bericht beansprucht nur die nachfolgende Frage, welche Sichtbarkeitsklasse bei gleicher Identität überlebt.

Reply-all kann die Blindkopie nachträglich verraten

Selbst korrektes serverseitiges bcc schützt nicht vor einem Client, der die blinde Adresse in eine Antwort an alle einfügt. RFC 5364 macht die empfangene Historie deshalb zu einem Signal für lokale Bedienlogik.

Fehlt die eigene URI oder ist sie blind gekennzeichnet, sollte der Agent die Sammelantwort verhindern oder einschränken. Dafür muss er sich trotz Aliasen, Weiterleitungen und mehreren Konten selbst erkennen.

Ein Fehlvergleich sperrt entweder eine legitime Antwort oder legt die Blindkopie offen. Auch eine gefälschte Historie kann die Oberfläche beeinflussen.

Speichern Sie empfangenen Body, Parsergebnis, gewählte lokale Identität, Match, Schaltflächenzustand und tatsächliche Antwortadressen. Die richtige Projektion am Server ist kein Beweis für Vertraulichkeit am Endgerät.

Der Test endet erst bei der gesendeten Antwort, nicht bei einer UI-Aufnahme.

Optionaler Inhalt kann unbeachtet bleiben

Die Historie soll recipient-list-history mit handling=optional tragen. Ein älteres Endgerät kann die Hauptanfrage annehmen und den unbekannten Multipart-Teil ignorieren.

Anfrageannahme und Historienverarbeitung sind getrennte Erfolge. „Mit Historie zugestellt“ kann lediglich heißen, dass der Relay Bytes angehängt hat. Speicherung, Parsing, Anzeige und Reply-all-Regel bleiben unbewiesen.

MIME-Aufbau, Boundary, Disposition, Parameter, Endgerätefähigkeit, Parsergebnis, Darstellung und Fallback gehören in den Beleg. Das erlaubte Verwerfen muss sichtbar sein.

Kompatibilität schützt Verfügbarkeit, kann aber den Datenschutzkontext entfernen. Sensible Dienste brauchen eine ausdrückliche Regel, ob dieser degradierte Modus zulässig ist.

Eine Historie ist kein Anwesenheitsnachweis

Die RFC warnt ausdrücklich: Die Liste beweist keine tatsächlichen Teilnehmer. Eine URI kann nicht existieren, unerreichbar sein, nicht antworten, ablehnen oder zu einem Automaten gehören. Eine Person kann unter anderer Identität teilnehmen.

Ebenso wenig trägt sie Abrechnung. Einladung ist keine Nutzung; erzeugte Anfrage ist keine angenommene Sitzung; sichtbarer Eintrag misst weder Dauer noch Ressource oder Zahlungspflicht.

Die Historie kann außerdem gefälscht werden. Gültiges XML bestätigt Form, nicht Wahrheit. Signierte oder verschlüsselte Falschaussagen bleiben falsch.

Endpunktantwort, authentifizierter Beitritt, Medienbeobachtung, Dauer, Verbrauch und Buchung sind spätere eigenständige Belege. Korrelation ist erlaubt, Ersetzung durch Listenmitgliedschaft nicht.

Die Historie beantwortet: „Welche Offenlegungssicht begleitete diese Anfrage?“ Sie beantwortet nicht: „Wer war wirklich dabei?“

TLS und S/MIME schützen Verwahrung

Empfängerbeziehungen sind sensibel. Authentifizierung, Autorisierung, TLS und S/MIME begrenzen Zugriff und schützen Hop oder Inhalt innerhalb ihrer Vertrauensmodelle.

Sie beweisen nicht, dass die richtige Listenversion expandiert, URI korrekt verglichen, Prioritäten eingehalten, Zählwerte richtig oder Ansichten passend dargestellt wurden.

Peer, Zertifikat oder Schlüssel, Prüfungsergebnis und Schutzumfang sind getrennt von Eingabehash, Transformatorversion, Regelwerk und Ausgabehash zu speichern.

Ein sicherer Kanal kann eine falsche Projektion fehlerfrei transportieren. Die Sicherheit des Weges verleiht dem Inhalt keine zusätzliche Wahrheit.

Das Projektionsbuch bewahrt auch das Unsichtbare

Der erste Beleg friert Principal, Berechtigung, XML und Kontext ein. Der zweite dokumentiert Expansion, der dritte URI-Vergleich und Kollisionsgruppen.

Der vierte hält explizite Werte, Default-bcc, Anonymisierung und Prioritäten fest. Der fünfte bindet pro Empfänger sichtbare, entfernte und ersetzte Einträge samt Body-Hash an die Anfrage.

Danach folgen optionale Verarbeitung, Anzeige, Antwortschutz, Zustellung, reale Teilnahme und Abrechnung. Jede Stufe hat eigenen Verantwortlichen und eigene Zeit.

Nur die Projektion beweist nicht, was verborgen wurde. Nur die Masterliste beweist nicht, was offengelegt wurde. Beide Seiten und ihre Transformation müssen erhalten bleiben.

Der Test vergleicht exakte Bodies pro Empfänger

Fixtures brauchen fehlendes Attribut, to, cc, bcc, einzelne und gruppierte Anonymisierung, kombinierte Blind-/Anonymregeln, äquivalente Duplikate mit Konflikt, Eigenkopie des blinden Empfängers und ein Altgerät ohne Multipart-Verarbeitung.

Für jeden Fall werden Anfragezahl und genaue Body-Bytes geprüft. Danach folgen Eigenerkennung, Darstellung und Antwort. Teilnahme- oder Abrechnungssysteme dürfen Historienmitgliedschaft nicht als Ereignis übernehmen.

Ändern Sie die Quelle nach Autorisierung, sortieren Sie Duplikate um, entfernen Sie Attribute, manipulieren Sie count, fälschen Sie Historien, streifen Sie den optionalen Teil ab und spielen Sie alte Projektionen ein. Jede Annahme braucht eine nachvollziehbare Regel.

Der Proposed-Standard-Status vom Oktober 2008 und die erfasste Errata-Seite ohne Treffer beschreiben den Dokumentbestand. Sie belegen keine heutige Implementierung, Einführung oder reale Störung.