imapsync: praktijkgids voor veilige e-mailmigratie (2026)

U staat voor een migratieproject waar u nerveus van wordt. U moet e-mail van Server A naar Server B verplaatsen zonder ook maar één bericht kwijt te raken, zonder de mappenstructuur te vernielen en zonder een externe leverancier $15 per gebruiker te betalen voor een "migratielicentie", alleen maar om bytes te verplaatsen die al van u zijn.

U zoekt imapsync. Deze gids vertelt u precies hoe u het gebruikt zonder de postvakken van uw gebruikers overhoop te halen.

Wat imapsync is (en wat het niet is)

imapsync is een opdrachtregelprogramma dat postvakken tussen twee IMAP-servers synchroniseert. Het fungeert als proxy: het maakt gelijktijdig verbinding met beide servers, leest berichten van de bron en voegt ze toe aan de bestemming. Het houdt de status bij, vangt onderbrekingen op en behoudt de mappenstructuur, vlaggen en berichtinhoud.

Het is geen back-upprogramma. Het is geen SMTP-relay. Het blijft van uw Google Agenda, Outlook-contactpersonen en Exchange-transportregels af. Het spreekt IMAP, en uitsluitend IMAP. Als uw bronserver achter een firewall zit of offline is, kan imapsync deze niet bereiken. Punt.

Wat het de industriestandaard maakt voor verhuizingen van postvak naar postvak, is het statusbehoud. Bij een geslaagde migratie gaat het niet alleen om het verplaatsen van tekst, maar om het behouden van drie zaken:

• Inhoud: de RFC 822-berichttekst, bijlagen, MIME-codering, alles binnen de envelop.
• Metagegevens: de vlaggen. \Seen (gelezen), \Answered (beantwoord), \Flagged (gemarkeerd). Als deze niet meegaan, denkt iedere gebruiker op dag één 4,000 nieuwe ongelezen e-mails te hebben.
• Structuur: de mappenhiërarchie. INBOX/Clients/ProjectA moet er op de nieuwe server identiek uitzien en mag niet worden samengevoegd tot een map die letterlijk INBOX.Clients.ProjectA heet, met punten in de naam.

imapsync regelt alle drie, als u het correct configureert. Dat is het lastige deel en daarvoor is deze gids bedoeld.

De harde beperkingen: het kent niet automatisch de snelheidslimieten van Gmail of de API-beperkingen van Microsoft. Laat het op volle kracht draaien en uw IP-adres kan worden geblokkeerd. Het pusht ook niet: als gegevens ergens heen moeten, moet u ze ophalen. En standaard verwijdert het niets op de bestemming. Dat is een veiligheidsvoorziening die ook tegen u kan werken als u niet oplet (meer daarover in Fase 6).

Voor een bredere uitleg van het protocol zelf leest u onze gids over e-mail instellen op uw domein.

Fase 1: forensische inventarisatie, sla dit niet over

Amateurs beginnen met kopiëren. Professionals controleren eerst de omgeving. Als u niet weet wat u verplaatst, gaat het mis, en wel om 2 uur 's nachts op een zondag, wanneer het te laat is om het nog te herstellen.

1. Vind de grootverbruikers

U hebt een gebruiker met een postvak van 45GB. Misschien de CEO. Misschien degene die sinds 2011 eigenaar is van de alias sales@. Als u die in dezelfde batch probeert te migreren als uw gebruikers met 500MB, loopt de batch vast en kijkt u naar een bevroren terminal zonder enig idee hoe ver het proces is.

Voer eerst een voorscan uit:

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

Dit geeft u een uitsplitsing per map zonder ook maar één bericht aan te raken. Elk postvak groter dan 10GB vraagt om een eigen aanpak: langere time-outs, een apart uitvoervenster en uw volledige aandacht.

2. Het probleem van verborgen gegevens

