eM Client: feil datoer etter PST- eller Thunderbird-import

Symptomet: alle e-postene har fått samme dato

Du har nettopp fullført en PST-import i eM Client, eller migrert fra Thunderbird til den nye postkassen din. Importen gikk tilsynelatende feilfritt. Men når du åpner innboksen, er noe galt: hundrevis, noen ganger tusenvis av e-poster viser alle samme dato, nemlig den dagen importen skjedde. En e-post fra 2019 ser ut til å ha kommet inn i går. En kontrakt signert for tre år siden dukker opp som om den nettopp ankom.

Den første naturlige reaksjonen er å skylde på eM Client. Feil innstilling, feil sorteringskolonne, visningsfeil... Man leter i innstillingene. Man veksler mellom "Mottaksdato" og "Sendedato". Ingenting endrer seg. Eller rettere sagt, noe endrer seg, men det løser ikke det egentlige problemet.

Det er fordi problemet ikke ligger i eM Client. Det ligger i serverens metadata.

Den reelle årsaken: IMAP INTERNALDATE overskrevet under import

For å forstå hva som skjer, må man gå ett nivå ned og se på hvordan IMAP-protokollen lagrer e-poster.

Hver melding på en IMAP-server har to distinkte typer datoer:

• Hodet Date: (definert av RFC 2822): dette er datoen avsender la inn i meldingen ved sending. Den er innkapslet i meldingskroppen og skal i teorien være urørlig.
• INTERNALDATE: en servermetadata, utenfor selve meldingen, som representerer datoen meldingen ble lagt inn i postkassen. Det er denne verdien e-postklienter bruker i første rekke for å sortere og vise e-poster.

Under en PST-import eller en migrering fra Thunderbird leverer importverktøyet (enten det er eM Clients innebygde modul, et tredjepartsverktøy eller en manuell IMAP-kopiering) meldingene til destinasjons-IMAP-serveren. Og der, hvis verktøyet ikke eksplisitt bevarer den opprinnelige INTERNALDATE ved innsetting, tildeler serveren automatisk gjeldende INTERNALDATE, det vil si dato og klokkeslett for importen.

Resultat: 8000 arkiverte e-poster siden 2017, alle stemplet som "mottatt" på migreringstidspunktet.

(Forresten, hvis du noen gang har prøvd å lese de rå hodene på en e-post via Vis kilde i eM Client, har du sett at det opprinnelige Date:-hodet fortsatt er der, intakt. Det er et tydelig tegn på at problemet kommer fra server-INTERNALDATE, ikke fra selve meldingen.)

Hvorfor å bytte sorteringskolonne ikke hjelper

Forvirringen oppstår fra et skille de fleste ikke kjenner til. I eM Client, som i Outlook eller Thunderbird, finnes det vanligvis to datokolonner:

• "Mottaksdato" (eller "Ankomstdato"): basert på server-INTERNALDATE.
• "Dato" eller "Sendedato": basert på Date:-hodet i meldingen.

Mange administratorer oppdager dette og tror de har funnet løsningen: bytt til "Sendedato", så forsvinner problemet visuelt i eM Client. Men det er ikke helt riktig.

Egentlig, selv om du sorterer etter sendedato i eM Client, fortsetter problemet for alle andre klienter og alle andre grensesnitt som har tilgang til samme postkasse. Hvis brukerne dine leser e-post fra OWA, fra Outlook på kontoret, fra Gmail-appen på mobilen, eller fra en hvilken som helst IMAP-konfigurert klient, vil de se importdatoene. Sorteringsinnstillingen i eM Client gjelder bare eM Client, og den påvirker ikke metadataene lagret på serveren.

I tillegg sorterer det native nettgrensesnittet i Microsoft 365 og Google Workspace etter INTERNALDATE. Det kan du ikke endre fra klientsiden.

Sortering etter sendedato er ikke en løsning. Det er et plaster som skjuler et reelt problem uten å rette det.

Særtrekk ved PST-import

Import av PST-filer fortjener et eget avsnitt. En PST-fil (Personal Storage Table) er et proprietært Microsoft-format som lagrer e-poster, kontakter og kalendere lokalt. Når du importerer en PST til eM Client, er to scenarioer mulige:

• Lokal import til en IMAP-konto: eM Client leser PST-filen og sender meldingene til destinasjons-IMAP-serveren. Hvis innsettingsdatoen ikke bevares, overskrives INTERNALDATE. Dette er det vanligste tilfellet, og der datoene ender opp korrupte.
• Import til en lokal mappe: meldingene forblir på maskinen, utenfor serveren. INTERNALDATE eksisterer ikke i den konteksten, og eM Client kan vise meldingenes Date:-hode. Mindre datoproblemer her, men også begrenset praktisk nytte.

For Thunderbird er situasjonen lik. Bruker du eM Clients innebygde importfunksjon (som leser Thunderbird-profiler), eller har du kopiert mbox-mapper via IMAP, legges meldingene på nytt inn på serveren uten garanti for at INTERNALDATE bevares. En server som mottar en melding uten eksplisitt datoinstruksjon for INTERNALDATE vil alltid tidsstemple ved mottakstidspunktet.

Hvilke plattformer er berørt?

