Takeout mbox importert: alle e-poster datert i dag

Du har åpnet Google Takeout-arkivet, importert mbox-filen i Thunderbird med ImportExportTools NG (eller i Apple Mail), og så dratt mappene over til den nye IMAP-kontoen din. I klienten lå e-postene pent sortert år for år. På målkontoen er alle datert i dag. Denne artikkelen forklarer hva som skjer med en importert Takeout mbox, hvorfor datoen som vises er kopieringsdatoen, hvordan du bekrefter det på noen minutter og hvordan du retter det på serversiden.

Det første du bør vite: e-postene dine er ikke skadet. Den opprinnelige datoen ligger fortsatt i meldingen. Den er bare ikke lenger den målkontoen viser frem.

Det typiske scenarioet med en importert Takeout mbox

Du har nettopp lagt ned en privat Gmail-konto som ble opprettet for femten år siden. Du ba om eksport på takeout.google.com, ventet på meldingen fra Google (to dager for en stor postkasse) og lastet ned fire zip-arkiver. I hver av dem lå én .mbox-fil per etikett. Du importerer dem i Thunderbird: den lokale mappen fylles opp, sorteringen etter dato er upåklagelig, 2009 nederst og i går øverst.

Så gjør du det alle ville gjort. Du markerer mappene og drar dem over til IMAP-kontoen du skal bruke, enten det er Microsoft 365, en nettvert eller Google Workspace. Overføringen tar en hel kveld. Mandag morgen åpner du webmailen.

Problemet? Alle de 18 400 e-postene er datert i helgen, innenfor et tidsrom på noen få timer. En kontrakt fra 2014 ligger side om side med et nyhetsbrev fra forrige uke, og ingen finner noe lenger i kronologisk rekkefølge.

Dette ligner sterkt på tilfellet med gamle e-poster som alle har samme dato, med én stor forskjell: her er det ikke noe migreringsverktøy involvert. Å dra og slippe holder.

Tre datoer i én e-post

For å forstå dette må du slutte å snakke om "datoen" til en e-post. En melding som er importert fra en mbox-fil bærer minst tre, og de brukes til ulike ting.

Date-headeren: avsenderens dato

Dette er Date:-headeren som er definert i RFC 2822 (videreført i RFC 5322). Avsenderens klient skriver den i det øyeblikket e-posten sendes, for eksempel Date: Tue, 14 Mar 2017 09:12:45 +0100. Den er en del av meldingen, følger den overalt, og Takeout beholder den uendret. Det er den som gjør retting mulig, siden den er intakt.

From-linjen i mbox-filen: en fasadedato

I en mbox-fil har hver melding foran seg en linje som begynner med From (med mellomrom, uten kolon). Det er ikke en header: det er et skilletegn som hører til filformatet og ikke til selve meldingen. Ingen seriøse verktøy bør stole på den for å datere en e-post.

INTERNALDATE: datoen for avleveringen på serveren

Den tredje datoen er den mest lavmælte: INTERNALDATE, definert i RFC 3501. Det er en egenskap IMAP-serveren lagrer ved siden av meldingen (ikke inni den), og den tilsvarer tidspunktet meldingen ble lagt inn i postkassen. Outlook, webmail og mobiltelefoner bruker den til å vise og sortere mottaksdatoen. Vil du ha detaljene om mekanismen, går artikkelen om INTERNALDATE og feil datoer i IMAP lenger.

En presisering om Received:-headerne, som ofte får skylden uten grunn. Received-linjene i en eksportert Gmail-melding forteller om meldingens faktiske reise i 2017: de har gamle og legitime datoer. I dette tilfellet ligger den feilaktige datoen altså ikke i meldingen, men i metadataene serveren gir kopien.

Hvorfor målkontoen viser kopieringsdatoen

Når en klient legger en melding på en IMAP-server, bruker den APPEND-kommandoen. Kommandoen tar imot en valgfri dato som skal gis til meldingen. Sender klienten den med, lagrer serveren den som INTERNALDATE. Ellers følger serveren regelen i RFC 3501: dato og klokkeslett akkurat nå. Med andre ord avhenger datoen som vises av hvordan verktøyet skrev e-posten. Et verktøy som ikke sender med den opprinnelige datoen, får kopieringsdatoen.

Konsekvensen: mens du drar mappene over, får hver melding datoen for sin egen avlevering. En mappe med 3 000 e-poster som kopieres på 40 minutter havner i et vindu på 40 minutter.

Og den lokale mappen i Thunderbird, da? Den så perfekt ut fordi Thunderbird sorterer der etter Date-headeren og ikke etter en serverdato, siden en lokal mappe ikke har noen server. Apple Mail oppfører seg på lignende vis med importerte postkasser: alt går fint så lenge meldingene blir liggende på Macen. Sannheten kommer frem i det øyeblikket et annet program, for eksempel Outlook, leser IMAP-postkassen.

Egentlig er det ikke helt riktig å si at alle klienter tar feil hver gang. Noen versjoner sender med datoen, andre gjør det ikke, og oppførselen har endret seg med oppdateringene. Så to kolleger som følger samme fremgangsmåte, kan få ulikt resultat, og det gjør feilsøkingen mer forvirrende enn den ser ut til.

Å dra og slippe er ikke en migrering. Det er en kopiering, og en kopi bærer datoen den ble laget.