Elk bedrijf heeft zombieaccounts. Voormalige werknemers van wie de e-mail nog altijd ergens naartoe wordt doorgestuurd. "Serviceaccounts" die in werkelijkheid gedeelde postvakken zijn voor een printer of een verouderde CRM-integratie. Als u deze tijdens de inventarisatie mist, blijven die gegevens achter wanneer u de DNS-omschakeling uitvoert.

Vergelijk de gebruikerslijst van uw bron met uw werkelijk actieve gebruikers. Als bob@company.com drie jaar geleden is vertrokken, neem dan nu een besluit: migreert u zijn postvak of archiveert u het als EML-export? Als u dat niet voor de omschakeling beslist, moet u de keuze onder druk maken op het slechtst mogelijke moment. Bekijk onze gids voor het beheer van e-mail van klanten voor een volledig inventarisatiesjabloon ter voorbereiding.

3. Het werkelijke aantal items

Vertrouw nooit op de grootte in gigabytes. Bronserver A kan een postvak als 10GB rapporteren. Bestemmingsserver B kan exact dezelfde gegevens als 11GB rapporteren. Dit is geen fout: verschillende servers berekenen opslag op een andere manier. Exchange neemt de map Recoverable Items (de "Dumpster") mee. Gmail dedupliceert berichten over labels heen.

De maatstaf die telt, is het aantal items. Als de bron 14,200 berichten bevat en de bestemming 14,200 berichten, bent u klaar. Een verschil in bytes van minder dan 10% is normaal en te verwachten. Meer dan 10%? Onderzoek het voordat u uw goedkeuring geeft.

Fase 2: de veilige migratiewerkwijze

De grootste fout bij elke migratie is de "Big Bang"-aanpak: alles op vrijdagavond verplaatsen en hopen dat het maandagochtend klaar is. Als u 50GB aan e-mail hebt en een limiet van 500KB/s, klopt die rekensom niet. Maandag ligt de dienst eruit en moet u de CEO uitleggen waarom diens inbox leeg is.

De professionele aanpak is een gefaseerde migratie. U doet het zware werk terwijl gebruikers nog op het oude systeem werken en voert daarna een piepkleine laatste delta uit wanneer u de omschakeling maakt.

Stap 1: de testuitvoering

Controleer of u verbinding kunt maken voordat u ook maar één byte verplaatst. Gebruik --dry in combinatie met --justfolders. Hiermee simuleert u de uitvoering en ziet u de mappenstructuur zonder iets te kopiëren.

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

Let op twee dingen: is de authenticatie geslaagd en hoe zien de mapnamen eruit? Als u bij de bron [Gmail]/Sent Mail ziet, moet u die toewijzen aan Sent Items op de bestemming. Ontdek dit niet pas tijdens de daadwerkelijke omschakeling.

Stap 2: de bulksynchronisatie (voorfase)

Voer deze 1-2 weken voor de omschakeling uit terwijl gebruikers nog op het oude systeem werken. Het doel is om 90-95% van de gegevens buiten het kritieke pad te brengen.

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 is niet onderhandelbaar. Hiermee wordt de migratiestatus lokaal opgeslagen. Elke volgende uitvoering vergelijkt met deze cache en verwerkt alleen wijzigingen: niet elk bericht wordt opnieuw vanaf nul bekeken. Zonder deze optie is elke uitvoering een volledige scan.

--maxsize 25000000 slaat tijdens de eerste ronde berichten groter dan 25MB over. Grote bijlagen veroorzaken de meeste time-outs en verbroken verbindingen. U pakt ze op in een aparte uitvoering met langere time-outs.

Stap 3: de deltasynchronisatie

Voer het een paar dagen voor de omschakeling opnieuw uit. imapsync leest de cache, ziet dat er al 10,000 e-mails op de bestemming staan, slaat deze over en kopieert alleen de 50-100 nieuwe berichten die sinds de bulksynchronisatie zijn binnengekomen. Deze uitvoering hoort binnen enkele minuten klaar te zijn, niet na uren.

Stap 4: de omschakeling

Dit is het moment. Werk de stappen in deze volgorde af:

1. Verlaag uw DNS-TTL: stel 48 uur voor de omschakeling de TTL van uw MX-record in op 300 seconden. Als u tot het laatste moment wacht, houden sommige resolvers uw oude MX maximaal 24 uur in de cache en komt e-mail nog op de oude server terecht nadat u al bent omgeschakeld.
2. Wijzig de MX-records: laat ze naar uw nieuwe host verwijzen.
3. Wacht 60 minuten totdat de verspreiding bij de belangrijkste resolvers is gestabiliseerd.
4. Voer de laatste delta uit: een laatste ronde met imapsync haalt alle berichten op die tijdens het verspreidingsvenster nog op de oude server zijn aangekomen.

Voor een gedetailleerde uitleg van het DNS-venster en waar u tijdens de verspreiding op moet letten, leest u onze gids over e-mail instellen op uw domein.

Fase 3: vlaggen, mappen en de valkuil van Verzonden

IMAP-servers spreken verschillende dialecten. Als u daar niet tussen vertaalt, worden uw gebruikers wakker met een structureel defect postvak, en terecht zullen ze u de schuld geven.

Het scheidingstekenprobleem

Dit is de meest voorkomende technische fout waar niemand over praat totdat diegene ermee te maken krijgt.

Verschillende IMAP-servers gebruiken verschillende tekens om niveaus in de mappenhiërarchie te scheiden:

• Dovecot gebruikt doorgaans een punt: INBOX.Clients.ProjectA
• Exchange/Outlook gebruikt een schuine streep: INBOX/Clients/ProjectA
• Sommige servers gebruiken helemaal geen scheidingsteken en vertrouwen op de IMAP-opdracht NAMESPACE

Als u blind migreert, kan imapsync op de bestemming een map maken die letterlijk INBOX.Clients.ProjectA heet: één platte map met punten in de naam, geen geneste hiërarchie van drie niveaus. De mappenstructuur van elke gebruiker ziet eruit alsof die is ontploft.

De oplossing is --regextrans2, waarmee mappaden tijdens de overdracht met reguliere expressies worden herschreven. Test het aanmaken van mappen altijd met --dry op één testaccount voordat u een batch van 100 gebruikers uitvoert.

De chaos rond Verzonden items

Elke server gebruikt een andere naam voor de map Verzonden. Dit is geen klein ongemak: als u het negeert, is het een ramp voor de gebruikerservaring.

Als u deze niet toewijst, houdt uw gebruiker twee mappen voor verzonden berichten over: de actieve map Sent Items en een nieuwe spookmap met de naam Sent Mail die de volledige geschiedenis bevat. Dat valt op. Daar worden gebruikers niet blij van.

Wijs ze expliciet toe:

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

Hiermee zegt u tegen imapsync: "Als de bronmap begint met [Gmail]/Sent Mail, wijzig de naam op de bestemming dan in Sent Items." Voer uw volledige maptoewijzing eerst uit als --dry-ronde om te bevestigen dat elke toewijzing correct wordt toegepast voordat u de wijziging definitief maakt.

De valkuil van Gmail All Mail

Gmail heeft een map met de naam [Gmail]/All Mail. Deze bevat een kopie van elke afzonderlijke e-mail, ongeacht het label. Het is de interne totaalweergave van Gmail, die als IMAP-map beschikbaar wordt gemaakt.

Als u All Mail en Inbox en Sent Mail migreert, dupliceert u elke e-mail twee of drie keer op de bestemming. Een postvak van 10GB wordt 30GB. Elk bericht verschijnt meerdere keren. Het is een ramp.

Sluit deze map altijd uit:

--exclude "All Mail"

Sluit ook [Gmail]/Spam en [Gmail]/Trash uit, tenzij u een specifieke reden hebt om ze mee te nemen. Niemand wil dat oude spam wordt gemigreerd.

Fase 4: prestaties afstemmen en snelheid beperken

U kunt niet onbeperkt gegevens naar Google of Microsoft sturen. Hun infrastructuur behandelt een IMAP-verbinding met een groot volume precies als een denial-of-serviceaanval. Vanuit hun perspectief ziet die er immers hetzelfde uit.

