POP til IMAP: gamle e-poster viser dagens dato

Scenariet du kjenner igjen fra mandag morgen

Du har nettopp byttet e-postkontoen din fra POP3 til IMAP. Oppsettet gikk greit, leverandøren din hjalp deg gjennom det, alt virket fint. Helt til du åpnet innboksen igjen. E-poster fra 2019, 2021, arkiver fra i fjor... alle viser samme dato: i dag. Noen ganger til og med samme klokkeslett, ned til noen sekunder.

Dette er ikke en feil i e-postklienten din. Det er ikke et tidssone-problem. Det er forventet oppførsel fra IMAP-protokollen, og det rammer alle som laster opp lokalt lagrede e-poster til en server via denne metoden.

POP3 vs IMAP: en grunnleggende forskjell i lagring

For å forstå hvorfor problemet oppstår, må du først forstå hvordan POP3 fungerer, og hva som skiller det radikalt fra IMAP.

Med POP3 fungerer serveren kun som en midlertidig postkasse. Klienten din (Outlook, Thunderbird, Apple Mail) kobler til, laster ned meldingene, og sletter dem fra serveren etterpå (eller beholder dem, avhengig av innstillingene dine). E-postene lever deretter utelukkende lokalt: i en .pst-fil for Outlook, i Thunderbirds lokale profil, i en database på harddisken din.

Med IMAP er det motsatt: e-postene lever på serveren. Klienten din viser bare det som er lagret eksternt. Derav den transparente synkroniseringen mellom alle enhetene dine.

Problemet oppstår i overgangen mellom de to. Når du laster opp de gamle lokale POP-e-postene til IMAP-serveren.

IMAP APPEND: kommandoen som endrer alt

Når e-postklienten din laster opp en lokal melding til en IMAP-server, bruker den kommandoen IMAP APPEND. Denne kommandoen sier til serveren: "lagre denne meldingen i den og den mappen".

Serveren mottar meldingen, lagrer den, og tilordner et tidsstempel. Dette tidsstempelet kalles INTERNALDATE. Det er den sentrale metadataen i IMAP: den angir når meldingen ble plassert på serveren. Og som standard, hvis klienten ikke eksplisitt oppgir en dato i APPEND-kommandoen, bruker serveren... nåværende tidspunkt.

Med andre ord: uansett om meldingen inneholder en dato fra 2018 i hodene sine, hvis ingen forteller serveren "denne e-posten er fra 2018", konkluderer serveren med at den ble levert nå, og tilordner dagens INTERNALDATE.

(Har du noen gang sett på rå e-posthoder, vet du at det ikke akkurat er avslappende lesning. Du ser Date:-linjen midt blant en rekke Received:-linjer. Dette Date:-feltet, definert av RFC 2822, inneholder den reelle avsendingsdatoen. Men IMAP INTERNALDATE er en separat metadata lagret på serversiden, som ikke har noe med selve meldingsinnholdet å gjøre.)

Hvorfor dette er annerledes enn en IMAP-til-IMAP-migrering

Ved en vanlig migrering fra én IMAP-server til en annen (med BitTitan, CloudM, imapsync osv.) er problemet litt annerledes. Migreringverktøyet kopierer meldinger fra én server til en annen, og kan i prinsippet sende den opprinnelige INTERNALDATE til destinasjonsserveren via APPEND-kommandoen. Problemet der er at noen verktøy legger til et Received:-hode med migreringsdatoen, noe som forstyrrer visningen i klienter som Outlook.

I ditt tilfelle starter du fra rent lokale data. Det finnes ingen kilde-INTERNALDATE å kopiere. .pst-filen eller Thunderbird-profilen lagrer meldingene i sitt eget proprietære format, med sine egne interne metadata. Når e-postklienten leser disse meldingene på nytt for å laste dem opp til IMAP-serveren, rekonstruerer den APPEND-kommandoen fra meldingsinnholdet. Og som oftest sender den ikke en eksplisitt dato.

Resultatet: IMAP-serveren mottar hundrevis eller tusenvis av meldinger i løpet av minuttene som følger, og tilordner dem alle det samme tidsintervallet: nå.

Det er nøyaktig derfor problemet umiddelbart vises på alle enhetene dine. Telefonen, nettbrettet, den andre PC-en: de kobler alle til den samme IMAP-serveren og ser nøyaktig det samme. Ingen korrigering er mulig på klientsiden.

Hvilken klient viser hva, og hvorfor

Ikke alle e-postklienter reagerer på samme måte. Det er noe mange IT-administratorer oppdager i etterkant.

Outlook (i nyere versjoner, særlig etter oppdateringene i 2023-2024) bruker serverens INTERNALDATE for "Mottatt"-kolonnen. Den viser altså opplastingsdatoen, ikke den opprinnelige avsendingsdatoen. Mer om denne spesifikke oppførselen i Outlook finner du i artikkelen Outlook: mottaksdato IMAP vs sendedato etter migrering.

Gmail / Google Workspace og Thunderbird oppfører seg litt mer nyansert. Gmail kan for eksempel noen ganger bruke Date:-feltet i meldingshodet for visning, noe som gir inntrykk av at alt er i orden... helt til du prøver å sortere etter dato og innser at rekkefølgen er fullstendig tilfeldig.

