Rett imapsync-migreringsdatoer i Gmail

imapsync er standardverktøyet for IMAP-til-IMAP-postboksmigrering, og med god grunn - det håndterer mappetilordning, flaggbevaring og inkrementell synkronisering bedre enn de fleste alternativer. Men når destinasjonen er Gmail, blir datobevaring upålitelig på måter som overrasker selv erfarne systemadministratorer.

--syncinternaldates-flagget skal egentlig løse dette. Det ber imapsync om å sende kildemeldingenes INTERNALDATE til destinasjonsserveren under APPEND. På en standard IMAP-server fungerer dette. På Gmail? Ikke alltid. Gmails IMAP-implementasjon kjører innkommende meldinger gjennom sin egen interne behandlingspipeline - spamfiltrering, sikkerhetsskanning, innholdsindeksering. Under denne behandlingen kan Gmail overstyre den forespurte INTERNALDATE og stemple meldingen med opplastingstidsstempelet i stedet. Den legger også til en Received-header (typisk med "gmailapi.google.com" eller IMAP-gatewayidentifikatoren) datert til opplastingsøyeblikket.

Den frustrerende delen: dette skjer ikke med alle meldinger. Noen e-poster i den migrerte postboksen får riktig INTERNALDATE. Andre får opplastingsdatoen. Det finnes ikke noe tydelig mønster - en melding fra 2018 kan være fin mens den rett ved siden av fra den samme dagen er stemplet med migreringsdatoen. Du ender opp med en postboks der 30-70 % av e-postene har feil datoer, spredt tilfeldig på tvers av mapper og tidsperioder.

Har du noen gang prøvd å forklare en samsvarsansvarlig hvorfor 4 200 av 11 000 migrerte e-poster viser feil mottaksdato, men de resterende 6 800 er fine? Lykke til med å finne et mønster i det.

Gmails nettgrensesnitt skjuler faktisk problemet. Gmail på nett viser Date-headerverdien, ikke INTERNALDATE, så de fleste berørte e-poster ser fine ut i nettleseren. Dette skaper en farlig falsk trygghet - migreringsadministratoren sjekker Gmail på nett, ser riktige datoer og lukker saken.

Så begynner brukerne å koble Outlook, Apple Mail og Thunderbird til sine nye Gmail-kontoer. Disse klientene leser IMAP INTERNALDATE for datokolonnene sine. Plutselig viser tilfeldige e-poster migreringsdatoen mens andre viser riktig dato. Avviket mellom Gmail på nett og skrivebordsklienter skaper forvirrende henvendelser til brukerstøtte. IMAP-søkekommandoer på serversiden (SEARCH SINCE, SEARCH BEFORE) refererer til INTERNALDATE og gir ufullstendige eller unøyaktige resultater. Tredjeparts sikkerhetskopiverktøy som arkiverer via IMAP fanger opp de ødelagte datoene permanent. Google Vault og Workspace-samsvarsverktøy kan referere til INTERNALDATE for datobasert hold, noe som potensielt påvirker juridisk funn. Redate.io sin mønstergjenkjenning på tvers av migreringsverktøysignaturer identifiserer de spesifikke Gmail Received-headerne som indikerer datokorrupsjon, og utfører deretter målrettet metadatakorreksjon på alle berørte meldinger mens alle etiketter, stjerner og lest/ulest-status bevares.