imapsync Daten korrigieren

Das Versprechen von --syncinternaldates (und wo es an seine Grenzen stößt)

Sie haben den imapsync-Befehl ausgeführt. Sie haben --syncinternaldates angegeben, weil Sie die Dokumentation gelesen haben und gründlich vorgehen. Die Migration endet, das Log sagt alles übertragen, null Fehler. Dann öffnen Sie die Mailbox in Outlook und jede E-Mail zeigt das gestrige Datum.

Das ist eine der häufigsten Frustrationen mit imapsync, und sie verwirrt Systemadministratoren seit mindestens 2017. Das Flag --syncinternaldates soll das IMAP INTERNALDATE während der Migration bewahren. Und das tut es auch: Es gibt jeder Kopie das interne Datum, das der Quellserver hält. Genau dort liegt die Falle.

imapsync ist ein Open-Source-Perl-Tool, geschrieben von Gilles Lamiral, und es ist aufrichtig gut in dem, was es tut. Es bewältigt IMAP-zu-IMAP-Mailboxtransfers mit einer Zuverlässigkeit, um die die meisten kommerziellen Tools es beneiden. Aber imapsync kann nur die Datumsangaben kopieren, die es vorfindet, und da wird es kompliziert.

Wie IMAP-Daten tatsächlich funktionieren

Bei jeder E-Mail sind drei verschiedene "Daten" beteiligt, und die meisten Menschen (einschließlich mancher IT-Administratoren) verwechseln sie:

Der Date:-Header (RFC 2822) - das Datum, das der E-Mail-Client des Absenders beim Verfassen gestempelt hat. Dieses lebt im Nachrichtenkörper und wird nie von Mailservern geändert.
Received:-Header - jeder Mailserver, der die Nachricht verarbeitet, fügt einen mit eigenem Zeitstempel hinzu. Sie bilden eine Kette vom Absender zum Empfänger. Der oberste (neueste) Received-Header ist das, was manche E-Mail-Clients zur Anzeige verwenden.
INTERNALDATE - ein serverseitiger IMAP-Zeitstempel, der steuert, wie Nachrichten im Postfach sortiert werden. Er wird gesetzt, wenn die Nachricht erstmals über IMAP APPEND gespeichert wird.

Wenn imapsync eine Nachricht migriert, liest es die Nachricht vom Quellserver (einschließlich des INTERNALDATE) und schreibt sie über IMAP APPEND auf den Zielserver. Das Flag --syncinternaldates weist imapsync an, das Quell-INTERNALDATE während des APPEND an den Zielserver zu übergeben.

Hier die gute Nachricht: Microsoft 365, Outlook.com und Gmail behalten das Datum, das sie erhalten. Wenn also Datumsangaben falsch herauskommen, liegt das Problem woanders.

Warum das Datum trotzdem falsch sein kann

Die IMAP-Spezifikation (RFC 3501) sagt, dass der Server das Datum verwenden SOLLTE, wenn eine Datum-Zeit mit dem APPEND-Befehl angegeben wird. "SOLLTE" in RFC-Sprache bedeutet "tun Sie es, es sei denn, Sie haben einen guten Grund dagegen". Microsoft 365, Outlook.com und Gmail tun genau das: Eine Kopie, die ihr Originaldatum trägt, behält es.

Was imapsync übergibt, ist jedoch das Datum, das der QUELLSERVER für jede Nachricht hält, nicht das Datum, an dem die E-Mail gesendet wurde. Bei einem unversehrten Postfach stimmen beide überein. Bei einem Postfach, das bereits einmal migriert oder aus einer Datensicherung wiederhergestellt wurde, kann die Quelle das Datum dieser früheren Operation halten, und imapsync kopiert es unverändert.

Gmail ist nur dann ein Sonderfall, wenn die Kopie über Gmails eigene Import-API läuft statt über IMAP: Diese API fügt eine Received:-Zeile mit dem Datum der Kopie hinzu, und Outlook kann dieses Datum anzeigen. imapsync spricht IMAP, davon ist es nicht betroffen.

Dovecot und Cyrus, die zwei verbreitetsten Open-Source-IMAP-Server, behalten ebenfalls das Datum vom APPEND. Ganz gleich, welches Ziel es ist, die Frage bleibt dieselbe: Welches Datum hielt die Quelle?

Häufige imapsync-Befehlszeilenfehler, die Daten zerstören

Über die Quelldaten hinaus stolpern Administratoren oft über imapsyncs Befehlszeilenoptionen, oder geben den falschen die Schuld. Hier die Fehler, die ich am häufigsten sehe:

