Zusammenfassung

  • RFC 9979 registriert $istrusted als gemeinsames, hinweisendes IMAP/JMAP-Schlüsselwort, das der Server bei Zustellung setzt, wenn er sowohl Absendername als auch E-Mail-Adresse mit hoher Sicherheit überprüft hat. Ein gewöhnlicher Erfolg von SPF, DKIM oder DMARC allein genügt ausdrücklich nicht.
  • Clients können daraus eine Verifizierungsanzeige machen. Das Abzeichen beweist jedoch weder sichere Inhalte und zulässige Handlungen noch eine korrekte Darstellung oder die dauerhafte Gültigkeit des Serverurteils.
  • Daniel Kade schlägt einen datensparsamen Korrekturbeleg vor, der Evidenzklasse und Policy-Epoche des Servers, Zustandsänderung, Clientdarstellung, wesentliche Abhängigkeit und spätere Berichtigung verbindet, ohne Nachrichtentext oder Geheimnisse zu speichern.

Aus einem Zustellurteil werden viele sichtbare Versprechen

Ein Mailanbieter verschickt einen dringenden Kontohinweis an einen Kunden. Der empfangende Dienst besitzt starke Belege dafür, dass angezeigter Name und Adresse tatsächlich zum Anbieter gehören, und setzt bei der Zustellung $istrusted. Im Web erscheint ein kleines Häkchen, auf dem Telefon der Text „Absender verifiziert“. Ohne die interne Prüfung zu kennen, versteht der Empfänger: Mein Maildienst bürgt in besonderer Weise für diese Identität.

Später stellt eine Untersuchung fest, dass die Markierung falsch war. Eine Evidenzquelle war zu weit gefasst, eine alte Regel blieb aktiv oder die Integrität des Servers war beeinträchtigt. Das Entfernen des Schlüsselworts berichtigt die Gegenwart, rekonstruiert aber nicht die Vergangenheit. Welche Nachrichten waren betroffen? Welche Policy-Version entschied? Welche Clients zeigten welches Versprechen? Begann eine risikoreiche Handlung, während das Zeichen sichtbar war?

Der im Mai 2026 als Informational RFC im IETF-Stream veröffentlichte RFC 9979 definiert 17 Nachrichtenschlüsselwörter und drei Mailbox-Namensattribute, die bereits in verschiedenen Implementierungen verwendet wurden. Ihre Registrierung vermeidet Namenskollisionen und beschreibt den beabsichtigten Gebrauch. Server und Clients erhalten dadurch ein gemeinsames Vokabular für Zustände, deren private Bedeutungen sonst auseinanderlaufen könnten.

$istrusted setzt eine hohe Schwelle. Das Schlüsselwort zeigt an, dass der Server die Echtheit von Absendername und E-Mail-Adresse mit großer Sicherheit überprüft hat. Als typischer Fall gilt ein Mailanbieter, der seine eigenen legitimen Nachrichten an Kunden erkennt. Ein unterstützender Client kann ein Prüfzeichen anzeigen und damit helfen, echte Mitteilungen von Phishing-Imitationen zu unterscheiden.

Gerade wegen dieser Wirkung verlangt der RFC Vorsicht. Eine falsche Anwendung kann Nutzer dazu bringen, betrügerischen Nachrichten zu vertrauen. Das Merkmal darf nicht allein deshalb gesetzt werden, weil SPF, DKIM oder DMARC die übliche Prüfung bestanden hat. Solche Ergebnisse liefern innerhalb ihres jeweiligen Umfangs wichtige Fakten; sie erzeugen nicht automatisch das stärkere Urteil über sichtbaren Namen und Adresse.

Das Register benennt den Sprecher, nicht dessen vollständige Begründung

Im IANA-Register der IMAP- und JMAP-Schlüsselwörter steht $istrusted als SHARED, COMMON und BOTH. Die RFC-Registrierung nennt es hinweisend und weist das Setzen bei Zustellung dem Server zu. Damit ist geklärt: Die Behauptung stammt vom Server, wird kontoweit geteilt und ist selbst kein automatischer Befehl.

Der Client erhält aber kein Begründungsdossier. Das Token nennt weder die Evidenzklasse noch die Version der Entscheidungsregel, den Beobachtungszeitpunkt, einen späteren Prüfer oder den Grund eines Widerrufs. Umgekehrt weiß der Server nicht zwingend, wie ein Client das Ergebnis formuliert. Ein unauffälliges Symbol, ein kräftiger Balken mit „sichere Nachricht“, eine Sprachausgabe oder gar keine Darstellung können demselben Zustand folgen und völlig verschiedene Erwartungen erzeugen.

Andere Einträge des RFC zeigen die Vielfalt solcher Grenzen. $new ist ein Aufmerksamkeitshinweis und kann nach Interaktion gelöscht werden. $notify kann eine Benachrichtigung auslösen. Das vom Client gesetzte $muted kann den Server veranlassen, künftige Thread-Nachrichten herunterzustufen. $unsubscribed dokumentiert einen Abmeldeversuch, nicht dessen sicheren Erfolg. Ein gemeinsamer Name koordiniert einen Zustand; er ersetzt keinen vollständigen Ablauf.

Die Mailbox-Attribute verdeutlichen das zusätzlich. Snoozed kennzeichnet den Speicherort vorübergehend zurückgestellter Nachrichten, doch RFC 9979 sagt ausdrücklich, dass das Attribut den Snooze-Mechanismus und seine Oberfläche nicht definiert. Das IANA-Register der Mailbox-Namensattribute macht eine Rolle auffindbar, wird aber nicht zum Zeitplaner. Ebenso transportiert $istrusted ein Urteil, ohne dessen Audit- und Korrektursystem zu bilden.

Ein echter Absender macht nicht jede Forderung zulässig

