POP til IMAP: dine gamle mails har fået dagens dato

Den klassiske mandag morgen

Du har netop skiftet din e-mailkonto fra POP3 til IMAP. Konfigurationen var enkel, din udbyder guidede dig igennem det, og alt gik fint. Indtil du åbnede din indbakke igen. Dine e-mails fra 2019, 2021, dine arkiver fra sidste år... alle viser samme dato: i dag. Nogle gange endda samme klokkeslæt, med få sekunders forskel.

Det er ikke en fejl i dit mailprogram. Det er ikke et tidszoneroblem. Det er den forventede opførsel fra IMAP-protokollen, og det rammer alle der uploader lokalt lagrede e-mails til en server på denne måde.

POP3 vs. IMAP: en grundlæggende forskel i lagring

For at forstå hvorfor problemet opstår, er man nødt til at forstå hvordan POP3 fungerer, og hvad der adskiller det radikalt fra IMAP.

Med POP3 fungerer serveren kun som en midlertidig postkasse. Din klient (Outlook, Thunderbird, Apple Mail) forbinder sig, henter beskederne og sletter dem fra serveren (eller lader dem ligge, afhængigt af din konfiguration). E-mails lever derefter udelukkende lokalt: i en .pst-fil for Outlook, i Thunderbirds lokale profil, i en database på din harddisk.

Med IMAP er det omvendt: e-mails lever på serveren. Din klient viser blot det der er lagret eksternt. Deraf den transparente synkronisering på tværs af alle dine enheder.

Problemet opstår i overgangen mellem de to. Når du uploader dine gamle lokale POP-e-mails til IMAP-serveren.

IMAP APPEND: kommandoen der ændrer alt

Når dit mailprogram uploader en lokal besked til en IMAP-server, bruger det kommandoen IMAP APPEND. Denne kommando siger til serveren: "gem denne besked i den her mappe".

Serveren modtager beskeden, gemmer den og tildeler den et timestamp. Det timestamp er INTERNALDATE. Det er IMAP's centrale metadata: det angiver hvornår beskeden blev lagt på serveren. Og som standard, hvis klienten ikke eksplicit angiver en dato i APPEND-kommandoen, bruger serveren... det aktuelle tidspunkt.

Med andre ord: ligegyldigt om beskeden i sine headere indeholder en dato fra 2018, hvis ingen fortæller serveren "denne e-mail er fra 2018", konkluderer serveren at den er blevet lagt ind nu, og tildeler den dagens INTERNALDATE.

