Zusammenfassung

  • RFC 5256 macht Sortierung und Threadbildung reproduzierbar; das Ergebnis bleibt jedoch eine durch Suchmenge, Algorithmus, Kollation, Headerqualität und Mailboxzustand bestimmte Projektion.
  • Eine Kante kann aus einer erklärten Message-ID-Referenz, einem Platzhalter für einen fehlenden Vorfahren oder einer Betreffzusammenführung entstehen. Sie beweist weder Antwortabsicht noch vollständige Abstammung, Verwahrung oder Zustellung.

Die Oberfläche schloss die Akte zu früh

Im Untersuchungsbericht standen sechs Nachrichten unter einer Wurzel. Das Bild wirkte wie Anweisung, Bestätigung und Vollzug. Erst später fiel auf, dass die Suche Nachrichten vor einem Stichtag ausschloss. Der Server hatte den abgefragten Ausschnitt richtig geordnet. Die Leser hatten aus dem Ausschnitt eine vollständige Geschichte gemacht.

THREAD beginnt mit einer Suche. Erst danach ordnet der Server die passenden Nachrichten nach dem verlangten Algorithmus. Ein anderer Zeitraum, Suchbegriff, Ordner oder Zustand kann den Baum verändern, obwohl keine Nachricht geändert wurde. Die Antwort beschreibt, wie diese Regel diese Datensätze jetzt darstellt; sie rekonstruiert nicht automatisch das gesamte Gespräch.

Datensatz, Transformation und Darstellung müssen getrennt bleiben. Nachrichten und Servermetadaten bilden den Datensatz. Suche, Dekodierung, Normalisierung, Kollation und Baumbau sind Transformation. Einrückung, Linien und das Wort „Unterhaltung“ sind Darstellung. Die Oberfläche darf sie für Lesbarkeit verbinden, aber keine Beweisautorität erben, die im Datensatz nicht vorhanden ist.

Die Zuständigkeit ist verteilt

Der Client wählt Suchkriterien, Zeichensatz und Algorithmus. Der Server verarbeitet einen Mailboxzustand, interpretiert Header und liefert Sequenznummern oder UIDs. Die absendende Software erzeugte Message-ID, References und In-Reply-To. Die Anwendung zeichnet das Ergebnis.

Alle Beteiligten können standardkonform handeln und dennoch eine irreführende Schlussfolgerung ermöglichen. Ein falscher References:-Wert wird bei korrekter Verarbeitung zu einem überzeugenden Zweig. Ein fehlender Elternknoten kann ausgefiltert, gelöscht oder nie eingegangen sein. Die Linie authentifiziert den Header nicht; die Lücke erklärt ihre Ursache nicht.

Die Agency-Frage lautet deshalb: Wer bestimmte welche Transformation und wer trägt den Schaden, wenn die Ansicht zur offiziellen Erinnerung wird? Der Betreiber einer Oberfläche darf nicht allein darüber entscheiden, wer wem antwortete oder zustimmte.

ORDEREDSUBJECT verspricht Gruppierung

RFC 5256 nennt ORDEREDSUBJECT „poor man's threading“. Ein vorgeschriebenes Verfahren bildet den Basisbetreff, gleiche Ergebnisse werden gruppiert und nach Sendedatum geordnet. Die erste Nachricht wird Wurzel, alle späteren werden direkte Kinder und Geschwister. Enkel gibt es nicht.

Das ist Betreffgruppierung, keine Antwortgenealogie. Sie ist nützlich, wenn Referenzen fehlen, kann aber unabhängige Nachrichten mit gleichem Betreff verbinden und echte Gespräche nach einem Betreffwechsel trennen.

Auch der Basisbetreff ist abgeleitet. Kodierte Wörter werden dekodiert, Leerraum verdichtet, definierte Antwortpräfixe, Weiterleitungshüllen, Endungen und Blöcke entfernt. Verbundene und getrennte Implementierungen müssen dasselbe Verfahren verwenden, damit ihre Ansichten nicht auseinanderlaufen. Diese Gleichförmigkeit beweist eine Regelanwendung, nicht die semantische Richtigkeit. Der RFC warnt, dass bedeutender Text irrtümlich als Artefakt entfernt werden kann.

REFERENCES löst unvollständige Behauptungen auf

REFERENCES verwendet Message-IDs aus References und unter bestimmten Bedingungen die erste gültige ID aus In-Reply-To. Äquivalente Schreibweisen werden normalisiert; Verbindungen, die Schleifen erzeugen würden, werden verweigert.

