imapsync: Daten nicht erhalten - Korrekturanleitung

7 min

imapsync ist das Referenz-Migrationswerkzeug für Linux-Systemadministratoren, Hosting-Anbieter und alle, die Open-Source-Lösungen bevorzugen. Erstellt von Gilles Lamiral, wird imapsync seit 2001 aktiv gepflegt und wurde weltweit für Millionen von Postfachmigrationen eingesetzt. Es unterstützt praktisch jeden IMAP-Server: Dovecot, Courier, Cyrus, Zimbra, Exchange, Gmail und Dutzende weitere.

imapsync hat den Ruf, vollständig und konfigurierbar zu sein. Administratoren schätzen die granulare Kontrolle über zu migrierende Ordner, Duplikatbehandlung und Ordnernamenzuordnung zwischen verschiedenen IMAP-Servern. Aber trotz all dieser Kontrolle besteht ein Problem fort: E-Mail-Daten werden nach einer imapsync-Migration häufig nicht korrekt erhalten. Benutzer öffnen ihr Postfach nach der Migration und stellen fest, dass jede E-Mail das Migrationsdatum anzeigt. Das ist ärgerlich, besonders weil imapsync eigentlich Daten korrekt behandeln sollte.

Wie imapsync das INTERNALDATE behandelt

Der Versuch der INTERNALDATE-Erhaltung

imapsync versucht tatsächlich, das INTERNALDATE jeder E-Mail während der Migration zu erhalten. Das INTERNALDATE ist der Zeitstempel, den der IMAP-Server als Metadatum für jede Nachricht speichert, getrennt von den E-Mail-Headern. Wenn imapsync eine Nachricht von der Quelle zum Ziel kopiert, liest es das INTERNALDATE vom Quellserver und übergibt es dem Zielserver im IMAP-APPEND-Befehl.

Theoretisch sollte das das Originaldatum erhalten. In der Praxis hängt das Ergebnis vom Verhalten des Zielservers ab und davon, wie E-Mail-Clients die verschiedenen datumsbezogenen Felder in der Nachricht interpretieren.

Das "Received"-Header-Problem

Selbst wenn imapsync das INTERNALDATE erfolgreich erhält, fügt der Ziel-Mailserver bei der APPEND-Operation jeder Nachricht einen neuen "Received"-Header hinzu. Dieser "Received"-Header enthält den aktuellen Zeitstempel - das Migrationsdatum. E-Mail-Clients wie Outlook, Apple Mail und Thunderbird bestimmen das angezeigte "Empfangsdatum", indem sie den obersten "Received"-Header lesen, nicht das INTERNALDATE. Trotz des Bemühens von imapsync, das INTERNALDATE zu erhalten, ist das in den meisten Clients sichtbare Datum also trotzdem falsch.

Diese grundsätzliche Diskrepanz verursacht die Verwirrung. imapsync erhält einen Datumswert (INTERNALDATE), aber E-Mail-Clients zeigen einen anderen an (den Zeitstempel des "Received"-Headers). Für eine technische Vertiefung dieses Mechanismus siehe Warum E-Mails nach der Migration das falsche Datum zeigen.

Das Missverständnis der imapsync-FAQ

Die imapsync-Dokumentation und FAQ gehen auf das Datumsproblem ein, stellen es aber als inhärente Einschränkung dar. Die FAQ suggeriert, dass "Daten bei der IMAP-Migration möglicherweise nicht erhalten bleiben" und impliziert, dass das einfach so ist, wie das IMAP-Protokoll funktioniert. Es stimmt zwar, dass das IMAP-Protokoll von Servern verlangt, beim Einfügen von Nachrichten "Received"-Header hinzuzufügen, aber die FAQ erweckt den Eindruck, das Problem sei permanent und irreparabel.

Das ist nicht korrekt. Die während der Migration hinzugefügten "Received"-Header können nachträglich identifiziert und entfernt werden, wodurch die ursprüngliche Datumsanzeige in E-Mail-Clients wiederhergestellt wird. Der ursprüngliche "Date"-Header (der aufzeichnet, wann die E-Mail gesendet wurde) wird von imapsync immer erhalten und dient als Referenz für das korrekte Datum.