(Har du nogensinde kigget på en e-mails råe headere, ved du at det ikke ligefrem er afslappende læsning. Men du har sikkert set linjen Date: midt iblandt en snes andre Received:-linjer. Det er dette Date:-felt, defineret af RFC 2822, der indeholder den reelle afsendelsesdato. Men IMAP's INTERNALDATE er en separat metadata, gemt på serversiden, der ikke har noget med selve beskedens indhold at gøre.)

Hvorfor det er anderledes end en IMAP-til-IMAP-migrering

Ved en klassisk migrering fra en IMAP-server til en anden (med BitTitan, CloudM, imapsync osv.) er problemet lidt anderledes. Migreringsværktøjet kopierer beskederne fra en server til en anden, og kan i teorien videresende den originale INTERNALDATE til destinationsserveren via APPEND-kommandoen. Problemet dér er at visse værktøjer tilføjer en Received:-header med migrationsdatoen, hvilket forstyrrer visningen i klienter som Outlook.

I dit tilfælde starter du fra rent lokale data. Der er ingen kilde-INTERNALDATE at kopiere. .pst-filen eller Thunderbird-profilen gemmer beskederne i sit eget proprietære format med sine egne interne metadata. Når mailprogrammet genindlæser disse beskeder for at uploade dem til IMAP-serveren, rekonstruerer det APPEND-kommandoen ud fra beskedens indhold. Og det meste af tiden sender det ingen eksplicit dato med.

Resultatet: IMAP-serveren modtager hundredvis eller tusindvis af beskeder på få minutter og tildeler dem alle samme tidsrum: nu.

Det er præcis derfor problemet spreder sig til alle dine enheder øjeblikkeligt. Din telefon, din tablet, din anden computer: de forbinder alle til den samme IMAP-server og ser præcis det samme. Ingen rettelse er mulig på klientsiden.

Hvad viser hvilken klient, og hvorfor

Alle mailprogrammer reagerer ikke på samme måde. Det er noget mange IT-admins opdager i bagklogskabens klare lys.

Outlook (i nyere versioner, og især siden opdateringerne i 2023-2024) bruger serverens INTERNALDATE til kolonnen "Modtaget". Det viser altså uploadtidspunktet, ikke den originale afsendelsesdato. Vil du vide mere om denne specifikke opførsel i Outlook, er denne artikel nyttig: Outlook: modtagelsesdato IMAP vs. afsendelsesdato.

Gmail / Google Workspace og Thunderbird opfører sig lidt mere nuanceret. Gmail kan for eksempel sommetider bruge beskedens Date:-header-felt til visningen, hvilket giver indtrykket af at alt er fint... indtil du prøver at sortere efter dato og opdager at rækkefølgen er fuldstændig tilfældig.

Apple Mail viser som regel datoen udtrukket fra Date:-headeren, men sortering og søgning kører på INTERNALDATE i baggrunden. Så dine e-mails kan "se ud til" at have rigtige datoer visuelt, men sorteringsfunktionen virker ikke længere korrekt. For detaljer om Apple Mails opførsel, se Apple Mail: forkert dato efter migrering.

Den gode nyhed: den originale dato er intakt

Date:-headeren i hver e-mail, den der indeholder den reelle afsendelsesdato (eller modtagelsesdato), er ikke blevet rørt. Den er stadig der, i beskedens indhold. Det er den du ser når du åbner en e-mail og kigger på detaljerne.

Det IMAP-serveren har "ødelagt", er udelukkende INTERNALDATE, den metadata der ligger eksternt i forhold til beskeden. Selve beskeden er intakt.

Det er det der gør rettelsen mulig. Og det forklarer også hvorfor problemet kan gå ubemærket hen et stykke tid: e-mails ser rigtige ud når du åbner dem én ad gangen. Det er først når du kigger på listen i din indbakke, sorteret efter dato, at problemet bliver synligt. E-mails fra 2019 dukker op øverst som om de netop var ankommet. Alle med samme dato.

Skalaproblemet: 3000 e-mails er noget andet end 3

Måske tænker du: "Jeg sletter bare og importerer igen, denne gang korrekt." På 5 eller 10 teste-mails, ja, det virker. På en postkasse med 8000 beskeder, indlejrede mapper, store vedhæftede filer, S/MIME-signerede e-mails og tråde der går tilbage til 2015... er det en helt anden sag.

Et hjemmelavet script der fungerer på en testbatch med 50 e-mails kan sagtens producere dubletter, miste vedhæftede filer eller ødelægge samtaletråde i en produktionspostkasse. Håndtering af API-kvoter, netværks-timeouts, beskeder med atypiske MIME-strukturer... alle edge cases som et ikke-specialiseret værktøj ikke håndterer.

Og hvis noget går galt halvvejs? Uden backup-mekanisme og rollback mister du data uden mulighed for at gendanne dem.

Problemet er velkendt blandt admins der håndterer migreringer i større skala. At forstå hvorfor datoerne er ødelagt er én ting. At rette 15.000 e-mails korrekt og bevare hver beskedstruktur er noget helt andet. For at gå dybere ned i emnet beskriver artiklen Kan e-maildatoer rettes efter en migrering? de forskellige tilgange og deres begrænsninger.

Sådan håndterer Redate.io dette specifikke tilfælde

Redate.io er bygget præcis til denne type situation. Analysemotoren identificerer e-mails hvor INTERNALDATE ikke stemmer overens med datoen i beskedens headere, uanset om det drejer sig om en POP-til-IMAP-migrering, en migrering mellem IMAP-servere eller en manuel upload af lokale arkiver.

Den flertrinede analysepipeline inspicerer header-kæden for hver besked, validerer RFC-overensstemmelse og rekonstruerer dato-metadata uden at ændre beskedens indhold: hverken tekst, vedhæftede filer, MIME-strukturen eller eventuelle digitale signaturer. Hver rettet e-mail verificeres individuelt inden validering.

Originalerne bevares i en synlig backup-mappe i 30 dage. Hvis noget ikke er som du ønsker, kan du gendanne.

Det indledende scan er gratis: Redate analyserer din postkasse, identificerer de berørte e-mails og oplyser dig om det præcise antal, inden du beslutter noget som helst. Ingen blindt engagement.

Redate.io forbinder sig direkte til dine postkasser via Google Workspace (domænedelegering), Microsoft 365 (Azure AD) eller direkte IMAP. Ingen lokal installation. Ingen .pst-filer der skal håndteres manuelt.

For admins der administrerer flere postkasser og ønsker erfaringer fra denne type sager, er artiklen MSP: ret dine kunders e-maildatoer en god supplerende læsning. Og for Thunderbirds specifikke opførsel ved POP/IMAP-skiftet, se Thunderbird: forkert dato efter migrering.

Hvis det stadig skal gøres: forebyg problemet

Har du endnu ikke uploadet dine lokale arkiver til IMAP-serveren, eller planlægger du yderligere migreringer af POP-konti i din organisation, er her hvad du bør huske på.

• Tjek om dit mailprogram understøtter eksplicit angivelse af dato i APPEND-kommandoen. Thunderbird har for eksempel haft varierende opførsel på dette punkt afhængigt af versionen.
• Lav først en test på en valideringskonto med 50-100 repræsentative beskeder: gamle e-mails, med vedhæftede filer, signerede e-mails. Tjek de viste datoer i forskellige mailprogrammer.
• Planlæg rettelsen inden slutbrugerne begynder at arbejde i den migrerede postkasse. At rette datoer i en aktiv postkasse er mere komplekst end i en tom postkasse lige efter migrering.
• Dokumenter antallet af e-mails før og efter migrering. Det er den eneste måde at opdage stille datatab på.

For en komplet tjekliste over hvad du skal kontrollere før og efter en migrering, dækker artiklen Tjekliste til e-mailmigrering: undgå datoproblemer alle tilfælde.

Viser dine gamle e-mails dagens dato efter et skift fra POP til IMAP? Start et gratis scan på Redate.io for at måle problemets omfang og rette dato-metadata uden at røre ved dine beskeder.