De tre datoene inne i hver e-post
Hver e-post lagret paa en IMAP-server baerer minst tre separate datoverdier. Aa forstaa hvordan disse datoene fungerer, og hvordan e-postklienter velger hvilken de skal vise, er noekkkelen til aa forstaa hvorfor migrering oedelegger datoer. Denne artikkelen er en teknisk dybdeanalyse av IMAP-datosystemet, rettet mot IT-administratorer og alle som oensker aa forstaa grunnorsaken til datoproblemer etter migrering.
1. RFC 2822 "Date"-headeren
"Date"-headeren er definert i RFC 2822 (format for internettmeldinger). Den settes av avsenderens e-postklient naar meldingen skrives og sendes. Denne headeren er en del av selve meldingsteksten - den foelger med meldingen og endres aldri av e-postservere underveis. En typisk Date-header ser slik ut:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Date-headeren representerer meldingens "sendedato". Det er den mest paalitelige datoen fordi den settes en gang og aldri endres. Den reflekterer imidlertid avsenderens klokke, som kan vaere feilkonfigurert. I sjeldne tilfeller kan Date-headeren vaere helt fravarende (saerlig i automatiserte systemvarsler eller feilformaterte meldinger).
2. IMAP INTERNALDATE
INTERNALDATE er definert i RFC 3501 (IMAP4rev1-protokollen). Det er en serverside metadataverdi som representerer datoen og klokkeslettet meldingen ble levert til serveren. I motsetning til Date-headeren er INTERNALDATE ikke en del av selve e-postmeldingen. Den lagres separat av IMAP-serveren som metadata.
Naar en e-post leveres normalt (ikke migrert), setter IMAP-serveren INTERNALDATE til gjeldende klokkeslett ved leveringstidspunktet. Denne verdien samsvarer tett med Date-headeren, vanligvis innenfor noen sekunder eller minutter. E-postklienter bruker ofte INTERNALDATE som "mottaksdato" fordi den reflekterer naar serveren faktisk mottok meldingen.
Og her blir det interessant. Naar en melding settes inn via IMAP APPEND-kommandoen (som migreringsverktoy bruker), lar APPEND-kommandoen klienten spesifisere INTERNALDATE eksplisitt. Veldesignede migreringsverktoy bruker denne funksjonen for aa bevare den opprinnelige INTERNALDATE fra kildeserveren. Men selv naar INTERNALDATE er korrekt satt, kan "Received"-headerproblemet (beskrevet nedenfor) fortsatt overstyre den viste datoen i mange klienter.
3. "Received"-headerkjeden
Hver gang en e-post passerer gjennom en e-postserver, legger den serveren til en "Received"-header oeverst i meldingen. Dette skaper en kjede av Received-headere som registrerer e-postens reise fra avsender til mottaker. Den nyeste (oeverst) viser den siste serveren som behandlet meldingen, og den eldste (nederst) viser den foerste.
En normal e-post kan ha 3 til 6 Received-headere, som dokumenterer reisen fra avsenderens utgaaende server gjennom releer til mottakerens innkommende server. Hver Received-header inkluderer et tidsstempel. Her er et forenklet eksempel:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Hvordan e-postklienter velger hvilken dato aa vise
Outlook (Desktop, Web, Mobil)
Microsoft Outlook bruker en kombinasjon av INTERNALDATE og den nyeste "Received"-headeren for aa bestemme "Mottatt"-datoen som vises i innboksen. I praksis tenderer Outlook mot aa prioritere tidsstempelet i den nyeste Received-headeren for "Mottatt"-kolonnen. "Sendt"-kolonnen bruker Date-headeren. Siden Outlook som standard sorterer etter "Mottatt"-kolonnen, er det Received-headerens tidsstempel brukerne ser foerst.
Apple Mail
Apple Mail paa macOS og iOS bruker primaert IMAP INTERNALDATE for aa vise datoen. Hvis INTERNALDATE ble korrekt bevart under migreringen, kan Apple Mail vise riktig dato - men bare hvis INTERNALDATE ble eksplisitt satt under APPEND-operasjonen. Hvis migreringsverktoeyet ikke satte INTERNALDATE, bruker serveren innsettingstidspunktet (migreringsdatoen) som standard. For detaljer om innvirkningen for Apple Mail-brukere, se Apple Mail: feil dato etter migrering.
Thunderbird
Mozilla Thunderbird tilbyr mest fleksibilitet. Den kan vise baade "Dato" (fra Date-headeren) og "Mottatt" (fra Received-headere). Som standard viser Thunderbird Date-headerens verdi, noe som betyr at datoer kan se korrekte ut i Thunderbird selv naar de er feil i Outlook. "Mottatt"-kolonnen i Thunderbird viser alltid migreringsdatoen. Se Thunderbird: feil dato etter migrering for mer informasjon.
Gmails webgrensesnitt
Gmails webklient bruker Date-headeren for sin primaere datovisning. Det betyr at Gmail web ofte viser korrekte datoer selv etter migrering. Men IMAP INTERNALDATE paa Gmail-serveren er likevel feil, noe som paavirker hver IMAP-klient som kobler til den Gmail-kontoen. Forskjellen mellom Gmail web og Outlook eller Apple Mail er en hyppig kilde til forvirring, og en som koster administratorer mye feilsoekingstid.
Hvorfor IMAP APPEND oedelegger datoer
Hva som skjer under migrering
Naar et migreringsverktoy flytter en e-post fra Server A til Server B, kobler verktoeyet til Server A via IMAP og laster ned raameldingen, og kobler deretter til Server B og bruker APPEND-kommandoen for aa sette den inn. Under denne innsettingen behandler Server B den innkommende meldingen og legger til en ny Received-header med gjeldende tidsstempel: migreringsdatoen. Det er standard IMAP-oppfoersel definert i protokollen. Serveren behandler hver APPEND som en ny meldingslevering.
Resultatet: en kontaminert headerkjede
Etter migrering ser e-postens Received-headere slik ut:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Migreringsverktoyets Received-header er naa den oeverste oppfoeringen. Enhver e-postklient som bruker den nyeste Received-headeren for aa bestemme visningsdatoen (Outlook, spesielt) vil vise "11. april 2025" i stedet for "15. januar 2024". Den opprinnelige Date-headeren og de opprinnelige Received-headerne er fortsatt intakte nedenfor, men de er ikke lenger i posisjonen e-postklienter prioriterer.
Selv god INTERNALDATE-haandtering forhindrer ikke dette
Noen migreringsverktoy setter INTERNALDATE korrekt under APPEND. For eksempel bevarer imapsync eksplisitt INTERNALDATE fra kildeserveren. Men Received-headeren legges til av maalserveren, ikke av migreringsverktoeyet. Migreringsverktoeyet har ingen kontroll over denne oppfoerselen. Selv med perfekt INTERNALDATE-bevaring inneholder den oeverste Received-headeren fortsatt migreringsdatoen, og klienter som Outlook viser fortsatt feil dato.
Kort sagt, hva kan man konkret gjoere med det?
Hvilke migreringsverktoy legger til Received-headere
Alle IMAP-migreringsverktoy foraarsaker dette problemet fordi Received-headeren legges til av maalserveren, ikke av verktoeyet selv. Innholdet i den tillagte headeren varierer etter verktoy og server.
BitTitan MigrationWiz legger til en Received-header som inneholder "mx.migrationwiz.com". CloudM Migrate legger til headere som refererer til "cloudm.io". imapsync utloeser en generisk Received-header fra maalserveren. GSMMO legger til headere med "gmailapi.google.com"-referanser.
Korreksjonen: gjenopprette korrekte datoer
Den gode nyheten er at korrekt datoinformasjon fortsatt eksisterer i hver e-post. Den opprinnelige Date-headeren er intakt. De opprinnelige Received-headerne er intakte. Problemet er at en kontaminerende header sitter oppaa dem.
Redate.ios proprietaere korreksjonsmotor analyserer den fullstendige headerkjeden til hver paavirket e-post, og anvender signaturmatchning mot hundrevis av kjente migreringsverktoeysignaturer for aa identifisere noeyaktig hvilke headere som trenger korrigering. Den flertrinns analysepipelinen haandterer spesialtilfellene som faar enklere tilnaerminger til aa feile: S/MIME-signerte meldinger, PGP-kryptert innhold, multipart/alternative-strukturer, Content-Transfer-Encoding-problemer, ikke-ASCII-headere (RFC 2047), store vedlegg og korrupte MIME-grenser.
Etter korreksjon gjennomgaar hver e-post en integritetsverifiseringsprosess for aa bekrefte at meldingens struktur, innhold og vedlegg er bevart identisk. Originaler bevares i en synlig sikkerhetskopimappe i 30 dager.
Kunne du skrive et skript for aa forsoeke denne korreksjonen selv? Teknisk sett, ja. Men forskjellen mellom "det fungerer paa 95 % av e-postene" og "det fungerer paa 100 % av e-postene uten aa korruptere en eneste" representerer maaneders utvikling. Og naar det gjelder noens fullstendige postkasse, betyr en feilrate paa 5 % hundrevis av stille skadede meldinger uten mulighet til aa verifisere hva som gikk galt.
Vil du vite hvor mange e-poster i postkassen din har feil datoer? Kjoer en gratis analyse med Redate.io for aa faa en umiddelbar telling av paavirkede e-poster, uten betaling krevd.