Kopieren aus einer Quelle, deren Datumsangaben schon falsch waren

--syncinternaldates ist standardmäßig aktiviert: imapsync gibt jeder Kopie das interne Datum, das der Quellserver hält (laut Dokumentation: "Sets the internal dates on host2 as the same as host1"). Wenn das Quellpostfach selbst aus einer früheren Migration oder Wiederherstellung stammt, können seine internen Datumsangaben bereits die dieser Operation sein, und imapsync kopiert das falsche Datum originalgetreu. Das ist die häufigste Ursache, und sie ist am leichtesten zu übersehen, weil das Log zwei identische Datumsangaben zeigt.

--syncinternaldates mit --addheader verwenden

Einige Anleitungen empfehlen die Verwendung von --addheader, um einen benutzerdefinierten Header während der Migration einzufügen. Das Hinzufügen eines Headers ändert die Nachricht (eine Zeile mehr am Anfang), aber nicht das Datum, das imapsync übergibt, es erklärt also keine falschen Datumsangaben. Die Kopie ist damit einfach nicht mehr identisch mit dem Original, was zählt, wenn Sie beide vergleichen.

Verwechslung von --minage und --maxage mit Datumsbewahrung

Die Flags --minage und --maxage filtern, welche Nachrichten basierend auf ihrem Alter migriert werden. Sie beeinflussen nicht, wie Daten am Ziel behandelt werden. Ich habe gesehen, wie Administratoren Stunden damit verbracht haben, diese Flags anzupassen, in der Annahme, das würde das Datumsproblem beheben. Wird es nicht.

TLS für verschobene Datumsangaben verantwortlich machen

Über TLS (--ssl1, --ssl2) fügt der Verbindungsaufbau Latenz hinzu, und bei einer großen Migration (50.000+ Nachrichten) summiert sich das auf Stunden. Das betrifft die Datumsangaben nicht: Jede Kopie trägt das Datum, das imapsync übergibt, egal wann sie tatsächlich ankommt.

imapsync-Logs lesen: Was die Ausgabe wirklich sagt

imapsync produziert detaillierte Logs, was gut ist. Aber die Logausgabe kann bei Daten irreführend sein.

Eine typische erfolgreiche Transferzeile sieht so aus:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Beide Daten stimmen überein. Das bedeutet, dass imapsync das korrekte INTERNALDATE an das Ziel gesendet hat. Und Microsoft 365, Outlook.com und Gmail behalten alle das Datum, das sie erhalten. Aber zwei identische Datumsangaben belegen nur, dass die Kopie der QUELLE treu ist: War das Quelldatum schon falsch, zeigen beide Spalten dasselbe falsche Datum.

Wollen Sie verifizieren, was wirklich passiert ist? Verbinden Sie sich nach der Migration mit einem IMAP-Client zum Ziel und prüfen Sie das INTERNALDATE direkt:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Wenn das zurückgegebene Datum nicht dem Versanddatum der E-Mail entspricht, sehen Sie sich dieselbe Nachricht auf der Quelle an: Dort finden Sie dasselbe falsche Datum. Das Log hat nicht gelogen, es hat kopiert, was es erhalten hat.

Das ist einer der frustrierendsten Aspekte beim Debugging von Datumsproblemen: eine saubere Logdatei, zwei identische Datumsangaben, und trotzdem das falsche Datum in Outlook, weil der Fehler schon da war, bevor imapsync lief.

Große imapsync-Migrationen: Wo sich Datumsprobleme vervielfachen

Eine einzelne Postfachmigration mit imapsync ist ärgerlich, wenn Daten kaputtgehen. Aber MSPs und IT-Abteilungen, die imapsync über Hunderte von Postfächern laufen lassen, stehen vor einem ganz anderen Ausmaß des Problems.

Betrachten Sie ein typisches Unternehmens-Migrationsszenario. Sie verschieben 200 Postfächer von einem Zimbra-Server zu Microsoft 365. Sie schreiben ein Wrapper-Skript, das über eine CSV mit Benutzern iteriert und für jeden imapsync aufruft. Die Migration läuft über das Wochenende. Montagmorgen haben Sie 200 Postfächer mit kaputten Daten und rund 1,2 Millionen E-Mails insgesamt, die den Migrationszeitstempel zeigen.

