eM Client: forkerte datoer efter PST- eller Thunderbird-import

Symptomet: alle dine e-mails har samme dato

Du har netop afsluttet en PST-import i eM Client, eller du har migreret fra Thunderbird til din nye postkasse. Importen forløb tilsyneladende uden fejl. Men da du åbner din indbakke, er der noget galt: hundredvis, måske tusindvis af e-mails viser alle samme dato, nemlig den dag importen fandt sted. En e-mail fra 2019 ser ud til at være modtaget i går. En kontrakt underskrevet for tre år siden fremstår som om den netop er ankommet.

Den første reaktion er naturligvis at give eM Client skylden. Forkert indstilling, forkert sorteringskolonne, visningsfejl... Man leder i præferencerne. Man skifter frem og tilbage mellem "Modtagelsesdato" og "Afsendelsesdato". Intet ændrer sig. Eller rettere sagt, noget ændrer sig, men det løser ikke det grundlæggende problem.

Det skyldes, at problemet ikke sidder i eM Client. Det sidder i serverens metadata.

Den egentlige årsag: IMAP INTERNALDATE overskrives under importen

For at forstå hvad der sker, skal man gå et niveau ned og se på, hvordan IMAP-protokollen gemmer e-mails.

Hver besked på en IMAP-server har to forskellige typer datoer:

• Headeren Date: (defineret af RFC 2822): den dato afsenderen satte i beskeden på afsendelsestidspunktet. Den er indkapslet i selve meddelelsen og er i princippet urørlig.
• INTERNALDATE: en server-side metadata, uafhængig af selve beskeden, som repræsenterer det tidspunkt, beskeden blev lagt i postkassen. Det er denne værdi e-mailklienter primært bruger til at sortere og vise e-mails.

Ved en PST-import eller en migrering fra Thunderbird lægger importværktøjet (hvad enten det er eM Clients eget modul, et tredjepartsværktøj eller en manuel IMAP-kopiering) beskederne op på destinations-IMAP-serveren. Og her, hvis værktøjet ikke eksplicit bevarer den originale INTERNALDATE ved oploadet, tildeler serveren automatisk den aktuelle INTERNALDATE, altså dato og tidspunkt for importen.

Resultatet: 8.000 arkiverede e-mails fra 2017, alle stemplet som "modtaget" på migreringstidspunktet.

(Hvis du nogensinde har forsøgt at læse de rå headers på en e-mail via Vis kilde i eM Client, vil du kunne konstatere, at den originale Date:-header stadig er der, intakt. Det er et klart tegn på, at problemet ligger i serverens INTERNALDATE, ikke i selve beskeden.)

Hvorfor det ikke hjælper at skifte sorteringskolonne

Forvirringen opstår på grund af en skelnen, som de færreste kender til. I eM Client, ligesom i Outlook og Thunderbird, findes der typisk to datokolonner:

• "Modtagelsesdato" (eller "Ankomstdato"): baseret på serverens INTERNALDATE.
• "Dato" eller "Afsendelsesdato": baseret på beskedernes Date:-header.

Mange administratorer opdager dette og tror, de har fundet løsningen: skift til "Afsendelsesdato", og problemet forsvinder visuelt i eM Client. Men det er ikke helt rigtigt.

Faktisk: selv om du sorterer efter afsendelsesdato i eM Client, vedvarer problemet for alle andre klienter og grænseflader, der tilgår den samme postkasse. Hvis dine brugere tjekker deres e-mails via OWA, via Outlook på arbejdspladsen, via Gmail-appen på mobilen eller via en hvilken som helst IMAP-konfigureret klient, vil de se importdatoerne. eM Clients sorteringsindstilling gælder kun eM Client og påvirker ikke de metadata, der er gemt på serveren.

Desuden sorterer den native webvisning i Microsoft 365 og Google Workspace efter INTERNALDATE. Den adfærd kan du ikke ændre fra klienten.

Sortering efter afsendelsesdato er ikke en løsning. Det er et plaster, der dækker over et reelt problem uden at rette det.

Det særlige tilfælde med PST-import

PST-filimport fortjener sit eget afsnit. En PST-fil (Personal Storage Table) er et proprietært Microsoft-format, der gemmer e-mails, kontakter og kalendre lokalt. Når du importerer en PST i eM Client, er der to mulige scenarier:

• Lokal import til en IMAP-konto: eM Client læser PST-filen og skubber beskederne op på destinations-IMAP-serveren. Hvis uploadets dato ikke bevares, overskrives INTERNALDATE. Det er det hyppigste tilfælde, og det er her datoerne ender med at blive ødelagt.
• Import til en lokal mappe: beskederne forbliver på maskinen, uden for serveren. INTERNALDATE eksisterer ikke i den kontekst, og eM Client kan vise beskedernes Date:-header. Færre datoer problemer her, men også mindre praktisk nytte.

For Thunderbird er situationen den samme. Enten bruger du eM Clients indbyggede importfunktion (som læser Thunderbird-profiler), eller du har kopieret mbox-mapper via IMAP - i begge tilfælde genoplades beskederne på serveren uden garanti for, at INTERNALDATE bevares. En server, der modtager en besked uden en eksplicit datoinstruktion for INTERNALDATE, vil systematisk tidsstemple ved modtagelsen.