Der semantische Gegenstand des RFC sind Name und Adresse im From-Feld. Das Schlüsselwort beglaubigt nicht jeden Satz, jedes Linkziel, jeden Anhang oder eine Zahlungsforderung. Ein legitimer Absender kann irren, intern missbraucht werden oder etwas verlangen, das dieser Empfänger nicht tun darf.

Produktgestaltung kann diese Grenze bewahren oder verwischen. „Identität vom Mailserver erkannt“ beschreibt das Urteil. „Diese E-Mail ist sicher“ gibt ein viel weiter reichendes Versprechen. Steht das Häkchen unmittelbar neben einer Zahlung oder Kontowiederherstellung, kann die Identitätsaussage psychologisch als Transaktionsfreigabe wirken. Der geteilte Zustand hält diese redaktionelle Entscheidung nicht fest.

Nicht jeder Client muss die Serverprüfung wiederholen. Eine zentrale Bewertung kann effizient, konsistent und besser informiert sein. Verantwortlichkeit verlangt aber getrennte Eigentümer: Der Server verantwortet die Echtheitsentscheidung, der Client ihre Erklärung, Mensch oder nachgelagertes System die spätere Handlung. Das erste Urteil darf das dritte nicht verkörpern.

Why BTW Media Exists liefert dafür die passende Disziplin: Beobachtete Wirklichkeit und zugeschriebene Erzählung auseinanderhalten. Beobachtbar ist, dass ein bestimmter Server unter einer bestimmten Policy einen Zustand für eine bestimmte Nachricht setzte. „Die Mail ist sicher“ wäre eine zusätzliche Behauptung.

Das Vertrauen in den Server gehört zum Inhalt der Aussage

Der Sicherheitsabschnitt des RFC 9979 behandelt den Server nicht als neutrale Kulisse. Nutzung und Auslegung der Schlüsselwörter hängen davon ab, ob Client und Nutzer dem IMAP-Server vertrauen können. Ein kompromittierter oder böswilliger Server kann Zustände falsch setzen oder manipulieren, um Menschen zu täuschen. $istrusted ist deshalb kein vom Aussteller unabhängiger Zeuge.

Ein Screenshot beweist höchstens, dass eine Oberfläche zu einem Zeitpunkt etwas zeigte. Eine Untersuchung muss die Anzeige mit dem empfangenen Zustand, dem liefernden Server, dessen Entscheidungsdienst-Version und der akzeptierten Evidenzklasse verbinden. Ist die Serverintegrität selbst strittig, wird das Abzeichen zum angefochtenen Beweisstück.

Gemeinsamer Zustand schafft außerdem Zeitversatz. Der Server entfernt das Merkmal; ein verbundener Client aktualisiert sofort; ein Offline-Gerät behält den Cache; eine frühere Benachrichtigung wirkt im Gedächtnis fort. RFC 9979 verspricht keine einheitliche Cache- oder Oberflächenlebensdauer. „Auf dem Server gelöscht“ und „überall nicht mehr sichtbar“ sind zwei verschiedene Ereignisse.

The Policy Mirror fordert, Policy an die tatsächliche Steuerung anzupassen. Der Server steuert die Schlussfolgerung, Synchronisierung und Cache die Verteilung, das Produkt die Darstellung, Mensch oder Folgesystem die Handlung. Ein einziges grünes Zeichen darf diese vier Zuständigkeiten nicht verbergen.

Ein Korrekturbeleg braucht keine Kopie des Postfachs

Die Lösung ist kein Überwachungsarchiv. Nachrichtentext, Zugangsdaten, Schlüssel, vollständige Authentifizierungsspuren und detailliertes Leseverhalten wären unverhältnismäßig sensibel. Die Frage bleibt eng: Wie gelangte das Serverurteil auf eine Oberfläche, und wie wurde seine Änderung weitergegeben?

Die erste Ebene identifiziert die Nachricht mit einem postfachgebundenen Objektbezeichner oder gesalzenen Digest sowie Zustellzeit und Kontoumfang, ohne den Inhalt zu duplizieren. Die zweite hält Entscheidungsdienst, Evidenzklassen, Policy-Epoche, Entscheidungszeit und Vertrauensband fest, ohne Rohgeheimnisse.

Die dritte speichert den Zustandsübergang: Wer setzte $istrusted, welche Version und Sichtbarkeit galten, wann wurde entfernt oder ersetzt und aus welcher Grundklasse. Die vierte beschreibt die Darstellung grob, aber belastbar: Clientfamilie und -version, semantische Bezeichnung, barrierefreie Entsprechung, erste und letzte bekannte Sichtbarkeit und abrufbare Erklärung.

Die fünfte erfasst nur wesentliche Folgen, die der Betreiber rechtmäßig beobachten darf, etwa den Start eines Hochrisikoablaufs während der Anzeige. Inhalt und sachfremdes Verhalten bleiben außen vor. Die sechste dokumentiert die Korrektur: Untersuchungsinstanz, geänderte Schlussfolgerung, betroffener Zeitraum, benachrichtigte Clients oder Konten, Abhilfe, Einspruch und Abschlussverantwortung.

Jede Ebene muss ihre Wissensgrenze einhalten. Der Server darf aus der Löschung nicht auf verschwundene Symbole schließen. Der Client darf aus seinem Cache keine Echtheitsgrundlage erfinden. Das Incident-Team darf ohne Zeit- und Darstellungsbeleg keine Handlung dem Abzeichen zuschreiben. Ein guter Beleg hält Unsicherheit sichtbar.

Der Vorschlag stammt von Daniel Kade und ist keine Vorgabe des RFC 9979. Er verändert nicht die Protokollsemantik, sondern macht ihren Weg durch den Betrieb überprüfbar.

Quellen