E-mail naar een andere host verhuizen: duplicaten en mappen

E-mail naar een andere host verhuizen lijkt eenvoudig, totdat een mailbox dubbel wordt gekopieerd en iemands verzendgeschiedenis verdwijnt. Veel handleidingen besteden daar weinig aandacht aan. Ze behandelen e-mail als losse bestanden, terwijl ook de mailboxstructuur en status ertoe doen.

Je kopieert actieve IMAP-gegevens tussen twee servers met verschillende mapregels, UID-verwerking en systeemmappen voor verzonden berichten. Een verkeerde aanname kan lege mappen, dubbele conversaties of mail verspreid over beide systemen opleveren.

Een gefaseerde IMAP-werkwijze, duidelijke mapkoppelingen en grondige controle na de omschakeling beperken die risico's. Lees voor de bredere planning van providers, prijzen en eigenaarschap eerst onze gids over zakelijke e-mail. Hier staat de migratie zelf centraal.

Bij een overstap naar TrekMail begin je met de actuele IMAP-migratiehandleiding en daarna de gids voor Gmail of cPanel, afhankelijk van de bronserver. Volgens de bronbeschrijving is server-side IMAP-migratie beschikbaar op betaalde abonnementen vanaf $3.50/mo. Nano wordt daarin als gratis zonder betaalkaart beschreven, met een gratis proefperiode van 14 dagen voor betaalde abonnementen. Controleer de huidige prijzen, functies en voorwaarden.

Wat gebeurt er wanneer je e-mail naar een andere host verhuist?

Kort gezegd: een IMAP-tool meldt zich aan bij de oude mailbox, leest mappen en berichten en kopieert ze naar de nieuwe mailbox. Mapnamen normaliseren, bronduplicaten herkennen en DNS-timing beheersen gebeurt alleen wanneer de gekozen tool en werkwijze daarvoor zijn ingericht.

IMAP-migratie kopieert gegevens tussen twee mailsystemen. Bij een zuivere kopieerbewerking blijft het bronaccount intact. Het doel krijgt kopieën van berichten, mappen en, afhankelijk van ondersteuning, vlaggen zoals gelezen of ongelezen. Contacten, agenda's en serverregels worden hiermee niet gekopieerd. Hoe beide servers berichten identificeren, blijft een aandachtspunt.

Volgens RFC 3501 horen UIDs bij een afzonderlijke mailbox en haar UIDVALIDITY-waarde. Ze zijn geen globale berichtidentiteiten en kunnen niet rechtstreeks tussen servers worden vergeleken. Tools die deze status gebruiken, kunnen na een wijziging eerder gekopieerde berichten niet meer herkennen.

Daarom kan een ogenschijnlijk geslaagde eerste ronde bij herhaling toch problemen geven. Een dashboardstatus “voltooid” vervangt geen controle van de daadwerkelijk gekopieerde gegevens.

Waarom ontstaan dubbele berichten bij een verhuizing?

Kort gezegd: duplicaten kunnen ontstaan wanneer de tool berichten niet betrouwbaar kan koppelen aan eerdere kopieën. Gewijzigde UIDVALIDITY, opnieuw aangemaakte doelmappen of Gmail-labels die als zelfstandige mappen worden gekopieerd zijn mogelijke oorzaken. Het resultaat hangt af van de matchingstrategie van de tool.

De valkuil van UIDVALIDITY

Veel migratietools bewaren UIDs per map of gebruiken aanvullende berichtkenmerken; niet iedere tool werkt met dezelfde UID-koppeling. Opnieuw indexeren verandert UIDs niet noodzakelijk. Een verwijderde en opnieuw aangemaakte map of verloren synchronisatiestatus kan de herkenning wel verstoren.

RFC 3501 vereist stabiele UIDs binnen hun geldigheidscontext; ongeldige eerdere UIDs moeten via UIDVALIDITY herkenbaar worden. Bij een wijziging moet de tool de opgeslagen koppelingen opnieuw beoordelen. Zonder geschikte herstelstrategie kunnen duizenden berichten opnieuw worden geïmporteerd.

Voorbeeld: de eerste ronde kopieert 38,000 berichten uit Inbox. Na een time-out start de beheerder opnieuw, maar de bron- of doelmap is inmiddels opnieuw opgebouwd. Als de oude UID-koppelingen daardoor niet meer bruikbaar zijn en de tool geen andere herkenning toepast, kunnen nog eens 38,000 berichten worden gekopieerd.

Het probleem met Gmail-labels

Gmail gebruikt labels in plaats van uitsluitend gewone mappen. Een bericht kan meerdere labels hebben en gearchiveerde mail staat in All Mail. De Gmail-documentatie beschrijft dat archiveren mail uit Inbox verwijdert, terwijl het bericht via All Mail beschikbaar blijft.