De tijdelijke blokkade

Overschrijd de snelheidslimieten, doorgaans ongeveer 1 bericht per seconde of 500MB per uur voor Gmail, en de server begint HTTP 429-, NO [OVERQUOTA]- of gewoon BAD-fouten terug te sturen. Blijft u doorgaan, dan kan het account maximaal 24 uur worden vergrendeld. Dat is een telefoontje met support dat u liever niet pleegt.

De opties voor fijnafstelling

--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 bericht per seconde klinkt tergend langzaam. Dat is het ook. Maar het is stabiel, en een stabiel proces wordt afgerond. Een agressieve uitvoering die na 3 uur wordt geblokkeerd, wordt nooit afgerond.

Opmerking voor MSP's: als u voor meerdere klanten parallelle migraties uitvoert, laat deze dan niet gelijktijdig tegen dezelfde bronserver draaien. Spreid de starttijden. Elke parallelle stroom heeft een eigen limietbudget nodig.

Als u naar TrekMail migreert, is onze IMAP-opname ontworpen voor veel gelijktijdige verbindingen. Aan de bestemmingszijde kunt u doorgaans meer capaciteit benutten dan aan de bronzijde bij Google of Microsoft.

Fase 5: authenticatie, de hindernis van moderne authenticatie

De tijd dat u password123 in een onversleuteld tekstbestand zette, is voorbij. Zowel Google als Microsoft heeft Basic Auth voor IMAP afgeschaft. Als u uw normale inloggegevens gebruikt, mislukt de poging met een authenticatiefout en vraagt u zich een uur lang af wat u verkeerd hebt gedaan.

App-wachtwoorden (route voor het mkb)

Voor de meeste migraties binnen één domein zijn App-wachtwoorden de snelste route. Het zijn tekenreeksen van 16 tekens die 2FA omzeilen en met verouderde IMAP-clients werken:

1. Meld u aan bij het bronaccount (Gmail, Workspace, enz.)
2. Schakel 2FA in als dit nog niet actief is (vereist om App-wachtwoorden te genereren)
3. Ga naar Beveiligingsinstellingen → App-wachtwoorden
4. Genereer een wachtwoord voor "E-mail" op "Ander apparaat"
5. Gebruik die tekenreeks als wachtwoord in uw --passfile voor imapsync

Sla het op in een bestand met chmod 600, niet op de opdrachtregel. Inloggegevens in de bash-geschiedenis vragen om problemen.

OAuth2 (route voor MSP / Enterprise)

Als u als MSP 500 gebruikers migreert, kunt u niet handmatig 500 App-wachtwoorden genereren. U hebt OAuth2 nodig. Deze route is ingewikkelder, maar op grote schaal de enige realistische optie:

1. Registreer een toepassing in de brontenant (Azure AD voor Microsoft, Google Cloud Console voor Google)
2. Geef deze volledige toegang tot postvakken in de hele tenant (goedkeuring van een globale beheerder vereist)
3. Genereer per gebruiker een Refresh Token of gebruik accountimitatie met een serviceaccount
4. Geef het token aan imapsync door via --oauthaccesstoken1

Als u de toepassingsmachtigingen in Azure AD of GCP verkeerd configureert, wordt de toegang tot elk postvak geweigerd of, erger nog, verleent u per ongeluk ruimere machtigingen dan bedoeld. Lees de machtigingsbereiken zorgvuldig voordat u op "Grant admin consent" klikt.

Voor een praktische kijk op grootschalige migratie leest u onze gids over de aanpak voor het beheer van e-mail van klanten.

Fase 6: veelvoorkomende fouten en herstel

Zelfs een perfect plan stuit op problemen. Zo leest u wat er is misgegaan en herstelt u het zonder opnieuw te beginnen.

1. Het UIDVALIDITY-probleem (het nachtmerriescenario)

Elke IMAP-map heeft een unieke identificatie met de naam UIDVALIDITY. Daarmee houdt imapsync bij welke berichten al zijn gekopieerd. Als een map op de bronserver wordt verwijderd en opnieuw aangemaakt, of als de serverindex beschadigd raakt en opnieuw wordt opgebouwd, verandert deze ID.

