IMAP INTERNALDATE: hvorfor datoer går i stykker

De tre datoer inde i hver e-mail

Hver e-mail gemt på en IMAP-server indeholder mindst tre separate datoværdier. At forstå hvordan disse datoer fungerer, og hvordan e-mailklienter vælger hvilken der vises, er nøglen til at forstå hvorfor migrering ødelægger datoer. Denne artikel er en dybtgående teknisk analyse af IMAP-datosystemet, rettet mod IT-administratorer og alle der ønsker at forstå den grundlæggende årsag til datoproblemer efter migrering.

1. RFC 2822 "Date"-headeren

"Date"-headeren er defineret i RFC 2822 (Internet Message Format). Den sættes af afsenderens e-mailklient på det tidspunkt beskeden skrives og sendes. Denne header er del af selve beskedkroppen, den rejser med beskeden og ændres aldrig af mailservere undervejs. En typisk Date-header ser sådan ud:

Date: Mon, 15 Jan 2024 09:32:17 +0100

Date-headeren repræsenterer beskedens "afsendelsesdato". Det er den mest pålidelige dato fordi den sættes en gang og aldrig ændres. Den afspejler dog afsenderens ur, som kan være forkert konfigureret. I sjældne tilfælde kan Date-headeren være helt fraværende (særligt i automatiserede systemnotifikationer eller misdannede beskeder).

2. IMAP INTERNALDATE

INTERNALDATE er defineret i RFC 3501 (IMAP4rev1-protokollen). Det er en serverside-metadataværdi der repræsenterer dato og tid for hvornår beskeden blev leveret til serveren. I modsætning til Date-headeren er INTERNALDATE ikke del af selve e-mailbeskeden. Den gemmes separat af IMAP-serveren som metadata.

Når en e-mail leveres normalt (ikke migreret), sætter IMAP-serveren INTERNALDATE til det aktuelle tidspunkt ved levering. Denne værdi matcher Date-headeren tæt, typisk inden for få sekunder eller minutter. E-mailklienter bruger ofte INTERNALDATE som "modtagelsesdato" fordi den afspejler hvornår serveren faktisk modtog beskeden.

Og her bliver det interessant. Når en besked indsættes via IMAP APPEND-kommandoen (som migreringsværktøjer bruger), giver APPEND-kommandoen klienten mulighed for at specificere INTERNALDATE eksplicit. Veldesignede migreringsværktøjer bruger denne funktion til at bevare den originale INTERNALDATE fra kildeserveren. Men selv når INTERNALDATE sættes korrekt, kan "Received"-header-problemet (beskrevet nedenfor) stadig overskrive den viste dato i mange klienter.

3. "Received"-headerkæden

Hver gang en e-mail passerer en mailserver, tilføjer den server en "Received"-header øverst i beskeden. Det skaber en kæde af "Received"-headers der dokumenterer e-mailens rejse fra afsender til modtager. Den nyeste (øverst) viser den sidste server der behandlede beskeden, og den ældste (nederst) viser den første.

En normal e-mail kan have 3 til 6 "Received"-headers der dokumenterer rejsen fra afsenderens udgående server gennem relays til modtagerens indgående 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-mailklienter vælger hvilken dato der vises

Outlook (Desktop, Web, Mobile)

Microsoft Outlook bruger en kombination af INTERNALDATE og den nyeste "Received"-header til at bestemme "Modtaget"-datoen vist i indbakken. I praksis tenderer Outlook til at prioritere den nyeste "Received"-headers tidsstempel til kolonnen "Modtaget". Kolonnen "Sendt" bruger Date-headeren. Da Outlook som standard sorterer efter kolonnen "Modtaget", er det "Received"-headerens tidsstempel brugerne ser først.

Apple Mail

Apple Mail på macOS og iOS bruger primært IMAP INTERNALDATE til at vise datoen. Hvis INTERNALDATE er korrekt bevaret under migreringen, kan Apple Mail vise den rigtige dato, men kun hvis INTERNALDATE eksplicit blev sat under APPEND-operationen. Hvis migreringsværktøjet ikke satte INTERNALDATE, bruger serveren som standard indsættelsestidspunktet (migreringsdatoen). For detaljer om påvirkningen på Apple Mail-brugere, se Apple Mail: forkert dato efter migrering.

Thunderbird

Mozilla Thunderbird tilbyder mest fleksibilitet. Den kan vise både "Dato" (fra Date-headeren) og "Modtaget" (fra "Received"-headers). Som standard viser Thunderbird Date-headerens værdi, hvilket betyder at datoer kan se korrekte ud i Thunderbird selv når de er forkerte i Outlook. Kolonnen "Modtaget" i Thunderbird viser altid migreringsdatoen. Se Thunderbird: forkert dato efter migrering for flere detaljer.

