Takeout mbox: alla e-postmeddelanden har dagens datum

Du har öppnat ditt Google Takeout-arkiv, importerat mbox-filen i Thunderbird med ImportExportTools NG (eller i Apple Mail) och sedan dragit mapparna till ditt nya IMAP-konto. I programmet låg e-postmeddelandena ordnade år för år. På målkontot har alla dagens datum. Den här artikeln förklarar vad som händer med en importerad Takeout mbox, varför datumet som visas är kopians, hur du bekräftar det på några minuter och hur du fixar det på serversidan.

Först det viktigaste: dina e-postmeddelanden är inte skadade. Det ursprungliga datumet finns kvar i meddelandet. Det är bara inte längre det som målkontot visar.

Det typiska scenariot med en importerad Takeout mbox

Du har precis stängt ett privat Gmail-konto som du öppnade för femton år sedan. Du begärde exporten på takeout.google.com, väntade på meddelandet från Google (två dagar för en stor brevlåda) och laddade ner fyra zip-arkiv. I vart och ett ligger en .mbox-fil per etikett. Du importerar dem i Thunderbird: den lokala mappen fylls på, sorteringen på datum är felfri, 2009 längst ner, igår högst upp.

Sen gör du som alla skulle göra. Du markerar mapparna och drar dem till IMAP-kontot där de ska hamna, ett Microsoft 365, ett webbhotell eller ett Google Workspace. Överföringen tar en hel kväll. På måndag morgon öppnar du webbmejlen.

Problemet? Alla 18 400 e-postmeddelanden är daterade till helgen, inom ett tidsintevall på några timmar. Ett kontrakt från 2014 hamnar bredvid ett nyhetsbrev från förra veckan, och ingen hittar längre något i kronologisk ordning.

Fallet liknar det med gamla e-postmeddelanden som alla har samma datum, men med en stor skillnad: här är inget migreringsverktyg inblandat. Det räcker med dra och släpp.

Tre datum i ett enda e-postmeddelande

För att förstå det måste du sluta prata om "datumet" för ett e-postmeddelande. Ett meddelande som importerats från en mbox-fil bär minst tre, och de används till olika saker.

Date-headern: avsändarens datum

Det är headern Date: som definieras i RFC 2822 (övertagen av RFC 5322). Avsändarens klient skriver den när mejlet skickas, till exempel Date: Tue, 14 Mar 2017 09:12:45 +0100. Den är en del av meddelandet, följer med det, och Takeout bevarar den orörd. Det är den som gör det möjligt att fixa datumen, eftersom den är intakt.

From-raden i mbox-filen: ett skendatum

I en mbox-fil föregås varje meddelande av en rad som börjar med From (med ett mellanslag, utan kolon). Det är ingen header: det är en avgränsare som hör till filformatet och inte till meddelandet. Inget seriöst verktyg bör lita på det för att datera ett e-postmeddelande.

INTERNALDATE: datumet då meddelandet lades in på servern

Det tredje datumet är det mest undanskymda: INTERNALDATE, som definieras i RFC 3501. Det är ett attribut som IMAP-servern lagrar bredvid meddelandet (inte i det) och som motsvarar tidpunkten då meddelandet lades in i brevlådan. Outlook, webbmejl och mobiler använder det för att visa och sortera ankomstdatum. Vill du ha mekanismen i detalj går artikeln om INTERNALDATE och felaktiga datum i IMAP djupare.

Ett förtydligande om Received:-headers, som ofta felaktigt får skulden här. Received-raderna i ett exporterat Gmail-mejl berättar vilken väg meddelandet verkligen tog 2017: de har gamla, korrekta datum. Här finns alltså det felaktiga datumet inte i meddelandet, utan i de metadata som servern ger kopian.

Därför visar målkontot kopians datum

När en klient lägger in ett meddelande på en IMAP-server använder den kommandot APPEND. Kommandot kan, som ett tillval, få med ett datum som meddelandet ska ha. Om klienten skickar med det behåller servern det som INTERNALDATE. Annars tillämpar servern regeln i RFC 3501: den aktuella tidpunkten. Det datum som visas beror alltså på hur verktyget skrev in e-postmeddelandet. Ett verktyg som inte skickar med det ursprungliga datumet får kopians datum.

Följden: medan du drar dina mappar får varje meddelande datumet för sin egen inläggning. En mapp med 3 000 e-postmeddelanden som kopieras på 40 minuter hamnar i ett fönster på 40 minuter.

Och Thunderbirds lokala mapp då? Den såg perfekt ut eftersom Thunderbird sorterar på Date-headern och inte på ett serverdatum, för en lokal mapp har ingen server. Apple Mail beter sig på liknande sätt med importerade brevlådor: allt ser bra ut så länge meddelandena ligger kvar på Macen. Sanningen kommer fram när ett annat program, till exempel Outlook, läser IMAP-brevlådan.

För att vara exakt är det inte helt rätt att säga att alla klienter gör fel varje gång. Vissa versioner skickar med datumet, andra inte, och beteendet har ändrats med uppdateringarna. Två kollegor som följer samma metod kan därför få olika resultat, vilket gör felsökningen mer förvirrande än man tror.

