Takeout mbox geïmporteerd: alle e-mails van vandaag

U hebt uw Google Takeout-archief geopend, het mbox-bestand met ImportExportTools NG in Thunderbird geïmporteerd (of in Apple Mail) en de mappen vervolgens naar uw nieuwe IMAP-account gesleept. In het programma stonden de e-mails netjes per jaar gesorteerd. Op het doelaccount hebben ze allemaal de datum van vandaag. Dit artikel legt uit wat er gebeurt bij een geïmporteerde Takeout mbox, waarom de getoonde datum die van de kopie is, hoe u dat in een paar minuten bevestigt en hoe u het aan de serverkant corrigeert.

Eerst het belangrijkste: uw e-mails zijn niet beschadigd. De oorspronkelijke datum zit nog gewoon in het bericht. Het doelaccount zet die alleen niet meer voorop.

Het typische scenario van een geïmporteerde Takeout mbox

U hebt zojuist een persoonlijk Gmail-account opgeheven dat vijftien jaar oud was. U vroeg de export aan op takeout.google.com, wachtte op het bericht van Google (twee dagen voor een grote mailbox) en downloadde vier zipbestanden. In elk daarvan zit een .mbox-bestand per label. U importeert ze in Thunderbird: de lokale map vult zich, de sortering op datum is onberispelijk, 2009 helemaal onderaan, gisteren bovenaan.

Dan doet u wat iedereen zou doen. U selecteert de mappen en sleept ze naar het IMAP-account van bestemming, een Microsoft 365, een hostingprovider of een Google Workspace. De overdracht duurt een hele avond. Maandagochtend opent u de webmail.

Het probleem? Alle 18.400 e-mails staan op het weekend, verspreid over een paar uur. Een contract uit 2014 staat naast een nieuwsbrief van vorige week en niemand vindt nog iets terug in chronologische volgorde.

Het geval lijkt sterk op dat van oude e-mails die allemaal dezelfde datum hebben, met een groot verschil: hier is geen enkele migratietool in het spel. Slepen is genoeg.

Drie datums in één e-mail

Om het te begrijpen moet u ophouden te praten over "de datum" van een e-mail. Een bericht dat uit een mbox-bestand wordt geïmporteerd, draagt er minstens drie, en ze dienen niet allemaal hetzelfde doel.

De Date-header: die van de afzender

Dit is de Date:-header uit RFC 2822 (overgenomen in RFC 5322). Het programma van de afzender schrijft hem op het moment van verzending, bijvoorbeeld Date: Tue, 14 Mar 2017 09:12:45 +0100. Hij hoort bij het bericht, reist met het bericht mee en Takeout bewaart hem ongewijzigd. Precies omdat hij intact blijft, is een correctie mogelijk.

De From-regel van het mbox-bestand: een decorstuk

In een mbox-bestand wordt elk bericht voorafgegaan door een regel die begint met From (met een spatie erachter, zonder dubbele punt). Dat is geen header: het is een scheidingsteken dat bij het bestandsformaat hoort en geen deel uitmaakt van het bericht. Geen enkele serieuze tool zou hierop moeten vertrouwen om een e-mail te dateren.

De INTERNALDATE: de datum van plaatsing op de server

De derde datum is de meest onopvallende: de INTERNALDATE, gedefinieerd in RFC 3501. Het is een attribuut dat de IMAP-server naast het bericht bewaart (niet erin) en dat overeenkomt met het moment waarop het bericht in de mailbox is geplaatst. Outlook, webmail en telefoons gebruiken hem om de ontvangstdatum te tonen en op te sorteren. Voor de details van het mechanisme gaat het artikel over INTERNALDATE en verkeerde datums in IMAP dieper in.

Een kanttekening over de Received:-headers, die hier vaak ten onrechte worden aangewezen. De Received-regels van een geëxporteerde Gmail-e-mail vertellen de echte route van het bericht in 2017: ze bevatten oude, legitieme datums. In dit geval zit de foute datum dus niet in het bericht, maar in de metadata die de server aan de kopie toekent.

Waarom het doelaccount de datum van de kopie toont

Wanneer een programma een bericht op een IMAP-server plaatst, gebruikt het de opdracht APPEND. Die opdracht accepteert optioneel een datum die het bericht meekrijgt. Geeft het programma die mee, dan bewaart de server hem als INTERNALDATE. Zo niet, dan past de server de regel uit RFC 3501 toe: de datum en tijd van dat moment. Met andere woorden: de getoonde datum hangt af van hoe de tool de e-mail heeft geschreven. Een tool die de oorspronkelijke datum niet doorgeeft, krijgt de datum van de kopie.

Het gevolg: terwijl u uw mappen versleept, krijgt elk bericht de datum van zijn eigen plaatsing. Een map van 3.000 e-mails die in 40 minuten wordt gekopieerd, valt binnen een venster van 40 minuten.

En de lokale map van Thunderbird dan? Die zag er perfect uit omdat Thunderbird daar op de Date-header sorteert en niet op een serverdatum, want een lokale map heeft geen server. Apple Mail gedraagt zich met geïmporteerde mailboxen vergelijkbaar: alles ziet er goed uit zolang de berichten op de Mac blijven. De waarheid komt boven zodra een ander programma, Outlook bijvoorbeeld, de IMAP-mailbox uitleest.

Eigenlijk is het niet helemaal juist om te zeggen dat alle programma's het elke keer fout doen. Sommige versies geven de datum wel door, andere niet, en het gedrag is met updates veranderd. Twee collega's die dezelfde methode volgen, kunnen dus verschillende resultaten krijgen, en dat maakt de diagnose verwarrender dan ze lijkt.

