POP naar IMAP: uw oude e-mails tonen de datum van vandaag

Het klassieke scenario van maandagochtend

U hebt zojuist uw e-mailaccount omgezet van POP3 naar IMAP. De configuratie was eenvoudig, uw hostingprovider heeft u door het proces geleid en alles leek goed te gaan. Tot u uw inbox weer opende. E-mails uit 2019, uit 2021, uw archief van vorig jaar... allemaal tonen ze dezelfde datum: vandaag. Soms zelfs hetzelfde tijdstip, op een paar seconden na.

Dit is geen bug in uw e-mailclient. Het is geen tijdzonefout. Het is het verwachte gedrag van het IMAP-protocol, en het treft iedereen die lokaal opgeslagen e-mails via deze methode naar een server uploadt.

POP3 versus IMAP: een fundamenteel verschil in opslag

Om te begrijpen waarom dit probleem ontstaat, moet u eerst weten hoe POP3 werkt, en waarom dat zo anders is dan IMAP.

Bij POP3 fungeert de server uitsluitend als tijdelijke brievenbus. Uw client (Outlook, Thunderbird, Apple Mail) maakt verbinding, downloadt de berichten en verwijdert ze daarna van de server (of laat ze staan, afhankelijk van uw instellingen). De e-mails leven vervolgens uitsluitend lokaal: in een .pst-bestand bij Outlook, in het lokale profiel van Thunderbird, in een database op uw harde schijf.

Bij IMAP is het precies omgekeerd: e-mails leven op de server. Uw client geeft alleen weer wat er op afstand is opgeslagen. Vandaar de transparante synchronisatie tussen al uw apparaten.

Het probleem ontstaat bij de overgang tussen die twee situaties. Wanneer u uw lokale POP-e-mails uploadt naar de IMAP-server.

IMAP APPEND: de opdracht die alles verandert

Wanneer uw e-mailclient een lokaal bericht naar een IMAP-server uploadt, gebruikt hij de opdracht IMAP APPEND. Die opdracht vertelt de server: "sla dit bericht op in deze map".

De server ontvangt het bericht, slaat het op en kent er een tijdstempel aan toe. Dat tijdstempel is de INTERNALDATE. Dit is de centrale metadatawaarde van IMAP: die geeft aan wanneer het bericht op de server is geplaatst. En als de client bij de APPEND-opdracht geen expliciete datum meegeeft, gebruikt de server standaard... het huidige moment.

Met andere woorden: het maakt niet uit dat het bericht in zijn headers een datum uit 2018 bevat. Als niemand de server vertelt "dit e-mailbericht is uit 2018", concludeert de server dat het zojuist is afgeleverd en kent het de INTERNALDATE van vandaag toe.

(Als u ooit de ruwe headers van een e-mail hebt bekeken, zag u de regel Date: tussen een tiental Received:-regels. Dat veld Date:, gedefinieerd door RFC 2822, bevat de werkelijke verzenddatum. Maar de IMAP INTERNALDATE is een afzonderlijke metadatawaarde die server-side wordt opgeslagen en niets te maken heeft met de inhoud van het bericht zelf.)

Waarom dit verschilt van een IMAP-naar-IMAP-migratie

Bij een gewone migratie van de ene IMAP-server naar de andere (met BitTitan, CloudM, imapsync, enzovoort) ligt het probleem iets anders. Het migratietool kopieert berichten van de ene server naar de andere en kan daarbij (in theorie) de originele INTERNALDATE via de APPEND-opdracht doorgeven aan de doelserver. Het probleem daar is dat sommige tools een Received:-header toevoegen met de migratiedatum, waardoor de weergave in clients zoals Outlook verstoord raakt.

In uw geval vertrekt u van puur lokale gegevens. Er is geen bron-INTERNALDATE om te kopiëren. Het .pst-bestand of het Thunderbird-profiel slaat berichten op in een eigen, propriëtair formaat met eigen interne metadata. Wanneer de e-mailclient deze berichten herleest om ze naar de IMAP-server te uploaden, bouwt hij de APPEND-opdracht op vanuit de berichtinhoud. En in de meeste gevallen geeft hij daarbij geen expliciete datum mee.

Resultaat: de IMAP-server ontvangt honderden of duizenden berichten in de daaropvolgende minuten en kent ze allemaal hetzelfde tijdvenster toe: nu.

Dat is precies waarom het probleem zich direct op al uw apparaten verspreidt. Uw telefoon, uw tablet, uw tweede computer: ze verbinden allemaal met dezelfde IMAP-server en zien precies hetzelfde. Correctie aan de clientkant is niet mogelijk.

Welke client toont wat, en waarom

Niet alle e-mailclients reageren op dezelfde manier. Veel IT-beheerders ontdekken dit achteraf.

Outlook (in recente versies, en zeker na de updates van 2023-2024) gebruikt de INTERNALDATE van de server voor de kolom "Ontvangen". Het toont dus de uploaddatum, niet de originele verzenddatum. Voor meer informatie over dit specifieke gedrag in Outlook is dit artikel nuttig: Outlook: ontvangstdatum IMAP-migratie vs verzenddatum.

Gmail / Google Workspace en Thunderbird vertonen iets genuanceerder gedrag. Gmail kan soms het veld Date: uit de berichtheader gebruiken voor de weergave, wat de indruk wekt dat alles in orde is... tot u probeert op datum te sorteren en merkt dat de volgorde volledig willekeurig is.