Gmails webgrænseflade

Gmails webclient bruger Date-headeren til sin primære datovisning. Det betyder at Gmail web ofte viser korrekte datoer selv efter migrering. Men IMAP INTERNALDATE på Gmail-serveren er stadig forkert, hvilket påvirker enhver IMAP-klient der forbinder til den Gmail-konto. Forskellen mellem Gmail web og Outlook eller Apple Mail er en hyppig kilde til forvirring, og en der koster administratorer mange fejlsøgningstimer.

Hvorfor IMAP APPEND ødelægger datoer

Hvad der sker under migrering

Når et migreringsværktøj flytter en e-mail fra Server A til Server B, forbinder værktøjet til Server A via IMAP og downloader den rå besked, forbinder derefter til Server B og bruger APPEND-kommandoen til at indsætte den. Under denne indsættelse behandler Server B den indgående besked og tilføjer en ny "Received"-header med det aktuelle tidsstempel: migreringsdatoen. Serveren behandler hver APPEND som en ny beskedlevering, uanset hvilket migreringsværktøj der bruges.

Resultatet: en forurenet headerkæde

Efter migrering ser e-mailens "Received"-headers sådan ud:

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

Migreringsværktøjets "Received"-header er nu den øverste post. Enhver e-mailklient der bruger den nyeste "Received"-header til at bestemme visningsdatoen (Outlook, særligt) vil vise "11. april 2025" i stedet for "15. januar 2024". Den originale Date-header og de originale "Received"-headers er stadig intakte nedenunder, men de er ikke længere i den position e-mailklienter prioriterer.

Selv god INTERNALDATE-håndtering forhindrer ikke dette

Nogle migreringsværktøjer sætter korrekt INTERNALDATE under APPEND. F.eks. bevarer imapsync eksplicit INTERNALDATE fra kildeserveren. Men "Received"-headeren tilføjes af destinationsserveren, ikke af migreringsværktøjet. Migreringsværktøjet har ingen kontrol over denne adfærd. Selv med perfekt INTERNALDATE-bevarelse indeholder den øverste "Received"-header stadig migreringsdatoen, og klienter som Outlook viser stadig den forkerte dato.

Kort sagt, hvad kan man konkret gøre ved det?

Hvilke migreringsværktøjer tilføjer "Received"-headers

Alle IMAP-migreringsværktøjer forårsager dette problem fordi "Received"-headeren tilføjes af destinationsserveren, ikke af værktøjet selv. Indholdet af den tilføjede header varierer efter værktøj og server.

BitTitan MigrationWiz tilføjer en "Received"-header indeholdende "mx.migrationwiz.com". CloudM Migrate tilføjer headers der refererer "cloudm.io". imapsync udløser en generisk "Received"-header fra destinationsserveren. GSMMO tilføjer headers med "gmailapi.google.com"-referencer.

Rettelsen: gendan korrekte datoer

Den gode nyhed er at de korrekte datooplysninger stadig eksisterer i hver e-mail. Den originale Date-header er intakt. De originale "Received"-headers er intakte. Problemet er at en forurenende header sidder oven på dem.

Redate.io's egenudviklede korrektionsmotor analyserer den komplette headerkæde for hver påvirket e-mail og opdager datoafvigelserne i headerne for præcist at identificere hvilke headers der skal korrigeres. Metoden virker uanset hvilket migreringsværktøj der er brugt. Den flertrins analysepipeline håndterer de særtilfælde der får simplere tilgange til at fejle: S/MIME-signerede beskeder, PGP-krypteret indhold, multipart/alternative-strukturer, Content-Transfer-Encoding-problemer, ikke-ASCII-headers (RFC 2047), overstore vedhæftninger og korrupte MIME-grænser.

Efter korrektion gennemgår hver e-mail en integritetsverifikationsproces for at bekræfte at beskedens struktur, indhold og vedhæftninger er bevaret identisk. Originalerne flyttes til en synlig backup-mappe i postkassen og forbliver der, indtil kunden selv fjerner dem.

Kunne man skrive et script for at forsøge denne korrektion selv? Teknisk ja. Men forskellen mellem "det virker på 95 % af e-mails" og "det virker på 100 % af e-mails uden at korrumpere en eneste" repræsenterer måneders udvikling. Og når man taler om en persons komplette postkasse, betyder en fejlrate på 5 % hundredvis af beskeder stille og roligt beskadiget uden mulighed for at verificere hvad der gik galt.

Vil du vide hvor mange e-mails i din postkasse der har forkerte datoer? Start en gratis analyse med Redate.io for at få en øjeblikkelig optælling af påvirkede e-mails, uden krav om betaling.