Postfachmigration: Ordner, Flags und historische Daten prüfen

Eine Postfachmigration wirkt einfach, bis Nutzer ihren Verlauf prüfen. Gesendete Post fehlt, Ungelesen-Zahlen steigen und zehn Jahre E-Mail scheinen heute angekommen zu sein. Es geht nicht nur um Nachrichtenkopien, sondern um unterstützte Zustandsdaten. Den ausführlicheren Ablauf erklärt dieser Betriebsleitfaden zu imapsync. Auch beim vollständigen Plattformwechsel helfen klar definierte Standards und Tests.

Wer nur Inhalte kopiert und sofort Erfolg meldet, verfehlt wichtige Nutzeranforderungen. Angekommener RFC 5322-Inhalt allein reicht nicht. Gesendete Post muss am vorgesehenen Ort erscheinen, Lesestatus stimmen und die Suche nachvollziehbar bleiben. Probleme in diesen drei Bereichen können schon am ersten Arbeitstag Supportfälle auslösen.

Dieser Leitfaden erklärt typische Fehler, ihre Prüfung und TrekMails möglichen Beitrag. Die Quelle beschreibt eingebauten IMAP-Import ab Starter und tarifbasierte Preise ab $3.50/Monat ohne nutzerbezogene Abrechnung. Prüfen Sie aktuelle Funktionen und Grenzen, ob ein Postfach oder einhundert betroffen sind. Weitere Planung bieten geschäftliche E-Mail für kleine Unternehmen und E-Mail-Hosting für mehrere Domains.

Warum Probleme nach der MX-Umschaltung sichtbar werden

Inhalte können ankommen, während Postfachzustand fehlt. Vier wichtige Prüfbereiche sind Ordnerzuordnung, Lesestatus, interne Datumswerte und Gmail-Labels. Sorgfältige Prüfung reduziert Probleme, garantiert aber keinen fehlerfreien Umzug.

Neuer Empfang nach einer MX-Änderung beweist keine vollständige Migration. MX dürfen Sie nur für eine eigene verwaltete Domain mit geändertem Empfang umstellen, nachdem Zieladressen und Vorabkopie geprüft sind. Nutzer benötigen ihren bisherigen Arbeitsablauf, nicht nur einen erreichbaren Server.

Betrachten Sie die Übertragung wie einen Datenbankumzug. Zu jeder Nachricht gehören Inhalt, Flags, Ordner und interne Zeitangaben. Fehlende Metadaten können das Verhalten ändern, obwohl sich das Postfach öffnen lässt.

Beispiel: Eine Geschäftsführerin sieht im neuen Postfach 8,000 ungelesene Nachrichten und vermutet einen Fehler des Anbieters. In diesem Beispiel wurden Inhalte, aber nicht der \Seen-Zustand übernommen. Andere Ursachen sind bei realen Fällen ebenfalls zu prüfen.

Vier leicht übersehene Fehlerquellen

Prüfen Sie die Zuordnung gesendeter Post, \Seen-Markierungen, INTERNALDATE und mehrfache Gmail-Ansichten. Solche Unterschiede fallen oft erst beim Arbeiten auf und nicht im Fortschrittsbalken.

1. Gesendete Post im falschen Ordner

Quell- und Zielsystem können verschiedene Namen verwenden: Sent, Sent Items, bei cPanel häufig INBOX.Sent, bei Gmail [Gmail]/Sent Mail.

Bei falscher Zuordnung landet der Verlauf in einem normalen Ordner, während der Client neue Post in den besonderen Gesendet-Ordner schreibt. Der erwartete Ordner wirkt leer, obwohl die historischen Nachrichten anderswo vorhanden sind.

RFC 6154 beschreibt Special-Use-Ordner, mit denen Clients Gesendet, Entwürfe, Spam und Papierkorb erkennen können. Entscheidend sind tatsächliche besondere Verwendung und Client-Zuordnung, nicht allein der sichtbare Name.