Wie [Gmail]/All Mail én labelmappen zonder plan importeert, kan hetzelfde bericht op meerdere plaatsen in het doel opslaan. Dat vergroot de opslag, hoewel kopieën per label soms juist de gewenste mapweergave zijn. Bepaal vooraf hoe labels en unieke berichten moeten worden weergegeven.

Gebruik bij Gmail de actuele Gmail-importhandleiding als uitgangspunt. TrekMails beschreven importer gebruikt rechtstreekse IMAP-aanmeldgegevens. Een app-wachtwoord kan nodig zijn bij tweestapsverificatie en toegestaan accountbeleid; het is niet voor ieder account beschikbaar. Een andere OAuth-geschikte tool of ondersteunde providermethode kan dan een alternatief zijn, niet automatisch deze importer.

Bij CLI-tools kan dit voorbeeld helpen bij de voorbereiding; controleer de gevolgen van iedere optie:

imapsync \
  --host1 imap.gmail.com \
  --user1 user@gmail.com \
  --password1 'APP_PASSWORD' \
  --host2 mail.newhost.com \
  --user2 user@example.com \
  --password2 'DEST_PASSWORD' \
  --exclude "\\[Gmail\\]/All Mail" \
  --useheader "Message-ID" \
  --dry

Een dry run kopieert geen berichten en is geen volledige inhoudstest. Message-ID kan ontbreken of hergebruikt zijn en is op zichzelf niet altijd een betrouwbare unieke sleutel. Controleer versleutelde verbindingen en certificaten; zet echte wachtwoorden niet in shellgeschiedenis of zichtbare procesargumenten. Het uitsluiten van All Mail kan gearchiveerde berichten zonder ander geïmporteerd label overslaan: plan afzonderlijk dekking voor unieke archiefmail. Onze imapsync-gids behandelt de operationele kant uitgebreider.

Waarom lijken mappen na een verhuizing verdwenen?

Kort gezegd: een map kan onder een andere hiërarchie terechtkomen, een andere systeemmapnaam krijgen of een prefix hebben die de mailapp niet zoals verwacht toont. Onderzoek dat voordat je gegevensverlies concludeert; werkelijk ontbrekende gegevens blijven ook mogelijk.

Verschillende namespaces en scheidingstekens

IMAP-servers gebruiken verschillende namespaces en hiërarchische scheidingstekens. De ene gebruikt punten, zoals INBOX.Sent, een andere schuine strepen, zoals Inbox/Sent Items, en weer een andere een INBOX.-prefix.

Zonder passende mapping kan Project.Alpha bijvoorbeeld een submap van Project worden. Een systeemmap kan als gewone map verschijnen. Een mobiele app kan vervolgens de verkeerde map volgen of de bedoelde map niet tonen.

Sent tegenover Sent Items

Verzonden berichten vallen gebruikers snel op. De bron kan Sent gebruiken, terwijl het doel Sent Items verwacht of Sent Messages toont.

Wordt de bronmap als gewone map gekopieerd in plaats van aan de systeemmap gekoppeld, dan kan de standaardmap voor verzonden mail leeg blijven. De geschiedenis lijkt verdwenen, terwijl de gegevens elders staan.

De tabel bevat voorbeelden: controleer de werkelijke namespace, mappen met een speciale functie en clientinstellingen. Voor gedeelde hosting beschrijft TrekMails migratiegids voor cPanel en andere hosts gebruikelijke aanmeldgegevens. Controleer de werkelijke toegangsinstellingen en mappen alsnog; de gids vervangt die controle niet.

Een gecontroleerd migratieplan in 3 fasen

Kort gezegd: een gefaseerde synchronisatie kan onderbrekingen en duplicatierisico beperken. Kopieer eerst historische mail, voer rond de omschakeling een deltasynchronisatie uit en wijzig daarna MX met een laatste controleronde. Het behoud van bronontvangst en een terugvalvenster blijft nodig.

1. Historische synchronisatie. Kopieer eerst oudere mail, bijvoorbeeld ouder dan 30 dagen. Gebruikers kunnen ondertussen op de bron blijven werken; kies het venster op basis van de situatie.
2. Deltasynchronisatie. Kopieer nieuwe en gewijzigde gegevens, ook laat binnengekomen mail met een oude berichtdatum en verplaatste berichten. Betrouwbare herkenning is belangrijk omdat een deel van de geschiedenis al is geïmporteerd.
3. Omschakeling en laatste ronde. Wijzig MX en blijf late bezorging op de bron tijdens DNS-caches en SMTP-herpogingen opvangen. Voer extra deltarondes uit zolang dat nodig is; een enkele wachttijd bewijst geen wereldwijde omschakeling.

Onjuiste DNS-records kunnen mail naar de verkeerde host sturen of tot weigering bijdragen. Houd de actuele vereiste DNS-records bij de hand en controleer ze vóór de omschakeling.

