imapsync: Praxisleitfaden für sichere E-Mail-Migrationen (2026)

Sie stehen vor einem Migrationsprojekt, das Ihnen Sorgen bereitet. Sie müssen E-Mails von Server A auf Server B verschieben, ohne eine einzige Nachricht zu verlieren, die Ordnerstruktur zu zerstören oder einem Drittanbieter $15 pro Benutzer für eine "Migrationslizenz" zu zahlen, nur um Daten zu übertragen, die Ihnen bereits gehören.

Was Sie suchen, ist imapsync. Dieser Leitfaden zeigt Ihnen genau, wie Sie das Werkzeug einsetzen, ohne die Postfächer Ihrer Benutzer ins Chaos zu stürzen.

Was imapsync ist (und was nicht)

imapsync ist ein Befehlszeilenprogramm, das Postfächer zwischen zwei IMAP-Servern synchronisiert. Es fungiert als Vermittler, stellt gleichzeitig eine Verbindung zu beiden Servern her, liest Nachrichten von der Quelle und fügt sie am Ziel ein. Das Programm merkt sich den Status, bewältigt Unterbrechungen und erhält Ordnerstruktur, Markierungen und Nachrichteninhalt.

Es ist kein Sicherungsprogramm und kein SMTP-Relay. Es übernimmt weder Google Kalender noch Outlook-Kontakte oder Exchange-Transportregeln. Es spricht IMAP und ausschließlich IMAP. Wenn der Quellserver durch eine Firewall abgeschottet oder offline ist, kann imapsync ihn nicht erreichen. Damit ist die Sache erledigt.

Zum Branchenstandard für Übertragungen zwischen Postfächern macht es die Erhaltung des Zustands. Bei einer erfolgreichen Migration geht es nicht nur darum, Text zu verschieben, sondern drei Dinge zu bewahren:

• Inhalt: RFC-822-Nachrichtentext, Anhänge, MIME-Codierung, also alles innerhalb des Umschlags.
• Metadaten: Die Markierungen. \Seen (gelesen), \Answered (beantwortet), \Flagged (markiert). Werden sie nicht übernommen, glauben alle Benutzer am ersten Tag, sie hätten 4,000 neue ungelesene E-Mails.
• Struktur: Die Ordnerhierarchie. INBOX/Clients/ProjectA muss auf dem neuen Server genauso aussehen und darf nicht zu einem einzigen Ordner namens INBOX.Clients.ProjectA mit Punkten im Namen zusammenfallen.

imapsync bewahrt alle drei, wenn es richtig konfiguriert ist. Genau das ist der schwierige Teil, bei dem dieser Leitfaden hilft.

Die festen Grenzen: imapsync kennt die Ratenbegrenzungen von Gmail oder die API-Drosselung von Microsoft nicht von selbst. Lassen Sie es mit voller Leistung laufen, kann Ihre IP-Adresse gesperrt werden. Das Programm überträgt Daten außerdem nicht aktiv an ein Ziel. Benötigen Sie Daten an einem anderen Ort, müssen Sie sie abrufen. Standardmäßig löscht es auch nichts am Ziel. Das ist eine Sicherheitsfunktion, kann aber bei mangelnder Aufmerksamkeit Probleme bereiten. Mehr dazu folgt in Phase 6.

Einen umfassenderen Überblick über das Protokoll selbst bietet unser Leitfaden zum Einrichten von E-Mail für Ihre Domain.

Phase 1: Sorgfältige Bestandsaufnahme, diesen Schritt nicht überspringen

Amateure beginnen sofort mit dem Kopieren. Profis prüfen zuerst die Umgebung. Wenn Sie nicht wissen, was Sie verschieben, wird die Migration scheitern, und zwar am Sonntag um 2 Uhr nachts, wenn es für eine schnelle Korrektur zu spät ist.

1. Die Schwergewichte finden

Ein Benutzer hat ein Postfach mit 45GB. Vielleicht ist es der CEO, vielleicht die Person, der seit 2011 der Alias sales@ gehört. Wenn Sie dieses Postfach im selben Stapel wie die Postfächer mit 500MB migrieren, kommt der ganze Durchlauf zum Stillstand und Sie sehen nur noch ein eingefrorenes Terminal, ohne den Fortschritt zu kennen.

