Zusammenfassung

  • Eine für alte Clients angepasste Nachricht kann lesbar bleiben, obwohl Antwortadressen, Headerinformationen oder die Grundlage bestimmter Signaturprüfungen nicht vollständig erhalten sind.
  • Wird nach dem Abruf der letzte vollständige Serverbestand gelöscht, kann allein die verlustbehaftete Ersatzfassung übrig bleiben. Ein Softwareupdate beseitigt dieses Problem nicht, wenn es alte Cache-Inhalte weiterverwendet.

Ein späterer Nachweis scheitert selten daran, dass niemand ein Dokument öffnen kann. Er kann daran scheitern, dass das geöffnete Dokument nicht mehr alle Informationen enthält, deren Erhalt vorausgesetzt wurde. Bei internationalisierter E-Mail entsteht diese Möglichkeit bereits vor der Ablage: Der alte Client bekommt eine Ersatznachricht, und das Archiv übernimmt genau diese Fassung.

Solange das Original an anderer Stelle erreichbar ist, lässt sich der Unterschied untersuchen. Kritisch wird der Übergang, wenn ein erfolgreicher Download zugleich die Löschung der Servernachricht auslöst. Die Annahme einer zweiten gleichwertigen Kopie kann dann falsch sein.

Dies ist ein hypothetischer Ablauf, keine Meldung über einen konkreten Ausfall. RFC 6858 beschreibt jedoch ausdrücklich, dass Herunterladen und anschließendes Löschen bei Ersatznachrichten zu dauerhaftem Informationsverlust führen können. Die Frage lautet deshalb nicht allein, ob die Übertragung erfolgreich war, sondern welche Fassung die Organisation danach noch besitzt.

Die Veränderung betrifft mehr als Schriftzeichen

RFC 6532 erlaubt UTF-8 unmittelbar in Headerwerten, einschließlich Adressen, und definiert den Medientyp message/global. Internationalisierung betrifft damit auch Strukturen, die ein Programm zum Antworten oder zum Interpretieren von Nachrichtenteilen verwendet. Nicht jede Mail mit nichtlateinischem Text besitzt eine internationale Antwortadresse; wo diese Strukturen die erweiterten Fähigkeiten benötigen, reicht reine Textdarstellung aber nicht aus.

Ein Server kann einem nicht geeigneten Client eine angepasste Ersatznachricht liefern. Das vereinfachte Verfahren in RFC 6858 gewichtet Implementierungsaufwand stärker als vollständige Wiedergabetreue. Eine nicht darstellbare internationale Adresse darf durch eine absichtlich ungültige Adresse oder eine leere Gruppe ersetzt werden. Eine Adresse, die einem anderen Menschen gehören könnte, darf dabei nicht erfunden werden.

Das ist eine wichtige Sicherheitsgrenze. Eine offen erkennbare Unfähigkeit zu antworten ist besser als ein scheinbar funktionierender Versand an die falsche Person. Doch die Erklärung im Anzeigenamen wird dadurch nicht zu einer benutzbaren Zieladresse. Der Nutzer kann verstehen, dass Information fehlt, ohne die verlorene Funktion zurückzuerhalten.

Auch nicht darstellbare MIME-Parameter und weitere Headerfelder können entfallen. Ein Anhang kann sich weiterhin öffnen lassen, obwohl Teile seiner Beschreibung fehlen. Eine erfolgreiche Sichtprüfung des Nachrichtentextes erfasst diesen Verlust nicht zwangsläufig.

Die Bezeichnung „anderes Format“ ist deshalb zu bequem. Sie legt eine allgemein umkehrbare Darstellung nahe. Eine Ersatzfassung kann aber Informationen überhaupt nicht mehr enthalten. Deren Wiedergewinnung erfordert eine andere erhaltene Quelle, nicht bloß einen besseren Zeichensatz.

Aufbewahrte Hinweise sind keine selbstbeglaubigenden Angaben

RFC 6857 beschreibt einen aufwendigeren Weg, mehr Information zu erhalten. Auch er garantiert nicht generell eine verlustfreie Antwort. Zusätzliche Downgraded-* Felder können bei der Rekonstruktion helfen, sind aber nicht allein aufgrund ihrer Bezeichnung vertrauenswürdig. Die Spezifikation behandelt auch böswillig eingefügte Inhalte solcher Felder.

Eine Wiederherstellung sollte daher nicht irgendeine adressähnliche Zeichenfolge automatisch zur verbindlichen Antwortadresse machen. Das ist eine betriebliche Folgerung dieses Berichts, keine zusätzliche normative Forderung. Ein Hinweis für die Untersuchung und eine ausreichend geprüfte Versandgrundlage erfüllen unterschiedliche Aufgaben.

Dasselbe Maß an Genauigkeit ist bei Signaturen erforderlich. Werden signierte Bestandteile verändert, kann die Prüfung fehlschlagen. Eine Signatur über einen unveränderten Teil kann dagegen weiterhin gültig sein. Weder scheitert jede Signatur zwingend, noch beweist ein erfolgreicher Teilnachweis die Vollständigkeit entfernter Header.