Slepen is geen migratie. Het is een kopie, en een kopie draagt de datum van zijn eigen makingsmoment.

Zo herkent u dit geval in vijf minuten

Voordat u een oplossing zoekt, bevestigt u dat u echt in dit scenario zit en niet in een ander. Vier controles volstaan.

• Vergelijk de twee plekken. De lokale map van Thunderbird (of de geïmporteerde mailbox van Apple Mail) toont juiste datums, het IMAP-account recente datums voor dezelfde berichten.
• Kijk naar de spreiding. In een map van het IMAP-account vallen de ontvangstdatums binnen een paar uur, soms een paar minuten, rond het moment waarop u de mappen hebt verplaatst.
• Open de bron van een bericht. In Thunderbird via Weergave en dan Berichtbron; in Outlook geven de eigenschappen van het bericht de headers. U moet daar een oude Date:-regel vinden terwijl de weergave een recente datum toont.
• Controleer de volgorde. De berichten staan in de volgorde waarin het programma ze heeft gekopieerd, niet in chronologische volgorde.

Zo ziet de vergelijking eruit bij een echt bericht:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (in het bericht, intact)
Datum getoond door het IMAP-account: dag van de kopie   (metadata van de server)

Vertellen die twee regels niet hetzelfde verhaal, dan bent u er. En als de getoonde datums fout zijn maar Date: ook, dan is het een ander, zeldzamer probleem dat buiten dit artikel valt.

(Overigens: als u nog nooit de ruwe headers van een e-mail hebt gelezen, zet dan koffie. Het is niet bepaald strandlectuur.)

Sorteren op verzenddatum: een pleister op de wond

Het eerste reflex is de sortering op verzenddatum te zetten. In Outlook werkt dat ongeveer, op voorwaarde dat u het in elke map en op elk apparaat opnieuw doet. Maar zoeken, meldingen, regels op basis van leeftijd en de weergaven op mobiel blijven de ontvangstdatum gebruiken. Wie op zijn telefoon zoekt naar "de mail van afgelopen september", ziet niets logisch.

Een andere verleidelijke route: de kopie opnieuw uitvoeren. Op een account dat al in gebruik is, levert dat vooral dubbele berichten op naast wat er al staat, met dezelfde foute datums of andere. Een goede honderd mappen later hebt u geen enkele schone mailbox meer.

De correctie aan de serverkant

Het goede nieuws is dat de oorspronkelijke datum er nog is. De correctie zorgt ervoor dat het doelaccount hem toont, zonder de inhoud van uw berichten aan te raken.

Dat is wat Redate doet. De service maakt verbinding met de mailbox (Google Workspace via domeinbrede delegatie, Microsoft 365, Outlook.com en Hotmail met het Microsoft-account van elke persoon, of rechtstreeks via IMAP met e-mailadres en wachtwoord). Redate hoeft niet te weten welke tool de schade heeft veroorzaakt: het vindt de e-mails waarvan de getoonde datum niet overeenkomt met hun oorspronkelijke datum, of de oorzaak nu slepen vanuit een Takeout mbox is of iets anders. De gratis scan toont u de omvang van het probleem voordat u iets beslist.

Voor de correctie zelf vertrouwt Redate op een eigen correctie-engine, een analysepijplijn met meerdere fasen die de headerketen van elk bericht onderzoekt en elke e-mail zijn oorspronkelijke datum teruggeeft. Elke gecorrigeerde e-mail wordt daarna afzonderlijk gecontroleerd, met validatie van RFC-conformiteit en behoud van de berichtstructuur. De originelen worden nooit verwijderd: ze blijven in een zichtbare map van uw mailbox staan tot u ze zelf verwijdert.

Waarom zelf knutselen riskant is

Het probleem begrijpen is één ding. 15.000 e-mails corrigeren zonder er één te verliezen is iets anders.

Een script dat op tien testberichten werkt, overleeft een productiemailbox van 30.000 berichten niet. Het stuit op ondertekende S/MIME-e-mails, waarvan de kleinste wijziging de handtekening breekt. Op versleutelde PGP-berichten. Op geneste multipart/alternative-structuren, inconsistente MIME-grenzen, onverwachte Content-Transfer-Encoding, niet-ASCII-headers gecodeerd volgens RFC 2047, bijlagen van 40 MB. Dan komen de API-quota, de fout 429 Too Many Requests om 3 uur 's nachts midden in een batch, de netwerktime-outs die de bewerking afbreken bij bericht 11.874.

En dan? Hoe weet u dat elk bericht intact is? Zonder rollback-mechanisme laat een fout dubbele berichten, verloren bijlagen, gebroken gesprekken en verdwenen labels achter. Redate controleert elke e-mail automatisch en houdt het origineel binnen handbereik, precies zodat u daar nooit op hoeft te gokken.

Nog een laatste, gratis tip: bewaar uw oorspronkelijke Takeout-archieven zolang de mailbox niet is gevalideerd. Het mbox-bestand blijft de referentiekopie, ook als het doelaccount er goed uitziet.

Gidsen voor uw programma

Afhankelijk van het programma waarmee u de kopie hebt gemaakt, beschrijven de volgende gidsen het precieze geval: handmatige IMAP-kopieerdatums in Thunderbird herstellen en hetzelfde geval in Apple Mail.

Staat uw Takeout al op het IMAP-account en zijn de datums fout? Start de gratis scan van Redate om te zien hoeveel e-mails het betreft en corrigeer ze daarna met een eenmalige betaling, zonder limiet op de grootte van de mailbox.