Führen Sie zuerst einen Vorabscan aus:

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfoldersizes

So erhalten Sie eine Aufschlüsselung nach Ordnern, ohne eine einzige Nachricht zu verändern. Jedes Postfach mit mehr als 10GB muss separat behandelt werden: mit längeren Zeitlimits, einem eigenen Ausführungsfenster und Ihrer ungeteilten Aufmerksamkeit.

2. Das Problem verborgener Daten

Jedes Unternehmen hat verwaiste Konten. Dazu gehören ehemalige Mitarbeiter, deren E-Mails noch immer irgendwohin weitergeleitet werden, und "Dienstkonten", die in Wirklichkeit gemeinsam genutzte Postfächer für einen Drucker oder eine alte CRM-Anbindung sind. Übersehen Sie diese bei der Bestandsaufnahme, bleiben ihre Daten zurück, sobald Sie den DNS-Eintrag umstellen.

Gleichen Sie die Benutzerliste des Quellsystems mit den tatsächlich aktiven Benutzern ab. Wenn bob@company.com das Unternehmen vor drei Jahren verlassen hat, entscheiden Sie jetzt: Wird sein Postfach migriert oder als EML-Export archiviert? Treffen Sie die Entscheidung nicht vor der Umstellung, müssen Sie sie später unter größtmöglichem Druck fällen. Unser Leitfaden zur E-Mail-Verwaltung für Kunden enthält eine vollständige Vorlage für die Bestandsaufnahme vor der Migration.

3. Auf die Anzahl der Elemente kommt es an

Verlassen Sie sich nie auf die Größe in Gigabyte. Quellserver A kann ein Postfach mit 10GB melden, während Zielserver B für exakt dieselben Daten 11GB angibt. Das ist kein Fehler, denn verschiedene Server berechnen die Speichernutzung unterschiedlich. Exchange berücksichtigt den Ordner "Recoverable Items", auch "Dumpster" genannt. Gmail dedupliziert Nachrichten über Labels hinweg.

Die entscheidende Kennzahl ist die Anzahl der Elemente. Hat die Quelle 14,200 Nachrichten und das Ziel ebenfalls 14,200, ist die Übertragung abgeschlossen. Eine Abweichung der Datenmenge von weniger als 10% ist normal und zu erwarten. Liegt sie über 10%, müssen Sie die Ursache vor der Abnahme untersuchen.

Phase 2: Der sichere Migrationsablauf

Der größte Fehler bei einer Migration ist die Komplettumstellung auf einen Schlag: am Freitagabend alles verschieben und hoffen, dass der Vorgang bis Montagmorgen abgeschlossen ist. Bei 50GB E-Mail und einer Drosselung auf 500KB/s geht die Rechnung nicht auf. Am Montag fällt der Dienst aus, während Sie Ihrem CEO erklären, warum der Posteingang leer ist.

Profis arbeiten mit einer mehrstufigen Migration. Der Großteil wird übertragen, während die Benutzer noch im alten System arbeiten. Bei der eigentlichen Umstellung bleibt dann nur noch eine kleine abschließende Differenz.

Schritt 1: Der Testlauf

Bevor Sie ein einziges Byte verschieben, prüfen Sie die Verbindung. Verwenden Sie --dry zusammen mit --justfolders. Damit simulieren Sie den Durchlauf und sehen die Ordnerstruktur, ohne etwas zu kopieren.

imapsync \
  --host1 imap.gmail.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.trekmail.net --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfolders

Achten Sie auf zwei Dinge: War die Authentifizierung erfolgreich, und wie sehen die Ordnernamen aus? Wenn die Quelle [Gmail]/Sent Mail enthält, müssen Sie diesen Ordner am Ziel Sent Items zuordnen. Finden Sie das nicht erst bei der laufenden Umstellung heraus.

Schritt 2: Die Hauptsynchronisierung (Vorbereitung)