2. Fehlende \Seen-Markierungen

Lesestatus sollte übernommen werden, soweit Quelle und Werkzeug dies unterstützen. Sonst kann jahrelang bearbeitete Post erneut ungelesen erscheinen und die Arbeit erschweren.

RFC 3501 beschreibt Systemflags wie \Seen. Prüfen Sie deren Übertragung im Pilotlauf. Ein abgeschlossener Kopiervorgang kann trotzdem unpassende Markierungen hinterlassen.

\Recent ist anders: Im älteren IMAP-Modell betrifft es Sitzungen und lässt sich nicht wie Lesestatus übertragen; moderne Implementierungen behandeln es gegebenenfalls nicht mehr so. Bereits alte Post kann am Ziel als neu sichtbar erscheinen. Erklären Sie solche Anzeigen vor dem Start.

3. Zurückgesetzte INTERNALDATE

Der Date-Header und das interne Serverdatum sind verschieden. Clients können nach dem internen Datum sortieren. Wird dieses beim Import neu gesetzt, verschiebt sich die Zeitleiste trotz intakter Nachricht.

RFC 3501 beschreibt APPEND mit optionaler Datums- und Zeitangabe. Wird sie übergeben, empfiehlt die beschriebene Regel ihre Verwendung für das interne Datum; ohne Angabe wird die aktuelle Zeit verwendet. So können zehn Jahre Archiv unter heute erscheinen. Übertragen Sie das tatsächlich von der Quelle gelieferte INTERNALDATE samt Zeitzonenoffset und unterstützter Genauigkeit. Der Date-Header allein rekonstruiert keinen unbekannten ursprünglichen Servereingang.

4. Gmail-Ansichten mehrfach kopiert

Gmail organisiert mit Labels, die über IMAP als Ordner erscheinen. Mehrere Ansichten können dieselbe Nachricht enthalten; Werkzeuge können daraus mehrere Zielkopien erstellen.

Wer [Gmail]/All Mail zusammen mit Posteingang, Gesendet und Labels übernimmt, kann zusätzlichen Speicher und mehrere Suchtreffer erzeugen. Solche Ordnerkopien können auch beabsichtigt sein. Vereinbaren Sie die Darstellung; „Alle Nachrichten“ darf erst ausgeschlossen werden, wenn auch archivierte Post ohne andere importierte Labels vollständig abgedeckt ist.

Ordner bei der Migration richtig zuordnen

Unterschiedliche Namen brauchen passende Zuordnung. Automatische Erkennung kann helfen, ersetzt aber keine Kontrolle. Die Zielnamen der Tabelle sind Beispiele, keine universellen Standards oder zugesicherten TrekMail-Vorgaben.

Bei manuellem Import mit imapsync können getestete reguläre Ausdrücke Ordner umbenennen. Das folgende Originalbeispiel ist keine sofort ausführbare Empfehlung: Die übermäßig maskierten INBOX-Muster passen nicht zu den beabsichtigten üblichen INBOX-Namen und müssen in einer eigenen Arbeitskopie korrigiert und getestet werden. Die Regeln werden nach automatischer Präfix- und Trennzeichenanpassung nacheinander auf das vorherige Ergebnis angewendet. Es kopiert wirklich, enthält keine explizite TLS- oder Zertifikatsprüfung und zeigt Passwörter in Argumenten. Nutzen Sie ein kontrolliertes Testziel, echte Trockenlaufprüfung bei Unterstützung, sichere Geheimnisübergabe und geprüfte verschlüsselte Verbindungen mit Hostname und Zertifikatskette:

imapsync \
  --host1 old.example.com --user1 user@old.example.com --password1 'oldpass' \
  --host2 new.example.com --user2 user@new.example.com --password2 'newpass' \
  --regextrans2 's/^Sent Messages$/Sent Items/' \
  --regextrans2 's/^INBOX\\.Sent$/Sent Items/' \
  --regextrans2 's/^INBOX\\.Trash$/Deleted Items/' \
  --exclude "\\[Gmail\\]/All Mail"