Att dra och släppa är ingen migrering. Det är en kopiering, och en kopia bär datumet för när den gjordes.

Så känner du igen fallet på fem minuter

Innan du letar efter en lösning bör du bekräfta att det verkligen är det här scenariot och inget annat. Fyra kontroller räcker.

• Jämför de två platserna. Thunderbirds lokala mapp (eller den importerade brevlådan i Apple Mail) visar rätt datum, IMAP-kontot visar nyliga datum för samma meddelanden.
• Titta på spannet. I en mapp på IMAP-kontot ryms ankomstdatumen inom några timmar, ibland några minuter, kring tillfället då du flyttade mapparna.
• Öppna källan till ett meddelande. I Thunderbird via Visa och sedan meddelandets källa, i Outlook via meddelandets egenskaper som visar headers. Där ska du hitta en gammal Date:-rad medan visningen anger ett nytt datum.
• Kontrollera ordningen. Meddelandena visas i den ordning klienten kopierade dem, inte i kronologisk ordning.

Så här ser jämförelsen ut för ett verkligt meddelande:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (i meddelandet, intakt)
Datum som IMAP-kontot visar: dagen för kopieringen   (metadata på servern)

Om de två raderna inte berättar samma historia har du hittat felet. Och om de visade datumen är fel men Date: också är det, är det ett annat och ovanligare problem som den här artikeln inte tar upp.

(Förresten, om du aldrig har läst råa headers i ett e-postmeddelande, ta med en kaffe: det är inte direkt strandläsning.)

Sortera på avsändningsdatum: ett plåster

Reflexen är att byta sortering till avsändningsdatum. I Outlook fungerar det hyfsat, om du gör om det i varje mapp och på varje enhet. Men sökning, aviseringar, regler baserade på ålder och vyerna i mobilen fortsätter att använda ankomstdatumet. Den som söker efter "mejlet från i september" i telefonen ser inget logiskt.

En annan frestande väg är att göra om kopieringen. På ett konto som redan används ger det mest dubbletter bredvid meddelandena som redan finns, med samma felaktiga datum eller andra. Ett hundratal mappar senare har du inte en enda ren brevlåda kvar.

Att fixa datumen på serversidan

Den goda nyheten är att det ursprungliga datumet fortfarande finns kvar. Det gäller att få målkontot att visa det, utan att röra innehållet i dina meddelanden.

Det är vad Redate gör. Tjänsten ansluter till brevlådan (Google Workspace via domändelegering, Microsoft 365, Outlook.com och Hotmail med varje persons Microsoft-konto, eller direkt IMAP med adress och lösenord). Redate behöver inte veta vilket verktyg som orsakade skadan: Redate hittar de e-postmeddelanden vars visade datum inte stämmer med deras ursprungliga datum, oavsett om orsaken är dra och släpp från en Takeout mbox eller något annat. Den gratis skanningen av brevlådan visar hur stort problemet är innan du fattar något beslut.

För själva fixen använder Redate en egenutvecklad motor, en analyskedja i flera steg som går igenom headerkedjan i varje meddelande och ger varje e-postmeddelande tillbaka sitt ursprungliga datum. Varje fixat e-postmeddelande verifieras sedan för sig, med RFC-validering och bevarad meddelandestruktur. Originalen tas aldrig bort: de ligger kvar i en synlig mapp i din brevlåda tills du själv tar bort dem.

Därför är det riskabelt att pilla själv

Att förstå problemet är en sak. Att fixa 15 000 e-postmeddelanden utan att förlora ett enda är en annan.

Ett skript som fungerar på tio testmeddelanden klarar inte en produktionsbrevlåda med 30 000 meddelanden. Det stöter på signerade S/MIME-mejl, där minsta ändring bryter signaturen. På krypterade PGP-meddelanden. På nästlade multipart/alternative-strukturer, inkonsekventa MIME-gränser, oväntade Content-Transfer-Encoding, icke-ASCII-headers kodade enligt RFC 2047 och bilagor på 40 MB. Sen kommer API-kvoterna, felet 429 Too Many Requests klockan 03 på natten mitt i en batch, och nätverkstimeouts som avbryter jobbet vid meddelande 11 874.

Och därefter? Hur vet du att varje meddelande är intakt? Utan återställningsmekanism (rollback) lämnar ett fel efter sig dubbletter, försvunna bilagor, trasiga konversationstrådar och borttappade etiketter. Redate kontrollerar varje e-postmeddelande automatiskt och håller originalet nära till hands, just för att du aldrig ska behöva chansa på det.

Ett sista råd, gratis: behåll dina ursprungliga Takeout-arkiv tills brevlådan är godkänd. Mbox-filen är fortfarande referenskopian, även när målkontot ser rätt ut.

Guider för just din klient

Beroende på vilken klient du använde för kopieringen beskriver följande guider det exakta fallet: fixa datumen efter en IMAP-kopiering i Thunderbird och samma fall i Apple Mail.

Är din Takeout redan kopierad till IMAP-kontot och datumen fel? Starta Redates gratis skanning av brevlådan för att se hur många e-postmeddelanden det gäller, och fixa dem sedan mot engångsbetalning, utan gräns för brevlådans storlek.