imapsync: opties die ontbrekende e-mail voorkomen

imapsync is het hulpmiddel voor wie IMAP-mail wil verplaatsen zonder gebruikers lastig te vallen met PST-export, desktopclients of een weekend vol giswerk. Dat deel werkt. Het probleem komt daarna. Eén verkeerde optie, maptoewijzing of aanname over authenticatie kan een migratie opleveren met ontbrekende verzonden mail, dubbele mappen of nieuwe berichten die bij de omschakeling worden verwijderd. Lees voor de volledige werkwijze eerst deze beheerdersgids voor imapsync.

Dit artikel is bewust specifiek. Het behandelt opties die het resultaat echt veranderen: time-outs, keepalives, maptoewijzing, snelheidsbeperking, deduplicatie en verwijderopties die een actief postvak kunnen beschadigen. Bij één account voorkomt dit een rommelige herhaling. Bij vijftig voorkomt het dat je klanten moet uitleggen waarom Verzonden in drie kopieën is opgesplitst.

Kort gezegd zijn de standaardinstellingen geen migratieplan, maar een beginpunt. Echte migraties vragen om gefaseerde rondes, expliciete mapregels en controle voordat je MX wijzigt. Als TrekMail de bestemming is, kan de ingebouwde importwizard van betaalde abonnementen de ontvangst in het dashboard afhandelen. Dat is doorgaans eenvoudiger dan ieder postvak met shellscripts beheren. Volgens de prijspagina begint TrekMail bij $3.50/month, gebruikt het gedeelde opslag in plaats van kosten per gebruiker en ondersteunt het IMAP-import aan de serverzijde voor Gmail, Outlook, Yahoo, iCloud en algemene IMAP.

Waarom imapsync stukloopt wanneer beheerders op standaardwaarden vertrouwen

imapsync kopieert mail tussen actieve IMAP-opslag, niet tussen platte bestanden. Het moet verschillende mapstructuren, serverafwijkingen, berichtidentificatoren en authenticatiemodellen verwerken terwijl het netwerk de sessie kan onderbreken. Veilige opdrachten zijn daarom explicieter dan voorbeelden die mensen uit forums kopiëren.

De gebruikelijke problemen zijn voorspelbaar en kostbaar:

1. Grote berichten lopen tijdens upload tegen een time-out.
2. Mappen worden verkeerd toegewezen, zodat mail verdwenen lijkt.
3. Providers beperken de taak en weigeren verbindingen.
4. Moderne authenticatie blokkeert gewone wachtwoorden.
5. Gewijzigde UID-status veroorzaakt duplicaten in latere rondes.
6. `--delete2` wist na de omschakeling nieuwe mail uit de bestemming.

Een migratie die “grotendeels goed was, behalve Sent Items” mislukte niet willekeurig. Het protocol liet het toe en de standaardwaarden beschermden je niet.

Verbindingsopties die imapsync actief houden

Bij grote postvakken mislukt imapsync vaak doordat de verbinding eindigt voordat het schrijven klaar is. Lange APPEND-bewerkingen, trage Exchange-servers en stateful firewalls zijn bekende oorzaken. Verhoog de tolerantie voor time-outs, stuur keepalives en cache de status, zodat herhalingen niet vanaf nul beginnen.

Gebruik deze opties bij de eerste serieuze ronde:

imapsync \
  --host1 imap.source.tld --user1 user@source.tld --passfile1 ./pass1 \
  --host2 imap.dest.tld   --user2 user@dest.tld   --passfile2 ./pass2 \
  --timeout 120 \
  --keepalive1 --keepalive2 \
  --usecache

Wat iedere optie doet:

De cache is belangrijker dan vaak wordt gedacht. Goede migraties zijn incrementeel: voer een bulkronde uit, herstel authenticatie of toewijzing en doe daarna één of twee inhaalrondes. Met `--usecache` leest imapsync beide kanten minder vaak opnieuw. Zonder cache is iedere herhaling zwaarder.

Er is een voorbehoud. De officiële documentatie waarschuwt dat `--usecache` in sommige gevallen niet veilig samengaat met combinaties van grootte- en ouderdomsfilters. Voeg geen willekeurige filters toe omdat ze efficiënt klinken. Houd de eerste ronde eenvoudig.

Mapopties die paniek over ontbrekende mappen voorkomen

Wanneer gebruikers zeggen dat imapsync mappen kwijt is, staat de mail er vaak nog. De bestemming heeft het pad anders geïnterpreteerd of een gelokaliseerde speciale map is niet aan de actieve map Verzonden gekoppeld. Bij afwijkende providers heeft imapsync een expliciete vertaling nodig.