Apple Mail toont doorgaans de datum uit de Date:-header, maar sorteren en zoeken verlopen op de achtergrond via de INTERNALDATE. Uw e-mails kunnen er visueel dus correct uit zien, maar de sorteerfunctie werkt niet meer goed. Voor het specifieke gedrag van Apple Mail, zie Apple Mail: verkeerde datum na migratie.

Het goede nieuws: de originele datum is intact

De Date:-header van elk e-mailbericht, die de werkelijke verzend- of ontvangstdatum bevat, is niet aangeraakt. Hij staat er nog steeds, in de berichtinhoud. Het is die datum die u ziet wanneer u een e-mail opent en de details bekijkt.

Wat de IMAP-server heeft "beschadigd", is uitsluitend de INTERNALDATE: die externe metadatawaarde buiten het bericht. Het bericht zelf is intact.

Dat maakt correctie mogelijk. En het verklaart ook waarom het probleem een tijdlang onopgemerkt kan blijven: e-mails lijken correct wanneer u ze één voor één opent. Pas wanneer u de berichtenlijst in uw inbox bekijkt, gesorteerd op datum, wordt het probleem zichtbaar. E-mails uit 2019 verschijnen bovenaan alsof ze net zijn binnengekomen. Allemaal met dezelfde datum.

Het schaalprobleem: 3000 e-mails is anders dan 3

Misschien denkt u: "Ik verwijder ze gewoon en importeer ze opnieuw, ditmaal correct." Op 5 of 10 teste-mails werkt dat inderdaad. Maar op een mailbox van 8000 berichten met geneste mappen, grote bijlagen, S/MIME-ondertekende e-mails en gespreksthreads die teruggaan tot 2015... is dat een heel ander verhaal.

Een zelfgemaakt script dat werkt op een testbatch van 50 berichten kan prima duplicaten aanmaken, bijlagen verliezen of gespreksthreads breken in een productieomgeving. Het beheer van API-quota's, netwerk-timeouts en berichten met atypische MIME-structuren... het zijn allemaal randgevallen die een niet-gespecialiseerde tool niet aankan.

En als er halverwege iets misgaat? Zonder back-up- en rollbackmechanisme verliest u gegevens zonder mogelijkheid tot herstel.

Het probleem is goed bekend bij beheerders die grootschalige migraties uitvoeren. Begrijpen waarom datums kapotgaan is één ding. 15.000 e-mails correct herstellen met behoud van elke berichtstructuur is iets heel anders. Voor meer achtergrond over dit onderwerp bevat het artikel Kunnen e-maildatums worden hersteld na migratie? een overzicht van de verschillende benaderingen en hun beperkingen.

Hoe Redate.io met dit specifieke geval omgaat

Redate.io is precies voor dit soort situaties ontworpen. De analyse-engine identificeert e-mails waarbij de INTERNALDATE niet overeenkomt met de datum in de berichtheaders, of het nu gaat om een POP-naar-IMAP-migratie, een migratie tussen IMAP-servers of een handmatige upload van lokale archieven.

De meertraps analysepipeline inspecteert de headerketen van elk bericht, valideert RFC-conformiteit en reconstrueert de datummetadata zonder de berichtinhoud te wijzigen: niet de tekst, niet de bijlagen, niet de MIME-structuur, niet eventuele digitale handtekeningen. Elk gecorrigeerd e-mailbericht wordt individueel geverifieerd vóór validatie.

De originelen worden gedurende 30 dagen bewaard in een zichtbare back-upmap. Staat u ergens niet achter, dan kunt u herstellen.

De initiële scan is gratis: Redate analyseert uw mailbox, identificeert de getroffen e-mails en geeft u het exacte aantal vóór u een beslissing neemt. Geen blinde verbintenis.

Redate.io verbindt rechtstreeks met uw mailboxen via Google Workspace (domeindelegatie), Microsoft 365 (Azure AD) of directe IMAP-verbinding. Geen lokale installatie. Geen .pst-bestanden die u handmatig moet bewerken.

Voor beheerders die meerdere mailboxen beheren en meer willen weten over dit type situatie, is het artikel MSP: e-maildatums van uw klanten herstellen een goede aanvulling. En voor de specifieke kenmerken van correctie in Thunderbird, dat zijn eigen gedrag heeft bij de overstap van POP naar IMAP, zie Thunderbird: verkeerde datum na migratie herstellen.

Als het nog moet gebeuren: het probleem voorkomen

Hebt u uw lokale archieven nog niet naar de IMAP-server geüpload, of plant u andere migraties van POP-accounts binnen uw organisatie? Dan zijn dit de punten om in gedachten te houden.

• Controleer of uw e-mailclient het expliciet doorgeven van de datum bij de APPEND-opdracht ondersteunt. Thunderbird heeft op dit punt wisselend gedrag vertoond, afhankelijk van de versie.
• Doe eerst een test op een validatieaccount met 50 tot 100 representatieve berichten: oude e-mails, e-mails met bijlagen, ondertekende e-mails. Controleer de weergegeven datums in verschillende clients.
• Plan de correctie vóórdat eindgebruikers met de gemigreerde mailbox beginnen te werken. Datums corrigeren op een actieve mailbox is complexer dan op een verse, net-gemigreerde mailbox.
• Documenteer het aantal e-mails vóór en na de migratie. Dat is de enige manier om stille verliezen te detecteren.

Voor een volledige checklist van te controleren punten vóór en na een migratie behandelt het artikel Checklist e-mailmigratie: datumproblemen voorkomen alle gevallen.

Tonen uw oude e-mails de datum van vandaag na de overstap van POP naar IMAP? Start een gratis scan op Redate.io om de omvang van het probleem te meten en de datummetadata te corrigeren zonder de inhoud van uw berichten aan te raken.