Führen Sie sie 1 bis 2 Wochen vor der Umstellung aus, während die Benutzer noch im alten System arbeiten. Das Ziel besteht darin, 90 bis 95% der Daten vor dem kritischen Zeitraum zu übertragen.

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --usecache --skipsize --maxsize 25000000

--usecache ist unverzichtbar. Die Option speichert den Migrationsstatus lokal. Jeder weitere Durchlauf gleicht die Daten mit diesem Cache ab und verarbeitet nur Änderungen. Es wird nicht jede Nachricht erneut von Grund auf geprüft. Ohne Cache ist jeder Durchlauf ein vollständiger Scan.

--maxsize 25000000 überspringt beim ersten Durchlauf Nachrichten, die größer als 25MB sind. Große Anhänge verursachen die meisten Zeitüberschreitungen und Verbindungsabbrüche. Sie übertragen diese später in einem separaten Durchlauf mit längeren Zeitlimits.

Schritt 3: Die Differenzsynchronisierung

Führen Sie imapsync einige Tage vor der Umstellung erneut aus. Das Programm liest den Cache, erkennt die bereits am Ziel vorhandenen 10,000 E-Mails, überspringt sie und kopiert nur die 50 bis 100 neuen Nachrichten, die seit der Hauptsynchronisierung eingegangen sind. Dieser Durchlauf sollte Minuten statt Stunden dauern.

Schritt 4: Die Umstellung

Jetzt kommt es darauf an. Gehen Sie der Reihe nach vor:

1. DNS-TTL senken: Setzen Sie die TTL des MX-Eintrags 48 Stunden vor der Umstellung auf 300 Sekunden. Warten Sie bis zur letzten Minute, speichern manche Resolver den alten MX-Eintrag bis zu 24 Stunden im Cache. Dann treffen E-Mails noch auf dem alten Server ein, obwohl Sie bereits umgestellt haben.
2. MX-Einträge umstellen: Lassen Sie sie auf den neuen Anbieter zeigen.
3. 60 Minuten warten, damit die Änderung bei den wichtigsten Resolvern ankommt.
4. Letzte Differenz ausführen: Ein letzter imapsync-Durchlauf übernimmt alle Nachrichten, die während der DNS-Aktualisierung noch auf dem alten Server eingegangen sind.

Eine ausführliche Beschreibung des DNS-Zeitfensters und der zu überwachenden Punkte finden Sie in unserem Leitfaden zum Einrichten von E-Mail für Ihre Domain.

Phase 3: Markierungen, Ordner und die Falle mit gesendeten Nachrichten

IMAP-Server sprechen unterschiedliche Dialekte. Wenn Sie nicht zwischen ihnen übersetzen, finden Ihre Benutzer ein strukturell beschädigtes Postfach vor, und sie werden Ihnen zu Recht die Schuld geben.

Das Problem mit Trennzeichen

Dies ist der häufigste technische Fehler, über den niemand spricht, bevor er selbst davon betroffen ist.

Verschiedene IMAP-Server trennen die Ebenen einer Ordnerhierarchie mit unterschiedlichen Zeichen:

• Dovecot verwendet üblicherweise einen Punkt: INBOX.Clients.ProjectA
• Exchange/Outlook verwendet einen Schrägstrich: INBOX/Clients/ProjectA
• Einige Server verwenden gar kein Trennzeichen und greifen auf den IMAP-Befehl NAMESPACE zurück

Bei einer unbedachten Migration kann imapsync am Ziel einen Ordner anlegen, der tatsächlich INBOX.Clients.ProjectA heißt. Dann entsteht ein einzelner flacher Ordner mit Punkten im Namen statt einer verschachtelten Hierarchie mit drei Ebenen. Die Ordnerstruktur jedes Benutzers sieht danach völlig zerstört aus.

Abhilfe schafft --regextrans2. Die Option schreibt Ordnerpfade während der Übertragung mithilfe regulärer Ausdrücke um. Testen Sie die Ordnererstellung immer mit --dry für ein einzelnes Testkonto, bevor Sie einen Stapel mit 100 Benutzern ausführen.

Das Chaos mit gesendeten Nachrichten

