imapsync datums herstellen

De belofte van --syncinternaldates (en waarom die breekt)

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 technisch gezien probeert het dat. Maar "probeert" doet veel zwaar werk in die zin.

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 commerciele tools jaloers op zijn. Maar datumbewaring ligt niet geheel in de handen van imapsync, 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 probleem: de doelserver is niet verplicht dat datum te respecteren.

Waarom doelservers het INTERNALDATE negeren

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". Verschillende grote e-mailplatforms hebben besloten dat ze een goede reden hebben.

Microsoft 365 is de grootste boosdoener. Wanneer een bericht via IMAP APPEND binnenkomt, stempelt de Exchange-transportpipeline er een nieuwe Received-header op met de huidige datum, en stelt vervolgens het INTERNALDATE in op basis van dat bezorgingstijdstempel. Het maakt niet uit welke datum imapsync heeft aangevraagd. De M365-server overschrijft het.

Google Workspace (Gmail) gedraagt zich anders maar kan toch problemen veroorzaken. De IMAP-implementatie van Gmail respecteert het INTERNALDATE van de APPEND in de meeste gevallen, maar voegt een eigen Received-header toe. Als de e-mailclient die de mailbox leest Received-headers prioriteert boven INTERNALDATE voor weergave (en Outlook doet precies dat), verschijnen datums toch verkeerd.

Dovecot en Cyrus, de twee meest voorkomende open-source IMAP-servers, respecteren over het algemeen het INTERNALDATE van de APPEND. Dus imapsync-migraties tussen twee Dovecot-servers bewaren datums meestal correct. De problemen beginnen wanneer de bestemming een gehost platform is met eigen transportverwerking.

Veelgemaakte imapsync-opdrachtregelfouten die datums breken

Zelfs wanneer de doelserver zou meewerken, struikelen beheerders vaak over de opdrachtregelopties van imapsync. Dit zijn de fouten die ik het vaakst zie:

--syncinternaldates helemaal vergeten

De flag is standaard niet ingeschakeld. Als u een basis imapsync --host1 source --host2 dest --user1 user --user2 user uitvoert zonder deze, probeert imapsync helemaal niet datums te bewaren. De doelserver gebruikt het huidige tijdstempel voor elk bericht. Dit is de meest voorkomende oorzaak, en de gemakkelijkst te missen omdat imapsync er niet voor waarschuwt.

--syncinternaldates gebruiken met --addheader

Sommige handleidingen raden aan om --addheader te gebruiken om een aangepaste header te injecteren tijdens de migratie. Als u headers toevoegt, wijzigt u het bericht, wat de doelserver kan triggeren om het als een "nieuw" bericht te behandelen en dienovereenkomstig te stempelen. De interactie tussen deze twee flags is slecht gedocumenteerd.

--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.

Tijdstempelverschuiving door SSL-onderhandeling

Bij migratie over TLS met --ssl1 en --ssl2 voegt de verbindingsopbouw latentie toe. Bij grote migraties (50.000+ berichten) accumuleert deze latentie. Het verandert datums niet met dagen, maar kan ertoe leiden dat berichten die minuten na elkaar zijn verzonden met identieke tijdstempels op de bestemming aankomen, waardoor hun relatieve volgorde verloren gaat.

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

Beide datums komen overeen. Dat betekent dat imapsync het correcte INTERNALDATE naar de bestemming heeft gestuurd. Maar het betekent niet dat de doelserver die datum daadwerkelijk heeft opgeslagen. imapsync rapporteert wat het heeft aangevraagd, niet wat de server heeft geaccepteerd.

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 de migratiedatum is in plaats van 2019-01-15, heeft de doelserver de aanvraag van imapsync genegeerd. Het log heeft tegen u gelogen (nou ja, het vertelde u wat het vroeg, niet wat het kreeg).

Dit gat tussen wat imapsync rapporteert en wat er werkelijk gebeurt is een van de meest frustrerende aspecten van het debuggen van datumproblemen. U kunt urenlang naar een schoon logbestand staren zonder ooit te beseffen dat de datums aan de andere kant verkeerd zijn.

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 met --syncinternaldates als u het de eerste keer bent vergeten? 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 zelfs dan, als de doelserver het INTERNALDATE negeert, bent u terug bij af.

Sommige beheerders proberen een hybride aanpak: eerst imapsync met --dry om te testen, dan de echte migratie. Maar --dry test niet wat de doelserver met het INTERNALDATE doet. Het simuleert alleen de overdracht. Het datumprobleem is onzichtbaar totdat berichten daadwerkelijk naar de bestemming worden geschreven.

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; het is de metadataverwerking van de doelserver die het weergaveprobleem veroorzaakt. 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 datumanomalieeen en past gerichte metadatacorrectie toe via een proprietary headerketenanalyse- en datumreconstructiepipeline. De correctie behandelt de specifieke patronen die imapsync-migraties achterlaten, inclusief de kenmerkende Received-headersignaturen van doelservers die het INTERNALDATE hebben overschreven.

Elke gecorrigeerde e-mail wordt individueel geverifieerd: berichtintegriteit, bijlagebehoud, mapplaatsing, threading, labels. Originelen worden bewaard in een zichtbare back-upmap Redate.io - Originals gedurende 30 dagen. 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