eM Client: fel datum efter PST- eller Thunderbird-import

Symptomet: alla e-postmeddelanden har samma datum

Du har precis importerat en PST-fil i eM Client, eller migrerat från Thunderbird till din nya brevlåda. Importen gick till synes utan fel. Men när du öppnar inkorgen stämmer något inte: hundratals, ibland tusentals e-postmeddelanden visar alla samma datum, det vill säga importdagen. Ett meddelande från 2019 ser ut att ha kommit in igår. Ett kontrakt som signerades för tre år sedan verkar ha anlänt nyss.

Den första reaktionen är att skylla på eM Client. Fel inställning, fel sorteringskolumn, visningsbugg... Man letar i inställningarna. Man växlar mellan "Mottaget datum" och "Skickat datum". Ingenting förändras, eller rättare sagt: något förändras, men grundproblemet kvarstår.

Det beror på att problemet inte sitter i eM Client. Det sitter i serverns metadata.

Den verkliga orsaken: IMAP INTERNALDATE skrivs över vid import

För att förstå vad som händer behöver man gå ett steg djupare och titta på hur IMAP-protokollet lagrar e-post.

Varje meddelande på en IMAP-server har två olika typer av datum:

• Headern Date: (definierad av RFC 2822): det är datumet som avsändaren wrote i meddelandet vid sändningstillfället. Det är inkapslat i meddelandets brödtext och ska i teorin vara orubbat.
• INTERNALDATE: en servermetadata, utanför själva meddelandet, som representerar det datum då meddelandet lades in i brevlådan. Det är det här värdet som e-postklienter i första hand använder för att sortera och visa meddelanden.

Vid en PST-import eller en migrering från Thunderbird lägger importverktyget (oavsett om det är eM Clients inbyggda modul, ett tredjepartsverktyg eller en manuell IMAP-kopiering) meddelanden på destinations-IMAP-servern. Om verktyget inte uttryckligen bevarar det ursprungliga INTERNALDATE vid insättningen tilldelar servern automatiskt aktuellt INTERNALDATE, det vill säga importens datum och tid.

Resultat: 8 000 arkiverade e-postmeddelanden från 2017, alla stämplade som "mottagna" vid migreringstillfället.

(Om du någon gång har försökt läsa råa e-postheaders via Visa källa i eM Client har du förmodligen sett att den ursprungliga Date:-headern fortfarande finns kvar, intakt. Det är ett tydligt tecken på att problemet ligger i serverns INTERNALDATE, inte i meddelandet självt.)

Varför det inte hjälper att byta sorteringskolumn

Förvirringen beror på en distinktion som de flesta inte känner till. I eM Client, precis som i Outlook eller Thunderbird, finns det oftast två datumkolumner:

• "Mottaget datum" (eller "Ankomstdatum"): baseras på serverns INTERNALDATE.
• "Datum" eller "Skickat datum": baseras på meddelandets Date:-header.

Många administratörer upptäcker det här och tror att de hittat lösningen: byt till "Skickat datum" så försvinner problemet visuellt i eM Client. Men det stämmer inte riktigt.

Faktiskt kvarstår problemet för alla andra klienter och gränssnitt som ansluter till samma brevlåda, även om du sorterar på skickat datum i eM Client. Om dina användare läser sin e-post via OWA, Outlook på kontoret, Gmail-appen på mobilen eller någon annan IMAP-konfigurerad klient kommer de att se importdatumen. eM Clients sorteringsinställning gäller bara eM Client och påverkar inte metadata på serversidan.

På Microsoft 365 och Google Workspace sorterar dessutom den inbyggda webbvyn efter INTERNALDATE. Det beteendet kan du inte ändra från klienten.

Att sortera på skickat datum är ingen lösning. Det är ett plåster som döljer ett verkligt problem utan att åtgärda det.

Det särskilda fallet PST-import

Import av PST-filer förtjänar ett eget avsnitt. En PST-fil (Personal Storage Table) är ett proprietärt Microsoft-format som lagrar e-post, kontakter och kalendrar lokalt. När du importerar en PST i eM Client finns det två scenarier:

• Lokal import till ett IMAP-konto: eM Client läser PST-filen och skickar meddelandena till destinations-IMAP-servern. Om insättningsdatumet inte bevaras skrivs INTERNALDATE över. Det här är det vanligaste fallet, och det är här datumen blir korrupta.
• Import till en lokal mapp: meddelandena stannar på maskinen, utanför servern. INTERNALDATE existerar inte i det här sammanhanget, och eM Client kan visa meddelandets Date:-header. Färre datumproblem här, men också mindre praktisk nytta.

För Thunderbird är situationen liknande. Oavsett om du använder eM Clients inbyggda importfunktion (som läser Thunderbird-profiler) eller har kopierat mbox-mappar via IMAP, läggs meddelandena om på servern utan garanterad bevarandeINTERNALDATE. En server som tar emot ett meddelande utan explicit datuminstruktion för INTERNALDATE tidsstämplar det konsekvent vid mottagningsögonblicket.

Vilka plattformar berörs?

Problemet är identiskt oavsett destinationsplattform, eftersom det rör sig om ett standardbeteende i IMAP-protokollet:

• Microsoft 365 / Exchange Online: INTERNALDATE skrivs över vid all import som inte använder IMAP APPEND med en explicit datumparameter. Samma sak gäller vid migrering från Exchange on-premise.
• Google Workspace: samma beteende. E-postmeddelanden importerade via eM Client eller tredjepartsverktyg visar importdatumet i Gmail och i administrationsgränssnittet.
• Klassiska IMAP-leverantörer (OVH, Infomaniak, Ionos, o2switch m.fl.): ingen särskild datumhantering vid mottagning av ett APPEND-meddelande. INTERNALDATE sätts till insättningstillfället.

En kund hörde av sig efter att ha migrerat ett hundratal brevlådor från Exchange 2013 till Microsoft 365, med eM Client som övergångsverktyg för vissa VIP-konton. Resultatet: brevlådorna som migrerats korrekt via MigrationWiz var felfria, men de som gick via eM Client hade alla importdatum. Att säga att de berörda användarna var missnöjda är en underdrift.

Varför ett hemmagjort skript inte löser det här enkelt

Rent tekniskt kan någon som förstår IMAP-protokollet tänka sig att skriva ett skript för att rätta INTERNALDATE. Den ursprungliga Date:-headern finns kvar, intakt i varje meddelande. Det borde räcka att läsa den och rekonstruera servermetadatan utifrån den, eller hur?

I teorin, ja. I praktiken är det ett minfält.

Först staplas kantfallen snabbt på varandra i en produktionsbrevlåda. Digitalt signerade S/MIME-meddelanden är särskilt känsliga för all strukturmanipulering. PGP-krypterade meddelanden likaså. E-postmeddelanden med stora bilagor, icke-standardiserade MIME-gränser eller ovanliga Content-Transfer-Encoding-kodningar kan korrupteras tyst om hanteringen inte är rigorös. Ett skript som fungerar på 50 testmeddelanden kommer inte att fungera tillförlitligt på en brevlåda med 20 000 meddelanden och 6 års historik.

Sedan finns kvothanteringen för API:et. På Microsoft 365 kan hastighetsbegränsningar på Graph API eller EWS kl. 03 på natten under ett korrigeringsbatch på 8 000 meddelanden hanteras, men inte av sig självt. Ett obevakat skript som stöter på ett 429 Too Many Requests-fel vid meddelande nummer 3741 kanske fortsätter, kanske inte. Och du vet förmodligen inte vilka meddelanden som faktiskt behandlades.

Framför allt: hur verifierar du att varje korrigerat e-postmeddelande är intakt efter behandlingen? Ett hemmagjort skript har sällan någon mekanism för individuell verifiering. Redate.io gör det automatiskt, för varje enskilt meddelande.

Korrigera datumen vid källan med Redate.io

Redate.io angriper problemet där det finns: på servermetadatanivå, inte på e-postklientnivå.

Processen börjar med en gratis skanningsfas. Redate.io ansluter till den berörda brevlådan (Microsoft 365 via Azure AD, Google Workspace via domändelegering eller direkt IMAP för klassiska leverantörer) och identifierar e-postmeddelanden vars datummetadata är inkonsekvent med meddelandets innehåll. Du ser resultatet innan du betalar något.

Korrigeringen använder ett proprietärt korrigeringsverktyg som analyserar hela headerkedjan för varje meddelande, tillämpar mönstermatchning mot hundratals kända importverktygs signaturer (inklusive eM Clients, Thunderbirds och PST-importers specifika beteenden) och rekonstruerar datummetadata på ett riktat sätt utan att ändra meddelandets innehåll, bilagor eller MIME-struktur.

Varje korrigerat e-postmeddelande verifieras individuellt. Originalen bevaras i en synlig säkerhetskopia i 30 dagar, något ett hemmagjort skript aldrig gör som standard.

Prismodellen är enkel: engångsbetalning per brevlåda, baserad på antalet e-postmeddelanden som ska korrigeras. Inget abonnemang, inga löpande avgifter. Se startsidan för detaljer.

Inför nästa migrering: vad du bör kontrollera

Om du planerar en migrering och vill undvika det här problemet från start är kontrollpunkten enkel: bevarar det verktyg du använder INTERNALDATE explicit när meddelanden läggs in på destinationsservern?

För PST-importer till Microsoft 365 hanterar Microsoft-certifierade verktyg (som MigrationWiz i sina inbyggda lägen eller Exchange Online-migreringsverktyget) vanligtvis den bevarandeprocessen. För manuella importer via eM Client eller Thunderbird är det sällan fallet. Kontrollera verktygets dokumentation innan du kör en import på produktionsbrevlådor.

En bra checklista för e-postmigrering innehåller alltid en verifiering av datum på ett urval brevlådor efter migreringen. Om du vill gå längre täcker vår checklista för e-postmigrering den punkten i detalj.

För administratörer som regelbundet hanterar migreringar åt sina kunder ger artikeln om datumkorrigering för MSP:er och den om hur IMAP INTERNALDATE fungerar en mer komplett bild av problemet.

Är datumen i din e-post korrupta efter en eM Client-import? Starta en gratis skanning på Redate.io för att mäta problemets omfattning innan du bestämmer vad du ska göra.