Hvilke platforme er berørt?

Problemet er identisk uanset destinationsplatform, fordi det er standardadfærd i IMAP-protokollen:

• Microsoft 365 / Exchange Online: INTERNALDATE overskrives ved enhver import, der ikke bruger IMAP APPEND med en eksplicit datoparameter. Det samme gælder ved migrering fra Exchange on-premise.
• Google Workspace: samme adfærd. E-mails importeret via eM Client eller tredjepartsværktøjer viser importdatoen i Gmail og i administrationsgrænsefladen.
• Klassiske IMAP-hostingudbydere (OVH, Infomaniak, Ionos, o2switch osv.): ingen særlig datohåndtering ved modtagelse af en APPEND-besked. INTERNALDATE vil være uploadets dato.

En kunde kontaktede Redate.io efter at have migreret godt hundrede postkasser fra Exchange 2013 til Microsoft 365 og brugt eM Client som overgangsværktøj for visse VIP-konti. Postkasserne migreret korrekt via MigrationWiz var fine, men postkasserne, der var gået igennem eM Client, havde alle importdatoer. Brugerne det gik ud over, var ikke begejstrede, for at sige det mildt.

Hvorfor et hjemmelavet script ikke løser det nemt

Rent teknisk ville nogen, der forstår IMAP-protokollen, måske overveje at skrive et script til at rette INTERNALDATE-værdierne. Den originale Date:-header er jo der, intakt i hver besked. Man skulle blot læse den og genopbygge serverens metadata derefter, ikke?

I teorien, ja. I praksis er det et minefelt.

For det første hober edge cases sig hurtigt op i en produktionspostkasse. S/MIME-signerede beskeder er særligt følsomme over for enhver strukturmanipulation. Det samme gælder PGP-krypterede beskeder. E-mails med store vedhæftede filer, ikke-standard MIME-grænser eller usædvanlige Content-Transfer-Encoding-kodninger kan blive stille korrumperet, hvis behandlingen ikke er omhyggelig. Et script, der fungerer på 50 test-e-mails, vil ikke fungere pålideligt på en postkasse med 20.000 beskeder og 6 års historik.

Dernæst er der API-kvotehåndtering. På Microsoft 365 kan ratebegrænsninger på Graph API eller EWS klokken 3 om natten under et korrektionsbatch på 8.000 beskeder håndteres. Men det håndterer sig ikke selv. Et script uden opsyn, der støder på en 429 Too Many Requests-fejl ved besked nummer 3.741, fortsætter måske, måske ikke. Og du ved sandsynligvis ikke, hvilke beskeder der er blevet behandlet.

Og frem for alt: hvordan verificerer du, at hver korrigeret e-mail er intakt efter behandlingen? Et hjemmelavet script har typisk ingen mekanisme til individuel verifikation. Redate.io gør det automatisk, for hver enkelt besked.

Ret datoerne ved kilden med Redate.io

Redate.io angriber problemet der, hvor det befinder sig: på server-metadata-niveau, ikke på e-mailklientniveau.

Processen starter med en gratis scanningsfase. Redate.io forbinder til den berørte postkasse (Microsoft 365 via Azure AD, Google Workspace via domænedelegering eller direkte IMAP til klassiske hostingudbydere) og identificerer e-mails, hvis datometadata er inkonsistente med beskedindholdet. Du ser resultatet, inden du betaler noget som helst.

Korrektionen bruger en proprietær korrektionsmotor, der analyserer den komplette headerkæde for hver besked, anvender mønstermatchning på hundredvis af kendte importværktøjssignaturer (herunder eM Clients, Thunderbirds og PST-importers specifikke adfærd) og genopbygger datometadata målrettet uden at ændre beskedindholdet, vedhæftede filer eller MIME-struktur.

Hver korrigeret e-mail verificeres individuelt. Originalerne opbevares i en synlig backup-mappe i 30 dage, noget et hjemmelavet script aldrig vil gøre som standard.

Prismodellen er enkel: engangsbetaling pr. postkasse baseret på antallet af e-mails, der skal rettes. Intet abonnement, ingen løbende gebyrer. Se startsiden for detaljer.

Til næste migrering: hvad du skal tjekke

Hvis du planlægger en migrering og vil undgå dette problem på forhånd, er kontrolpunktet enkelt: bevarer det værktøj, du bruger, eksplicit INTERNALDATE, når beskederne uploades til destinationsserveren?

Ved PST-import til Microsoft 365 håndterer Microsoft-certificerede værktøjer (som MigrationWiz i sine native tilstande eller Exchange Online-migreringsværktøjet) typisk denne bevarelse. Ved manuelle imports via eM Client eller Thunderbird er det sjældent tilfældet. Tjek din værktøjsdokumentation, inden du kører en import på produktionspostkasser.

En god tjekliste til e-mailmigrering indeholder altid en post-migrering-verifikation af datoer på et udsnit af postkasserne. For administratorer, der jævnligt håndterer migreringer for kunder, giver artiklen om datokorrektion på MSP-siden og artiklen om hvordan IMAP INTERNALDATE fungerer et mere komplet billede af problemet.

Er dine e-maildatoer ødelagt efter en eM Client-import? Start en gratis scanning på Redate.io for at måle omfanget af problemet, inden du beslutter dig for, hvad du vil gøre.