Apple Mail viser vanligvis datoen hentet fra Date:-hodet, men sortering og søk bruker INTERNALDATE i bakgrunnen. E-postene dine kan altså se ut til å ha riktig dato visuelt, mens sorteringsfunksjonen ikke lenger fungerer korrekt. Se mer om Apple Mails oppførsel i artikkelen Apple Mail: feil dato etter e-postmigrering.

Den gode nyheten: den opprinnelige datoen er intakt

Date:-hodet i hver e-post, det som inneholder den reelle avsendingsdatoen (eller mottaksdatoen), er ikke rørt. Det er fortsatt der, i meldingsteksten. Det er dette du ser når du åpner en e-post og ser på detaljene.

Det IMAP-serveren har "ødelagt", er utelukkende INTERNALDATE, denne metadataen som er ekstern i forhold til selve meldingen. Meldingen i seg selv er intakt.

Det er dette som gjør korrigering mulig. Og det forklarer også hvorfor problemet kan gå ubemerket en stund: e-postene ser riktige ut når du åpner dem én etter én. Det er først når du ser på innbokslisten sortert etter dato at problemet blir synlig. E-poster fra 2019 dukker opp øverst som om de nettopp ankom. Alle med samme dato.

Skalaproblemet: 3000 e-poster er ikke det samme som 3

Kanskje tenker du: "Jeg sletter bare og importerer på nytt, denne gangen riktig." På 5 eller 10 test-e-poster, ja, det fungerer. På en postkasse med 8000 meldinger, nestede mapper, store vedlegg, S/MIME-signerte e-poster og tråder som går tilbake til 2015... er det en helt annen sak.

Et hjemmelaget skript som fungerer på en testbatch med 50 e-poster kan godt produsere duplikater, miste vedlegg eller ødelegge konversasjonstråder på en produksjonspostkasse. Håndtering av API-kvoter, nettverkstimeouts, meldinger med atypiske MIME-strukturer... dette er kanttilfeller som et uspesialisert verktøy ikke håndterer.

Og hvis noe går galt midtveis? Uten en backup- og rollback-mekanisme mister du data uten mulighet til å gjenopprette dem.

Problemet er godt kjent blant administratorer som håndterer migreringer i stort volum. Å forstå hvorfor datoene er ødelagt er én ting. Å korrigere 15 000 e-poster skikkelig og bevare hver meldingsstruktur er noe helt annet. For mer om dette, går artikkelen Kan e-postdatoer rettes etter migrering? gjennom de ulike tilnærmingene og begrensningene deres.

Slik håndterer Redate.io dette spesifikke tilfellet

Redate.io er bygget nettopp for denne typen situasjoner. Analysemotoren identifiserer e-poster der INTERNALDATE ikke samsvarer med datoen i meldingshodene, enten det dreier seg om en POP-til-IMAP-migrering, en migrering mellom IMAP-servere, eller en manuell opplasting av lokale arkiver.

Den flertrinns analysepipelinen inspiserer hodekjeden til hver melding, validerer RFC-samsvar, og rekonstruerer datometadataene uten å endre meldingsinnholdet: verken tekst, vedlegg, MIME-struktur eller eventuelle digitale signaturer. Hver korrigert e-post verifiseres individuelt før validering.

Originalene beholdes i en synlig sikkerhetskopieringsmappe i 30 dager. Hvis noe ikke stemmer, kan du gjenopprette.

Det innledende skannet er gratis: Redate analyserer postkassen din, identifiserer berørte e-poster, og forteller deg det eksakte antallet før du bestemmer deg for noe. Ingen blindt engasjement.

Redate.io kobler seg direkte til postkassene dine via Google Workspace (domenedelegering), Microsoft 365 (Azure AD), eller direkte IMAP. Ingen lokal installasjon. Ingen .pst-filer å håndtere manuelt.

For administratorer som håndterer flere postkasser og vil lese om erfaringer med denne typen tilfeller, er artikkelen MSP: fiks e-postdatoer hos kundene dine god supplerende lesning. Og for Thunderbirds spesifikke oppførsel ved POP/IMAP-overgangen, se Thunderbird: feil dato etter e-postmigrering.

Hvis du ikke har gjort det ennå: forebygg problemet

Hvis du ennå ikke har lastet opp lokale arkiver til IMAP-serveren, eller planlegger å migrere flere POP-kontoer i organisasjonen din, er her det du bør huske på.

• Sjekk om e-postklienten din støtter eksplisitt datooverføring i APPEND-kommandoen. Thunderbird har for eksempel hatt varierende oppførsel på dette punktet avhengig av versjon.
• Gjør først en test på en valideringskonto med 50-100 representative meldinger: gamle e-poster, med vedlegg, signerte e-poster. Kontroller de viste datoene i forskjellige klienter.
• Planlegg korrigeringen før sluttbrukerne begynner å arbeide i den migrerte postkassen. Å rette datoer i en aktiv postkasse er mer komplisert enn i en fersk post-migrering-postkasse.
• Dokumenter antall e-poster før og etter migreringen. Det er den eneste måten å oppdage stille tap på.

For en fullstendig sjekkliste over hva du bør kontrollere før og etter en migrering, dekker artikkelen Sjekkliste for e-postmigrering: unngå datotrøbbel alle tilfellene.

Viser de gamle e-postene dine dagens dato etter overgangen fra POP til IMAP? Start et gratis skann på Redate.io for å kartlegge omfanget av problemet og rette datometadataene uten å røre meldingsinnholdet.