Fehlt eine gültige Message-ID, erhält die Nachricht eine eindeutige Rechen-ID. Beanspruchen mehrere Nachrichten dieselbe ID, behält nur die erste mit der kleinsten Sequenznummer den Wert; spätere erhalten erfundene IDs. Fehlt eine referenzierte Vorgängernachricht in der Menge, erzeugt der Algorithmus einen Dummy.

Danach wird beschnitten. Ein kinderloser Dummy verschwindet. Ein Dummy mit Kindern kann gelöscht werden, während seine Kinder aufsteigen. In Wurzelnähe kann ein struktureller Dummy erhalten bleiben. Konflikte aus gekürzten Referenzketten werden durch Regeln zum Beibehalten oder Brechen von Elternlinks gelöst.

Das ist deterministische Reparatur, keine historische Wiederherstellung. Ein Dummy ist keine wiedergefundene E-Mail. Die Beförderung eines Kindes beweist nicht, dass kein Vermittler existierte. Eine erfundene ID ist keine authentifizierte Identität. Der Baum dokumentiert eine algorithmische Entscheidung unter Unsicherheit.

Der Betreff kann Wurzeln nachträglich verbinden

Nach dem Aufbau über Identifikatoren vergleicht REFERENCES Basisbetreffe an der Wurzel. Threads mit gleichem nichtleeren Betreff können zusammengeführt werden. Eine Nicht-Antwort kann Vorrang erhalten oder ein neuer Dummy beide Zweige aufnehmen.

Zwei identisch gezeichnete Kanten können also aus direkter Referenz, mehrstufiger ID-Kette oder Betreffzusammenführung stammen. Ohne Herkunft pro Kante kann eine Prüfung Headerbehauptung und Darstellungsentscheidung nicht trennen.

RFC 5256 warnt ausdrücklich, dass falsche References:-Daten einen Thread in einen anderen einbauen können. Normalisierung verhindert Fehlvergleiche durch Anführungszeichen. Sie authentifiziert weder den Ersteller des Headers noch seine Erzählung.

Eine Datumsspalte kann mehrere Uhren enthalten

SORT sucht zuerst und wendet danach Kriterien in ihrer Prioritätsreihenfolge an. Bei vollständigem Gleichstand dient die Mailbox-Sequenznummer als impliziter letzter Schlüssel. Daher ist REVERSE SUBJECT nicht die vollständige Umkehrung von SUBJECT; der implizite Schlüssel wird nicht umgedreht.

DATE beginnt mit dem auf UTC normalisierten Date:-Header. Ungültige Zeitzonen oder Zeiten erhalten definierte Ersatzwerte. Ist kein Sendedatum auswertbar, wird INTERNALDATE verwendet. Eine Liste kann damit Autorzeit, normative Korrektur und Servermetadatum vermischen.

RFC 5957 ergänzt Sortierung nach Anzeigenamen. Er nutzt den dekodierten vollständigen Namen und fällt sonst auf Mailbox und Host zurück, versucht aber nicht, sprachabhängig einen Nachnamen zu erraten. Diese Zurückhaltung ist richtig: Eine Ordnung soll ihren Schlüssel offenlegen, nicht als universelle Personenordnung auftreten.

Eine lebende Ansicht ist kein Verwahrungsprotokoll

UIDs sind belastbarer als Sequenznummern, brauchen aber Mailboxkontext und UIDVALIDITY. RFC 5267 hält Such- oder Sortieransichten bei Änderungen aktuell; RFC 5182 verwendet gespeicherte Ergebnismengen erneut. Beides erhöht Effizienz, ohne ein unveränderliches Protokoll zu erzeugen.

Für folgenreiche Entscheidungen müssen Mailboxzustand, Suche und Zeichensatz, Algorithmus, Kollation, Serverfähigkeiten und Revision, UIDVALIDITY und UID, rohe Header, normalisierte Message-IDs, Regel jeder Kante, Dummy-Erzeugung und Beförderung, Betreffzusammenführung, Gleichstandsschlüssel, Ergebnishash und Renderingversion erhalten bleiben.

„Die RFC-5256-Ansicht ordnete B in diesem Snapshot unter A ein“ ist prüfbar. „B wurde als Antwort auf A geschrieben“ braucht weitere Belege. „Der Empfänger las und akzeptierte A“ ist ein anderes Ereignis.

Quellen