Nach dem Pilotlauf senden Sie aus dem Ziel eine echte Testnachricht. Prüfen Sie, ob neue gesendete Post und importierter Verlauf im vorgesehenen selben Ordner erscheinen. Passen Sie die Zuordnung an, bevor Sie weitere Nutzer übertragen.

Für TrekMail lesen Sie die aktuelle IMAP-Migrationsübersicht. Die Quelle beschreibt Importvorlagen für Gmail, Outlook, Yahoo, iCloud und anderes IMAP, Ordnerlisten mit Zahlen, Hintergrundläufe und Duplikatabgleich. Prüfen Sie heutige Unterstützung und Ergebnis; Message-ID und UIDs sind keine pauschalen Integritätsgarantien. Direktimport nutzt Benutzername und Passwort, nicht interaktives OAuth. App-Passwörter hängen von Kontorichtlinien ab; gegebenenfalls benötigen Sie einen anderen autorisierten OAuth-Weg. Vorbereitung erklären Gmail-Migration und cPanel-Migration.

Migration anhand tatsächlicher Daten prüfen

Vergleichen Sie Nachrichtenanzahl, Lesestatus, gesendete Post und Datumswerte. Gigabytes allein sind unzuverlässig, weil MIME-Darstellung, Indizes und Speicheraufwand variieren. Auch gleiche Zahlen beweisen keine Integrität: Öffnen Sie Inhalte und Anhänge und prüfen Sie Logs sowie Zuordnung.

Eine grüne Abschlussanzeige beschreibt den Jobstatus, nicht automatisch eine erhaltene Nutzererfahrung. Kontrollieren Sie den Bestand selbst.

1. Nachrichten pro vereinbartem Quell- und Zielordner vergleichen: Posteingang, Gesendet und Archiv.
2. Lesestatus vergleichen. Bei 50 ungelesenen in der Quelle und 4,000 im Ziel besteht Prüfbedarf; untersuchen Sie Flags, abweichenden Umfang, Filter und laufende Quelländerungen statt allein daraus die Ursache abzuleiten.
3. Historische Nachrichten öffnen: 2019 soll bei übernommenen Datumswerten weiterhin als 2019 eingeordnet sein.
4. Neue Testpost senden und ihre Ablage mit dem importierten Gesendet-Verlauf vergleichen.

Kleinere Abweichungen können durch problematische MIME-Daten, Ausschlüsse oder Nicht-Mail-Objekte entstehen. Jede relevante Differenz ist zu erklären. Speichergröße ersetzt weder Nachrichtenvergleich noch die Prüfung von Flags, Anhängen und Datumswerten.

Nach dem Wechsel brauchen Nutzer passende Clients. Aktuelle Werte stehen in TrekMails IMAP-/SMTP-Anleitung. Die Quelle beschreibt IMAP ohne POP3; sichern Sie vorhandene lokale und nicht synchronisierte Post vor dem Löschen alter Profile. Prüfen Sie die tatsächlich geltenden TLS-Einstellungen, Zertifikatskette und Hostname und nutzen Sie vollständige Postfachadresse samt Postfachpasswort statt Dashboard-Zugangsdaten.

Differenzabgleiche, Duplikate und UIDVALIDITY

Nach der ersten Kopie braucht es meist mindestens einen weiteren Abgleich und nach der Umschaltung nötige Nachläufe. Berücksichtigen Sie spät eingehende Post mit altem Datum, Ordnerverschiebungen und Flags. Alter SMTP-Empfang, administrativer Zugang und Rückfallmöglichkeit bleiben für Caches und Wiederholungen verfügbar; eine gesenkte TTL leert alte Caches nicht sofort.

