Rett manuelle IMAP-kopieringsdatoer i Gmail

Manuell IMAP-kopiering til Gmail høres enkelt nok ut: legg til både kildekontoen og Gmail i en e-postklient som Outlook, Thunderbird eller Apple Mail, og dra meldingene over. Det ingen forteller deg, er at alle e-postklienter mister de opprinnelige datometadataene under denne operasjonen. Klienten laster opp meldinger til Gmail uten å spesifisere den opprinnelige INTERNALDATE, så Gmail registrerer opplastingstidsstempelet i stedet. Tusenvis av e-poster, en dato.

Gmail legger til sin egen vri på problemet. Når Gmail mottar en opplastet melding, legger Gmails IMAP-gateway til en ny Received-header stemplet med gjeldende dato og klokkeslett. Denne headeren havner øverst i headerkjeden. Gmails nettgrensesnitt er smart nok til å bruke Date-headeren fra e-postteksten for visning, så datoer kan se riktige ut i nettleseren. Men alle IMAP-klienter som kobler seg til etterpå leser den ødelagte INTERNALDATE fra Googles servere.

Hvem gjør egentlig manuell IMAP-kopiering? Flere enn du kanskje tror. Små bedrifter som konsoliderer fra Yahoo Mail eller en billig hostingleverandør til Gmail. Frilansere som slår sammen tre kontoer til en. IT-konsulenter som migrerer en kundes postboks fra en leverandør som ikke har noe offisielt migreringsverktøy. Dra-og-slipp-tilnærmingen føles intuitiv og trygg. Men på IMAP-protokollnivå blir datometadata stille ødelagt under overføringen - og innen noen legger merke til det, kan kildekontoen allerede være stengt.

Konsekvensene deler seg i to verdener. I Gmails nettgrensesnitt kan datoer se riktige ut fordi Gmail leser Date-headeren fra e-postteksten. I alle IMAP-klienter - Outlook, Apple Mail, Thunderbird, Gmail-appen på Android - vises kopieringsdatoen i stedet. Dette skaper en forvirrende situasjon der den samme e-posten viser forskjellige datoer avhengig av hvordan du bruker den.

Men skaden går dypere enn visningsavvik. Har du noen gang prøvd å kjøre en samsvarsrevisjon på en postboks der 30 000 e-poster alle har den samme INTERNALDATE? Google Vault-søk etter dato gir misvisende resultater. Sikkerhetskopiverktøy som MailStore, Veeam eller egendefinerte arkiveringsskript som kobler seg til via IMAP registrerer permanent feil datoer. Google Takeout-eksporter kan referere til INTERNALDATE for filnavngiving, noe som skaper arkivmapper der 2017-e-poster ligger ved siden av 2023-e-poster under en enkelt dato. For noen som konsoliderte flere års e-post fra flere leverandører til Gmail, kan dette bety at hele e-posthistorikken har feil datometadata på Googles servere.

Redate.io løser dette gjennom en proprietær korreksjonsmotor som bruker mønstergjenkjenning på tvers av migreringsverktøysignaturer for å identifisere berørte meldinger. Prosessen utfører målrettet metadatakorreksjon på servernivå - og bevarer meldingsinnhold, etiketter, lesestatus og vedlegg mens nøyaktig datoinformasjon gjenopprettes. Hver melding verifiseres individuelt før og etter korreksjon.