eM Client: verkeerde datums na PST- of Thunderbird-import

Het symptoom: alle e-mails hebben dezelfde datum

U heeft zojuist een PST-import afgerond in eM Client, of u bent vanuit Thunderbird overgestapt naar uw nieuwe mailbox. De import verliep zonder zichtbare fouten. Maar als u uw postvak opent, klopt er iets niet: honderden, soms duizenden e-mails tonen allemaal dezelfde datum, die van de dag van de import. Een e-mail uit 2019 lijkt gisteren ontvangen. Een contract dat drie jaar geleden werd ondertekend, ziet eruit alsof het net is binnengekomen.

De eerste reactie is om eM Client de schuld te geven. Verkeerde instelling, verkeerde sorteerkolom, weergavefout... U zoekt in de voorkeuren. U schakelt tussen "Ontvangstdatum" en "Verzenddatum". Niets verandert. Of liever gezegd, er verandert wel iets, maar het lost het echte probleem niet op.

Dat komt omdat het probleem niet in eM Client zit. Het zit in de metadata op de server.

De echte oorzaak: INTERNALDATE overschreven tijdens import

Om te begrijpen wat er gebeurt, moet u een niveau dieper kijken en zien hoe het IMAP-protocol e-mails opslaat.

Elk bericht op een IMAP-server heeft twee afzonderlijke soorten datums:

• De Date:-header (vastgelegd in RFC 2822): de datum die de afzender in het bericht heeft opgenomen op het moment van verzending. Die zit ingesloten in de berichttekst en is in principe onaantastbaar.
• De INTERNALDATE: een servermetadatum, los van het bericht zelf, die aangeeft wanneer het bericht in de mailbox is geplaatst. Dit is de waarde die e-mailclients als eerste gebruiken voor het sorteren en weergeven van berichten.

Bij een PST-import of een migratie vanuit Thunderbird plaatst de importtool (of dat nu de ingebouwde module van eM Client is, een extern hulpmiddel, of een handmatige IMAP-kopie) de berichten op de doel-IMAP-server. En als die tool de originele INTERNALDATE niet expliciet bewaart op het moment van plaatsing, kent de server automatisch de actuele INTERNALDATE toe, dat wil zeggen de datum en tijd van de import.

Resultaat: 8.000 gearchiveerde e-mails uit 2017, allemaal gestempeld als "ontvangen" op het moment van uw migratie.

(Trouwens, als u ooit de ruwe headers van een e-mail heeft bekeken via Bron weergeven in eM Client, heeft u kunnen zien dat de originele Date:-header er nog steeds is, ongewijzigd. Dat is het teken dat het probleem bij de INTERNALDATE op de server ligt, niet bij het bericht zelf.)

Waarom van sorteerkolom wisselen niets oplost

De verwarring ontstaat door een onderscheid dat weinig mensen kennen. In eM Client, net als in Outlook of Thunderbird, zijn er doorgaans twee datumkolommen:

• "Ontvangstdatum" (of "Datum van aankomst"): gebaseerd op de INTERNALDATE van de server.
• "Datum" of "Verzenddatum": gebaseerd op de Date:-header van het bericht.

Veel beheerders ontdekken dit en denken de oplossing gevonden te hebben: overschakelen op "Verzenddatum", en het probleem verdwijnt visueel in eM Client. Maar dat klopt niet helemaal.

Eigenlijk is dit wat er echt speelt: zelfs als u in eM Client op verzenddatum sorteert, blijft het probleem bestaan voor alle andere clients en interfaces die toegang hebben tot dezelfde mailbox. Als uw gebruikers hun e-mails raadplegen via OWA, via Outlook op kantoor, via de Gmail-app op een telefoon, of via welke IMAP-client dan ook, zien zij de importdatums. De sorteerinstelling van eM Client geldt alleen voor eM Client en heeft geen effect op de metadata die aan de serverkant zijn opgeslagen.

Bovendien sorteert de native webweergave in Microsoft 365 en Google Workspace op INTERNALDATE. Dat gedrag kunt u niet aanpassen vanuit de client.

Sorteren op verzenddatum is geen oplossing. Het is een pleister die een echt probleem maskeert zonder het te verhelpen.

Het bijzondere geval van PST-import

PST-bestanden verdienen een aparte paragraaf. Een PST-bestand (Personal Storage Table) is een eigen Microsoft-formaat dat e-mails, contacten en agenda-items lokaal opslaat. Wanneer u een PST importeert in eM Client, zijn er twee scenario's:

• Lokale import naar een IMAP-account: eM Client leest het PST-bestand en plaatst de berichten op de doel-IMAP-server. Als de plaatsingsdatum niet wordt bewaard, wordt de INTERNALDATE overschreven. Dit is het meest voorkomende geval, en hier raken de datums beschadigd.
• Import naar een lokale map: de berichten blijven op de machine, buiten de server. De INTERNALDATE bestaat in die context niet, en eM Client kan de Date:-header van het bericht weergeven. Minder datumproblemen hier, maar ook minder praktisch nut.

Voor Thunderbird is de situatie vergelijkbaar. Of u nu de ingebouwde importfunctie van eM Client gebruikt (die Thunderbird-profielen leest), of dat u mbox-mappen via IMAP heeft gekopieerd: de berichten worden opnieuw op de server geplaatst zonder garantie dat de INTERNALDATE bewaard blijft. En een server die een bericht ontvangt zonder expliciete datuminstructie voor de INTERNALDATE, stempelt dat bericht altijd met het tijdstip van ontvangst.

Welke platforms zijn getroffen?

