Alle oude e-mails hebben dezelfde datum: wat is er aan de hand?

Het symptoom: al uw oude e-mails gegroepeerd op dezelfde datum

U opent Outlook, Gmail of Apple Mail op een ochtend. Er klopt iets niet. Honderden, soms duizenden oude e-mails tonen allemaal dezelfde datum: die van een paar dagen geleden, of een paar weken terug. Berichten uit 2021, 2019, 2016 verschijnen alsof ze gisteren zijn ontvangen. Sorteren op datum heeft geen betekenis meer. U zoekt een belangrijk bericht van vorig jaar, en het verdwijnt in een blok van duizenden berichten die allemaal van dezelfde dag lijken te zijn.

Nieuwe e-mails tonen wel de juiste datum. Alleen de oude berichten zijn getroffen.

Wat is er eigenlijk gebeurd?

De eerste reactie: de software de schuld geven

Het is logisch dat u aan een bug denkt. Outlook dat is gecrasht. Een update die mis is gegaan. Een beschadigd bestand. En dan begint vaak een vervelende zoektocht: u zoekt op "bug datum Outlook", belandt op forums die praten over OST-bestanden, SCANPST.exe, het opnieuw aanmaken van uw Outlook-profiel vanaf nul...

U bent twee uur bezig met het opnieuw proberen van alles. Het probleem blijft.

SCANPST is overigens een hersteltool voor lokale Outlook-gegevensbestanden. Het kan bepaalde bestandscorrupties verhelpen, maar raakt de gegevens op de mailserver niet aan. Zelfs als u uw OST-bestand perfect repareert, blijven de datums fout, want het probleem zit niet bij u.

Het probleem zit in de e-mails zelf, op de server.

Wat er echt is gebeurd: een migratie

In vrijwel alle gevallen verschijnt dit symptoom na een e-mailmigratie. Uw bedrijf is overgestapt van een oud systeem naar Google Workspace, Microsoft 365 of een nieuwe server. Iemand heeft ergens een tool gebruikt om al uw e-mails van de ene naar de andere plek te verplaatsen.

Misschien bent u er niet van op de hoogte gesteld. Of u wist het wel, maar legde geen verband met het datumsproблeem. Dat is heel begrijpelijk.

Migratieprogramma's doen veel werk: ze kopiëren duizenden berichten, complete mappen, bijlagen. Maar ze hebben een vrij verraderlijk neveneffect. Wanneer een e-mail van de ene server naar de andere wordt overgebracht, voegt de tool een kleine technische regel toe aan de e-mail, een zogenaamde "Received:"-header, die aangeeft wanneer het bericht op de nieuwe server is aangekomen. Dat wil zeggen: de datum van de migratie.

En daar zit het probleem.

Hoe uw e-mailprogramma bepaalt welke datum te tonen

Een e-mail bevat in werkelijkheid meerdere verschillende datums, verborgen in de technische gegevens. Er is de originele verzenddatum (die u normaal ziet), maar ook "Received:"-headers die elke stap van het traject van het bericht over het internet vastleggen.

(Als u ooit op "Bron weergeven" of "Volledige headers bekijken" van een e-mail hebt geklikt, hebt u misschien die cryptische regels gezien die eruitzien als een onbegrijpelijk blok tekst. Dat is precies wat dit is.)

Normaal gesproken kijkt uw e-mailprogramma naar de meest recente "Received:"-header om te bepalen wanneer de e-mail wordt weergegeven. Die logica werkt prima: de laatste "Received:" correspondeert altijd met de aankomst van het bericht in uw inbox, seconden na het verzenden.

Maar na een migratie keert deze logica zich tegen u. De migratietool heeft bovenaan een nieuwe "Received:"-header toegevoegd met de datum van de overdracht. Uw e-mailprogramma leest deze header als eerste, ziet de migratiedatum, en toont die. De originele verzenddatum is er nog steeds, intact, dieper begraven in de gegevens van de e-mail. Maar uw programma ziet hem niet, omdat het bij de eerste header stopt.

Resultaat: 8.000 e-mails die allemaal lijken te zijn aangekomen op dezelfde dinsdag in november.

Welke tools veroorzaken dit probleem?

De meestgebruikte migratieprogramma's vertonen allemaal dit gedrag. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (de gratis Google-tool om vanuit Outlook te migreren) en vele anderen. Het is niet echt een fout van hun kant: het is een gevolg van de technische werking van het e-mailprotocol. Deze tools voegen die header toe omdat het protocol dat voorschrijft wanneer een bericht van de ene naar de andere server wordt doorgezet.

Het probleem is dat niemand de gebruikers waarschuwt dat dit gaat gebeuren.

Als uw bedrijf onlangs van e-mailsysteem is gewisseld, of als uw IT-afdeling een "migratie naar de cloud" heeft uitgevoerd, is dat hoogstwaarschijnlijk de oorzaak. U kunt dit controleren door de getroffen datums te bekijken: vallen ze allemaal ruwweg in dezelfde periode? Dan is die periode die van de migratie.

