imapsync datums herstellen

De belofte van --syncinternaldates (en waar die stopt)

U hebt het imapsync-commando uitgevoerd. U hebt --syncinternaldates toegevoegd omdat u de documentatie hebt gelezen en zorgvuldig te werk gaat. De migratie eindigt, het log zegt alles overgedragen, nul fouten. Dan opent u de mailbox in Outlook en elke e-mail toont de datum van gisteren.

Dit is een van de meest voorkomende frustraties met imapsync, en het verwart systeembeheerders al sinds minstens 2017. De --syncinternaldates flag zou het IMAP INTERNALDATE tijdens de migratie moeten bewaren. En dat doet het ook: elke kopie krijgt de interne datum die de bronserver vasthoudt. Precies daar zit de valkuil.

imapsync is een open-source Perl-tool geschreven door Gilles Lamiral, en het is oprecht goed in wat het doet. Het handelt IMAP-naar-IMAP mailboxtransfers af met een betrouwbaarheid waar de meeste commerciële tools jaloers op zijn. Maar imapsync kan alleen de datums kopiëren die het aantreft, en daar wordt het ingewikkeld.

Hoe IMAP-datums werkelijk werken

Er zijn drie verschillende "datums" betrokken bij elke e-mail, en de meeste mensen (inclusief sommige IT-beheerders) halen ze door elkaar:

De Date:-header (RFC 2822) - de datum die de e-mailclient van de afzender stempelde bij het opstellen van het bericht. Deze leeft in het berichtlichaam en wordt nooit door mailservers gewijzigd.
Received:-headers - elke mailserver die het bericht afhandelt voegt er een toe met een eigen tijdstempel. Ze vormen een keten van afzender naar ontvanger. De bovenste (meest recente) Received-header is wat sommige e-mailclients gebruiken voor weergave.
INTERNALDATE - een IMAP-servertijdstempel die bepaalt hoe berichten in de mailbox worden gesorteerd. Deze wordt ingesteld wanneer het bericht voor het eerst wordt opgeslagen via IMAP APPEND.

Wanneer imapsync een bericht migreert, leest het het bericht van de bronserver (inclusief het INTERNALDATE) en schrijft het naar de doelserver met IMAP APPEND. De --syncinternaldates flag vertelt imapsync om het bron-INTERNALDATE aan de doelserver door te geven tijdens de APPEND.

Hier het goede nieuws: Microsoft 365, Outlook.com en Gmail bewaren de datum die ze krijgen. Als datums toch verkeerd zijn, ligt het probleem elders.

Waarom datums toch verkeerd kunnen zijn

De IMAP-specificatie (RFC 3501) zegt dat als een datum-tijd wordt meegegeven met het APPEND-commando, de server deze ZOU MOETEN gebruiken. "ZOU MOETEN" in RFC-taal betekent "doe het tenzij u een goede reden hebt om het niet te doen". Microsoft 365, Outlook.com en Gmail doen dat wel: een kopie die haar oorspronkelijke datum draagt, behoudt die.

Wat imapsync doorgeeft, is echter de datum die de bronserver voor elk bericht vasthoudt, niet de datum waarop de e-mail is verzonden. Bij een gezonde mailbox komen beide overeen. Bij een mailbox die al eerder is gemigreerd of uit een back-up is hersteld, kan de bron de datum van die eerdere handeling bevatten, en imapsync kopieert die zonder wijziging.

Gmail is alleen een apart geval wanneer de kopie via Gmail's eigen import-API verloopt in plaats van via IMAP: die API voegt een Received:-regel toe die gedateerd is op de dag van de kopie, en Outlook kan die datum tonen. imapsync spreekt IMAP, dus dat raakt het niet.

Dovecot en Cyrus, de twee meest voorkomende open-source IMAP-servers, bewaren ook de datum van de APPEND. Dus wat de bestemming ook is, blijft de vraag hetzelfde: welke datum had de bron?

Veelgemaakte imapsync-opdrachtregelfouten die datums breken