; Example cutover records
@      MX   10 mail.trekmail.net.
@      TXT     "v=spf1 include:spf.trekmail.net -all"
_dmarc TXT     "v=DMARC1; p=quarantine;"

Deze records zijn illustratief, niet een direct toepasbaar migratievoorschrift. Behoud alle werkelijke SPF-afzenders en controleer DKIM en DMARC-uitlijning; kies quarantaine pas na inventarisatie en tests. Sluit gebruikerstoegang tot de oude host pas na verificatie en aanpassing van clients, terwijl ontvangst en deltasynchronisatie waar nodig beschikbaar blijven. Anders ontstaan gescheiden mailboxen en nieuwe verzonden berichten op de bron. Schakel de host niet onmiddellijk uit.

Een gestandaardiseerde werkwijze kan ook bureaus en MSP's helpen. Bij veel merken of klantdomeinen gaat het naast kopiëren vooral om operationele samenhang. Daar kan hosting voor meerdere e-maildomeinen relevant zijn.

Controlelijst na de verhuizing

Kort gezegd: vergelijk aantallen, oudste en nieuwste berichten en de mappenstructuur. Controleer daarnaast berichtinhoud, bijlagen, vlaggen, datums en mapping. Alleen gigabytes of aantallen bewijzen geen volledigheid; compressie en indexering beïnvloeden gerapporteerde grootte, en Gmail-labelkopieën beïnvloeden aantallen.

1. Vergelijk aantallen, niet alleen mailboxgrootte

Heeft Inbox vóór de omschakeling 4,502 items, dan verwacht je bij dezelfde selectie na afloop 4,502 items. Onderzoek afwijkingen, maar houd rekening met labels, filtering en nieuwe mail. Een gelijk aantal bewijst nog geen inhoudelijke integriteit.

2. Controleer de oudste en nieuwste berichten

Sorteer op datum en vergelijk het oudste en nieuwste bericht in belangrijke mappen zoals Inbox en Sent. Ontbrekende oude mail kan op een onvolledige historische ronde wijzen; ontbrekende recente mail op de delta of omschakeling. Controleer ook filters, datumvelden en mapping.

3. Zoek losgeraakte mappen

Zoek naar onverwachte hoofdmappen zoals INBOX.Sent, achtergebleven [Gmail]-mappen en dubbele verzonden-mappen. Ze kunnen mappingproblemen aangeven, maar sommige mappen zijn bewust behouden.

4. Test daadwerkelijke ontvangst en verzending

Stuur vanaf een externe mailbox een bericht en antwoord vanuit het doelaccount. Controleer de bedoelde ontvangstmap en de juiste map voor het verzonden antwoord. Onderzoek eventuele filtering apart.

5. Controleer nieuwe clientinstellingen

Een goede kopie kan onvolledig lijken als de client nog met de oude server verbindt. Werk na de omschakeling IMAP- en SMTP-instellingen bij volgens de actuele TrekMail-documentatie. Controleer bij onzichtbare mail ook synchronisatie en mapabonnementen.

Daarom horen migratie en providervervanging in hetzelfde plan. Ons artikel over een alternatief voor Titan Email bekijkt dat vanuit de providerkeuze: mailboxgegevens kopiëren is slechts een onderdeel van de overstap.

Oude en nieuwe werkwijzen vergelijken

Kort gezegd: handmatige migraties kunnen veel herhaalwerk en uitzonderingen kennen. Een server-side werkwijze met geschikte duplicaatcontrole en centraal beheer kan dat verminderen. Of gedeelde opslag, DNS-beheer en omschakelcontroles beschikbaar zijn, hangt af van de huidige dienst en het abonnement.

Voor een klein team kan dit beheertijd besparen; voor een bureau kan minder handwerk de marge helpen. In plaats van vijf losse beheerplekken kan een centrale omgeving nuttig zijn. Bekijk de actuele TrekMail-prijzen. De bron noemt gratis Nano en een gratis proefperiode van 14 dagen voor betaalde abonnementen; controleer de voorwaarden van vandaag.

Tot slot

Wil je e-mail naar een andere host verhuizen met minder risico op duplicaten, ontbrekende mappen en onderbrekingen, behandel het dan als een gecontroleerde IMAP-omschakeling. Koppel mappen vooraf, plan Gmail-labels en archiefdekking, synchroniseer gefaseerd en controleer aantallen én inhoud. Sluit daarna de oude gebruikerstoegang volgens een gecontroleerd uitfaseringsplan.

Bekijk trekmail.net als je TrekMail als nieuwe host overweegt. Hosting voor meerdere domeinen, gedeelde opslag, IMAP-migratie en een abonnementsmodel zonder individuele gebruikersprijzen zijn bronbeschrijvingen: controleer huidige functies, gebruikerslimieten en voorwaarden vóór de overstap.