Takeout mbox importeret: alle e-mails har dagens dato

Du har åbnet dit Google Takeout-arkiv, importeret mbox-filen i Thunderbird med ImportExportTools NG (eller i Apple Mail) og derefter trukket mapperne over på din nye IMAP-konto. I klienten lå e-mails pænt sorteret år for år. På destinationskontoen har de alle sammen dagens dato. Denne artikel forklarer, hvad der sker med en importeret Takeout mbox, hvorfor den viste dato er kopiens dato, hvordan du bekræfter det på få minutter, og hvordan du retter det på serversiden.

Det første, du skal vide: dine e-mails er ikke beskadigede. Den oprindelige dato ligger stadig i selve beskeden. Det er bare ikke den, destinationskontoen fremhæver længere.

Det typiske scenarie ved en importeret Takeout mbox

Du har netop lukket en privat Gmail-konto, som du oprettede for femten år siden. Du bad om eksporten på takeout.google.com, ventede på beskeden fra Google (to dage for en stor postkasse) og hentede fire zip-arkiver. I hvert af dem ligger der en .mbox-fil pr. etiket. Du importerer dem i Thunderbird: den lokale mappe fyldes, sorteringen efter dato er upåklagelig, 2009 nederst og i går øverst.

Så gør du det, som alle ville gøre. Du markerer mapperne og trækker dem over på IMAP-kontoen, et Microsoft 365, en webhotel-udbyder eller en Google Workspace. Overførslen kører en hel aften. Mandag morgen åbner du webmailen.

Problemet? Alle 18.400 e-mails er dateret til weekenden, spredt over nogle få timer. En kontrakt fra 2014 ligger side om side med et nyhedsbrev fra sidste uge, og ingen kan længere finde noget i kronologisk rækkefølge.

Sagen ligner meget den med gamle e-mails, der alle har samme dato, men med én stor forskel: her er der intet migreringsværktøj involveret. Træk-og-slip er nok.

Tre datoer i én e-mail

For at forstå det skal du holde op med at tale om "datoen" på en e-mail. En besked, der er importeret fra en mbox-fil, bærer mindst tre, og de bruges til hver sit.

Date-headeren: afsenderens dato

Det er headeren Date:, defineret i RFC 2822 (videreført i RFC 5322). Afsenderens klient skriver den i det øjeblik, mailen sendes, for eksempel Date: Tue, 14 Mar 2017 09:12:45 +0100. Den er en del af beskeden, rejser med den, og Takeout bevarer den uændret. Det er den, der gør en rettelse mulig, fordi den er intakt.

From-linjen i mbox-filen: en kulissedato

I en mbox-fil indledes hver besked af en linje, der begynder med From (med et mellemrum, uden kolon). Det er ikke en header, men en skillelinje, der hører til filformatet og ikke til beskeden. Intet seriøst værktøj bør stole på den til at datere en e-mail.

INTERNALDATE: datoen for afleveringen på serveren

Tredje dato, og den mest diskrete: INTERNALDATE, defineret i RFC 3501. Det er en egenskab, som IMAP-serveren gemmer ved siden af beskeden (ikke inde i den), og den svarer til det tidspunkt, hvor beskeden blev lagt i postkassen. Outlook, webmails og telefoner bruger den til at vise og sortere modtagelsesdatoen. Vil du have mekanismen i detaljer, går artiklen om INTERNALDATE og forkerte datoer i IMAP dybere.

En præcisering om Received:-headerne, som ofte får skylden med urette her. Received-linjerne i en eksporteret Gmail-mail fortæller om beskedens faktiske rute i 2017: de har gamle, legitime datoer. I dette tilfælde bor den forkerte dato altså ikke i beskeden, men i de metadata, serveren giver kopien.

Hvorfor destinationskontoen viser kopiens dato

Når en klient lægger en besked på en IMAP-server, bruger den kommandoen APPEND. Kommandoen kan valgfrit tage en dato, som beskeden skal have. Sender klienten den med, gemmer serveren den som INTERNALDATE. Ellers følger serveren reglen i RFC 3501: tidspunktet lige nu. Med andre ord afhænger den viste dato af, hvordan værktøjet har skrevet e-mailen. Et værktøj, der ikke sender den oprindelige dato med, får kopiens dato.

Resultatet: mens du trækker dine mapper over, får hver besked datoen for sin egen aflevering. En mappe med 3.000 e-mails, der kopieres på 40 minutter, lander i et vindue på 40 minutter.

Og Thunderbirds lokale mappe, så? Den så perfekt ud, fordi Thunderbird sorterer efter Date-headeren og ikke efter en serverdato, for en lokal mappe har ingen server. Apple Mail opfører sig på samme måde med importerede postkasser: alt er fint, så længe beskederne bliver på Macen. Sandheden kommer frem i det øjeblik, et andet program, for eksempel Outlook, læser IMAP-postkassen.

Helt ærligt er det ikke helt rigtigt at sige, at alle klienter tager fejl hver gang. Nogle versioner sender datoen med, andre gør ikke, og adfærden har ændret sig med opdateringerne. Derfor kan to kolleger, der følger den samme fremgangsmåde, få forskellige resultater, og det gør fejlsøgningen mere forvirrende, end den burde være.

Træk-og-slip er ikke en migrering. Det er en kopi, og en kopi bærer datoen for sit eget tilblivelsestidspunkt.

