POP till IMAP: gamla e-post får dagens datum

Det klassiska måndagsmorgon-scenariot

Du har precis bytt ditt e-postkonto från POP3 till IMAP. Konfigurationen gick smidigt, din leverantör guidade dig igenom stegen och allt verkade fungera. Tills du öppnade inkorgen igen. Dina e-postmeddelanden från 2019, 2021, dina arkiv från förra året... alla visar samma datum: idag. Ibland till och med samma klockslag, med några sekunders mellanrum.

Det är inte ett fel i din e-postklient. Det är inte ett tidszons-problem. Det är det förväntade beteendet hos IMAP-protokollet, och det drabbar alla som laddar upp lokalt lagrade e-postmeddelanden till en server via den här metoden.

POP3 vs IMAP: en grundläggande skillnad i lagring

För att förstå varför problemet uppstår behöver du först förstå hur POP3 fungerar, och hur det skiljer sig radikalt från IMAP.

Med POP3 fungerar servern bara som en tillfällig brevlåda. Din klient (Outlook, Thunderbird, Apple Mail) ansluter, laddar ner meddelandena och raderar dem sedan från servern (eller låter dem vara kvar, beroende på inställning). E-posten lever sedan uteslutande lokalt: i en .pst-fil för Outlook, i Thunderbirds lokala profil, i en databas på din hårddisk.

Med IMAP är det tvärtom: e-posten lever på servern. Klienten visar bara det som lagras på distans. Det är därför synkroniseringen fungerar sömlöst mellan alla dina enheter.

Problemet uppstår i övergången mellan de två. När du laddar upp dina gamla lokala POP-meddelanden till IMAP-servern.

IMAP APPEND: kommandot som ändrar allt

När din e-postklient laddar upp ett lokalt meddelande till en IMAP-server används kommandot IMAP APPEND. Det talar om för servern: "lagra det här meddelandet i den här mappen".

Servern tar emot meddelandet, sparar det och tilldelar det ett tidsstämpel. Det tidsstämpeln är INTERNALDATE. Det är IMAP:s centrala metadata: den anger när meddelandet lades in på servern. Och som standard, om klienten inte explicit anger ett datum i APPEND-kommandot, använder servern... det aktuella ögonblicket.

Med andra ord: oavsett om meddelandet innehåller en rubrik med datum från 2018, om ingen talar om för servern att "det här e-postmeddelandet är från 2018" drar servern slutsatsen att det lades in nu och tilldelar det ett INTERNALDATE med dagens datum.

(Om du någon gång har tittat på råa e-postrubriker vet du att det inte direkt är strands-läsning. Du ser raden Date: mitt bland ett tiotal Received:-rader. Det är fältet Date:, definierat av RFC 2822, som innehåller det riktiga avsändningsdatumet. Men IMAP INTERNALDATE är en separat metadata, lagrad på serversidan, som inte har något att göra med meddelandets faktiska innehåll.)

Varför det skiljer sig från en IMAP-till-IMAP-migrering

Vid en klassisk migrering från en IMAP-server till en annan (med BitTitan, CloudM, imapsync osv.) är problemet lite annorlunda. Migreringsverktyget kopierar meddelanden från en server till en annan, och i det fallet kan det (i teorin) skicka med det ursprungliga INTERNALDATE till målservern via APPEND-kommandot. Problemet där är att vissa verktyg lägger till en Received:-rubrik med migreringsdatumet, vilket stör visningen i klienter som Outlook.

I ditt fall utgår du från rent lokala data. Det finns inget käll-INTERNALDATE att kopiera. Filen .pst eller Thunderbird-profilen lagrar meddelanden i ett eget proprietärt format med egna interna metadata. När e-postklienten läser om dessa meddelanden för att ladda upp dem till IMAP-servern rekonstruerar den APPEND-kommandot utifrån meddelandeinnehållet. Och i de flesta fall skickas inget explicit datum med.

Resultatet: IMAP-servern tar emot hundratals eller tusentals meddelanden på bara några minuter och tilldelar dem alla samma tidsintervall: nu.

Det är precis därför problemet sprider sig till alla dina enheter direkt. Din telefon, din surfplatta, din andra dator: de ansluter alla till samma IMAP-server och ser exakt samma sak. Det går inte att åtgärda på klientsidan.

Vilken klient visar vad, och varför

Alla e-postklienter reagerar inte på samma sätt. Det är något många IT-administratörer upptäcker i efterhand.

Outlook (i nyare versioner, och särskilt sedan uppdateringarna 2023-2024) använder serverns INTERNALDATE för kolumnen "Mottaget". Det visar alltså uppladdningsdatumet, inte det ursprungliga avsändningsdatumet. Mer om det specifika beteendet i Outlook finns i Outlook: mottaget datum IMAP vs skickat datum.

Gmail / Google Workspace och Thunderbird har lite mer nyanserade beteenden. Gmail kan ibland använda fältet Date: från meddelanderubriken för visningen, vilket ger intrycket att allt är okej... tills du försöker sortera efter datum och inser att ordningen är helt slumpmässig.

