IMAP INTERNALDATE: hvorfor datoer ødelegges

De tre datoene inne i hver e-post

Hver e-post lagret på en IMAP-server bærer minst tre separate datoverdier. Å forstå hvordan disse datoene fungerer, og hvordan e-postklienter velger hvilken de skal vise, er nøkkelen til å forstå hvorfor migrering ødelegger datoer. Denne artikkelen er en teknisk dybdeanalyse av IMAP-datosystemet, rettet mot IT-administratorer og alle som ønsker å forstå grunnårsaken 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 når meldingen skrives og sendes. Denne headeren er en del av selve meldingsteksten - den følger 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 pålitelige datoen fordi den settes en gang og aldri endres. Den reflekterer imidlertid avsenderens klokke, som kan være feilkonfigurert. I sjeldne tilfeller kan Date-headeren være helt fraværende (særlig 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.

Når 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 når serveren faktisk mottok meldingen.

Og her blir det interessant. Når en melding settes inn via IMAP APPEND-kommandoen (som migreringsverktøy bruker), lar APPEND-kommandoen klienten spesifisere INTERNALDATE eksplisitt. Veldesignede migreringsverktøy bruker denne funksjonen for å bevare den opprinnelige INTERNALDATE fra kildeserveren. Men selv når 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 øverst i meldingen. Dette skaper en kjede av Received-headere som registrerer e-postens reise fra avsender til mottaker. Den nyeste (øverst) viser den siste serveren som behandlet meldingen, og den eldste (nederst) viser den første.

En normal e-post kan ha 3 til 6 Received-headere, som dokumenterer reisen fra avsenderens utgående server gjennom reléservere 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 å vise

Outlook (Desktop, Web, Mobil)

Microsoft Outlook bruker en kombinasjon av INTERNALDATE og den nyeste "Received"-headeren for å bestemme "Mottatt"-datoen som vises i innboksen. I praksis tenderer Outlook mot å 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 først.

Apple Mail

Apple Mail på macOS og iOS bruker primært IMAP INTERNALDATE for å 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 migreringsverktøyet 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 både "Dato" (fra Date-headeren) og "Mottatt" (fra Received-headere). Som standard viser Thunderbird Date-headerens verdi, noe som betyr at datoene kan se korrekte ut i Thunderbird selv når 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 primære datovisning. Det betyr at Gmail web ofte viser korrekte datoer selv etter migrering. Men IMAP INTERNALDATE på Gmail-serveren er likevel feil, noe som påvirker 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 feilsøkingstid.

Hvorfor IMAP APPEND ødelegger datoer

Hva som skjer under migrering

Når et migreringsverktøy flytter en e-post fra Server A til Server B, kobler verktøyet til Server A via IMAP og laster ned råmeldingen, og kobler deretter til Server B og bruker APPEND-kommandoen for å 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-oppførsel 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

Migreringsverktøyets Received-header er nå den øverste oppføringen. Enhver e-postklient som bruker den nyeste Received-headeren for å 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-håndtering forhindrer ikke dette

Noen migreringsverktøy setter INTERNALDATE korrekt under APPEND. For eksempel bevarer imapsync eksplisitt INTERNALDATE fra kildeserveren. Men Received-headeren legges til av målserveren, ikke av migreringsverktøyet. Migreringsverktøyet har ingen kontroll over denne oppførselen. Selv med perfekt INTERNALDATE-bevaring inneholder den øverste Received-headeren fortsatt migreringsdatoen, og klienter som Outlook viser fortsatt feil dato.

Kort sagt, hva kan man konkret gjøre med det?

Hvilke migreringsverktøy legger til Received-headere

Alle IMAP-migreringsverktøy forårsaker dette problemet fordi Received-headeren legges til av målserveren, ikke av verktøyet selv. Innholdet i den tillagte headeren varierer etter verktøy 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 utløser en generisk Received-header fra målserveren. 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 oppå dem.

Redate.ios egenutviklede korreksjonsmotor analyserer den fullstendige headerkjeden til hver påvirket e-post og identifiserer avvik i datostemplene for å avgjøre nøyaktig hvilke headere som trenger korrigering. Metoden virker med ethvert migreringsverktøy. Den flertrinns analysepipelinen håndterer spesialtilfellene som får enklere tilnærminger til å 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 gjennomgår hver e-post en integritetsverifiseringsprosess for å bekrefte at meldingens struktur, innhold og vedlegg er bevart identisk. Originaler flyttes til en synlig sikkerhetskopimappe i postkassen og blir liggende der til kunden fjerner dem.

Kunne du skrive et skript for å forsøke denne korreksjonen selv? Teknisk sett, ja. Men forskjellen mellom "det fungerer på 95 % av e-postene" og "det fungerer på 100 % av e-postene uten å korruptere en eneste" representerer måneders utvikling. Og når det gjelder en hel postkasse, betyr en feilrate på 5 % hundrevis av stille skadede meldinger uten mulighet til å verifisere hva som gikk galt.

Vil du vite hvor mange e-poster i postkassen din har feil datoer? Kjør en gratis analyse med Redate.io for å få en umiddelbar telling av påvirkede e-poster, uten betaling krevd.