Jeder Server nennt den Ordner für gesendete Nachrichten anders. Das ist keine kleine Unannehmlichkeit, sondern führt zu einer miserablen Benutzererfahrung, wenn Sie es ignorieren.

Ohne Zuordnung erhält der Benutzer zwei Ordner für gesendete Nachrichten: den aktiven Ordner Sent Items und einen neuen verwaisten Ordner namens Sent Mail mit dem gesamten Verlauf. Das fällt auf und sorgt für Unmut.

Ordnen Sie die Namen ausdrücklich zu:

--regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/'

Damit weisen Sie imapsync an: "Wenn der Quellordner mit [Gmail]/Sent Mail beginnt, benenne ihn am Ziel in Sent Items um." Führen Sie zunächst die gesamte Ordnerzuordnung mit --dry aus. So bestätigen Sie vor der endgültigen Übernahme, dass jede Regel richtig greift.

Die Falle mit "All Mail" in Gmail

Gmail hat einen Ordner namens [Gmail]/All Mail. Er enthält unabhängig vom Label eine Kopie jeder einzelnen E-Mail. Es handelt sich um die interne Gesamtansicht von Gmail, die als IMAP-Ordner sichtbar ist.

Wenn Sie All Mail und Inbox und Sent Mail migrieren, wird jede E-Mail am Ziel zwei- oder dreimal dupliziert. Aus einem Postfach mit 10GB werden 30GB. Jede Nachricht erscheint mehrfach. Das Ergebnis ist verheerend.

Schließen Sie den Ordner immer aus:

--exclude "All Mail"

Schließen Sie außerdem [Gmail]/Spam und [Gmail]/Trash aus, sofern es keinen konkreten Grund für ihre Übernahme gibt. Niemand möchte alten Spam migrieren.

Phase 4: Leistungsoptimierung und Drosselung

Sie können Google oder Microsoft nicht mit Daten überfluten. Deren Infrastruktur behandelt eine IMAP-Verbindung mit hohem Datenvolumen genau wie einen Denial-of-Service-Angriff, denn aus ihrer Sicht sieht beides gleich aus.

Die Strafbank

Überschreiten Sie die Ratenbegrenzungen, bei Gmail meist ungefähr 1 Nachricht pro Sekunde oder 500MB pro Stunde, gibt der Server HTTP 429, NO [OVERQUOTA] oder schlicht BAD zurück. Machen Sie trotzdem weiter, kann das Konto für bis zu 24 Stunden gesperrt werden. Diesen Anruf beim Support möchten Sie vermeiden.

Optionen zur Feinabstimmung

--maxmessagespersecond 1     # Hard speed limit: 1 email per second
--maxbytespersecond 500000   # Bandwidth cap: 500KB/s
--timeout 120                # Network timeout in seconds (default is often too short for big attachments)
--reconnectretry1 3          # Retry on source connection drops
--reconnectretry2 3          # Retry on destination connection drops

1 Nachricht pro Sekunde klingt quälend langsam. Das ist es auch. Dafür läuft die Übertragung stetig und wird abgeschlossen. Ein aggressiver Durchlauf, der in Stunde 3 gesperrt wird, endet dagegen nie.

Hinweis für MSPs: Wenn Sie parallele Migrationen für mehrere Kunden durchführen, lassen Sie sie nicht gleichzeitig gegen denselben Quellserver laufen. Staffeln Sie die Startzeiten. Jeder parallele Datenstrom benötigt ein eigenes Drosselungskontingent.

Wenn Sie zu TrekMail migrieren, ist unsere IMAP-Übernahme auf viele gleichzeitige Verbindungen ausgelegt. Auf der Zielseite können Sie die Leistung in der Regel höher ansetzen als auf der Quellseite bei Google oder Microsoft.

Phase 5: Authentifizierung, die Hürde moderner Anmeldeverfahren

Die Zeiten, in denen password123 in einer Klartextdatei stand, sind vorbei. Google und Microsoft haben Basic Auth für IMAP eingestellt. Mit den üblichen Anmeldedaten erhalten Sie einen Authentifizierungsfehler und fragen sich eine Stunde lang, was Sie falsch gemacht haben.

