Ændre modtagelsesdato på en mail: tekniske grænser

En e-mail har tre "datoer". Ikke én.

Når folk taler om at "ændre modtagelsesdatoen på en mail", forestiller de sig typisk at redigere et felt et sted, ligesom man ville ændre oprettelsesdatoen på en fil i Windows. Virkeligheden er lidt mere kompliceret. En e-mail indeholder faktisk tre separate datlag, hvert med sine egne regler, sine egne vagter og sine egne konsekvenser, hvis man roder med dem.

At forstå disse tre lag er at forstå, hvorfor visse rettelser er teknisk forsvarlige, og andre enten er umulige eller øjeblikkeligt kan afsløres som forfalskninger.

Lag 1: IMAP INTERNALDATE

INTERNALDATE er en metadata, der er gemt på serversiden, uden for selve meddelelsen. Den er ikke en del af e-mailens indhold. Det er IMAP-serveren, der fastsætter den, og det er den, de fleste e-mailklienter bruger til at sortere dine beskeder på listen.

Outlook viser som standard beskeder sorteret efter INTERNALDATE. Det gør Gmail også i visse sammenhænge. Så hvis din INTERNALDATE er forkert, ser alle dine e-mails ud til at have den samme dato i grænsefladen, uanset hvad de interne headere siger.

INTERNALDATE fastsættes, når meddelelsen lægges på serveren. Via IMAP-protokollen er den eneste måde at "ændre" den på indirekte: man skal bruge kommandoen APPEND til at lægge en ny kopi af meddelelsen ind med den ønskede dato. Der findes ingen IMAP-kommando kaldet SETINTERNALDATE. Det detalje bliver vigtigt om et øjeblik.

Lag 2: Date:-headeren (RFC 2822)

Det er feltet Date: i de rå headere i meddelelsen. Det fastsættes af e-mailklienten på afsendelsestidspunktet og følger med beskeden fra server til server. Det er den af afsenderen erklærede afsendelsesdato.

(Har du aldrig set de rå headere på en e-mail, er det en ret fremmed oplevelse. Hver besked trækker en snes tekniske linjer med sig, som 99 % af folk aldrig har set.)

Teknisk set er der intet, der forhindrer en i at sende en e-mail med et tilbagedateret eller fremtidsdateret Date:-felt. SMTP-servere validerer ikke dette felt. Men modtagerserverene noterer det faktiske ankomsttidspunkt i Received:-headerne, hvilket øjeblikkeligt skaber en inkonsistens, der er synlig for enhver e-mailklient eller analyseværktøj.

Lag 3: de stablede Received:-headere

Hver gang en SMTP-server videresender en besked, tilføjer den en Received:-header øverst i stakken med et timestamp. En e-mail, der er passeret gennem tre servere, har tre Received:-headere. De læses nedefra og op: den ældste er nederst, den nyeste øverst.

Det er præcis her, migreringsværktøjer skaber problemet. Når BitTitan MigrationWiz, CloudM, imapsync eller GSMMO migrerer en e-mail, genindsætter de den på den nye server via IMAP. Denne indsættelse genererer en ny Received:-post med tidsstempel fra migreringstidspunktet. Resultat: den ældste besked i din indbakke, en e-mail fra 2019, ender med en Received: dateret november 2024. Og da visse e-mailklienter (Outlook i særdeleshed) bruger den nyeste Received: som visningsdato...

Der er problemet. 15.000 e-mails viser alle den samme migrationsdato.

Kan man egentlig "ændre" disse datoer?

Teknisk set ja for INTERNALDATE (med begrænsninger). Teknisk muligt men nyttesløst for Date:. Og for Received:-headerne er det værd at dvæle ved.

At omskrive en Received:-header er trivielt. Og øjeblikkeligt sporbart.

En Received:-header er blot en tekstlinje i meddelelsen. Man kan redigere den som enhver anden tekstfil. Det er præcis så enkelt, som det lyder.

Men her er, hvad der sker bagefter.

Første problem: DKIM. DKIM-signaturen (DomainKeys Identified Mail) beregnes ud fra et sæt headere i meddelelsen, herunder til tider Received:. At ændre en signeret header ugyldiggør signaturen. Enhver modtagerserver, der verificerer DKIM, vil øjeblikkeligt se, at meddelelsen er blevet ændret. Det er ikke en subtil forfalskning, det er en alarm.

Andet problem: interne identifikatorer. Moderne e-mailservere (Google Workspace, Microsoft 365) tildeler hver besked en stigende og unik intern identifikator. Disse identifikatorer er knyttet til INTERNALDATE og modtagelsesrækkefølgen. At ændre en Received:-header uden sammenhæng med disse identifikatorer skaber inkonsistenser, som revisionsværktøjer opdager uden besvær.

Tredje problem, mere praktisk: selv hvis du ændrer Received: i meddelelsens indhold, har du ikke rørt INTERNALDATE, som stadig er fra IMAP-indsættelsen. E-mailklienten bliver ved med at vise den forkerte dato ved sortering. Du har ændret meddelelsen forgæves.

Kort sagt: at omskrive Received:-headere for ondsindet at forfalske en e-maildato er teknisk trivielt og sporbart på få sekunder af en ekspert. Det er ikke en seriøs vej.

Date:-headeren: at ændre fortiden på papiret

Samme ræsonnement gælder for Date:. Man kan ændre den i meddelelsens krop. Men Received:-headerne, der er autentificeret af de mellemliggende servere, forbliver intakte og fortæller en anden historie. Den tidsmæssige kæde er inkonsistent. Enhver analytiker eller domstol, der sammenligner disse felter, vil se det øjeblikkeligt.