Problemet er det samme uansett hvilken destinasjonsplattform du bruker, fordi det er et standardadferd i IMAP-protokollen:

• Microsoft 365 / Exchange Online: INTERNALDATE overskrives ved enhver import som ikke bruker IMAP APPEND med en eksplisitt datoparameter. Det samme gjelder migrering fra Exchange on-premise.
• Google Workspace: samme adferd. E-poster importert via eM Client eller tredjepartsverktøy viser importdatoen i Gmail og i administrasjonsgrensesnittet.
• Klassiske IMAP-leverandører (OVH, Infomaniak, Ionos, o2switch m.fl.): ingen spesiell datobehandling ved mottak av en APPEND-melding. INTERNALDATE blir innsettingsdatoen.

En kunde tok kontakt etter å ha migrert godt over hundre postkasser fra Exchange 2013 til Microsoft 365, der eM Client ble brukt som overgangsverktøy for noen VIP-kontoer. Resultat: postkassene migrert korrekt via MigrationWiz var i orden, men postkassene som hadde gått gjennom eM Client hadde alle importdatoer. Brukerne det gjaldt satte ikke pris på det, for å si det mildt.

Hvorfor et hjemmelaget skript ikke løser dette enkelt

Teknisk sett kan noen som forstår IMAP-protokollen tenke seg å skrive et skript for å rette INTERNALDATE. Det opprinnelige Date:-hodet er der, intakt i hver melding. Man trenger bare å lese det og rekonstruere servermetadataene deretter, ikke sant?

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

Kanttilfellene hoper seg raskt opp i en produksjonspostkasse. S/MIME-signerte meldinger er spesielt sårbare for enhver strukturmanipulasjon. PGP-krypterte meldinger likeså. E-poster med store vedlegg, ikke-standard MIME-grenser, eller uvanlige Content-Transfer-Encoding-verdier kan korrupteres lydløst hvis behandlingen ikke er presis. Et skript som fungerer på 50 teste-poster vil ikke fungere pålitelig på en postkasse med 20 000 meldinger og 6 år med historikk.

Deretter er det API-kvotahåndteringen. I Microsoft 365 kan hastighetsbegrensningene på Graph API eller EWS klokken 03:00 under et korrigeringsbatch på 8000 meldinger håndteres. Men det håndterer seg ikke selv. Et uskjermet skript som treffer en 429 Too Many Requests-feil på melding nummer 3741 fortsetter kanskje, kanskje ikke. Og du vet sannsynligvis ikke hvilke meldinger som ble behandlet.

Og viktigst av alt: hvordan verifiserer du at hver korrigert e-post er intakt etter behandling? Et hjemmelaget skript har som regel ingen mekanisme for individuell verifisering. Redate.io gjør dette automatisk, for hver enkelt melding.

Rett datoene ved kilden med Redate.io

Redate.io angriper problemet der det befinner seg: på servernes metadatanivå, ikke på e-postklientnivå.

Prosessen starter med en gratis skannefase. Redate.io kobler seg til den aktuelle postkassen (Microsoft 365 via Azure AD, Google Workspace via domenedelegering, eller direkte IMAP for klassiske leverandører) og identifiserer e-poster der datometadataene er inkonsistente med meldingsinnholdet. Du ser resultatet før du betaler noe som helst.

Korreksjonen bruker en proprietær motor som analyserer den komplette hodekjeden i hver melding, utfører mønstergjenkjenning mot hundrevis av signaturer fra kjente importverktøy (inkludert de spesifikke adferdsmønstrene til eM Client, Thunderbird og PST-importer), og rekonstruerer datometadataene målrettet uten å endre meldingsinnholdet, vedleggene eller MIME-strukturen.

Hver korrigert e-post verifiseres individuelt. Originalene bevares i en synlig sikkerhetskopieringsmappe i 30 dager, noe et hjemmelaget skript aldri vil gjøre som standard.

Prissettingen er enkel: engangsbetaling per postkasse, basert på antall e-poster som skal korrigeres. Intet abonnement, ingen løpende kostnader. Se startsiden for detaljer.

Til neste migrering: hva du bør sjekke

Hvis du planlegger en migrering og vil unngå dette problemet på forhånd, er kontrollpunktet enkelt: bevarer verktøyet du bruker INTERNALDATE eksplisitt ved innsetting av meldinger på destinasjonsserveren?

For PST-importer til Microsoft 365 håndterer Microsoft-sertifiserte verktøy (som MigrationWiz i sine innebygde modi, eller Exchange Online-migreringverktøyet) vanligvis denne bevaringen. For manuelle importer via eM Client eller Thunderbird er det sjelden tilfellet. Sjekk dokumentasjonen for verktøyet ditt før du starter en import på produksjonspostkasser.

En god sjekkliste for e-postmigrering inkluderer alltid en kontroll av datoer på et utvalg postkasser etter migrering. For administratorer som jevnlig håndterer migreringer for sine kunder, gir artikkelen om korrigering av e-postdatoer for MSP-er og artikkelen om hvordan IMAP INTERNALDATE fungerer et mer fullstendig bilde av problemet.

Har e-postdatoene dine blitt korrupte etter en eM Client-import? Start en gratis skanning på Redate.io for å kartlegge omfanget av problemet før du bestemmer deg for hva du vil gjøre.