Sådan genkender du problemet på fem minutter

Før du leder efter en løsning, så bekræft, at du faktisk er i dette scenarie og ikke i et andet. Fire kontroller er nok.

• Sammenlign de to steder. Thunderbirds lokale mappe (eller den importerede postkasse i Apple Mail) viser rigtige datoer, mens IMAP-kontoen viser nylige datoer for de samme beskeder.
• Se på spændet. I en mappe på IMAP-kontoen ligger modtagelsesdatoerne inden for nogle få timer, måske endda minutter, omkring det tidspunkt, hvor du flyttede mapperne.
• Åbn kilden til en besked. I Thunderbird: Vis og derefter Beskedkilde. I Outlook giver beskedens egenskaber dig headerne. Du skal kunne finde en gammel Date:-linje, selv om visningen viser en nylig dato.
• Tjek rækkefølgen. Beskederne står i den rækkefølge, klienten kopierede dem i, ikke i kronologisk rækkefølge.

Sådan ser sammenligningen ud på en rigtig besked:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (i beskeden, intakt)
Dato vist af IMAP-kontoen: dagen for kopieringen   (serverens metadata)

Fortæller de to linjer ikke den samme historie, er du der. Og hvis de viste datoer er forkerte, men Date: også er det, er det et andet og sjældnere problem, som ikke hører hjemme i denne artikel.

(Har du aldrig læst rå e-mailheadere, så sæt kaffen over: det er ikke ligefrem strandlæsning.)

Sortering efter afsendelsesdato: et plaster

Refleksen er at skifte sorteringen til afsendelsesdato. I Outlook virker det nogenlunde, hvis du gør det igen i hver mappe og på hver enhed. Men søgning, notifikationer, regler baseret på alder og visningerne på mobilen bruger fortsat modtagelsesdatoen. En bruger, der leder efter "mailen fra sidste september" på sin telefon, ser ikke noget logisk.

Et andet fristende spor er at starte kopieringen forfra. På en konto, der allerede er i brug, giver det mest dubletter ved siden af de beskeder, der allerede er der, med de samme forkerte datoer eller nye. Et par hundrede mapper senere har du ikke længere en eneste ren postkasse.

Rettelsen på serversiden

Den gode nyhed er, at den oprindelige dato stadig er der. Rettelsen går ud på at få destinationskontoen til at vise den, uden at røre ved indholdet af dine beskeder.

Det er det, Redate gør. Tjenesten forbinder til postkassen (Google Workspace via domænedelegering, Microsoft 365, Outlook.com og Hotmail med hver persons Microsoft-konto eller direkte IMAP med adresse og adgangskode). Redate behøver ikke vide, hvilket værktøj der har skabt problemet: det finder de e-mails, hvis viste dato ikke svarer til deres oprindelige dato, uanset om årsagen er træk-og-slip fra en Takeout mbox eller noget helt andet. Den gratis scanning af postkassen viser dig omfanget af problemet, før du tager nogen beslutning.

Selve rettelsen sker med en proprietær rettemotor, en analysepipeline i flere trin, der undersøger headerkæden i hver enkelt besked og giver hver e-mail sin oprindelige dato tilbage. Hver rettet e-mail bliver derefter kontrolleret individuelt, med validering af RFC-overholdelse og bevarelse af beskedens struktur. Originalerne slettes aldrig: de ligger i en synlig mappe i din postkasse, indtil du selv sletter dem.

Hvorfor det er risikabelt at gøre det selv

At forstå problemet er én ting. At rette det på 15.000 e-mails uden at miste en eneste er noget helt andet.

Et script, der virker på ti testbeskeder, overlever ikke en produktionspostkasse med 30.000 beskeder. Det støder på signerede S/MIME-mails, hvor den mindste ændring ødelægger signaturen. På krypterede PGP-beskeder. På indlejrede multipart/alternative-strukturer, inkonsistente MIME-grænser, uventede Content-Transfer-Encoding-værdier, ikke-ASCII-headere kodet efter RFC 2047 og vedhæftede filer på 40 MB. Så kommer API-kvoterne, fejlen 429 Too Many Requests klokken 03 om natten midt i en batch, og netværkstimeouts, der afbryder kørslen ved besked 11.874.

Og hvad så? Hvordan ved du, at hver besked er intakt? Uden en rollback-mekanisme efterlader en fejl dubletter, tabte vedhæftede filer, brudte samtaletråde og forsvundne etiketter. Redate kontrollerer hver e-mail automatisk og har originalen inden for rækkevidde, netop så du aldrig behøver at gamble med det.

Et sidste råd, gratis: behold dine oprindelige Takeout-arkiver, indtil postkassen er valideret. Mbox-filen er stadig referencekopien, også når destinationskontoen ser rigtig ud.

Guides til din klient

Afhængigt af hvilken klient du brugte til kopieringen, beskriver disse guides det præcise tilfælde: ret datoer efter en manuel IMAP-kopiering i Thunderbird og det samme tilfælde i Apple Mail.

Er dit Takeout allerede kopieret til IMAP-kontoen, og er datoerne forkerte? Start Redates gratis scanning for at se, hvor mange e-mails der er berørt, og ret dem derefter med en engangsbetaling, uden grænse for postkassens størrelse.