For at være præcis: det forhindrer ikke visse e-mailklienter i at vise den ændrede Date:, hvis man præsenterer dem direkte for .eml-filen. Men i konteksten af en live e-mailserver med autentificering og logs er ændringen gennemsigtig.

IMAP-migrering: den eneste legitime sammenhæng for datokorrektion

Der er ét tilfælde, og kun ét, hvor det at ændre modtagelsesdatoen på en e-mail ikke alene er muligt, men teknisk begrundet: at rette skaderne fra en dårligt håndteret IMAP-migrering.

Her er den konkrete situation. Du har netop migreret 80 Exchange-postkasser til Microsoft 365. Migreringen sluttede en fredag aften. Mandag morgen begynder de første tickets at rulle ind: "Alle mine e-mails har den samme dato", "Jeg kan ikke finde en e-mail fra sidste år", "Min historik med denne kunde er helt ødelagt". Du har 80 brugere blokeret, og din chef venter på et svar.

I denne sammenhæng er problemet dokumenteret, identificerbart, og årsagen er klar: migreringsværktøjet har tilføjet en Received:-header dateret til migrationsdagen, og visse e-mailklienter bruger denne nye header som visningsdato. Den originale Date:-header er derimod intakt i hver besked. Den er aldrig blevet ændret. Den indeholder stadig den originale, korrekte afsendelsesdato.

Rettelsen er altså ikke en forfalskning: det er en genoprettelse. Man tager udgangspunkt i sande data (den originale Date:) for at rekonstruere konsistente metadata. Det er fundamentalt forskelligt fra at forsøge at få en e-mail fra 2024 til at se ud som en e-mail fra 2019.

For at gå dybere ned i mekanismerne for specifikke værktøjer beskriver disse guides de konkrete tilfælde: ret BitTitan-datoer i Microsoft 365, ret CloudM-datoer i Outlook, eller ret imapsync-datoer i Google Workspace.

Hvorfor du ikke bør skrive et script selv

Den grundlæggende logik er tilgængelig. Enhver IT-admin, der har brugt tid på IMAP-fora, kan rekonstruere den generelle fremgangsmåde. Det er ikke problemet.

Problemet er kløften mellem et script, der virker på 50 teste-mails, og et script, der kører på 40.000 beskeder i produktion uden at miste en eneste e-mail, uden at ødelægge en eneste vedhæftning og uden at bryde en eneste samtaletråd.

Nogle konkrete tilfælde, som hjemmelavede scripts generelt ikke håndterer:

• S/MIME-signerede e-mails: signaturen dækker indholdet og headerne. Enhver ændring af meddelelsesstrukturen ugyldiggør signaturen. En kluntet rettet signeret e-mail ankommer med "ugyldig signatur" hos modtagerne.
• PGP-krypterede beskeder: samme familie af problemer, med potentielt værre konsekvenser afhængigt af implementeringen.
• Ikke-ASCII-kodninger i headere: RFC 2047 beskriver kodningen af specialtegn i headere. Et script, der manipulerer headere uden at håndtere disse tilfælde, vil lydløst ødelægge e-mailemner med accenter, japanske tegn eller arabiske navne.
• API-rategrænser: Google Workspace og Microsoft 365 implementerer aggressiv throttling. Klokken 3 om natten vil en batch på 10.000 e-mails, der støder på en 429 Too Many Requests-fejl uden eksponentiel backoff-håndtering, efterlade halvdelen af postkasserne halvt rettet.
• Ødelagte MIME-grænser: multipart-beskeder med vedhæftninger har præcise MIME-grænser. At regenerere dem forkert gør vedhæftningerne ulæselige.

Og spørgsmålet, som intet hjemmelavet script besvarer: hvordan verificerer du, at hver rettet e-mail er intakt? Et script, der ændrer 40.000 beskeder uden individuel verifikation, er et væddemål. Et væddemål med data, som dine brugere ofte betragter som uerstattelige.

En artikel om de tilgængelige muligheder for at rette datoer efter migrering gennemgår de forskellige tilgange, herunder deres respektive begrænsninger.

Hvad Redate.io gør i denne sammenhæng

Redate.io er bygget specifikt til dette tilfælde: at rette datoer ødelagt af en IMAP-migrering, i stor skala, uden risiko for meddelelsernes integritet.

Tjenesten forbinder sig direkte til de berørte postkasser (Google Workspace via domænedelegation, Microsoft 365 via Azure AD eller direkte IMAP), scanner gratis for beskeder med forkerte datoer og anvender derefter en proprietær korrektionspipeline, der håndterer de ovenfor dokumenterede edge cases. Hver e-mail verificeres individuelt efter korrektion. Originalerne forbliver i en synlig backup-mappe i 30 dage.

Mønstergenkendelsen dækker hundredvis af kendte migreringsværktøjssignaturer: BitTitan MigrationWiz, CloudM, imapsync, GSMMO og deres varianter. Detektionen er præcis: Redate.io rører ikke ved e-mails, hvis dato er korrekt.

Prismodellen er enkel: engangsbetaling pr. postkasse, intet abonnement. Diagnostikscanning er gratis, så du kan måle skadernes omfang, inden du beslutter noget som helst.

Hvis du administrerer postkasser berørt af dette problem, beskriver denne artikel om forkerte datoer i Outlook efter migrering de mest almindelige symptomer og hvordan man skelner dem fra andre årsager.

Klar til at måle problemets omfang på dine postkasser? Start en gratis scanning på Redate.io og se præcis, hvor mange e-mails der er berørt, inden der rettes noget.