Kann man imapsync erneut ausführen, um das Problem zu beheben? Technisch ja, aber imapsync überspringt Nachrichten, die bereits am Ziel existieren (es ist auf Idempotenz ausgelegt). Man bräuchte --delete2, um Zielnachrichten zu löschen und neu zu übertragen, was bei einer Produktionsmailbox riskant ist. Und wenn die Quelldatumsangaben das Problem waren, kopiert ein zweiter Durchlauf dieselben falschen Datumsangaben erneut.

Einige Administratoren versuchen einen Hybridansatz: erst imapsync mit --dry zum Testen, dann die echte Migration. Aber --dry simuliert nur den Transfer: Es zeigt die Datumsangaben, die imapsync übergeben würde, nicht ob es sich um die Versanddaten der E-Mails handelt. Nichts warnt Sie, dass die Quelldatumsangaben bereits falsch sind.

Selbstgemachte Korrekturen und ihre Grenzen

Wenn Sie in Foren und Mailinglisten suchen (die imapsync-devel-Liste auf SourceForge ist Anfang 2026 noch aktiv), finden Sie Vorschläge, die von kreativ bis gefährlich reichen.

Manche schlagen vor, einen Perl-Einzeiler zu verwenden, um das INTERNALDATE direkt auf dem Zielserver zu ändern. Andere empfehlen, alle Nachrichten ins mbox-Format zu exportieren, die Daten zu manipulieren und neu zu importieren. Einige haben Python-Skripte geschrieben, die imaplib verwenden, um Nachrichten abzurufen, zu ändern und neu einzufügen.

Alle diese Ansätze teilen dieselben grundlegenden Probleme. Wie behandelt man S/MIME-signierte Nachrichten, ohne die Signatur zu brechen? Was ist mit Multipart-MIME-Strukturen mit verschachtelten Boundaries? Nicht-ASCII-Header, die mit RFC 2047 kodiert sind? PGP-verschlüsselte Nachrichten, bei denen man den Inhalt nicht einmal inspizieren kann? Ein Skript, das 50 Testnachrichten in einer Entwicklungsumgebung bewalitgt, wird an den Randfällen einer Produktionsmailbox mit 30.000 Nachrichten scheitern.

Und die größte Frage, die niemand stellt, bis es zu spät ist: Wie verifiziert man, dass jede einzelne modifizierte Nachricht noch intakt ist? Dass Anhänge nicht beschädigt wurden, dass das Threading noch funktioniert, dass die 85-MB-Tabelle, die jemand 2020 per E-Mail geschickt hat, die Manipulation überlebt hat?

(Wenn Sie jemals versucht haben, rohe E-Mail-Header in Perl zu parsen, ehrlich gesagt wissen Sie, dass das nicht gerade eine entspannende Nachmittagsbeschäftigung ist.)

Wie Redate.io imapsync-Datumsprobleme behebt

Der originale Date:-Header ist nach einer imapsync-Migration immer intakt. imapsync überträgt die Rohnachricht originalgetreu; das falsche Datum liegt in den Metadaten der Kopie, nicht in der Nachricht selbst. Dieser ursprüngliche Header ermöglicht die Korrektur.

Redate.io verbindet sich direkt mit dem Postfach (Google Workspace, Microsoft 365 oder beliebiger IMAP-Server), scannt nach E-Mails mit Datumsanomalien und wendet gezielte Metadaten-Korrektur durch eine proprietäre Header-Ketten-Analyse und Datums-Rekonstruktions-Pipeline an. Es muss nicht wissen, welches Werkzeug die Migration durchgeführt hat: Es findet die E-Mails, deren angezeigtes Datum nicht mit ihrem Originaldatum übereinstimmt.

Jede korrigierte E-Mail wird einzeln verifiziert: Nachrichtenintegrität, Anhangserhaltung, Ordnerplatzierung, Threading, Labels. Originale werden in einem sichtbaren Sicherungsordner Redate.io - Originals aufbewahrt, bis Sie sie selbst löschen. Wenn etwas nicht stimmt, ist das Zurücksetzen einen Klick entfernt.

Der kostenlose Scan verbindet sich mit dem Postfach, identifiziert jede E-Mail mit einer Datumsanomalie und meldet die genaue Anzahl und Kosten. Keine Kreditkarte erforderlich, keine Software zu installieren. Für die Details Ihrer Plattform:

Redate.io funktioniert auch bei Migrationen, die Monate oder Jahre zurückliegen. Der Date:-Header läuft nicht ab, und die Möglichkeit zur Korrektur auch nicht.

Mit imapsync migriert und falsche Daten auf den E-Mails? Starten Sie einen kostenlosen Scan, um genau zu sehen, wie viele E-Mails betroffen sind.

imapsync: Daten nicht erhalten? So beheben Sie das