Los van de brondatums struikelen beheerders vaak over de opdrachtregelopties van imapsync, of geven ze de verkeerde optie de schuld. Dit zijn de fouten die ik het vaakst zie:

Kopiëren vanuit een bron waarvan de datums al verkeerd waren

--syncinternaldates staat standaard aan: imapsync geeft elke kopie de interne datum die de bronserver vasthoudt (documentatie: "Sets the internal dates on host2 as the same as host1"). Als de bronmailbox zelf het resultaat is van een eerdere migratie of een herstel, kunnen de interne datums daar al die van die handeling zijn, en imapsync kopieert getrouw de verkeerde datum. Dit is de meest voorkomende oorzaak, en de gemakkelijkst te missen, omdat het log twee identieke datums toont.

--syncinternaldates gebruiken met --addheader

Sommige handleidingen raden aan om --addheader te gebruiken om een aangepaste header te injecteren tijdens de migratie. Een header toevoegen wijzigt het bericht (een regel extra boven aan) maar niet de datum die imapsync doorgeeft, dus dat verklaart geen verkeerde datums. De kopie is alleen niet meer identiek aan het origineel, wat van belang is als u de twee vergelijkt.

--minage en --maxage verwarren met datumbewaring

De --minage en --maxage flags filteren welke berichten worden gemigreerd op basis van hun leeftijd. Ze beinvloeden niet hoe datums op de bestemming worden behandeld. Ik heb beheerders uren zien besteden aan het aanpassen van deze flags in de veronderstelling dat het datumprobleem daarmee opgelost zou worden. Dat gebeurt niet.

TLS de schuld geven van verschoven datums

Bij migratie over TLS (--ssl1, --ssl2) voegt het opzetten van verbindingen latentie toe, en bij een grote migratie (50.000+ berichten) telt dat op tot uren. Dit raakt de datums niet: elke kopie draagt de datum die imapsync doorgeeft, hoe laat ze ook daadwerkelijk aankomt.

imapsync-logs lezen: wat de output werkelijk zegt

imapsync produceert gedetailleerde logs, wat goed is. Maar de logoutput kan misleidend zijn als het om datums gaat.

Een typische succesvolle overdrachtsregel ziet er zo uit:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

En Microsoft 365, Outlook.com en Gmail bewaren allemaal de datum die ze krijgen. Maar twee identieke datums bewijzen alleen dat de kopie getrouw is aan de BRON: als de brondatum al verkeerd was, tonen beide kolommen dezelfde verkeerde datum.

Wilt u verifiereen wat er werkelijk is gebeurd? Maak na de migratie verbinding met de bestemming via een IMAP-client en controleer het INTERNALDATE direct:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Als de teruggegeven datum niet de datum is waarop de e-mail is verzonden, bekijk dan hetzelfde bericht op de bron: daar vindt u dezelfde verkeerde datum. Het log heeft niet gelogen, het heeft gekopieerd wat het meekreeg.

Dit is een van de meest frustrerende aspecten van het debuggen van datumproblemen: een schoon logbestand, twee identieke datums, en toch de verkeerde datum in Outlook, omdat de fout er al was voordat imapsync draaide.

Grootschalige imapsync-migraties: waar datumproblemen zich vermenigvuldigen

Een enkele mailboxmigratie met imapsync is vervelend wanneer datums breken. Maar MSP's en IT-afdelingen die imapsync over honderden mailboxen uitvoeren staan voor een heel andere schaal van het probleem.

Neem een typisch bedrijfsmigatiescenario. U verplaatst 200 mailboxen van een Zimbra-server naar Microsoft 365. U schrijft een wrapper-script dat door een CSV met gebruikers loopt en voor elk imapsync aanroept. De migratie draait het weekend. Maandagochtend hebt u 200 mailboxen met kapotte datums en rond de 1,2 miljoen e-mails totaal die het migratietijdstempel tonen.

