imapsync Daten korrigieren

Das Versprechen von --syncinternaldates (und warum es bricht)

Sie haben den imapsync-Befehl ausgefuhrt. Sie haben --syncinternaldates angegeben, weil Sie die Dokumentation gelesen haben und grundlich vorgehen. Die Migration endet, das Log sagt alles ubertragen, null Fehler. Dann offnen Sie die Mailbox in Outlook und jede E-Mail zeigt das gestrige Datum.

Das ist eine der haufigsten Frustrationen mit imapsync, und sie verwirrt Systemadministratoren seit mindestens 2017. Das Flag --syncinternaldates soll das IMAP INTERNALDATE wahrend der Migration bewahren. Und technisch versucht es das. Aber "versucht" tragt eine Menge Gewicht in diesem Satz.

imapsync ist ein Open-Source-Perl-Tool, geschrieben von Gilles Lamiral, und es ist aufrichtig gut in dem, was es tut. Es bewaltigt IMAP-zu-IMAP-Mailboxtransfers mit einer Zuverlassigkeit, um die die meisten kommerziellen Tools es beneiden. Aber die Datumsbewahrung liegt nicht vollstandig in imapsyncs Handen, und da wird es kompliziert.

Wie IMAP-Daten tatsachlich funktionieren

Bei jeder E-Mail sind drei verschiedene "Daten" beteiligt, und die meisten Menschen (einschliesslich 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 Nachrichtenkorper und wird nie von Mailservern geandert.
Received:-Header - jeder Mailserver, der die Nachricht verarbeitet, fugt einen mit eigenem Zeitstempel hinzu. Sie bilden eine Kette vom Absender zum Empfanger. 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 uber IMAP APPEND gespeichert wird.

Wenn imapsync eine Nachricht migriert, liest es die Nachricht vom Quellserver (einschliesslich des INTERNALDATE) und schreibt sie uber IMAP APPEND auf den Zielserver. Das Flag --syncinternaldates weist imapsync an, das Quell-INTERNALDATE wahrend des APPEND an den Zielserver zu ubergeben.

Hier das Problem: Der Zielserver ist nicht verpflichtet, dieses Datum zu ubernehmen.

Warum Zielserver das INTERNALDATE ignorieren

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". Mehrere grosse E-Mail-Plattformen haben entschieden, dass sie einen guten Grund haben.

Microsoft 365 ist der grosste Ubeltater. Wenn eine Nachricht uber IMAP APPEND ankommt, versieht die Exchange-Transportpipeline sie mit einem neuen Received-Header mit dem aktuellen Datum und setzt dann das INTERNALDATE basierend auf diesem Zustellungszeitstempel. Egal welches Datum imapsync angefordert hat. Der M365-Server uberschreibt es.

Google Workspace (Gmail) verhalt sich anders, kann aber trotzdem Probleme verursachen. Gmails IMAP-Implementierung respektiert das INTERNALDATE vom APPEND in den meisten Fallen, fugt aber einen eigenen Received-Header hinzu. Wenn der E-Mail-Client, der die Mailbox liest, Received-Header gegenuber INTERNALDATE fur die Anzeige priorisiert (und Outlook tut genau das), erscheinen die Daten trotzdem falsch.

Dovecot und Cyrus, die zwei verbreitetsten Open-Source-IMAP-Server, respektieren generell das INTERNALDATE vom APPEND. Daher bewahren imapsync-Migrationen zwischen zwei Dovecot-Servern normalerweise die Daten korrekt. Die Probleme beginnen, wenn das Ziel eine gehostete Plattform mit eigener Transportverarbeitung ist.

Haufige imapsync-Befehlszeilenfehler, die Daten zerstoren

Selbst wenn der Zielserver kooperieren wurde, stolpern Administratoren oft uber imapsyncs Befehlszeilenoptionen. Hier die Fehler, die ich am haufigsten sehe:

--syncinternaldates komplett vergessen

Das Flag ist standardmassig nicht aktiviert. Wenn Sie ein einfaches imapsync --host1 source --host2 dest --user1 user --user2 user ohne das Flag ausfuhren, versucht imapsync uberhaupt nicht, Daten zu bewahren. Der Zielserver verwendet den aktuellen Zeitstempel fur jede Nachricht. Das ist die haufigste Ursache, und sie ist am leichtesten zu ubersehen, weil imapsync Sie nicht davor warnt.

--syncinternaldates mit --addheader verwenden

Einige Anleitungen empfehlen die Verwendung von --addheader, um einen benutzerdefinierten Header wahrend der Migration einzufugen. Wenn Sie Header hinzufugen, andern Sie die Nachricht, was den Zielserver veranlassen kann, sie als "neue" Nachricht zu behandeln und entsprechend zu stempeln. Die Wechselwirkung zwischen diesen beiden Flags ist schlecht dokumentiert.

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 wurde das Datumsproblem beheben. Wird es nicht.

Zeitstempelverschiebung durch SSL-Aushandlung

Bei Migrationen uber TLS mit --ssl1 und --ssl2 fugt der Verbindungsaufbau Latenz hinzu. Bei grossen Migrationen (50.000+ Nachrichten) akkumuliert sich diese Latenz. Das andert Daten zwar nicht um Tage, kann aber dazu fuhren, dass Nachrichten, die Minuten auseinander gesendet wurden, mit identischen Zeitstempeln am Ziel ankommen, was ihre relative Reihenfolge zerstort.

imapsync-Logs lesen: Was die Ausgabe wirklich sagt

imapsync produziert detaillierte Logs, was gut ist. Aber die Logausgabe kann bei Daten irrefuhrend 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 uberein. Das bedeutet, dass imapsync das korrekte INTERNALDATE an das Ziel gesendet hat. Aber es bedeutet nicht, dass der Zielserver dieses Datum tatsachlich gespeichert hat. imapsync meldet, was es angefordert hat, nicht was der Server akzeptiert hat.

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

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Wenn das zuruckgegebene Datum das Migrationsdatum ist statt 2019-01-15, hat der Zielserver imapsyncs Anfrage ignoriert. Das Log hat Sie angelogen (na ja, es hat Ihnen gesagt, was es angefragt hat, nicht was es bekommen hat).

Diese Lucke zwischen dem, was imapsync meldet, und dem, was tatsachlich passiert, ist einer der frustrierendsten Aspekte beim Debugging von Datumsproblemen. Man kann stundenlang auf eine saubere Logdatei starren und nie merken, dass die Daten auf der anderen Seite falsch sind.

Grosse imapsync-Migrationen: Wo sich Datumsprobleme vervielfachen

Eine einzelne Postfachmigration mit imapsync ist argerlich, wenn Daten kaputtgehen. Aber MSPs und IT-Abteilungen, die imapsync uber Hunderte von Postfachern laufen lassen, stehen vor einem ganz anderen Ausmass des Problems.

Betrachten Sie ein typisches Unternehmens-Migrationsszenario. Sie verschieben 200 Postfacher von einem Zimbra-Server zu Microsoft 365. Sie schreiben ein Wrapper-Skript, das uber eine CSV mit Benutzern iteriert und fur jeden imapsync aufruft. Die Migration lauft uber das Wochenende. Montagmorgen haben Sie 200 Postfacher mit kaputten Daten und rund 1,2 Millionen E-Mails insgesamt, die den Migrationszeitstempel zeigen.

Kann man imapsync mit --syncinternaldates erneut ausfuhren, wenn man es beim ersten Mal vergessen hat? Technisch ja, aber imapsync uberspringt Nachrichten, die bereits am Ziel existieren (es ist auf Idempotenz ausgelegt). Man brauchte --delete2, um Zielnachrichten zu loschen und neu zu ubertragen, was bei einer Produktionsmailbox riskant ist. Und selbst dann, wenn der Zielserver das INTERNALDATE ignoriert, ist man wieder am Anfang.

Einige Administratoren versuchen einen Hybridansatz: erst imapsync mit --dry zum Testen, dann die echte Migration. Aber --dry testet nicht, was der Zielserver mit dem INTERNALDATE macht. Es simuliert nur den Transfer. Das Datumsproblem ist unsichtbar, bis die Nachrichten tatsachlich ans Ziel geschrieben werden.

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 Vorschlage, die von kreativ bis gefahrlich reichen.

Manche schlagen vor, einen Perl-Einzeiler zu verwenden, um das INTERNALDATE direkt auf dem Zielserver zu andern. 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 andern und neu einzufugen.

Alle diese Ansatze 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-verschlusselte Nachrichten, bei denen man den Inhalt nicht einmal inspizieren kann? Ein Skript, das 50 Testnachrichten in einer Entwicklungsumgebung bewalitgt, wird an den Randfallen einer Produktionsmailbox mit 30.000 Nachrichten scheitern.

Und die grosste Frage, die niemand stellt, bis es zu spat ist: Wie verifiziert man, dass jede einzelne modifizierte Nachricht noch intakt ist? Dass Anhange nicht beschadigt wurden, dass das Threading noch funktioniert, dass die 85-MB-Tabelle, die jemand 2020 per E-Mail geschickt hat, die Manipulation uberlebt hat?

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

Wie Redate.io imapsync-Datumsprobleme behebt

Der originale Date:-Header ist nach einer imapsync-Migration immer intakt. imapsync ubertragt die Rohnachricht originalgetreu; es ist die Metadatenverarbeitung des Zielservers, die das Anzeigeproblem verursacht. Dieser ursprungliche Header ermoglicht 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 proprietare Header-Ketten-Analyse und Datums-Rekonstruktions-Pipeline an. Die Korrektur behandelt die spezifischen Muster, die imapsync-Migrationen hinterlassen, einschliesslich der charakteristischen Received-Header-Signaturen von Zielservern, die das INTERNALDATE uberschrieben haben.

Jede korrigierte E-Mail wird einzeln verifiziert: Nachrichtenintegritat, Anhangserhaltung, Ordnerplatzierung, Threading, Labels. Originale werden in einem sichtbaren Sicherungsordner Redate.io - Originals fur 30 Tage aufbewahrt. Wenn etwas nicht stimmt, ist das Zurucksetzen 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. Fur die Details Ihrer Plattform:

Redate.io funktioniert auch bei Migrationen, die Monate oder Jahre zuruckliegen. Der Date:-Header lauft nicht ab, und die Moglichkeit 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