De tre datoer inde i hver e-mail
Hver e-mail gemt paa en IMAP-server indeholder mindst tre separate datovaerdier. At forstaa hvordan disse datoer fungerer, og hvordan e-mailklienter vaelger hvilken der vises, er noeglen til at forstaa hvorfor migrering oedelaegger datoer. Denne artikel er en dybtgaaende teknisk analyse af IMAP-datosystemet, rettet mod IT-administratorer og alle der oensker at forstaa den grundlaeggende aarsag til datoproblemer efter migrering.
1. RFC 2822 "Date"-headeren
"Date"-headeren er defineret i RFC 2822 (Internet Message Format). Den saettes af afsenderens e-mailklient paa det tidspunkt beskeden skrives og sendes. Denne header er del af selve beskedkroppen - den rejser med beskeden og aendres aldrig af mailservere undervejs. En typisk Date-header ser saadan ud:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Date-headeren repraesenterer beskedens "afsendelsesdato". Det er den mest paalidelige dato fordi den saettes en gang og aldrig aendres. Den afspejler dog afsenderens ur, som kan vaere forkert konfigureret. I sjaeldne tilfaelde kan Date-headeren vaere helt fravaerende (saerligt i automatiserede systemnotifikationer eller misdannede beskeder).
2. IMAP INTERNALDATE
INTERNALDATE er defineret i RFC 3501 (IMAP4rev1-protokollen). Det er en serverside-metadatavaerdi der repraesenterer dato og tid for hvornaar beskeden blev leveret til serveren. I modsaetning til Date-headeren er INTERNALDATE ikke del af selve e-mailbeskeden. Den gemmes separat af IMAP-serveren som metadata.
Naar en e-mail leveres normalt (ikke migreret), saetter IMAP-serveren INTERNALDATE til det aktuelle tidspunkt ved levering. Denne vaerdi matcher Date-headeren taet, typisk inden for faa sekunder eller minutter. E-mailklienter bruger ofte INTERNALDATE som "modtagelsesdato" fordi den afspejler hvornaar serveren faktisk modtog beskeden.
Og her bliver det interessant. Naar en besked indsaettes via IMAP APPEND-kommandoen (som migreringsvaerktojer bruger), giver APPEND-kommandoen klienten mulighed for at specificere INTERNALDATE eksplicit. Veldesignede migreringsvaerktojer bruger denne funktion til at bevare den originale INTERNALDATE fra kildeserveren. Men selv naar INTERNALDATE saettes korrekt, kan "Received"-header-problemet (beskrevet nedenfor) stadig overskrive den viste dato i mange klienter.
3. "Received"-headerkaeden
Hver gang en e-mail passerer en mailserver, tilfojer den server en "Received"-header oeverst i beskeden. Det skaber en kaede af "Received"-headers der dokumenterer e-mailens rejse fra afsender til modtager. Den nyeste (oeverst) viser den sidste server der behandlede beskeden, og den aeldste (nederst) viser den foerste.
En normal e-mail kan have 3 til 6 "Received"-headers der dokumenterer rejsen fra afsenderens udgaaende server gennem relays til modtagerens indgaaende 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 vaelger 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 foerst.
Apple Mail
Apple Mail paa macOS og iOS bruger primaert 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 migreringsvaerktojet ikke satte INTERNALDATE, bruger serveren som standard indsaettelsestidspunktet (migreringsdatoen). For detaljer om paavirkningn paa Apple Mail-brugere, se Apple Mail: forkert dato efter migrering.
Thunderbird
Mozilla Thunderbird tilbyder mest fleksibilitet. Den kan vise baade "Dato" (fra Date-headeren) og "Modtaget" (fra "Received"-headers). Som standard viser Thunderbird Date-headerens vaerdi, hvilket betyder at datoer kan se korrekte ud i Thunderbird selv naar de er forkerte i Outlook. Kolonnen "Modtaget" i Thunderbird viser altid migreringsdatoen. Se Thunderbird: forkert dato efter migrering for flere detaljer.
Gmails webgraenseflade
Gmails webclient bruger Date-headeren til sin primaere datovisning. Det betyder at Gmail web ofte viser korrekte datoer selv efter migrering. Men IMAP INTERNALDATE paa Gmail-serveren er stadig forkert, hvilket paavirker 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 fejlsogniingstimer.
Hvorfor IMAP APPEND oedelaegger datoer
Hvad der sker under migrering
Naar et migreringsvaerktoej flytter en e-mail fra Server A til Server B, forbinder vaerktojet til Server A via IMAP og downloader den raa besked, forbinder derefter til Server B og bruger APPEND-kommandoen til at indsaette den. Under denne indsaettelse behandler Server B den indgaaende besked og tilfojer en ny "Received"-header med det aktuelle tidsstempel: migreringsdatoen. Det er standard IMAP-adfaerd defineret i protokollen. Serveren behandler hver APPEND som en ny beskedlevering.
Resultatet: en forurenet headerkade
Efter migrering ser e-mailens "Received"-headers saadan 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
Migreringsvaerktojets "Received"-header er nu den oeverste post. Enhver e-mailklient der bruger den nyeste "Received"-header til at bestemme visningsdatoen (Outlook, saerligt) 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 laengere i den position e-mailklienter prioriterer.
Selv god INTERNALDATE-haandtering forhindrer ikke dette
Nogle migreringsvaerktojer saetter korrekt INTERNALDATE under APPEND. F.eks. bevarer imapsync eksplicit INTERNALDATE fra kildeserveren. Men "Received"-headeren tilfojes af destinationsserveren, ikke af migreringsvaerktojet. Migreringsvaerktojet har ingen kontrol over denne adfaerd. Selv med perfekt INTERNALDATE-bevarelse indeholder den oeverste "Received"-header stadig migreringsdatoen, og klienter som Outlook viser stadig den forkerte dato.
Kort sagt, hvad kan man konkret goere ved det?
Hvilke migreringsvaerktojer tilfojer "Received"-headers
Alle IMAP-migreringsvaerktojer foraarsager dette problem fordi "Received"-headeren tilfojes af destinationsserveren, ikke af vaerktojet selv. Indholdet af den tilfoejede header varierer efter vaerktoej og server.
BitTitan MigrationWiz tilfojer en "Received"-header indeholdende "mx.migrationwiz.com". CloudM Migrate tilfojer headers der refererer "cloudm.io". imapsync udloeser en generisk "Received"-header fra destinationsserveren. GSMMO tilfojer 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 paa dem.
Redate.io's proprietaere korrektionsmotor analyserer den komplette headerkade for hver paavirket e-mail og anvender moenstergenkendelse paa hundredvis af kendte migreringsvaerktojssignaturer for praecist at identificere hvilke headers der behoever korrektion. Den flertrins analysepipeline haandterer de saertilfaelde der faar 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 vedhaeftninger og korrupte MIME-graenser.
Efter korrektion gennemgaar hver e-mail en integritetsverifikationsproces for at bekraefte at beskedens struktur, indhold og vedhaeftninger er bevaret identisk. Originaler bevares i en synlig backup-mappe i 30 dage.
Kunne man skrive et script for at forsoge denne korrektion selv? Teknisk ja. Men forskellen mellem "det virker paa 95 % af e-mails" og "det virker paa 100 % af e-mails uden at korrumpere en eneste" repraesenterer maaneders udvikling. Og naar vi taler om en persons komplette postkasse, betyder en fejlrate paa 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 faa en ojeblikkelig optaelling af paavirkede e-mails, uden betaling kraeves.