De twee grootste valkuilen zijn hiërarchiescheidingstekens en speciale mappen.

Sommige servers gebruiken punten voor nesting, andere schuine strepen. Heeft de bron INBOX.Clients.ProjectA en verwacht de bestemming INBOX/Clients/ProjectA, herschrijf het pad dan tijdens het kopiëren.

imapsync \
  --host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
  --regextrans2 's/\./\//g'

Dan is er het probleem met Verzonden. Providers gebruiken verschillende namen, terwijl gebruikers alleen willen dat hun mail in de actieve map verschijnt.

Probeer bij standaard speciale mappen eerst --automap. Voor rommelige, gelokaliseerde of oude cPanel-postvakken zijn expliciete regex-transformaties veiliger. TrekMail heeft ook gidsen voor een import starten in het dashboard en een domein toevoegen wanneer je de bestemming voorbereidt.

Conceptueel voorbeeld: de map verdween niet. Ze verhuisde van de verwachte map Verzonden naar een ruwe archiefnaam die de client niet als “Verzonden” behandelt. Dezelfde bytes, verkeerde plaats en toch hetzelfde supportticket.

Beperk imapsync voordat Google of Microsoft jou beperkt

Providers kunnen imapsync als misbruik zien. Snelle reeksen APPEND- en FETCH-opdrachten over veel postvakken activeren snelheidsbeperkingen, tijdelijke schorsingen of fouten die op authenticatieproblemen lijken maar capaciteitslimieten zijn. Rustig werken kan sneller zijn dan geblokkeerd raken.

Beheer het tempo bij Google Workspace of Microsoft 365:

imapsync \
  --host1 imap.gmail.com --user1 user@source.tld --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@dest.tld --passfile2 ./pass2 \
  --maxbytespersecond 500000 \
  --maxmessagespersecond 2

Dit vermindert pieken die verdediging activeren en voorkomt dat kleine berichten een gedeelde omgeving overbelasten. Dat telt bij oude cPanel-systemen en drukke Office 365-tenants.

Beschouw de getallen niet als absolute regels, maar als startwaarden. De juiste limiet hangt af van omvang, gelijktijdigheid en tolerantie van de provider. Begint een migratie goed en volgen later afwisselende fouten, vertraag dan voordat je het wachtwoord verdenkt.

Hier wordt ook het verschil tussen oud en nieuw duidelijk.

Oude aanpak: voor elk postvak scripts schrijven, beperkingen met vallen en opstaan afstellen en om 2 uur 's nachts fouten bewaken.

Nieuwe aanpak: voor de ontvangende kant de serverimport in betaalde TrekMail-abonnementen gebruiken, de bestemming standaardiseren en kosten per gebruiker vermijden. Bureaus met veel domeinen willen liever geen drie dagen herhalingen onderzoeken dan één postvak tien minuten eerder afronden. Lees dan deze gids over e-mailhosting voor meerdere domeinen.

Authenticatieopties voor 2025-2026: wachtwoorden falen, OAuth wint

Bij Google Workspace en Microsoft 365 kun je niet aannemen dat IMAP met alleen gebruikersnaam en wachtwoord werkt. Google stelt dat Workspace-accounts vanaf May 1, 2025 geen “minder veilige apps” meer ondersteunen die zo aanmelden. Exchange Online verwijst IMAP-clients eveneens naar OAuth.

Dat verandert de imapsync-opdracht. Ondersteunt de bron XOAUTH2, dan heb je een toegangstoken nodig in plaats van het gewone wachtwoord.

imapsync \
  --host1 outlook.office365.com \
  --user1 user@source.tld \
  --authmech1 XOAUTH2 \
  --oauthaccesstoken1 "ACCESS_TOKEN" \
  --host2 imap.trekmail.net \
  --user2 user@dest.tld --passfile2 ./pass2

Bij Google Workspace kunnen app-wachtwoorden praktisch zijn voor eenmalige verhuizingen wanneer 2-Step Verification aanstaat. Gebruik bij Microsoft 365 de gedocumenteerde OAuth-stroom voor oudere protocollen. Een script dat “correct wachtwoord” gelijkstelt aan “correcte authenticatie” loopt achter.

Officiële bronnen: Google over minder veilige apps en Microsoft over OAuth voor IMAP.

Integriteitsopties die voorkomen dat imapsync slechte mail overslaat

