Waarom imapsync populair is (en waarom datums toch kapotgaan)
imapsync is de standaard e-mailmigratietool voor Linux-systeembeheerders, hostingproviders en iedereen die de voorkeur geeft aan opensourceoplossingen. Gemaakt door Gilles Lamiral, wordt imapsync actief onderhouden sinds 2001 en is het gebruikt voor miljoenen mailboxmigraties wereldwijd. Het ondersteunt vrijwel elke IMAP-server: Dovecot, Courier, Cyrus, Zimbra, Exchange, Gmail en tientallen andere.
imapsync staat bekend als uitgebreid en configureerbaar. Beheerders waarderen de gedetailleerde controle over welke mappen worden gemigreerd, de duplicaatafhandeling en het mappen van mapnamen tussen verschillende IMAP-servers. Maar ondanks al die controle blijft er een probleem bestaan: e-maildatums worden na een imapsync-migratie regelmatig niet behouden. Gebruikers openen hun mailbox na migratie en constateren dat elke e-mail de migratiedatum toont. Dat is frustrerend, vooral omdat imapsync verondersteld wordt datums correct af te handelen.
Hoe imapsync de INTERNALDATE verwerkt
De poging tot INTERNALDATE-behoud
imapsync probeert inderdaad de INTERNALDATE van elke e-mail te behouden tijdens migratie. De INTERNALDATE is het tijdstempel dat de IMAP-server als metadata opslaat voor elk bericht, los van de e-mailheaders. Wanneer imapsync een bericht van bron naar bestemming kopieert, leest het de INTERNALDATE van de bronserver en geeft deze door aan de doelserver in het IMAP APPEND-commando.
In theorie zou dit de oorspronkelijke datum moeten behouden. In de praktijk hangt het resultaat af van het gedrag van de doelserver en hoe e-mailclients de verschillende datumgerelateerde velden in het bericht interpreteren.
Het "Received"-headerprobleem
Zelfs wanneer imapsync de INTERNALDATE met succes behoudt, voegt de bestemmingsmailserver een nieuwe "Received"-header toe aan elk bericht tijdens de APPEND-operatie. Deze "Received"-header bevat het huidige tijdstempel - de migratiedatum. E-mailclients zoals Outlook, Apple Mail en Thunderbird bepalen de weergegeven "ontvangstdatum" door de bovenste "Received"-header te lezen, niet de INTERNALDATE. Dus ondanks de inspanning van imapsync om de INTERNALDATE te behouden, is de zichtbare datum in de meeste clients alsnog verkeerd.
Het is deze fundamentele discrepantie die de verwarring veroorzaakt. imapsync behoudt een datumwaarde (INTERNALDATE), maar e-mailclients tonen een andere (het tijdstempel van de "Received"-header). Zie voor een technische verdieping waarom e-mails de verkeerde datum tonen na IMAP-migratie.
Het misverstand in de imapsync FAQ
De documentatie en FAQ van imapsync behandelen het datumprobleem, maar presenteren het als een inherente beperking. De FAQ suggereert dat "datums mogelijk niet bewaard blijven" bij IMAP-migratie en impliceert dat dit nu eenmaal is hoe het IMAP-protocol werkt. Hoewel het klopt dat het IMAP-protocol servers verplicht "Received"-headers toe te voegen bij berichtinsertie, wekt de FAQ de indruk dat het probleem permanent en onherstelbaar is.
Dat is niet juist. De "Received"-headers die tijdens migratie zijn toegevoegd, kunnen achteraf worden geidentificeerd en verwijderd, waardoor de oorspronkelijke datumweergave in e-mailclients wordt hersteld. De oorspronkelijke "Date"-header (die registreert wanneer de e-mail oorspronkelijk is verzonden) wordt altijd bewaard door imapsync en dient als referentie voor de correcte datum.
De imapsync-migratieheader identificeren
Hoe de header eruitziet
imapsync zelf voegt geen "Received"-header toe - de IMAP-doelserver doet dat. De header die wordt toegevoegd bij een imapsync-migratie lijkt doorgaans op een standaard IMAP-insertieheader van de doelserver. Bij migratie naar een Dovecot-server kan de header er bijvoorbeeld als volgt uitzien:
Received: from localhost by mail.example.com;
Wed, 15 Jan 2025 09:14:22 +0100De belangrijkste indicator is dat deze "Received"-header de bovenste in de keten is, dat het tijdstempel overeenkomt met de datum waarop de imapsync-migratie is uitgevoerd, en dat er doorgaans wordt verwezen naar "localhost" of de hostnaam van de doelserver in plaats van een externe mailserver.
Datums vergelijken
Om het probleem te bevestigen, vergelijkt u het tijdstempel van de bovenste "Received"-header met de "Date"-header van de e-mail. Als de "Received"-header januari 2025 aangeeft maar de "Date"-header maart 2020, is de migratie-"Received"-header de oorzaak van de verkeerde datumweergave. Deze vergelijking kan worden gemaakt door de ruwe berichtbron in elke e-mailclient te bekijken.
Waarom gangbare imapsync-opties het probleem niet oplossen
De --syncinternaldates vlag
imapsync biedt de --syncinternaldates vlag, die de INTERNALDATE op de doelserver instelt op basis van de "Date"-header van de e-mail. Dit is nuttig wanneer de INTERNALDATE van de bronserver al verkeerd is, maar het voorkomt niet dat de doelserver een "Received"-header toevoegt. De zichtbare datum in Outlook en andere clients blijft de migratiedatum, ongeacht de INTERNALDATE-waarde.
De --addheader optie
imapsync kan aangepaste headers toevoegen aan berichten tijdens migratie, maar kan de doelserver er niet van weerhouden zijn eigen "Received"-header toe te voegen. Het IMAP-protocol vereist dat servers het insertietijdstempel registreren, en geen enkele imapsync-optie kan dit servergedrag overschrijven.
Postmigratiescripts
Sommige beheerders schrijven aangepaste postmigratiescripts om ongewenste "Received"-headers te verwijderen. Dat klinkt redelijk, vooral voor het type persoon dat in eerste instantie voor imapsync heeft gekozen (iemand die thuis is op de commandoregel). Maar de realiteit is veel complexer dan een zoek-en-vervangactie op headertekst. Wat gebeurt er wanneer het script een S/MIME-ondertekende e-mail tegenkomt? Of een multipart-bericht met geneste MIME-grenzen en base64-gecodeerde bijlagen? Of een header met niet-ASCII-tekens gecodeerd volgens RFC 2047? Een enkele verkeerd geplaatste byte in een MIME-grens kan stilletjes een heel bericht beschadigen, bijlagen vernietigen of de e-mail onleesbaar maken. En hoe bevestigt u dat 10.000 gecorrigeerde e-mails allemaal intact zijn? Voor duizenden e-mails over meerdere mailboxen vormt DIY-scripting een aanzienlijk risico.
imapsync-datums herstellen met Redate.io
Hoe Redate.io imapsync-migraties verwerkt
De eigen correctie-engine van Redate.io is specifiek ontworpen voor deze categorie problemen. Na verbinding met de mailbox analyseert Redate.io elke e-mail en stuurt elk bericht door een meerfasig analyseproces. Voor imapsync-migraties detecteert Redate.io de door de server geplaatste "Received"-header door patroonherkenning op honderden bekende migratieprofielen, analyse van de volledige headerketen en kruisverwijzing van tijdstempels met de oorspronkelijke "Date"-header.
Dit is geen eenvoudige headerbewerking. De correctie-engine verwerkt RFC-conformiteitsvalidatie, berichtstructuurbehoud (inclusief multipart/alternative-structuren, inline-bijlagen en Content-Transfer-Encoding-variaties) en detectie van digitale handtekeningen. E-mails met S/MIME- of PGP-handtekeningen worden automatisch geidentificeerd en op passende wijze behandeld om de integriteit van de handtekeningen te behouden.
Wat u krijgt na de correctie
Elke gecorrigeerde e-mail toont de oorspronkelijke ontvangstdatum in alle e-mailclients. De chronologische volgorde is hersteld. Elke correctie ondergaat een integriteitscontrole voordat deze wordt afgerond. Het oorspronkelijke bericht wordt verplaatst naar een map "Redate.io - Originals" en 30 dagen bewaard als vangnet.
Compatibiliteit met alle doelservers
Omdat imapsync wordt gebruikt om naar vrijwel elke IMAP-server te migreren, ondersteunt Redate.io hetzelfde brede scala aan doelplatformen. Of de imapsync-migratie nu gericht was op Dovecot, Courier, Cyrus, Zimbra, Google Workspace, Microsoft 365 of een andere IMAP-server - Redate.io maakt verbinding en herstelt de datums.
Datums herstellen na een imapsync-migratie
De mailbox verbinden
Log in bij Redate.io en voeg de mailbox toe. Voor Google Workspace of Microsoft 365 gebruikt u de optie voor beheerdersdelegatie. Voor andere IMAP-servers (gebruikelijk bij imapsync-scenarios) voert u het serveradres, de gebruikersnaam en het wachtwoord in. Redate.io maakt verbinding via standaard IMAP.
Gratis analyse
Start de gratis analyse om getroffen e-mails te identificeren. Het analyserapport toont het totale aantal e-mails, hoeveel de verkeerde datum hebben en welke migratiedatum is gedetecteerd. Deze analyse kost niets en geeft een helder beeld voor eventuele verdere stappen.
Corrigeren en controleren
Selecteer een plan op basis van het aantal getroffen e-mails en start de correctie. De voortgang is in realtime zichtbaar. Na voltooiing controleert u de resultaten door de e-maildatums in uw client te bekijken. De datums zouden weer op hun plek moeten staan.
Platformspecifieke imapsync-correctiehandleidingen
Veelgestelde vragen
Moet ik --syncinternaldates van imapsync gebruiken voor Redate.io?
Dat is niet nodig. Redate.io stelt de juiste INTERNALDATE in tijdens het correctieproces, ongeacht de huidige waarde. Of imapsync de oorspronkelijke INTERNALDATE nu wel of niet heeft behouden, Redate.io leidt de correcte waarde af uit de oorspronkelijke "Date"-header.
Kunnen datums op de bronserver worden hersteld voor migratie met imapsync?
Als de bronserver al verkeerde datums heeft (als gevolg van een eerdere migratie), kan Redate.io deze voor of na de imapsync-migratie herstellen. Maar het herstellen van datums op de doelserver na migratie is de meest gangbare en praktische aanpak.
Hoeveel e-mails kan Redate.io verwerken?
Redate.io verwerkt mailboxen van elke omvang. Er zijn plannen beschikbaar voor maximaal 100.000 e-mails per mailbox. Voor organisaties met veel mailboxen biedt Redate.io volumekortingen.
Heeft de imapsync-migratie de datums kapotgemaakt? Start een gratis analyse om te zien hoeveel e-mails zijn getroffen en herstel ze met Redate.io.