App-Passwörter (für kleine und mittlere Unternehmen)

Bei den meisten Migrationen einer einzelnen Domain sind App-Passwörter der schnellste Weg. Diese Zeichenfolgen aus 16 Zeichen umgehen 2FA und funktionieren mit älteren IMAP-Clients:

1. Beim Quellkonto anmelden (Gmail, Workspace usw.)
2. 2-Faktor-Authentifizierung aktivieren, wenn sie noch nicht aktiv ist (für die Erstellung von App-Passwörtern erforderlich)
3. Zu Sicherheitseinstellungen → App-Passwörter wechseln
4. Ein Passwort für "Mail" auf "Anderes Gerät" erstellen
5. Diese Zeichenfolge als Passwort in der imapsync-Option --passfile verwenden

Speichern Sie das Passwort mit chmod 600 in einer Datei und nicht in der Befehlszeile. Anmeldedaten im Bash-Verlauf führen früher oder später zu einem bösen Erwachen.

OAuth2 (für MSPs und Unternehmen)

Als MSP, der 500 Benutzer migriert, können Sie nicht manuell 500 App-Passwörter erzeugen. Sie benötigen OAuth2. Dieser Weg ist komplexer, aber in diesem Umfang die einzige realistische Möglichkeit:

1. Eine Anwendung im Quellmandanten registrieren (Azure AD bei Microsoft, Google Cloud Console bei Google)
2. Der Anwendung vollständigen Zugriff auf alle Postfächer des Mandanten gewähren (Genehmigung durch einen Global Admin erforderlich)
3. Für jeden Benutzer ein Refresh Token erstellen oder die Identitätsübernahme durch ein Dienstkonto verwenden
4. Das Token über --oauthaccesstoken1 an imapsync übergeben

Wenn Sie die Anwendungsberechtigungen in Azure AD oder GCP falsch konfigurieren, wird entweder der Zugriff auf jedes Postfach verweigert oder, noch schlimmer, Sie gewähren versehentlich umfassendere Rechte als beabsichtigt. Lesen Sie die Berechtigungsbereiche sorgfältig, bevor Sie auf "Grant admin consent" klicken.

Einen praxisnahen Einblick in umfangreiche Migrationen bietet unser Leitfaden zum Verwalten von Kunden-E-Mail.

Phase 6: Häufige Fehler und ihre Behebung

Auch der beste Plan stößt auf Probleme. So erkennen Sie, was schiefgegangen ist, und beheben es, ohne von vorn beginnen zu müssen.

1. Das UIDVALIDITY-Problem (das schlimmste Szenario)

Jeder IMAP-Ordner besitzt eine eindeutige Kennung namens UIDVALIDITY. Anhand dieser Kennung verfolgt imapsync, welche Nachrichten bereits kopiert wurden. Wird ein Ordner auf dem Quellserver gelöscht und neu erstellt oder wird der Serverindex nach einer Beschädigung neu aufgebaut, ändert sich diese ID.

Symptom: imapsync erkennt eine neue UIDVALIDITY, hält den Ordner für vollständig neu und lädt alles erneut herunter. Danach ist jede Nachricht in diesem Ordner doppelt vorhanden. Bei einer großen Migration entstehen so Tausende Duplikate in Hunderten Postfächern.

Lösung: Löschen Sie die lokalen Cache-Dateien im temporären Verzeichnis und führen Sie imapsync dann erneut mit --useheader aus:

--useheader

Damit vergleicht imapsync statt der Ordner-UID den Header Message-ID jeder E-Mail. Dieser ist unveränderlich und eindeutig. Das Verfahren ist langsamer, verhindert aber Duplikate. Verwenden Sie es immer, wenn Sie vermuten, dass der Index des Quellservers verändert wurde.

2. Beschädigte Nachrichten und Nachrichten mit null Byte

Auf alten Servern sammeln sich "Geisternachrichten" an: Header ohne Nachrichtentext oder Dateien mit exakt 0 Byte. Meist entstehen sie durch einen fehlgeschlagenen Import, einen Absturz bei der Zustellung oder einen sehr alten Server, dessen Wartung jahrelang aufgeschoben wurde.