Den imapsync-Migrationsheader identifizieren

Wie der Header aussieht

imapsync selbst fügt keinen "Received"-Header hinzu - das macht der IMAP-Zielserver. Der bei einer imapsync-Migration hinzugefügte Header sieht in der Regel wie ein Standard-IMAP-Einfügeheader des Zielservers aus. Bei einer Migration zu einem Dovecot-Server könnte der Header zum Beispiel so aussehen:

Received: from localhost by mail.example.com;
  Wed, 15 Jan 2025 09:14:22 +0100

Der Schlüsselindikator ist, dass dieser "Received"-Header der oberste in der Kette ist, sein Zeitstempel dem Datum der imapsync-Migration entspricht und er in der Regel "localhost" oder den Hostnamen des Zielservers referenziert statt eines externen Mailservers.

Daten vergleichen

Um das Problem zu bestätigen, vergleichen Sie den Zeitstempel des obersten "Received"-Headers mit dem "Date"-Header der E-Mail. Wenn der "Received"-Header Januar 2025 anzeigt, aber der "Date"-Header März 2020, dann ist der Migrations-"Received"-Header die Ursache der falschen Datumsanzeige. Dieser Vergleich lässt sich durch Anzeige der Rohnachrichtenquelle in jedem E-Mail-Client durchführen.

Warum gängige imapsync-Optionen das Problem nicht lösen

Das Flag --syncinternaldates

imapsync bietet das Flag --syncinternaldates, das das INTERNALDATE auf dem Zielserver so setzt, dass es dem "Date"-Header der E-Mail entspricht. Das ist nützlich, wenn das INTERNALDATE des Quellservers bereits falsch ist, verhindert aber nicht, dass der Zielserver einen "Received"-Header hinzufügt. Das in Outlook und anderen Clients sichtbare Datum bleibt das Migrationsdatum, unabhängig vom INTERNALDATE-Wert.

Die Option --addheader

imapsync kann während der Migration benutzerdefinierte Header zu Nachrichten hinzufügen, kann aber den Zielserver nicht daran hindern, seinen eigenen "Received"-Header hinzuzufügen. Das IMAP-Protokoll verlangt von Servern, den Einfügezeitstempel aufzuzeichnen, und keine imapsync-Option kann dieses serverseitige Verhalten überschreiben.

Skripte nach der Migration

Einige Administratoren schreiben benutzerdefinierte Skripte nach der Migration, um unerwünschte "Received"-Header zu entfernen. Das klingt vernünftig, besonders für den Typ Mensch, der imapsync überhaupt erst gewählt hat (jemand, der mit der Kommandozeile vertraut ist). Aber die Realität ist weit komplexer als ein Suchen-und-Ersetzen von Header-Text. Was passiert, wenn das Skript auf eine S/MIME-signierte E-Mail trifft? Oder eine Multipart-Nachricht mit verschachtelten MIME-Grenzen und base64-kodierten Anhängen? Oder einen Header mit Nicht-ASCII-Zeichen, die nach RFC 2047 kodiert sind? Ein einziges falsch platziertes Byte in einer MIME-Grenze kann stillschweigend eine gesamte Nachricht beschädigen, Anhänge zerstören oder die E-Mail unlesbar machen. Und wie bestätigt man, dass 10.000 korrigierte E-Mails alle intakt sind? Für Tausende von E-Mails über mehrere Postfächer birgt DIY-Scripting ein erhebliches Risiko.

imapsync-Daten mit Redate.io korrigieren

Wie Redate.io imapsync-Migrationen behandelt

Die proprietäre Korrektur-Engine von Redate.io wurde speziell für diese Problemkategorie entwickelt. Nach der Verbindung mit dem Postfach analysiert Redate.io jede E-Mail und leitet jede Nachricht durch eine mehrstufige Analyse-Pipeline. Für imapsync-Migrationen erkennt Redate.io den vom Server eingefügten "Received"-Header, indem es einen Signaturabgleich mit Hunderten bekannter Migrationsprofile durchführt, die vollständige Header-Kette analysiert und Zeitstempel mit dem ursprünglichen "Date"-Header abgleicht.

