Zusammenfassung

  • Die Unterstützung alter Server bleibt in RFC 2061 freiwillig. Eine erkannte Protokollvariante belegt noch nicht, dass jeder Ersatzbefehl die erwartete Wirkung hat. RFC 2061
  • Nachträgliches Zurücksetzen von \Seen garantiert keinen durchgehend unveränderten Zustand; ein erfolgreiches COPY bestätigt bei IMAP2bis keinen Metadatenerhalt. RFC 2061, RFC 2060

Die Vorschau funktioniert, doch womöglich hat sie bereits eine Markierung verändert. Genau diese Möglichkeit steckt im Ersatz von BODY.PEEK[section] durch BODY[section] mit anschließendem Löschen von \Seen, soweit nötig. Der gewünschte Inhalt und die gewünschte Wirkung auf das Postfach sind zwei verschiedene Erfolgskriterien. RFC 2061

Eine freiwillige Brücke zwischen verschiedenen Fassungen

Im Dezember 1996 veröffentlichte Mark Crispin von der University of Washington RFC 2061 als Informationsmemo, nicht als Internetstandard. IMAP2bis sei damals sehr verbreitet und mit Pine vielfach ausgeliefert worden; eine definitive Beschreibung fehle jedoch. Das Memo räumt Wissenslücken und überlieferte Protokollerfahrungen ein. Es behandelt die wahrscheinlich anzutreffende Altvariante, nicht sämtliche IMAP-Spielarten. Daraus lassen sich weder Marktanteile noch heutige Bestände ableiten. Keine seiner Anpassungen ist durch IMAP4 vorgeschrieben. RFC 2061

Die Fassungen bleiben auseinanderzuhalten: RFC 1176 beschreibt IMAP2 vom August 1990, nicht verbindlich IMAP2bis. RFC 1730 spezifiziert IMAP4 vom Dezember 1994, RFC 2060 die Revision IMAP4rev1 vom Dezember 1996. Wer beide IMAP4-Fassungen unterstützt, muss beide berücksichtigen. RFC 1732 liefert den breiteren Kompatibilitätskontext von 1994 einschließlich seltenerer Varianten, nicht dieselbe Eingrenzung wie RFC 2061.

Erkennen entscheidet über den Weg, nicht über das Ergebnis

Bei CAPABILITY nennt eine erfolgreiche OK-Antwort die unterstützten IMAP4-Varianten. Erkennt der Client keine davon, soll er den Server als IMAP2bis behandeln; BAD deutet auf IMAP2bis oder älter. Das ist eine Heuristik zur Wahl des Kompatibilitätswegs, keine eindeutige Serveridentifikation. Zeitüberschreitungen, Sicherheitsprobleme oder sonstige Fehler dürfen nicht pauschal als BAD behandelt werden. Auch die gewählte Route beweist noch keine Befehlswirkung. RFC 2061

Die Ersatzwege lassen sich redaktionell in drei Klassen ordnen; das Memo selbst führt diese Kategorien nicht ein.

Weitgehend gleicher Zweck: Für LIST empfiehlt es FIND ALL.MAILBOXES, mit ähnlicher Syntax und Antwortform wie FIND MAILBOXES aus RFC 1176. Letzteres liefere wahrscheinlich keine nützlichen Informationen. Für * in Sequenzangaben dient die Nachrichtenanzahl aus unaufgeforderten EXISTS-Antworten. Das friert keinen Postfachzustand ein. RFC 2061

Annäherung oder Kompensation: Erweiterte SEARCH-Anfragen werden in die Syntax von RFC 1176 umformuliert, gegebenenfalls als mehrere Suchen; gleiche Zeichensatz- und Kriterienunterstützung ist damit nicht zugesagt. BODYSTRUCTURE weicht dem nicht erweiterbaren BODY; für HEADER, TEXT, MIME, HEADER.FIELDS und HEADER.FIELDS.NOT bleiben Abschnittsnummern. Umbenennen erzeugt keine fehlende Strukturinformation. Hierher gehören auch nachträgliche Zustandskorrekturen. RFC 2061

Fehlende Entsprechungen: Für das UID-Abrufelement, UID-Befehle und CLOSE gibt es keinen funktionalen Ersatz. Sequenznummern oder eine Kombination mit EXPUNGE schließen diese Lücke nicht. LSUB, SUBSCRIBE und UNSUBSCRIBE haben keine direkte Entsprechung. Die früheren bboards waren ein anderes Konzept; ihre Befehle sollen nicht in neuer Software implementiert werden, auch nicht in Servern für alte Clients. RFC 2061