Kunt u imapsync opnieuw uitvoeren om het te herstellen? Technisch ja, maar imapsync slaat berichten over die al op de bestemming bestaan (het is ontworpen om idempotent te zijn). U zou --delete2 nodig hebben om doelberichten te verwijderen en opnieuw over te dragen, wat riskant is op een productiemailbox. En als de brondatums het probleem waren, kopieert een tweede uitvoering dezelfde verkeerde datums opnieuw.

Sommige beheerders proberen een hybride aanpak: eerst imapsync met --dry om te testen, dan de echte migratie. Maar --dry simuleert alleen de overdracht: het toont de datums die imapsync zou doorgeven, niet of dat de datums zijn waarop de e-mails zijn verzonden. Niets waarschuwt u dat de brondatums al verkeerd zijn.

Doe-het-zelf-oplossingen en hun grenzen

Als u in forums en mailinglijsten zoekt (de imapsync-devel lijst op SourceForge is begin 2026 nog actief), vindt u suggesties die varieren van creatief tot gevaarlijk.

Sommigen stellen voor een Perl-oneliner te gebruiken om het INTERNALDATE direct op de doelserver te wijzigen. Anderen raden aan alle berichten te exporteren naar mbox-formaat, de datums te manipuleren en opnieuw te importeren. Enkelen hebben Python-scripts geschreven die imaplib gebruiken om berichten op te halen, te wijzigen en opnieuw in te voegen.

Al deze benaderingen delen dezelfde fundamentele problemen. Hoe handelt u S/MIME-ondertekende berichten af zonder de handtekening te breken? Hoe zit het met multipart MIME-structuren met geneste grenzen? Niet-ASCII-headers gecodeerd met RFC 2047? PGP-versleutelde berichten waarvan u de inhoud niet eens kunt inspecteren? Een script dat 50 testberichten in een ontwikkelomgeving afhandelt, zal vastlopen op de randgevallen van een productiemailbox met 30.000 berichten.

En de grootste vraag die niemand stelt totdat het te laat is: hoe verifieert u dat elk gewijzigd bericht nog intact is? Dat bijlagen niet beschadigd zijn, dat threading nog werkt, dat het 85 MB spreadsheet dat iemand in 2020 per e-mail verstuurde de manipulatie heeft overleefd?

(Als u ooit geprobeerd hebt ruwe e-mailheaders in Perl te parsen, tja, weet u dat het niet bepaald een ontspannen middagactiviteit is.)

Hoe Redate.io imapsync-datumproblemen herstelt

De originele Date:-header is altijd intact na een imapsync-migratie. imapsync draagt het ruwe bericht getrouw over; de verkeerde datum zit in de metadata die de kopie heeft meegekregen, niet in het bericht. Die originele header maakt correctie mogelijk.

Redate.io maakt rechtstreeks verbinding met de mailbox (Google Workspace, Microsoft 365 of elke IMAP-server), scant op e-mails met datumanomalieën en past gerichte metadatacorrectie toe via een eigen headerketenanalyse- en datumreconstructiepipeline. Het hoeft niet te weten welke tool de migratie heeft uitgevoerd: het vindt de e-mails waarvan de weergegeven datum niet overeenkomt met hun oorspronkelijke datum.

Elke gecorrigeerde e-mail wordt individueel geverifieerd: berichtintegriteit, bijlagebehoud, mapplaatsing, threading, labels. Originelen worden bewaard in een zichtbare back-upmap Redate.io - Originals totdat u ze zelf verwijdert. Als iets er niet goed uitziet, is terugdraaien een klik verwijderd.

De gratis scan maakt verbinding met de mailbox, identificeert elke e-mail met een datumanomalie en rapporteert het exacte aantal en de kosten. Geen creditcard nodig, geen software te installeren. Voor de details van uw platform:

Redate.io werkt ook voor migraties die maanden of jaren geleden hebben plaatsgevonden. De Date:-header verloopt niet, en het vermogen om te corrigeren evenmin.

Gemigreerd met imapsync en vast met verkeerde datums? Start een gratis scan om precies te zien hoeveel e-mails zijn getroffen.

imapsync: datums niet behouden? Zo herstelt u ze