RFC 6858 empfiehlt, Signaturen nicht einfach zu entfernen, weil die Anpassung eine Prüfung vermutlich beeinträchtigt. Eine sauberer aussehende Fehleranzeige wäre kein Gewinn, wenn dafür Untersuchungsmaterial verlorenginge. Erst die Kenntnis der geprüften Fassung und des tatsächlich abgedeckten Inhalts erlaubt eine belastbare Interpretation.

Der Client kann neu sein, seine Kopie aber alt

RFC 9755 wurde im März 2025 veröffentlicht und überarbeitet die UTF-8-Erweiterung für IMAP4rev1. IMAP4rev2 enthält die betreffenden Fähigkeiten bereits. Bei der rev1-Erweiterung sind die Ankündigung UTF8=ACCEPT und die Aktivierung durch den authentifizierten Client getrennte Schritte. Auch bei einem Server mit UTF8=ONLY lautet die Aktivierung ENABLE UTF8=ACCEPT.

Diese ausdrückliche Vereinbarung ordnet die laufende Sitzung. Sie bescheinigt nicht den Informationsgehalt bereits lokal gespeicherter Nachrichten. RFC 9755 verlangt von einem Client, der neu UTF8=ACCEPT versteht, den Cache heruntergeladener Nachrichten zu verwerfen. Andernfalls kann die modernisierte Anwendung weiterhin die frühere Ersatzfassung zeigen.

Der Sachverhalt unterscheidet sich von der üblichen Geschichte einer neu aufgebauten Mailbox mit veränderten UID-Zuordnungen. RFC 9051 bindet die Bedeutung eines UID an Mailbox und Gültigkeitsgeneration. Hier kann die Generation gleich bleiben, während sich die Fähigkeiten des Clients ändern. Ein unverändertes UIDVALIDITY ist deshalb kein ausreichender Nachweis dafür, dass die alte lokale Darstellung nach dem Update genügt.

Eine aussagekräftige Abnahme sollte die bereits installierte Geschichte einschließen. In einer wiederherstellbaren Testumgebung lässt sich das Original erhalten, die vom alten Client bezogene Fassung prüfen und nach dem Update ein frischer Abruf nachweisen. Ein sauberer Test mit einem neuen Konto zeigt nur einen Teil dieser Kette.

Das ist ausdrücklich kein Aufruf, reale Benutzerarchive durch Löschversuche zu testen. Die Wiederherstellung muss bewiesen werden, solange ein vollständiges Original vorhanden und der Versuch kontrollierbar ist.

Zahlen mit begrenzter Aussagekraft

Selbst eine passende Größenangabe hilft weniger, als sie verspricht. RFC 6858 erlaubt bei IMAP-Ersatznachrichten die Angabe der ursprünglichen Nachrichtengröße, obwohl die gelieferte Fassung eine andere Größe besitzt. Gleichheit im Zähler ist somit kein Beweis gleicher Inhalte.

Auch DOWNGRADED ist kein vollständiges Verzeichnis sämtlicher internationalisierter Nachrichten. Die Aussage hängt von den betreffenden Abrufen ab. Eine begrenzte Feldauswahl kann ohne Anpassung auskommen, obwohl andere Felder derselben Mail verändert werden müssten. Wer Warnungen zählt, ohne den angeforderten Umfang zu erfassen, verwechselt einen Beobachtungsausschnitt mit einer Gesamtlage.

Es ist daher möglich, dass ein Betriebsbericht erfolgreiche Downloads korrekt meldet und dennoch nichts über die Vollständigkeit des Archivs aussagt. Dazu muss kein Baustein täuschen. Die Organisation kann eine richtige, aber eng begrenzte Aussage schlicht für die falsche Entscheidung verwenden.

Übertragungserfolg, Nutzbarkeit und Wiederherstellbarkeit sollten getrennte Nachweise erhalten. Erst ihre Verbindung zeigt, ob aus einer technischen Kompatibilitätsmaßnahme eine tragfähige Übergabe des Informationsbestands geworden ist.

Quellenlage und Grenzen

Die Standards beschreiben Verfahren und mögliche Folgen. Sie belegen keine heutige Verbreitungsquote, keine gemessene Verlusthäufigkeit und keinen aktuellen Fehler eines bestimmten Produkts. Softwarebeispiele aus Dokumenten von 2013 sind nicht ohne Weiteres Aussagen über Fassungen von 2026. Aus ihnen wird hier auch keine gesetzliche Aufbewahrungsfrist abgeleitet.

Als redaktioneller Blickwinkel dient Heng Lus Unterscheidung zwischen symbolischer Darstellung und wirksamen Bedingungen. Sie ersetzt nicht die Protokollquellen. Berücksichtigt ist außerdem das verifizierte Erratum 8697, das den Medientypverweis in Abschnitt 6 von RFC 9755 zu message/rfc822 berichtigt.

Die Schlussfolgerung ist nicht, jeden alten Zugang sofort abzuschalten. Sie ist enger: Eine lesbare Ersatzfassung darf nicht ohne gesonderte Begründung zur einzigen erhaltenen Grundlage werden. Nach dem Verlust des letzten Originals kann selbst ein vorbildliches Update die fehlenden Informationen nicht neu abrufen.