Het probleem is identiek ongeacht het doelplatform, omdat het om standaardgedrag van het IMAP-protocol gaat:

• Microsoft 365 / Exchange Online: de INTERNALDATE wordt overschreven bij elke import die geen IMAP APPEND-opdracht gebruikt met een expliciete datumparameter. Hetzelfde geldt voor een migratie vanuit Exchange on-premises.
• Google Workspace: zelfde gedrag. E-mails geïmporteerd via eM Client of externe tools tonen de importdatum in Gmail en in de beheerconsole.
• Klassieke IMAP-providers (OVH, Infomaniak, Ionos, o2switch, enzovoort): geen speciale datumverwerking bij ontvangst van een APPEND-bericht. De INTERNALDATE is de datum van plaatsing.

Een klant nam contact op na het migreren van ruim honderd mailboxen van Exchange 2013 naar Microsoft 365, waarbij eM Client als overgangsoplossing werd gebruikt voor bepaalde VIP-accounts. De mailboxen die netjes via MigrationWiz waren gemigreerd, waren correct, maar de mailboxen die via eM Client waren gegaan, hadden allemaal importdatums. De betrokken gebruikers waardeerden dat bepaald niet.

Waarom een zelfgemaakt script dit niet makkelijk oplost

Technisch gezien zou iemand die het IMAP-protocol begrijpt kunnen denken aan een script om de INTERNALDATE te corrigeren. De originele Date:-header is er immers nog, intact in elk bericht. Je leest hem uit en reconstrueert de servermetadata op basis daarvan, toch?

In theorie wel. In de praktijk is het een mijnenveld.

Ten eerste stapelen de randgevallen zich snel op in een productieomgeving. Digitaal ondertekende S/MIME-berichten zijn bijzonder gevoelig voor elke structuurwijziging. Hetzelfde geldt voor PGP-versleutelde berichten. E-mails met grote bijlagen, niet-standaard MIME-grenzen, of ongebruikelijke Content-Transfer-Encoding-coderingen kunnen stil beschadigd raken als de verwerking niet rigoureus is. Een script dat werkt op 50 teste-mails, werkt niet betrouwbaar op een mailbox van 20.000 berichten met 6 jaar geschiedenis.

Daarna: het beheer van API-quota. Op Microsoft 365 zijn de snelheidslimieten op de Graph API of op EWS om 3 uur 's nachts bij een correctiebatch van 8.000 berichten beheersbaar. Maar ze beheren zichzelf niet. Een script zonder toezicht dat een 429 Too Many Requests-fout tegenkomt bij bericht nummer 3.741, gaat misschien door, misschien niet. En u weet dan niet precies welke berichten al zijn verwerkt.

En bovenal: hoe controleert u dat elk gecorrigeerd e-mailbericht na verwerking intact is? Een zelfgemaakt script heeft doorgaans geen mechanisme voor individuele verificatie. Redate.io doet dat automatisch, voor elk bericht afzonderlijk.

Datums aan de bron corrigeren met Redate.io

Redate.io pakt het probleem aan daar waar het zich bevindt: op het niveau van de servermetadata, niet op het niveau van de e-mailclient.

Het proces begint met een gratis scanfase. Redate.io verbindt zich met de betreffende mailbox (Microsoft 365 via Azure AD, Google Workspace via domeindelegatie, of directe IMAP voor klassieke providers) en identificeert de e-mails waarvan de datummetadata niet overeenkomen met de inhoud van het bericht. U ziet het resultaat voordat u iets betaalt.

De correctie maakt gebruik van een eigen correctie-engine die de volledige headerketen van elk bericht analyseert, patroonherkenning toepast op honderden handtekeningen van bekende importtools (inclusief het specifieke gedrag van eM Client, Thunderbird en PST-imports), en de datummetadata gericht reconstrueert zonder de inhoud van het bericht, de bijlagen of de MIME-structuur te wijzigen.

Elk gecorrigeerd e-mailbericht wordt individueel geverifieerd. De originelen worden 30 dagen bewaard in een zichtbare back-upmap, iets wat een zelfgemaakt script standaard nooit doet.

De tarieven zijn eenvoudig: eenmalige betaling per mailbox, gebaseerd op het volume te corrigeren e-mails. Geen abonnement, geen terugkerende kosten. Bekijk de startpagina voor de details.

Voor de volgende migratie: wat u moet controleren

Als u een migratie plant en dit probleem vooraf wilt vermijden, is het controlepunt eenvoudig: bewaart de tool die u gebruikt de INTERNALDATE expliciet bij het plaatsen van berichten op de doelserver?

Voor PST-imports naar Microsoft 365 verwerken gecertificeerde Microsoft-tools (zoals MigrationWiz in de native modus, of de Exchange Online-migratietool) dit doorgaans correct. Voor handmatige imports via eM Client of Thunderbird is dat zelden het geval. Controleer de documentatie van uw tool voordat u een import start op productieomgevingen.

Een goede checklist voor e-mailmigraties bevat altijd een post-migratieverificatie van de datums op een steekproef van mailboxen. Als u dieper wilt gaan, behandelt de checklist e-mailmigratie dit punt in detail.

Voor beheerders die regelmatig migraties uitvoeren voor hun klanten bieden het artikel over het corrigeren van e-maildatums als MSP en dat over hoe IMAP INTERNALDATE werkt een volledigere kijk op het probleem.

Zijn de datums van uw e-mails beschadigd na een eM Client-import? Start een gratis scan op Redate.io om de omvang van het probleem in kaart te brengen voordat u beslist wat u doet.