Apple Mail visar i allmänhet datumet från Date:-rubriken, men sortering och sökning använder INTERNALDATE i bakgrunden. Så dina e-postmeddelanden kan se rätt daterade ut visuellt, men sorteringsfunktionen fungerar inte längre korrekt. Mer om Apple Mails beteende i Apple Mail: fel datum efter migrering.

Det goda nyheten: originaldatumet är intakt

Rubriken Date: i varje e-postmeddelande, den som innehåller det riktiga avsändnings- (eller mottagnigs-)datumet, har inte ändrats. Den finns fortfarande kvar, i meddelandets innehåll. Det är den du ser när du öppnar ett e-postmeddelande och kollar detaljerna.

Det enda som IMAP-servern har "förstört" är INTERNALDATE, den metadata som är extern i förhållande till meddelandet. Meddelandet i sig är intakt.

Det är det som gör korrigering möjlig. Och det förklarar också varför problemet kan gå obemärkt en stund: e-postmeddelandena verkar korrekta när du öppnar dem ett och ett. Det är först när du tittar på listan i inkorgen, sorterad efter datum, som problemet blir synligt. E-post från 2019 dyker upp högst upp som om de precis anlänt. Alla med samma datum.

Skalproblemet: 3 000 e-postmeddelanden är inte detsamma som 3

Du tänker kanske: "Jag tar bort och importerar om, den här gången rätt." På 5 eller 10 test-e-postmeddelanden fungerar det. På en brevlåda med 8 000 meddelanden, kapslade mappar, stora bilagor, S/MIME-signerade e-postmeddelanden och trådar som sträcker sig tillbaka till 2015... är det en helt annan historia.

Ett hemmagjort skript som fungerar på 50 testmeddelanden kan mycket väl skapa dubbletter, tappa bilagor eller förstöra konversationstrådar i en produktionsbrevlåda. Hantering av API-kvoter, nätverkstimeouts, meddelanden med ovanliga MIME-strukturer... det är kantfall som ett icke-specialiserat verktyg inte klarar av.

Och om något går fel halvvägs? Utan backup- och återställningsmekanism förlorar du data utan möjlighet att återfå dem.

Problemet är välkänt bland admins som hanterar migrering i stor skala. Att förstå varför datum är trasiga är en sak. Att korrekt åtgärda 15 000 e-postmeddelanden och bevara varje meddelandestruktur är en helt annan. Mer om det i Kan e-postdatum korrigeras efter migrering?, som går igenom de olika metoderna och deras begränsningar.

Hur Redate.io hanterar det här fallet

Redate.io är byggt exakt för den här typen av situationer. Analysmotorn identifierar e-postmeddelanden där INTERNALDATE inte stämmer överens med datumet i meddelandets rubriker, oavsett om det rör sig om en POP-till-IMAP-migrering, en migrering mellan IMAP-servrar eller en manuell uppladdning av lokala arkiv.

Den flerstegsanalys-pipeline som inspekterar rubrikkedjan i varje meddelande validerar RFC-överensstämmelse och rekonstruerar datum-metadata utan att ändra meddelandeinnehållet: varken texten, bilagorna, MIME-strukturen eller eventuella digitala signaturer. Varje korrigerat e-postmeddelande verifieras individuellt före godkännande.

Originalen sparas i en synlig säkerhetskopia-mapp i 30 dagar. Om något inte stämmer kan du återställa.

Den inledande skanningen är gratis: Redate analyserar din brevlåda, identifierar de berörda e-postmeddelandena och visar det exakta antalet innan du bestämmer dig för något. Inget blindt åtagande.

Redate.io ansluter direkt till dina brevlådor via Google Workspace (domändelegering), Microsoft 365 (Azure AD) eller direkt IMAP. Ingen lokal installation. Inga .pst-filer att hantera manuellt.

För admins som hanterar flera brevlådor och vill ha erfarenhetsåterblick om den här typen av fall är MSP: korrigera e-postdatum hos dina kunder en bra kompletterande läsning. Och för Thunderbirds specifika beteende vid POP/IMAP-övergången, se Thunderbird: fel datum efter migrering.

Om det fortfarande ska göras: förebygg problemet

Om du ännu inte har laddat upp dina lokala arkiv till IMAP-servern, eller om du planerar fler POP-kontomigrationer i din organisation, är det här vad du bör tänka på.

• Kontrollera om din e-postklient stöder att explicit ange datum i APPEND-kommandot. Thunderbird har till exempel haft varierande beteende beroende på version i det avseendet.
• Testa först på ett valideringskonto med 50-100 representativa meddelanden: gamla e-postmeddelanden, med bilagor, signerade e-postmeddelanden. Kontrollera datumen som visas i olika klienter.
• Planera korrigeringen innan slutanvändarna börjar arbeta i den migrerade brevlådan. Att åtgärda datum i en aktiv brevlåda är mer komplext än i en ny post-migrering.
• Dokumentera antalet e-postmeddelanden före och efter migrering. Det är det enda sättet att upptäcka tysta förluster.

För en komplett checklista över vad du bör kontrollera före och efter en migrering täcker Checklista e-postmigrering: undvik datumproblem alla fallen.

Dina gamla e-postmeddelanden visar dagens datum efter en POP-till-IMAP-övergång? Kör en gratis skanning på Redate.io för att mäta problemets omfattning och korrigera datum-metadata utan att röra innehållet i dina meddelanden.