Slik kjenner du igjen dette tilfellet på fem minutter

Før du leter etter en løsning, bekreft at det faktisk er dette scenarioet du står i og ikke et annet. Fire kontroller er nok.

• Sammenlign de to stedene. Den lokale mappen i Thunderbird (eller den importerte postkassen i Apple Mail) viser riktige datoer, mens IMAP-kontoen viser nylige datoer for de samme meldingene.
• Se på tidsrommet. I en mappe på IMAP-kontoen ligger mottaksdatoene innenfor noen få timer, eller til og med noen få minutter, rundt tidspunktet du flyttet mappene.
• Åpne kilden til en melding. I Thunderbird velger du Vis og deretter Meldingskilde; i Outlook gir egenskapene til meldingen deg headerne. Du skal finne en gammel Date:-linje mens visningen viser en fersk dato.
• Sjekk rekkefølgen. Meldingene vises i den rekkefølgen klienten kopierte dem, ikke i kronologisk rekkefølge.

Slik ser sammenligningen ut på en ekte melding:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (i meldingen, intakt)
Dato vist av IMAP-kontoen: dagen for kopieringen   (metadata fra serveren)

Forteller ikke disse to linjene den samme historien, er du der. Og hvis datoene som vises er feil, men Date: også er det, er det et annet og sjeldnere problem som ikke hører hjemme i denne artikkelen.

(Forresten, har du aldri lest de rå headerne i en e-post, bør du sette på en kaffe først: det er ikke akkurat strandlektyre.)

Sortere etter sendingsdato: et plaster på såret

Refleksen er å bytte sorteringen til sendingsdato. I Outlook fungerer det sånn noenlunde, forutsatt at du gjør det om igjen i hver mappe og på hver enhet. Men søk, varsler, regler basert på alder og visningene på mobil bruker fortsatt mottaksdatoen. En bruker som leter etter "e-posten fra i september i fjor" på telefonen, ser ikke noe logisk.

Et annet fristende spor er å kopiere på nytt. På en konto som allerede er i bruk gir det mest av alt duplikater ved siden av meldingene som allerede ligger der, med de samme feil datoene eller nye. Rundt hundre mapper senere har du ikke én eneste ren postkasse igjen.

Rettingen på serversiden

Den gode nyheten er at den opprinnelige datoen fortsatt finnes. Rettingen går ut på å få målkontoen til å vise den, uten å røre innholdet i meldingene dine.

Det er dette Redate gjør. Tjenesten kobler seg til postkassen (Google Workspace via domenedelegering, Microsoft 365, Outlook.com og Hotmail med hver persons Microsoft-konto, eller direkte IMAP med adresse og passord). Redate trenger ikke å vite hvilket verktøy som forårsaket problemet: tjenesten finner e-postene der datoen som vises ikke stemmer med den opprinnelige datoen, enten årsaken er dra og slipp fra en Takeout mbox eller noe helt annet. Den gratis skanningen av postkassen viser deg omfanget før du tar noen avgjørelse.

Selve rettingen gjøres av en proprietær rettemotor, en analysepipeline i flere trinn som går gjennom header-kjeden i hver melding og gir hver e-post tilbake den opprinnelige datoen. Hver rettede e-post blir deretter kontrollert enkeltvis, med RFC-validering og bevaring av meldingsstrukturen. Originalene slettes aldri: de blir liggende i en synlig mappe i din egen postkasse til du sletter dem selv.

Hvorfor det er risikabelt å fikle selv

Å forstå problemet er én ting. Å rette det på 15 000 e-poster uten å miste en eneste en er noe helt annet.

Et skript som fungerer på ti testmeldinger, overlever ikke en produksjonspostkasse på 30 000 meldinger. Det støter på signerte S/MIME-e-poster, der den minste endring ødelegger signaturen. På PGP-krypterte meldinger. På nestede multipart/alternative-strukturer, inkonsistente MIME-grenser, uventet Content-Transfer-Encoding, ikke-ASCII-headere kodet etter RFC 2047 og vedlegg på 40 MB. Så kommer API-kvotene, feilen 429 Too Many Requests klokken 03 midt i en batch, og nettverkstidsavbrudd som stopper operasjonen ved melding 11 874.

Og hva så? Hvordan vet du at hver melding er intakt? Uten en tilbakerullingsmekanisme etterlater en feil doble meldinger, tapte vedlegg, brutte samtaletråder og forsvunne etiketter. Redate kontrollerer hver e-post automatisk og beholder originalen innen rekkevidde, nettopp slik at du aldri trenger å gamble på det.

Et siste råd, gratis: behold de opprinnelige Takeout-arkivene til postkassen er godkjent. Mbox-filen er fortsatt referansekopien, selv når målkontoen ser riktig ut.

Guider for klienten du brukte

Avhengig av hvilken klient du brukte til kopieringen, beskriver disse guidene det konkrete tilfellet: rett datoer etter en IMAP-kopiering gjort i Thunderbird og det samme tilfellet i Apple Mail.

Er Takeout allerede kopiert til IMAP-kontoen, og datoene er feil? Start den gratis skanningen fra Redate for å se hvor mange e-poster det gjelder, og rett dem opp med en engangsbetaling, uten grense for størrelsen på postkassen.