Das ist keine einfache Header-Bearbeitung. Die Korrektur-Engine behandelt RFC-Konformitätsvalidierung, Bewahrung der Nachrichtenstruktur (einschließlich multipart/alternative-Strukturen, Inline-Anhänge und Content-Transfer-Encoding-Variationen) und die Erkennung digitaler Signaturen. E-Mails mit S/MIME- oder PGP-Signaturen werden automatisch identifiziert und angemessen behandelt, um die Signaturintegrität zu wahren.

Was Sie nach der Korrektur erhalten

Jede korrigierte E-Mail zeigt ihr ursprüngliches Empfangsdatum in allen E-Mail-Clients. Die chronologische Ordnung ist wiederhergestellt. Jede Korrektur durchläuft eine Integritätsprüfung vor der Finalisierung. Die Originalnachricht wird in einen Ordner "Redate.io - Originals" verschoben und 30 Tage als Sicherheitsnetz aufbewahrt.

Kompatibilität mit allen Zielservern

Da imapsync für die Migration zu praktisch jedem IMAP-Server verwendet wird, unterstützt Redate.io dieselbe Bandbreite an Zielplattformen. Ob die imapsync-Migration auf Dovecot, Courier, Cyrus, Zimbra, Google Workspace, Microsoft 365 oder einen anderen IMAP-Server abzielte - Redate.io verbindet sich und korrigiert die Daten.

So korrigieren Sie Daten nach einer imapsync-Migration

Postfach verbinden

Melden Sie sich bei Redate.io an und fügen Sie das Postfach hinzu. Für Google Workspace oder Microsoft 365 nutzen Sie die Admin-Delegationsoption. Für andere IMAP-Server (üblich bei imapsync-Szenarien) geben Sie Serveradresse, Benutzername und Passwort ein. Redate.io verbindet sich per Standard-IMAP.

Kostenlose Analyse

Starten Sie die kostenlose Analyse, um betroffene E-Mails zu identifizieren. Der Analysebericht zeigt die Gesamtzahl der E-Mails, wie viele das falsche Datum haben und welches Migrationsdatum erkannt wurde. Diese Analyse ist kostenlos und gibt ein klares Bild vor jeder Verpflichtung.

Korrigieren und verifizieren

Wählen Sie einen Tarif basierend auf der Anzahl betroffener E-Mails und starten Sie die Korrektur. Der Fortschritt ist in Echtzeit sichtbar. Nach Abschluss überprüfen Sie die Ergebnisse, indem Sie die E-Mail-Daten in Ihrem Client kontrollieren. Die Daten sollten wieder an ihrem Platz sein.

Plattformspezifische imapsync-Korrekturanleitungen

Häufig gestellte Fragen

Sollte man --syncinternaldates von imapsync vor Redate.io verwenden?

Das ist nicht nötig. Redate.io setzt das korrekte INTERNALDATE während des Korrekturprozesses, unabhängig vom aktuellen Wert. Ob imapsync das ursprüngliche INTERNALDATE erhalten hat oder nicht, Redate.io leitet den korrekten Wert aus dem ursprünglichen "Date"-Header ab.

Kann man Daten auf dem Quellserver vor der imapsync-Migration korrigieren?

Wenn der Quellserver bereits falsche Daten hat (aufgrund einer früheren Migration), kann Redate.io sie vor oder nach der imapsync-Migration korrigieren. Die Korrektur der Daten auf dem Zielserver nach der Migration ist jedoch der gängigste und praktischste Ansatz.

Wie viele E-Mails kann Redate.io verarbeiten?

Redate.io verarbeitet Postfächer jeder Größe. Tarife sind für bis zu 100.000 E-Mails pro Postfach verfügbar. Für Organisationen mit vielen Postfächern bietet Redate.io Mengenrabatte.

imapsync-Migration hat die Daten zerstört? Starten Sie eine kostenlose Analyse, um zu sehen, wie viele E-Mails betroffen sind, und korrigieren Sie sie mit Redate.io.