UIDVALIDITY beschreibt die Gültigkeit von UIDs innerhalb eines Ordners. Wiederherstellung, Reparatur oder Neuindizierung können sie verändern, müssen es aber nicht. Ein Werkzeug kann gespeicherte Zuordnung verlieren und abhängig vom Verfahren erneut kopieren. UIDs sind keine globalen Kennungen und kein Inhaltsnachweis.

Ein am Freitag sauber wirkender Lauf kann am Montag deshalb Duplikate zeigen. Verschieben Sie nicht notwendige Wartung während des Umzugs. Unverzichtbare Reparaturen müssen koordiniert werden: pausieren, Zustand prüfen und Wiederanlauf neu validieren, statt notwendige Arbeiten pauschal zu verbieten.

Viele Werkzeuge kopieren additiv. Eine nachträgliche Quelllöschung wird dann nicht automatisch im Ziel wiederholt. Das kann neue Zielpost schützen, ersetzt aber keine Konfliktplanung. Nur ein System darf aktive Nutzerarbeitsumgebung sein; zwei gleichzeitig bearbeitete Konten sind keine sichere bidirektionale Synchronisation.

Spiegelnde Löschungen nur nach gesonderter Prüfung von Richtung, Zeitraum, Backup und Test zulassen. Eine falsche Annahme kann gültige Daten entfernen.

Manuelle Migration und TrekMail-Verwaltung

Manuelle Postfachmigration kann viele Einzelbefehle, reguläre Ausdrücke und Prüfungen erfordern. Ein integrierter IMAP-Ablauf kann Aufwand bündeln. Ob tarifbasierte Preise geeigneter sind als Nutzerpreise, hängt von Anforderungen und tatsächlichen Grenzen ab.

Bei vielen Postfächern zählt Wirtschaftlichkeit ebenso wie Protokolltechnik. Bereitstellung und Kontrolle gehören dazu. Weitere Beiträge sind E-Mail-Konten massenhaft anlegen und Kunden-E-Mail verwalten.

TrekMail ersetzt keine Prüfung. Multi-Domain-Dashboard, gemeinsamer Speicher, IMAP-Import und eigener oder enthaltener SMTP können die Verwaltung vereinfachen, soweit der Tarif dies unterstützt. Zusätzliche Nutzer, Speicher und Funktionen bleiben an heutige Limits gebunden.

Vergleichen Sie vor dem Umzug die TrekMail-Tarife. Kostenloses Nano ohne Karte, Bezahltarife ab $3.50/Monat und eine kostenlose 14-tägige Testphase für Bezahltarife mit Kreditkarte sind Angaben der Quelle; prüfen Sie aktuelle Bedingungen.

Fazit: Woran Sie eine gelungene Migration erkennen

Das Ziel ist ein nachvollziehbarer Verlauf: gesendete Post am richtigen Ort, plausibler Lesestatus, passende historische Sortierung und bewusst geplante Gmail-Ansichten. Das muss anhand tatsächlicher Nachrichten überprüft werden, nicht allein an einer Anzeige.

Ordnen Sie Ordner vor dem Vollimport zu, übernehmen Sie unterstützte Flags wie \Seen und vorhandenes INTERNALDATE bei APPEND. Schließen Sie Gmail „Alle Nachrichten“ nur nach gesicherter vollständiger Archivabdeckung aus. Vergleichen Sie Anzahl, Inhalte, Anhänge, Datumswerte und Logs, nicht nur Speichergröße.

Diese Schritte machen aus der Kopie einen kontrollierten Umzug und begrenzen Nacharbeiten, garantieren aber keine verlust- oder unterbrechungsfreie Migration. Kontofunktionen wie Aliasse, Weiterleitungen, Kalender und Kontakte müssen zusätzlich getrennt eingerichtet und geprüft werden.

Protokollgrundlagen beschreiben RFC 3501 für IMAP und RFC 6154 für Special-Use-Ordner.