De doodlopende wegen die u kunt vermijden

Een paar oplossingen die u vaak op forums tegenkomt, maar die niet werken:

Het gegevensbestand herstellen met SCANPST

Zoals eerder vermeld: SCANPST herstelt lokale Outlook-bestanden (de .pst- of .ost-bestanden op uw computer). Het wijzigt geen e-mails op de server. Na de reparatie heeft u nog steeds dezelfde foute datums, want die zitten in de e-mails zelf, niet in het lokale bestand.

Het Outlook-profiel opnieuw aanmaken

Dezelfde redenering. Een Outlook-profiel opnieuw aanmaken is lokaal met een schone lei beginnen, om vervolgens al uw e-mails opnieuw van de server te downloaden. De opnieuw gedownloade berichten hebben precies dezelfde foute datums als voorheen. U hebt alleen tijd verspild aan het opnieuw instellen van alles.

Sorteren op "verzenddatum" in plaats van "ontvangstdatum"

Sommige forums suggereren het sorteercriterium in Outlook te wijzigen, van ontvangstdatum naar verzenddatum. Dat kan in sommige gevallen helpen... maar niet altijd. En het lost niets op voor andere apparaten, andere programma's of andere personen die toegang hebben tot uw mailbox. De onderliggende oorzaak blijft aanwezig. Sorteren op verzenddatum is geen oplossing, het is een doekje voor het bloeden.

Het e-mailprogramma opnieuw installeren

Nee. De e-mails staan op de server, niet in het programma. Outlook, Gmail, Apple Mail of Thunderbird opnieuw installeren verandert niets aan de online opgeslagen gegevens.

Het goede nieuws: de echte datums zijn er nog

Dit is iets belangrijks om te begrijpen, en wat correctie mogelijk maakt: de originele verzenddatum van elke e-mail is niet gewist. Die is er nog steeds, in de e-mail, in een header genaamd "Date:" die de verzenddatum bevat zoals de afzender die heeft ingesteld. Dit is een e-mailstandaard (vastgelegd in een technische specificatie genaamd RFC 2822) die alle migratieprogramma's respecteren, want die wijzigen zou een ernstige schending van de standaarden zijn.

Als u op 14 maart 2022 een e-mail heeft ontvangen, bevat dat bericht die datum nog steeds ergens in de gegevens. Uw programma toont hem alleen niet als eerste.

Dat is precies waarom correctie mogelijk is. Het probleem is geen gegevensverlies. Het is een kwestie van het lezen van de metagegevens: uw e-mailprogramma leest de verkeerde datum, terwijl de juiste datum er nog steeds is.

Waarom dit zelf proberen te corrigeren riskant is

U vraagt zich misschien af of een IT-er gewoon een script kan schrijven om het probleem op te lossen. Begrijpen wat er aan de hand is, is één ding. Het netjes corrigeren op duizenden e-mails zonder er één te verliezen, is een heel ander verhaal.

Een e-mail is geen eenvoudig tekstbestand. Het kan bijlagen bevatten, digitale handtekeningen, inhoud die is gecodeerd in complexe formaten. De metagegevens van zo'n bericht aanpassen zonder de structuur te beschadigen vereist het afhandelen van tientallen bijzondere gevallen: elektronisch ondertekende berichten (S/MIME), versleutelde e-mails (PGP), niet-standaard coderingen, meerdelige structuren... Een zelfgemaakt script dat werkt op 20 testmails, zal hoogstwaarschijnlijk niet correct werken op een productiemailbox van 15.000 berichten. En als er iets misgaat, hoe stelt u dan vast dat geen enkel bericht beschadigd of verloren is gegaan? Met een zelfgemaakt script: onmogelijk.

Zonder een mechanisme voor back-up en individuele verificatie per e-mail is het risico op schade reëel.

Wat Redate.io doet

Redate.io is een dienst die specifiek voor dit probleem is ontwikkeld. Het maakt verbinding met uw mailbox (Google Workspace, Microsoft 365 of een IMAP-server), identificeert de e-mails waarvan de datums door een migratie zijn aangetast, en corrigeert ze via een eigen correctie-engine die de volledige headerketen analyseert en de datummetagegevens per bericht reconstrueert.

Elk gecorrigeerd bericht wordt individueel geverifieerd. De originelen worden 30 dagen bewaard in een zichtbare back-upmap. Gaat er iets mis, dan kunt u terugdraaien.

De eerste scan is gratis: Redate.io analyseert uw mailbox en laat u precies zien hoeveel e-mails zijn getroffen, voordat u ook maar iets beslist. Geen verrassingen.

De prijsstelling is een eenmalige betaling, gebaseerd op het volume e-mails dat gecorrigeerd moet worden. Geen abonnement. U betaalt eenmalig, het probleem is opgelost.

Wilt u de omvang van het probleem zien voordat u zich ergens aan verbindt? Start een gratis scan van uw mailbox op Redate.io en ontdek binnen enkele minuten hoeveel e-mails zijn getroffen.