Zurücksetzen ist nicht Nichtstun

RFC 2060 erklärt den Unterschied: BODY[section] setzt implizit \Seen, BODY.PEEK[section] nicht. Andere Akteure dürfen Flags verändern; automatische Flag-Aktualisierungen werden empfohlen. Daraus folgt für veränderlichen, gemeinsam genutzten Zustand: Abrufen und Kompensieren sind getrennte Eingriffe; eine atomare Wiederherstellung ist damit nicht zugesichert. Dazwischen können Beobachter oder weitere Clients tätig werden. Ein schon zuvor gesetztes \Seen darf nicht blind gelöscht werden; auch eine inzwischen erfolgte fremde Änderung lässt sich nicht einfach dem eigenen Abruf zurechnen. Das ist eine technische Folgerung, kein in RFC 2061 dokumentierter Vorfall und keine Behauptung über jede Serverimplementierung.

Ähnlich begrenzt ist der Ersatz von FLAGS.SILENT, +FLAGS.SILENT und -FLAGS.SILENT durch die entsprechenden STORE-Datenelemente ohne .SILENT. Der Client ignoriert dabei die zurückkommenden FETCH-Antworten ohne Befehlskennzeichen. Lokales Ignorieren beseitigt weder die Antworten noch serverseitige oder für andere sichtbare Auswirkungen. RFC 2061

Kopiert heißt nicht bewahrt

Bei IMAP2bis bleibt laut RFC 2061 unbestimmt, ob COPY Flags und internes Datum erhält; das Serververhalten ist aus dieser Beschreibung nicht zu ermitteln. Die Erhaltungsempfehlung (SHOULD) aus RFC 2060 gilt nicht rückwirkend. Ein Erfolg bestätigt keinen Metadatenerhalt; Einzeltests belegen beobachtete Fälle, keinen allgemeinen Vertrag. Auch TRYCREATE verlangt Aufmerksamkeit: Der Hinweis erscheint separat in einer unaufgeforderten OK-Antwort statt innerhalb von NO. Diese Antwortform muss im Fehlerkontext ausgewertet werden; der Hinweis macht ein fehlgeschlagenes COPY nicht erfolgreich.

Was die historische Anleitung nicht verspricht

Für gut geschriebene IMAP2bis-Clients an IMAP4-Servern nennt das Memo nur ein Problem mit Rückstrichen in Zeichenketten in Anführungszeichen: Bei enthaltenem Rückstrich oder Anführungszeichen seien Literale zu verwenden. Diese eingeschränkte Aussage ist keine Zusicherung für sämtliche Altsoftware. Auch LOGIN statt des fehlenden AUTHENTICATE ist historische Kompatibilitätsberatung; Sicherheitsfragen behandelt das Memo ausdrücklich nicht. RFC 2061 Die spätere IETF-Spezifikation RFC 8314 vom Januar 2018 formuliert TLS-Empfehlungen für Mailzugriff und Einlieferung. Der Rat von 1996 rechtfertigt keine heutige Klartextanmeldung oder Sicherheitsherabstufung; RFC 8314 belegt umgekehrt keinen damaligen TLS-Einsatz.

Quellen und Grenzen der Deutung

  • RFC 2061: historische Ersatzwege und ausdrücklich begrenztes Wissen.
  • RFC 2060: zeitgenössische Semantik von IMAP4rev1.
  • RFC 1176: ältere IMAP2-Syntax.
  • RFC 1730: eigenständige IMAP4-Fassung von 1994.
  • RFC 1732: breiterer Vorgängerkontext zur Kompatibilität.
  • RFC 8314: spätere Sicherheitsabgrenzung, keine Quelle für 1996.
  • Lu Heng über freiwillige Übernahme, 2026: „Non-adoption is not a violation.“ Als spätere Deutung verdeutlicht dies die freiwillige Wahl der Kompatibilitätsbeziehungen.
  • Lu Heng über Wirklichkeitsebenen, 2025: „Most conflicts persist because participants mix these layers.“ Die redaktionelle Anwendung hier trennt benannte Fähigkeiten von ausführbaren Wirkungen.

Beide späteren Deutungen liefern weder historische IMAP-Belege noch einen Nachweis für die Absichten von Mark Crispin. Die Folgerung dieses Artikels bleibt enger: Kompatibilität braucht eine ausdrücklich begrenzte Zusage, nicht das unsichtbare Versprechen vollständiger Gleichwertigkeit.