Zusammenfassung

  • $hasattachment und $hasnoattachment sind nach RFC 9979 zwei ausdrückliche, gegenseitig ausschließende Zustände. Fehlt der positive Wert, kann die Prüfung noch ausstehen; eine leere Anzeige darf nicht als „kein Anhang“ gelten.
  • Dieselbe Beweisdisziplin gilt für stärkere Wörter: $istrusted ist eine Serverbehauptung, $unsubscribed eine versuchte Handlung, $new Aufmerksamkeit und Scheduled ein Ablageort.

In der Nachrichtenliste fehlte die Büroklammer. Ein Export machte daraus „Anhang: nein“, und eine nachgelagerte Regel behandelte die Nachricht als geprüft. Später zeigte sich, dass der MIME-Parser wegen eines Zeitlimits gar nicht gelaufen war. Die Benutzeroberfläche hatte unbekannt und negativ gleich aussehen lassen; die Datenpipeline hatte aus dem Aussehen eine Tatsache gebaut.

Der Fall ist konstruiert und beschreibt weder Anbieter noch Vorfall. Seine Semantik steht in RFC 9979, einem im Mai 2026 veröffentlichten Informational-Dokument der IETF. Es definiert 17 in verschiedenen Implementierungen verwendete IMAP/JMAP-Schlüsselwörter und drei Mailbox-Namensattribute. Gemeinsame Bezeichnungen verhindern Namenskollisionen. Sie bescheinigen keinen einzelnen Klassifikationslauf.

Das IANA-Register IMAP and JMAP Keywords nennt Name, Typ, Nutzung, Geltungsbereich und Spezifikation. Das Register der IMAP Mailbox Name Attributes enthält unter anderem Memos, Scheduled und Snoozed. IANA koordiniert die Sprache. Es prüft weder den Inhalt einer Nachricht noch den Erfolg einer Abmeldung oder Zustellung.

Die registrierten Zustände haben unterschiedliche Urheber. Manche setzt der Server bei der Einlieferung, andere setzt oder entfernt ein Client nach einer Nutzerhandlung. Einige beraten nur die Darstellung; andere können automatische Behandlung auslösen. Wird beim Export nur das Token bewahrt, bleibt ein sichtbares Ergebnis ohne verantwortlichen Entscheider zurück.

RFC 5788 schuf das Schlüsselwortregister. RFC 8457 lieferte mit $Important ein früheres Modell geteilter Semantik. RFC 9051 definiert IMAP4rev2, RFC 8621 JMAP Mail. Dass beide Protokolle denselben Zustand abbilden, beweist Projektionstreue, nicht die Richtigkeit der lokalen Entscheidung.

Die Anhangspaare machen ein Dreizustandsmodell zwingend. $hasattachment und $hasnoattachment dürfen nicht gleichzeitig vorhanden sein. Doch das Fehlen des ersten Werts ist ausdrücklich nicht schlüssig, weil die Analyse möglicherweise ausstand. „Gefunden“, „geprüft und nicht gefunden“ sowie „nicht bekannt“ benötigen getrennte Werte. Ein binäres Symbol löscht sonst die wichtigste Fehlerklasse.

JMAP hasAttachment muss dieselbe Information widerspiegeln. Übereinstimmung zwischen IMAP und JMAP ist ein Kohärenzbeleg. Sie sagt nicht, welcher Parser welche Nachrichtenfassung zu welchem Zeitpunkt untersuchte. Eine einzige veraltete oder fehlerhafte Klassifikation kann auf allen Clients widerspruchsfrei erscheinen.

Bei Memos ist nicht der Wert, sondern die Beziehung zweigeteilt. $memo markiert die Notiznachricht, $hasmemo die kommentierte Nachricht. Erstellen und Löschen müssen beide Seiten ändern. RFC 8474 stellt stabile Objekt- und Thread-Identitäten bereit. Es macht die zwei Änderungen aber nicht automatisch atomar. Ein Abbruch kann ein formal gültiges, sachlich verwaistes Label hinterlassen.

$istrusted besitzt größere symbolische Macht. Der Server setzt es als beratende Aussage, Name und E-Mail-Adresse des Absenders mit hoher Sicherheit geprüft zu haben. RFC 9979 warnt, dass eine Fehlvergabe betrügerischen Nachrichten Vertrauen verschafft. Das Schlüsselwort darf nicht allein deshalb gesetzt werden, weil SPF, DKIM oder DMARC bestanden wurden.

Die Einschränkung wahrt deren genaue Reichweite. RFC 7208 bewertet einen Host für eine Envelope-Identität. RFC 6376 bindet eine Domainsignatur an ausgewählte Nachrichtenteile. RFC 9989 prüft die Ausrichtung zur sichtbaren Absenderdomain und eine gewünschte Empfängerpolitik. Das beweist nicht automatisch den angezeigten Menschen, seine Befugnis, sichere Links oder wahre Aussagen.