Symptoom: imapsync ziet een nieuwe UIDVALIDITY, neemt aan dat het om een volledig nieuwe map gaat en downloadt alles opnieuw. U hebt nu duplicaten van elk bericht in die map. Op grote schaal zijn dit duizenden duplicaten in honderden postvakken.

Oplossing: verwijder de lokale cachebestanden uit uw tijdelijke map en voer het programma vervolgens opnieuw uit met --useheader:

--useheader

Dit dwingt imapsync om de header Message-ID van elke e-mail te vergelijken, die onveranderlijk en uniek is, in plaats van uit te gaan van de map-UID. Het is langzamer, maar voorkomt duplicaten. Gebruik deze optie telkens wanneer u vermoedt dat de index van de bronserver is gewijzigd.

2. Beschadigde berichten en berichten van nul bytes

Op verouderde servers hopen "spookberichten" zich op: headers zonder hoofdtekst of bestanden van exact 0 bytes. Meestal zijn ze het gevolg van een mislukte import, een gecrashte aflevering of een zeer oude server die jarenlang achterstallig onderhoud heeft gehad.

Symptoom: imapsync probeert een bericht op te halen, de server blijft 120 seconden hangen en verbreekt vervolgens de verbinding. Dit herhaalt zich eindeloos bij hetzelfde bericht.

Oplossing:

--minbytes 10

Hiermee geeft u imapsync opdracht om elk bericht kleiner dan 10 bytes over te slaan. Een echte e-mail is nooit kleiner dan 10 bytes. Dit is in feite een filter om lege bestanden over te slaan en kan veilig bij elke migratie worden gebruikt.

3. Het probleem van zombieverwijderingen

U voerde de bulksynchronisatie maandag uit. Dinsdag verwijderde de gebruiker 50 e-mails uit de bron. Woensdag voert u de delta uit.

Standaard voegt imapsync alleen e-mail toe: wat uit de bron is verwijderd, wordt niet van de bestemming verwijderd. Dat is bewust zo en voor de meeste gebruikssituaties correct. Het betekent echter dat die 50 verwijderde e-mails weer in het nieuwe postvak verschijnen. Gebruikers melden dit als "spookmails" of "e-mails die ik had verwijderd en die terugkomen".

De oplossing is --delete2, maar gebruik deze optie uiterst voorzichtig:

--delete2

Hiermee zegt u tegen imapsync: als een bericht niet in de bron staat, verwijder het dan van de bestemming.

Gebruik dit alleen tijdens de voorfase, vóór de MX-omschakeling. Als u het na de omschakeling uitvoert, wordt nieuwe e-mail die op de bestemming is aangekomen (omdat MX daar al naartoe verwijst) verwijderd omdat deze niet op de oude bron staat. U raakt e-mail kwijt. Gebruik --delete2 niet na de omschakeling.

4. Verbroken verbindingen bij grote bijlagen

Een PDF-bijlage van 40MB kan IMAP-verbindingen met een korte time-out soms laten vastlopen. De server verzendt het bericht, het netwerk hapert, de verbinding wordt bij 95% verbroken en imapsync registreert een fout en gaat verder, waardoor er een onvolledig bericht op de bestemming achterblijft.

Oplossing: verhoog --timeout tot 300 seconden voor rondes met grote bijlagen en overweeg --maxsize 25000000 te gebruiken om ze tijdens de bulksynchronisatie over te slaan. Voer daarna een aparte ronde voor grote bijlagen uit met ruimere limieten en langere time-outs.

Verificatie: zo bewijst u dat het is gelukt

Het script is voltooid. In de terminal staat dat het klaar is. Hoe weet u dat de e-mails van de CEO niet ergens in een null-route zijn verdwenen?

1. Lees het samenvattingsblok

imapsync drukt aan het einde van elke uitvoering een samenvatting af. De drie getallen die ertoe doen:

• Transferred: moet 0 zijn bij de laatste delta-uitvoering. Als dit niet nul is, hebt u nog steeds berichten die niet zijn overgekomen.
• Skipped: moet overeenkomen met (of hoger zijn dan) het totale aantal bij de bron. Dit zijn berichten die al op de bestemming staan.
• Errors: moet 0 zijn. Elk foutenaantal dat niet nul is, moet worden onderzocht voordat u het werk als voltooid beschouwt.

2. De steekproef

Meld u aan bij het nieuwe postvak met een nieuwe IMAP-client (niet met een client die een lokale opslagcache heeft, want dat schiet het doel voorbij). Controleer:

• Verzonden items: zijn de verzonden berichten van de afgelopen jaren aanwezig en correct genest?
• Een diep geneste submap: ziet de hiërarchie er goed uit?
• De meest recente e-mail: is dit hetzelfde bericht als in de bron?
• Een gemarkeerd bericht: is het kenmerk \Flagged meegekomen?

3. De forensische zoekopdracht

Een gebruiker meldt een ontbrekende e-mail. Controleer het logboek voordat u zegt dat het bericht "wel verloren zal zijn":

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

Het logboek registreert wat er met elk afzonderlijk bericht is gebeurd: Transferred, Skipped (staat al op de bestemming) of Error met de specifieke foutcode. Als het een Error is, weet u precies welk bericht, welke map en welke foutcode de oorzaak waren. Dat is uw vertrekpunt voor herstel, niet giswerk.

4. De controle van het aantal items

Vraag beide servers rechtstreeks op voor een laatste redelijkheidstoets:

# 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"

Vergelijk het aantal items in de bron met het aantal op de bestemming. Ze horen binnen 1-2% van elkaar te liggen (rekening houdend met uitgesloten spammappen en de deduplicatie van Gmail All Mail). Is het verschil groter, duik dan in het foutenlogboek voordat u uw goedkeuring geeft.

Het alternatief: sla de terminal over

We hebben deze gids geschreven omdat we in transparantie geloven. imapsync is het juiste hulpmiddel voor beheerders die volledige controle willen en er geen bezwaar tegen hebben om zelf aan de slag te gaan met Perl-afhankelijkheden, OAuth2-appregistraties en forensisch logonderzoek.

Maar voor veel beheerders, of u nu een oprichter bent die zijn eerste domein verhuist of een bureau dat 200 klantaccounts migreert, wegen de kosten in tijd voor het configureren van dit alles zwaarder dan de besparing op software.

De ingebouwde migratietool van TrekMail draait aan de serverzijde: u hoeft geen mappen drie uur lang in Outlook heen en weer te slepen en krijgt niet te maken met een hel van Perl-afhankelijkheden. U verwijst de tool naar uw bron (Gmail, cPanel, elke standaard IMAP-server), voert uw inloggegevens in en de server verzorgt de overdracht. U kunt de voortgang in het dashboard volgen.

Het prijsmodel wijkt ook af van wat u waarschijnlijk gewend bent. Geen kosten per gebruiker. Abonnementen met een vast tarief vanaf $3.50/maand zijn bedoeld voor maximaal 100 gebruikers in 50 domeinen, met gedeelde opslag voor al deze gebruikers. Die ene directeur met 40GB aan bijlagen dwingt u niet om iedereen te upgraden: de opslag wordt door uw hele account gedeeld.

Bekijk de prijzen van TrekMail voor een vergelijking van wat elk niveau omvat. Raadpleeg voor een stapsgewijze uitleg van de migratietool zelf de handleiding Een migratie starten in onze documentatie.

Of u nu zelf een imapsync-script gebruikt of ons platform inzet, het doel is hetzelfde: uw e-mail verplaatsen zonder gegevensverlies, zonder gedoe en zonder een heffing per gebruiker te betalen.

Als u klaar bent met betalen per gebruiker en de migratie voor u wilt laten verzorgen, probeer TrekMail gratis: een proefperiode van 14 dagen, geen creditcard nodig.