Symptom: imapsync versucht eine Nachricht abzurufen, der Server reagiert 120 Sekunden lang nicht und trennt dann die Verbindung. Bei derselben Nachricht wiederholt sich das endlos.

Lösung:

--minbytes 10

Damit überspringt imapsync jede Nachricht, die kleiner als 10 Byte ist. Eine echte E-Mail ist niemals kleiner als 10 Byte. Im Ergebnis ist dies ein Filter für leere Dateien, der bei jeder Migration sicher eingesetzt werden kann.

3. Das Problem wiederkehrender gelöschter Nachrichten

Am Montag haben Sie die Hauptsynchronisierung ausgeführt. Am Dienstag hat der Benutzer 50 E-Mails an der Quelle gelöscht. Am Mittwoch führen Sie die Differenzsynchronisierung aus.

Standardmäßig fügt imapsync nur E-Mails hinzu. Nachrichten, die an der Quelle gelöscht wurden, werden am Ziel nicht entfernt. Für die meisten Anwendungsfälle ist das bewusst so vorgesehen und richtig. Es bedeutet jedoch, dass diese 50 gelöschten E-Mails im neuen Postfach wieder auftauchen. Benutzer melden sie als "Geister-E-Mails" oder "gelöschte E-Mails, die zurückgekommen sind".

Abhilfe schafft --delete2, allerdings nur mit äußerster Vorsicht:

--delete2

Damit weisen Sie imapsync an: Wenn eine Nachricht nicht an der Quelle vorhanden ist, lösche sie am Ziel.

Verwenden Sie diese Option nur während der Vorbereitung und vor der MX-Umstellung. Nach der Umstellung würde neue E-Mail, die am Ziel eingetroffen ist, weil der MX-Eintrag bereits dorthin zeigt, gelöscht werden, da sie auf der alten Quelle nicht vorhanden ist. Sie würden E-Mails verlieren. Verwenden Sie --delete2 niemals nach der Umstellung.

4. Verbindungsabbrüche bei großen Anhängen

Ein PDF-Anhang mit 40MB kann IMAP-Verbindungen mit einem kurzen Zeitlimit zum Stillstand bringen. Der Server sendet die Nachricht, im Netzwerk tritt eine Störung auf, die Verbindung bricht bei 95% ab, und imapsync protokolliert einen Fehler und fährt fort. Am Ziel bleibt eine unvollständige Nachricht zurück.

Lösung: Erhöhen Sie --timeout für Durchläufe mit großen Anhängen auf 300 Sekunden. Erwägen Sie außerdem, solche Nachrichten bei der Hauptsynchronisierung mit --maxsize 25000000 zu überspringen und anschließend einen gesonderten Durchlauf für große Anhänge mit großzügigerer Drosselung und längeren Zeitlimits auszuführen.

Prüfung: So weisen Sie den Erfolg nach

Das Skript ist fertig und das Terminal meldet den Abschluss. Aber woher wissen Sie, dass die E-Mails des CEO nicht irgendwo im Nirgendwo gelandet sind?

1. Den Zusammenfassungsblock lesen

imapsync gibt am Ende jedes Durchlaufs eine Zusammenfassung aus. Drei Zahlen sind wichtig:

• Transferred: Beim letzten Differenzlauf sollte hier 0 stehen. Ist der Wert nicht null, wurden noch nicht alle Nachrichten übertragen.
• Skipped: Sollte der Gesamtzahl an der Quelle entsprechen oder darüber liegen. Diese Nachrichten sind bereits am Ziel vorhanden.
• Errors: Sollte 0 sein. Jeder Fehlerwert ungleich null muss untersucht werden, bevor Sie die Migration als abgeschlossen betrachten.

2. Die Stichprobe

Melden Sie sich mit einem neu eingerichteten IMAP-Client beim neuen Postfach an. Verwenden Sie keinen Client mit lokalem Cache, denn das würde den Zweck der Prüfung zunichtemachen. Prüfen Sie Folgendes:

• Gesendete Nachrichten: Sind die über Jahre gesendeten E-Mails vorhanden und richtig eingeordnet?
• Ein tief verschachtelter Unterordner: Wird die Hierarchie richtig dargestellt?
• Die neueste E-Mail: Ist es dieselbe wie an der Quelle?
• Eine markierte E-Mail: Wurde das Attribut \Flagged übernommen?

3. Die gezielte Suche

Ein Benutzer meldet eine fehlende E-Mail. Bevor Sie sagen, sie müsse verloren gegangen sein, prüfen Sie das Protokoll:

grep -i "bob@sender.com" /var/log/imapsync/user@source.com.log

Das Protokoll hält das Ergebnis für jede einzelne Nachricht fest: Transferred, Skipped (bereits am Ziel) oder Error mit dem jeweiligen Fehlercode. Bei einem Fehler wissen Sie genau, welche Nachricht, welcher Ordner und welcher Fehlercode die Ursache waren. Dort beginnt die Wiederherstellung, nicht beim Raten.

4. Prüfung der Elementanzahl

Fragen Sie für eine abschließende Plausibilitätsprüfung beide Server direkt ab:

# On source (example for Dovecot)
doveadm mailbox status -u user@source.com messages '*'

# Or use imapsync's own count
imapsync ... --dry --justfoldersizes 2>&1 | grep "Messages"

Vergleichen Sie die Anzahl der Elemente an Quelle und Ziel. Die Werte sollten höchstens 1 bis 2% voneinander abweichen, wenn ausgeschlossene Spamordner und die Deduplizierung von "All Mail" in Gmail berücksichtigt werden. Ist die Abweichung größer, prüfen Sie vor der Abnahme das Fehlerprotokoll.

Die Alternative: ohne Terminal

Wir haben diesen Leitfaden geschrieben, weil uns Transparenz wichtig ist. imapsync ist das richtige Werkzeug für Administratoren, die vollständige Kontrolle wünschen und sich nicht daran stören, Perl-Abhängigkeiten, OAuth2-Anwendungsregistrierungen und Protokolle detailliert zu untersuchen.

Für viele Verantwortliche, vom Gründer bei der Migration seiner ersten Domain bis zur Agentur, die 200 Kundenkonten umzieht, übersteigt der Zeitaufwand für diese Konfiguration jedoch die eingesparten Softwarekosten.

Das integrierte Migrationswerkzeug von TrekMail läuft serverseitig. Sie müssen weder drei Stunden lang Ordner in Outlook verschieben noch sich mit Perl-Abhängigkeiten herumschlagen. Sie geben die Quelle an (Gmail, cPanel oder einen beliebigen standardkonformen IMAP-Server), tragen die Anmeldedaten ein, und der Server übernimmt die Übertragung. Den Fortschritt verfolgen Sie im Dashboard.

Auch das Preismodell unterscheidet sich wahrscheinlich von dem, was Sie gewohnt sind. Es gibt keine Gebühr pro Benutzer. Pauschaltarife ab $3.50 pro Monat sind für bis zu 100 Benutzer in 50 Domains mit einem gemeinsamen Speicherpool ausgelegt. Eine Führungskraft mit 40GB an Anhängen zwingt Sie daher nicht zu einem Upgrade für alle, denn der Speicher wird im gesamten Konto gemeinsam genutzt.

Einen Vergleich des Leistungsumfangs der einzelnen Tarife finden Sie unter TrekMail-Preise. Eine genaue Anleitung zum Migrationswerkzeug bietet der Leitfaden Migration starten in unserer Dokumentation.

Ob Sie selbst ein Skript mit imapsync ausführen oder unsere Plattform nutzen, das Ziel bleibt gleich: Ihre E-Mails ohne Datenverlust und unnötige Probleme zu verschieben, ohne dafür eine Gebühr pro Benutzer zu zahlen.

Wenn Sie keine Gebühren pro Benutzer mehr zahlen und die Migration erledigen lassen möchten, testen Sie TrekMail kostenlos. Sie erhalten eine 14-tägige Testphase, für die keine Karte erforderlich ist.