Einen universellen Algorithmus oder Grenzwert für „hohe Sicherheit“ gibt RFC 9979 nicht vor. Der Server darf zusätzliche lokale Kenntnis nutzen. Dann muss er aber neben dem Token Herkunft sichern: behauptender Dienst, Regelversion, Evidenzklassen, Konfidenz, Zeitpunkt, Ablauf, Widerrufsgrund und Verantwortlicher. Die UI darf verdichten, nicht den Umfang aufblasen.

Der Sicherheitsabschnitt benennt den Vertrauensanker: Client und Nutzer müssen dem IMAP-Server vertrauen können. Ein kompromittierter oder böswilliger Server kann Zustände falsch setzen und Menschen täuschen. Fünf identische Badges auf fünf Geräten sind deshalb keine fünf unabhängigen Prüfungen, sondern fünf Kopien derselben Behauptung.

Bei der Abmeldung trennt RFC 9979 drei Ebenen. $canunsubscribe bedeutet, dass ein konformer List-Unsubscribe-Mechanismus nach implementierungsspezifischer Reputationsprüfung angeboten werden kann. RFC 8058 definiert die One-Click-Signalisierung. Das ist noch keine Nutzerhandlung.

$unsubscribed hält fest, dass der Nutzer eine Abmeldung versucht hat, auch ohne Erfolgsbestätigung. Bei sicherem Fehlschlag darf es nicht gesetzt werden. Angebot, Versuch, bestätigter Fehler, unbekannter Ausgang und bestätigter Erfolg sind verschiedene Zustände. Ein Wort, das sprachlich abgeschlossen klingt, darf nicht als rechtlicher Abschlussbeleg dienen.

Auch $new ist kein Zeitstempel. Eine alte, aus Snooze zurückkehrende Nachricht kann es erhalten, damit sie wieder Aufmerksamkeit bekommt. $notify fordert eine Benachrichtigung an, soweit Nutzereinstellungen dies zulassen. Anforderung, Darstellung, Wahrnehmung und Reaktion sind vier Ereignisse.

Snoozed benennt lediglich den Speicherort zeitweise zurückgestellter Nachrichten und definiert weder Weckmechanismus noch Oberfläche. Scheduled benennt eine Mailbox für später zu versendende Nachrichten. Darin zu liegen beweist weder Jobausführung noch Relay-Annahme oder Zustellung. Planung, Versuch, Transportantwort und Endstatus gehören in getrennte Belege.

$followed und $muted schließen einander aus; treten beide auf, gewinnt followed. Die Regel sorgt für deterministisches Verhalten, erklärt aber nicht den Widerspruch. RFC 9979 weist darauf hin, dass ein Angreifer mit Kontozugriff Threads stummschalten kann, und empfiehlt, Mute-Aktionen bei der Wiederherstellung zu prüfen oder zurückzunehmen.

Ein Passwortwechsel beseitigt zukünftigen Zugang, aber nicht automatisch die synchronisierten Entscheidungen des Angreifers. Filter, Mutes und Benachrichtigungen bestimmen, was der legitime Inhaber wahrnimmt. Sie gehören deshalb zur Wiederherstellungsfläche.

Die Informationsseite und die Errata-Suche begrenzen den Dokumentstand. Sie liefern keine Implementierungsliste, Klassifikationsmessung, Mailboxbeobachtung oder Vorfallbestätigung. Auch die Arbeitgeber der Autoren sind kein Einsatznachweis.

Heng Lus Reality Layers trennen Registerbedeutung, lokale Regel, Serverbehauptung, synchronisierten Zustand, Clientanzeige, menschliches Vertrauen, automatische Aktion und Außenwirkung. Running-Code Primacy stellt die tatsächlich ausgeführte Prüfung vor das Symbol. Minimum Initial Specification begrenzt das Gemeinsame auf Namen und klare Konfliktregeln, während die künftige lokale Entscheidung verantwortlich bleibt.

Der ergänzende Beleg nennt Nachricht, Thread oder Mailbox, exaktes Schlüsselwort, zulässigen Akteur, Server, Client und Protokoll, Alt- und Neuwert, Regel oder Nutzerhandlung, Evidenzreferenz und Konfidenz, Zeit und Ablauf, Synchronisation, tatsächliche Darstellung, Präferenz, Aktion, externe Antwort und Korrektur. Sensible Inputs dürfen geschützt sein; Methode und Eigentümer dürfen nicht verschwinden.

RFC 9979 liefert eine gemeinsame Sprache. Gute Systeme sorgen dafür, dass diese Sprache nicht aus „unbekannt“ heimlich „nein“ und aus „versucht“ heimlich „erledigt“ macht.

Quellen