Zusammenfassung

  • IMAP bezeichnet \Seen als „Nachricht wurde gelesen“, doch beobachtbar ist veränderlicher Postfachzustand: BODY[...] kann das Flag implizit setzen, BODY.PEEK[...] Inhalt ohne Setzen abrufen, und berechtigte Clients können es hinzufügen oder entfernen.
  • Eine Aussage über menschliches Lesen muss Principal, Client, Postfach-Inkarnation, UID, Befehl, Flags vorher/nachher, Serverantwort und Anzeigeereignis verbinden. Das Bit allein belegt weder Aufmerksamkeit noch Verständnis, Zustimmung oder Antwort.

Ein menschliches Verb in einer Zustandsmaschine

Mark Crispin entwickelte IMAP, damit Nachrichten auf dem Server bleiben und von unterschiedlichen Clients und Orten erreichbar sind. Stanford hält fest, dass er das Protokoll während seiner Tätigkeit als Systemprogrammierer von 1977 bis 1988 erfand. Sein IETF-Profil führt 25 RFCs, darunter RFC 3501 als langjährige IMAP4rev1-Referenz. Das Unicode Consortium erinnert seinen langjährigen Mitwirkenden als E-Mail-Experten und Vater von IMAP.

RFC 3501 definiert \Seen knapp: Die Nachricht wurde gelesen. RFC 9051 übernimmt diese Semantik für IMAP4rev2. Das Wort schafft gemeinsamen Zustand, doch die Spezifikationen trennen den menschlichen „user“ vom Software-„client“. Der Server beobachtet Befehle, ausgelieferte Daten und Attribute, nicht Augen oder Verständnis.

Die belastbare Aussage ist deshalb enger: Zum Beobachtungszeitpunkt trägt das Postfach das standardisierte Gelesen-Flag. Wer daraus eine Aussage über eine Person machen will, muss die Entstehung des Bits kennen.

FETCH schreibt, PEEK nicht implizit

Fordert ein Client mit BODY[...] einen Nachrichtenteil an, setzen RFC 3501 und RFC 9051 \Seen implizit. Ändert sich das Flag, meldet der Server den neuen Zustand. Der Abruf ist zugleich ein Metadaten-Schreibvorgang.

BODY.PEEK[...] ruft denselben Inhalt ab, ohne das Flag implizit zu setzen. Inhalt kann also mit oder ohne Änderung abgerufen werden; STORE kann Seen ohne Body-Abruf setzen; ein späterer Vorgang kann das Flag nach dem Abruf löschen.

Diese Möglichkeiten unterstützen Vorschau, Wiedervorlage und Synchronisierung. Sie machen das Bit aber nicht zum Menschensensor. Indexer, Filter, Cache oder Vorschauerzeugung können Inhalt abrufen — als Protokollszenario, nicht als Behauptung über ein Produkt. Umgekehrt kann ein Client PEEK-Daten anzeigen und das Postfach ungelesen lassen. Der Beleg des Servers endet beim Befehl und seiner Wirkung.

Eine Nachricht kann bereits gesehen ankommen

APPEND erlaubt Anfangs-Flags; beide RFCs zeigen Beispiele mit \Seen. Dann beschreibt das Bit den Einlieferungszustand, nicht das Lesen der neu gespeicherten Kopie durch einen Menschen.

STORE kann das Flag hinzufügen oder entfernen. „Alle als gelesen“ braucht keinen Body anzuzeigen; „als ungelesen“ kann es nach gründlicher Lektüre löschen. In delegierten oder von mehreren Clients genutzten Postfächern kann ein anderer Berechtigter den später beobachteten Zustand erzeugt haben.

„Ungelesen“ ist somit nicht das logische Gegenteil von „jemand hat gelesen“. Es besagt nur, dass \Seen jetzt fehlt. Abruf, manuelles Zurücksetzen, Synchronisationskonflikt oder Anfangszustand können in der Geschichte liegen, die der aktuelle Wert nicht mehr enthält.

Rechte verändern die Spur

RFC 4314 reserviert das Recht s für Änderungen an \Seen. Ein FETCH, der das Flag normalerweise setzen würde, darf es ohne dieses Recht nicht tun. STORE prüft dieselbe Berechtigung.

Zwei Identitäten können denselben Body abrufen und verschiedene dauerhafte Spuren hinterlassen. Bei einer ändert sich das Bit, bei der anderen verhindert die Richtlinie die Schreibwirkung. Sein Fehlen kann eine Berechtigungsgrenze anzeigen statt fehlender Darstellung.

Implementierungen können Flags zudem geteilt oder nicht geteilt führen. Die vollständige Frage lautet: Wessen Zustand ist es, in welchem Postfachmodell und unter welchem Recht geschrieben? Persönliches Postfach, gemeinsamer Support-Eingang und Vorstandsdelegation erzeugen trotz gleichen Flag-Namens keine gleichwertigen Belege.

Änderungsreihenfolge verrät keinen menschlichen Grund

RFC 7162 ergänzt CONDSTORE und QRESYNC. Modifikationssequenzen erkennen neuere Metadaten, aktualisieren Caches und koppeln STORE an UNCHANGEDSINCE. Veraltete Schreibvorgänge können als Konflikt scheitern, statt Neueres still zu überschreiben.

MODSEQ ist jedoch ein Reihenfolgebeleg, keine Zeugenaussage. Es unterscheidet nicht allein implizites FETCH, STORE, anderen Client oder externen Agenten und zeigt weder Bildschirm noch Aufmerksamkeit.

RFC 8621 führt die Idee als JMAP-Schlüsselwort $seen fort, das Berechtigte hinzufügen oder entfernen können. Konsistente Synchronisierung belegt replizierten Zustand; sie erweitert nicht dessen Beobachtungsumfang.

Einen Lesebeleg aus getrennten Quittungen bauen

Ein belastbares Protokoll bewahrt authentifizierten Principal, Delegation, Client-Instanz und Sitzung. UIDVALIDITY und Nachrichten-UID binden Postfachgeneration und Objekt. Als Ursache werden BODY FETCH, PEEK, STORE, APPEND, Synchronisierung oder externer Agent benannt; hinzu kommen angeforderter Teil, Flags vorher/nachher, Antwort, Zeit und verfügbare MODSEQ.

Die Anzeige ist ein separates Ereignis, eine menschliche Bestätigung ein weiteres. „Body abgerufen; Seen implizit gesetzt; Anzeige unbekannt; keine Bestätigung“ ist unbequemer als „gelesen“, aber überprüfbar.

Crispin machte Postfachzustand interoperabel. Spätere Systeme dürfen ihn nicht für einen Menschen aussagen lassen, den das Protokoll nie beobachtete.

Quellen