Op oude servers zijn sommige berichten beschadigd. Ontbrekende Message-ID-headers, ongeldige MIME, enorme bijlagen en lege berichtinhoud komen echt voor. imapsync kan een deel verwerken als je het instrueert.

--addheader voegt volgens de documentatie een gegenereerde Message-Id-header toe wanneer die ontbreekt. Berichtidentiteit bepaalt immers wat al bestaat.

--maxsize voorkomt dat één enorm, geweigerd bericht de hele taak ophoudt.

imapsync \
  --host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
  --addheader \
  --maxsize 35000000

Het doel is niet grote berichten negeren, maar eerst de 99% verplaatsen en de uitzonderingen daarna gecontroleerd verwerken.

Combineer parallelle uitrol met nette inrichting. Lees e-mailaccounts in bulk maken, want problemen groeien wanneer aanmaak, wachtwoorden en DNS in losse spreadsheets worden beheerd.

De gevaarlijkste imapsync-optie: --delete2

`--delete2` verwijdert uit de bestemming berichten die niet in de bron staan. Dat klinkt nuttig voor exact spiegelen, maar kan na de MX-omschakeling geldige nieuwe mail wissen.

Het foutscenario:

1. Je plaatst oude mail vooraf in de bestemming.
2. Je wijzigt MX.
3. Nieuwe mail komt bij de bestemming aan.
4. Je herhaalt imapsync met --delete2.
5. imapsync verwijdert mail die alleen in de bestemming staat.

Dat is geen fout, maar precies de gegeven opdracht.

Gebruik `--delete2` alleen gecontroleerd vóór de omschakeling, zolang de oude bron leidend is. Laat de optie na een MX-wijziging weg. Zodra de bestemming mail ontvangt, is die leidend voor nieuwe berichten.

Gebruik headervergelijking wanneer UID's misleiden

IMAP-UID's zijn alleen betrouwbaar binnen hun serverstatus. RFC 3501 definieert UIDVALIDITY omdat UID-aannames na wijzigingen kunnen breken. Na herbouw of herindexering kan imapsync elk bericht als nieuw zien en alles dupliceren.

Dan helpt vergelijking via headers:

imapsync \
  --host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
  --useheader 'Message-Id'

Dit is trager dan vertrouwen op server-UID's, maar veiliger bij een instabiele of herbouwde bron. De documentatie noemt --useheader "Message-Id" als oplossing voor veel dubbele berichten.

Voor de eindcontrole gebruik ik liefst een voorzichtige droge ronde vóór de DNS-wijziging en een korte incrementele ronde nadat gebruikers de oude omgeving niet meer wijzigen.

Een veilige sjabloon voor imapsync

Een veilige opdracht is expliciet over verbinding, toewijzing, uitsluitingen en testmodus. Begin droog, controleer de mappen en voer dan pas echt uit. Test een eerste concept niet op productiemail.

imapsync \
  --host1 imap.gmail.com --user1 user@source.com --passfile1 ./pass1 \
  --host2 imap.trekmail.net --user2 user@dest.com --passfile2 ./pass2 \
  --timeout 120 --keepalive1 --keepalive2 \
  --usecache \
  --automap \
  --regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/' \
  --exclude '^\[Gmail\]/All Mail' \
  --maxbytespersecond 500000 \
  --maxmessagespersecond 2 \
  --dry

Drie praktische opmerkingen:

1. Gebruik eerst --dry. Altijd.
2. Sluit grote, onnodige archiefmappen uit de eerste ronde uit.
3. Bewaar het logboek en versiebeheer de opdrachten per batch.

Na aankomst op TrekMail verbinden gebruikers via standaard IMAP op imap.trekmail.net via poort 993. TrekMail gebruikt IMAP en niet POP3, zodat de status tussen apparaten kan synchroniseren.

Conclusie: imapsync werkt wanneer je het als migratietool beheert

imapsync blijft geschikt voor veel verhuizingen als je het als stateful migratiesoftware behandelt, niet als eenvoudige kopieeropdracht. Stel time-outs in, gebruik keepalives, wijs mappen bewust toe, vertraag bij beperkingen, gebruik moderne authenticatie, vermijd `--delete2` na de omschakeling en vergelijk headers bij twijfelachtige UID-status.

Voor een eenvoudiger te beheren bestemming biedt TrekMail meerdere domeinen, vaste prijzen, gedeelde opslag en serverimport bij betaalde abonnementen, zonder extra kosten voor ieder postvak. Lees na de verhuizing ook dit artikel over zakelijke e-mail.