Zusammenfassung

  • RFC 9698 verknüpft eine authentifizierte IMAP-Sitzung mit einem JMAP-Zugang zum gleichen vollständigen Nachrichtenbestand und zu denselben Objektkennungen.
  • Die Ankündigung hängt davon ab, ob der Server aus dem benutzten Anmeldeverfahren auf ausreichende JMAP-Zugangsdaten schließen kann.
  • Die URL ersetzt keine weitere Anmeldung; gleiche Kennungen frieren weder Lebensdauer noch veränderlichen Zustand oder Darstellung ein.

Wer Beispiel 2 der ursprünglichen RFC 9698 abschrieb, konnte ausgerechnet beim Fragen nach dem neuen Zugang den falschen Befehl verwenden. Dort stand JMAPACCESS. Richtig ist GETJMAPACCESS. Das technische Erratum 8635 wurde am 21. November 2025 bestätigt und korrigiert genau diese Stelle.

Die Korrektur ist klein, aber die Unterscheidung hilft auch beim Lesen des gesamten Mechanismus. JMAPACCESS heißt die Fähigkeit und die unmarkierte Antwort. GETJMAPACCESS fordert eine Adresse an. Keines dieser Wörter besagt, dass der Client sich anschließend bereits erfolgreich über JMAP angemeldet hat. Das Erratum ist kein Bericht über einen Angriff und keine Änderung des Authentifizierungsverfahrens.

RFC 9698, im Januar 2025 veröffentlicht und beim RFC Editor als Proposed Standard geführt, soll schrittweise Migration und JMAP-Erweiterungen in IMAP-Clients ermöglichen. Der bestehende Zugang wird zum Ausgangspunkt eines weiteren Zugangs. Damit kann eine Anwendung bereits erworbenes Wissen nutzen, ohne eine abgeschlossene Umstellung behaupten zu müssen.

Drei Voraussetzungen statt eines Produktetiketts

Der Umfang ist vollständig: Über beide Protokolle muss dieselbe Nachrichtenmenge verfügbar sein. Ein Teilbestand reicht nicht, auch wenn beide Dienste denselben Betreiber haben. Für ein Postfach oder eine Nachricht gilt außerdem die zugesagte Objektkorrespondenz: dieselbe Kennung bezeichnet über beide Protokolle dasselbe zugängliche Objekt.

Der Server muss deshalb auch die Erweiterung OBJECTID aus RFC 8474 anbieten. Gewöhnliche IMAP-UIDs sind dafür kein Ersatz. Auch eine Objektkennung ist nicht ohne Geltungsbereich aussagekräftig. RFC 8620 verlangt Eindeutigkeit von JMAP-Datensatzkennungen innerhalb eines Kontos und Datentyps. Ein Abgleich muss diese Zuordnung erhalten.

Hinzu kommt das konkrete Anmeldeverfahren. Nach erfolgreichem LOGIN oder AUTHENTICATE beurteilt der Server, ob die verwendeten Zugangsdaten für JMAP genügen. Kann er dies ableiten, muss er JMAPACCESS in danach gesendete Fähigkeitslisten aufnehmen. Die RFC nennt ein gemeinsames OAuth-System und eine gemeinsame Passwortdatenbank als mögliche Grundlage.

Ein weiteres Beispiel lässt Passwörter bei IMAP vorübergehend zu, während JMAP sie bereits ablehnt. Die IMAP-Anmeldung funktioniert dann ohne JMAPACCESS-Ankündigung. Das Fehlen der Fähigkeit beweist somit nicht, dass kein JMAP-Dienst existiert. Eine bloße Bestandsaufnahme von Servernamen übersieht die relevante Unterscheidung zwischen Anmeldewegen.

Eine Session-Adresse ist ein Arbeitsauftrag

Kennt der Server den entsprechenden JMAP-Dienst, beantwortet er GETJMAPACCESS mit einer unmarkierten Antwort, die genau eine Session-URL enthält, gefolgt von markiertem OK. Kennt er ihn nicht, muss er BAD senden und darf JMAPACCESS nicht als Fähigkeit nennen.

Der Client muss an dieser Adresse noch den authentifizierten GET ausführen. Erst dessen erfolgreicher Abschluss liefert nach RFC 8620 das Session-Objekt mit den für diese Zugangsdaten verfügbaren Konten und Fähigkeiten. Die Erweiterung stellt keine neuen Zugangsdaten aus. Eine begründete Aussage über deren Eignung bleibt von der später beobachteten Anmeldung verschieden.

Auch die Sicherheitsabwägung der RFC sollte ihren Umfang behalten. Der Client ist bereits authentifiziert; die URL lässt sich außerdem über die vorhandene JMAP-Diensterkennung finden. Deshalb schätzen die Autoren den zusätzlichen Nutzen der Offenlegung für einen Angreifer als gering ein. Das ist keine Prüfung einer konkreten Installation und hebt die üblichen Anforderungen an Transport und Authentifizierung nicht auf.

Das gleiche Objekt ist nicht der gleiche Zeitpunkt

Eine Nachricht kann nach einem IMAP-Abruf gelöscht werden, bevor ein JMAP-Abruf eine halbe Sekunde später beginnt. RFC 9698 sagt ausdrücklich, dass sie die Lebensdauer nicht verändert. Ein fehlendes zweites Ergebnis lässt sich daher erst mit Zeit- und Löschinformationen als Identitätsfehler bewerten.

Für Eigenschaften gelten ebenfalls unterschiedliche Regeln. Die Erweiterung regt möglichst übereinstimmende Flags und andere Daten an, fordert selbst aber keine identischen Postfachnamen. RFC 8621 regelt Namen, Rollen und Zugehörigkeiten zusätzlich. Das JMAP-Mailmodell lässt eine Email-Kennung beim Wechsel des Postfachs bestehen und kann mehrere Postfachzugehörigkeiten erlauben.

EMAILID nach RFC 8474 betrifft unveränderlichen Inhalt. Instanzen mit gleicher EMAILID können unterschiedliche Schlüsselwörter besitzen. Daraus folgt für den Betrieb: Eine gespeicherte Identitätsbeziehung allein rechtfertigt nicht, alte Änderungen an veränderlichem Zustand ungeprüft erneut auszuführen.

Eine weitere Grenze betrifft internationalisierte Adressen. Unter den in RFC 9698 beschriebenen älteren IMAP-Bedingungen kann ohne aktiviertes UTF8=ACCEPT eine herabgestufte Darstellung erscheinen, während JMAP genaue Felder liefert. RFC 6855 erläutert, warum solche Ersatzdarstellungen unter anderem für Antworten und Signaturprüfungen nicht durchweg dem Original entsprechen. Gleiche Objektkennungen garantieren keine identischen Anzeigen. Diese Aussage gilt für den beschriebenen Übergangsfall, nicht pauschal für jede IMAP4rev2-Verbindung.

Lu Hengs Minimum Initial Specification, Running-Code Primacy und Analyse der Realitätsebenen bilden hier den redaktionellen Blickwinkel: Die gemeinsame Regel bleibt eng; Annahme, Ausführung und Ergebnis brauchen jeweils den passenden Nachweis.

Es wurden weder Anbieter getestet noch Vorfälle oder Leistungsgewinne gemessen. Vorgeschlagen wird eine Betriebskette aus beobachteter Fähigkeit, Adresse, erfolgreicher Anmeldung, Konto- und Objektabgleich, Zustandsabgleich und Aktionsresultat. Sie erweitert die RFC nicht um normative Pflichten. Sie verhindert, dass ein sauber beantworteter Entdeckungsbefehl zu einem unbelegten Migrationsabschluss wird.