Endre mottaksdatoen på en e-post: tekniske grenser

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

Når folk snakker om å "endre mottaksdatoen på en e-post", ser de for seg å redigere et felt et sted, litt som å endre opprettelsesdatoen på en fil i Windows. Virkeligheten er litt mer komplisert. En e-post inneholder faktisk tre separate datolag, hvert med sine egne regler, sine egne voktere, og sine egne konsekvenser hvis du rører ved dem.

Forstår du disse tre lagene, forstår du også hvorfor noen korreksjoner er teknisk forsvarlige, mens andre enten er umulige eller umiddelbart gjenkjennelige som forfalskning.

Lag 1: IMAP INTERNALDATE

INTERNALDATE er metadata lagret på serversiden, utenfor selve meldingen. Den er ikke en del av e-postinnholdet. Det er IMAP-serveren som setter den, og det er denne datoen de fleste e-postklienter bruker til å sortere meldingene i listen din.

Outlook viser for eksempel meldinger sortert etter INTERNALDATE som standard. Gmail gjør det samme i visse sammenhenger. Så hvis INTERNALDATE er feil, ser alle e-postene dine ut til å ha samme dato i grensesnittet, uansett hva de interne overskriftene i meldingen sier.

INTERNALDATE settes når meldingen legges inn på serveren. Via IMAP-protokollen er den eneste måten å "endre" den på indirekte: du må bruke APPEND-kommandoen for å legge inn en ny kopi av meldingen med ønsket dato. Det finnes ingen IMAP-kommando som heter SETINTERNALDATE. Dette detaljpunktet blir viktig om litt.

Lag 2: Date:-overskriften (RFC 2822)

Dette er Date:-feltet i de rå overskriftene til meldingen. Det settes av e-postklienten ved sending, og følger med meldingen fra server til server. Det er avsenderens erklærte sendedato.

(Hvis du aldri har sett på rå e-postoverskrifter, forresten, er det ganske spesiell lesing. Hver melding drar med seg et tjuetalls tekniske linjer som 99 % av folk aldri har sett.)

Teknisk sett er det ingenting som hindrer deg i å sende en e-post med et tilbake- eller fremdatert Date:-felt. SMTP-servere validerer ikke dette feltet. Men mottakende servere noterer den faktiske ankomsttiden i Received:-overskriftene, noe som umiddelbart skaper en inkonsistens som er synlig for enhver e-postklient eller analyseverktøy.

Lag 3: de stablede Received:-overskriftene

Hver gang en SMTP-server videresender en melding, legger den til en Received:-overskrift øverst i stabelen, med et tidsstempel. En e-post som har passert tre servere har tre Received:-overskrifter. De leses nedenfra og opp: den eldste er nederst, den nyeste øverst.

Det er nettopp her migrasjonsverktøy skaper problemet. Når BitTitan MigrationWiz, CloudM, imapsync eller GSMMO migrerer en e-post, injiserer de den på nytt på den nye serveren via IMAP. Denne innsettingen genererer en ny Received:-oppføring tidsstemplet til migrasjonsdatoen. Resultatet: den eldste meldingen i postkassen din, en e-post fra 2019, ender opp med en Received: datert november 2024. Og siden visse e-postklienter (med Outlook i spissen) bruker den nyeste Received: som visningsdato...

Der er problemet. 15 000 e-poster viser alle den samme migreringsdatoen.

Kan du egentlig "endre" disse datoene?

Teknisk sett ja for INTERNALDATE (med begrensninger). Teknisk mulig men meningsløst for Date:. Og for Received: er det verdt å dvele litt.

Å skrive om en Received:-overskrift er trivielt. Og umiddelbart detekterbart.

En Received:-overskrift er bare en tekstlinje i meldingen. Du kan redigere den som hvilken som helst tekstfil. Det er akkurat så enkelt som det høres ut.

Men her er hva som skjer etterpå.

Første problem: DKIM. DKIM-signaturen (DomainKeys Identified Mail) beregnes over et sett e-postoverskrifter, noen ganger inkludert Received:. Endrer du en signert overskrift, ugyldiggjøres signaturen. Enhver mottakende server som verifiserer DKIM vil umiddelbart se at meldingen er endret. Det er ikke en subtil forfalskning, det er en alarm.

Andre problem: interne identifikatorer. Moderne e-postservere (Google Workspace, Microsoft 365) tildeler hver melding en unik, stigende intern identifikator. Disse identifikatorene er knyttet til INTERNALDATE og mottaksrekkefølgen. Å endre en Received: uten samsvar med disse identifikatorene skaper inkonsistenser som revisjonsverktøy oppdager uten problem.

Tredje problem, mer praktisk: selv om du endrer Received: i meldingsinnholdet, har du ikke rørt INTERNALDATE, som fortsatt er den fra IMAP-innsettingen. E-postklienten viser fremdeles feil dato ved sortering. Du har endret meldingen for ingenting.

Altså. Å skrive om Received:-overskrifter for å forfalske en e-postdato i ondsinnet hensikt: trivielt teknisk sett, detekterbart på noen sekunder av en ekspert. Det er ikke en seriøs vei å gå.

Date:-overskriften: endre fortiden på papiret

Samme resonnement gjelder for Date:. Du kan endre den i meldingskroppen. Men Received:-overskriftene autentisert av mellomliggende servere forblir intakte og forteller en annen historie. Den temporale kjeden er inkonsistent. Enhver analytiker eller domstol som sammenligner disse feltene vil se det umiddelbart.

For å være presis: det hindrer ikke visse e-postklienter i å vise den endrede Date: hvis du gir dem .eml-filen direkte. Men i en live e-postserver med autentisering og logger er endringen gjennomsiktig.

IMAP-migrering: den eneste konteksten der datokorrigering er forsvarlig

Det finnes ett tilfelle, og bare ett, der det å endre mottaksdatoen på en e-post ikke bare er mulig men teknisk begrunnet: å rette opp skaden fra en dårlig håndtert IMAP-migrering.

Her er den konkrete situasjonen. Du har nettopp migrert 80 Exchange-postkasser til Microsoft 365. Migreringen ble ferdig en fredag kveld. Mandag morgen begynner de første sakene å komme inn: "Alle e-postene mine har samme dato", "Jeg finner ikke en e-post fra i fjor", "Historikken min med denne kunden er helt ødelagt". Du har 80 brukere som sitter fast og sjefen din som venter på svar.

I denne sammenhengen er problemet dokumentert, identifiserbart, og årsaken er klar: migrasjonsverktøyet la til en Received: datert migrasjonsdagen, og visse e-postklienter bruker denne nye overskriften som visningsdato. Den opprinnelige Date:-overskriften, derimot, er intakt i hver melding. Den har aldri blitt endret. Den inneholder fortsatt den opprinnelige, korrekte sendedatoen.

Korreksjonen er altså ikke en forfalskning: det er en restaurering. Man tar utgangspunkt i sanne data (den opprinnelige Date:) for å rekonstruere konsistente metadata. Det er fundamentalt forskjellig fra å prøve å få en e-post fra 2024 til å fremstå som en e-post fra 2019.

For mer om de spesifikke mekanismene for hvert verktøy, finner du konkrete tilfeller i disse guidene: rett BitTitan-datoer i Microsoft 365, rett CloudM-datoer i Outlook, eller rett imapsync-datoer i Google Workspace.

Hvorfor du ikke bør skrive et script selv

Grunnlogikken er tilgjengelig. Enhver IT-administrator som har brukt tid på IMAP-forum kan rekonstruere den generelle tilnærmingen. Det er ikke problemet.

Problemet er gapet mellom et script som fungerer på 50 teste-poster og et script som kjører på 40 000 meldinger i produksjon uten å miste én eneste e-post, uten å korruptere ett eneste vedlegg, og uten å ødelegge én eneste samtaletrå.

Noen konkrete tilfeller som hjemmelagde script vanligvis ikke håndterer:

• S/MIME-signerte e-poster: signaturen dekker innhold og overskrifter. Enhver endring av meldingsstrukturen ugyldiggjør signaturen. En klønete korrigert signert e-post ankommer som "ugyldig signatur" hos mottakerne.
• PGP-krypterte meldinger: samme familie av problemer, med potensielt verre konsekvenser avhengig av implementasjonen.
• Ikke-ASCII-kodinger i overskrifter: RFC 2047 beskriver kodingen av spesialtegn i overskrifter. Et script som manipulerer overskrifter uten å håndtere disse tilfellene vil stille korrumpere e-postemner med aksenter, japanske tegn, eller arabiske navn.
• API-ratebegrensninger: Google Workspace og Microsoft 365 har aggressiv throttling. Klokken 03:00 treffer en batch på 10 000 e-poster en 429 Too Many Requests-feil uten eksponentiell backoff-håndtering og etterlater halvparten av postkassene halvveis korrigert.
• Korrupte MIME-grenser: multipart-meldinger med vedlegg har presise MIME-grenser. Å regenerere dem feil gjør vedleggene uleselige.

Og spørsmålet ingen hjemmelaget script løser: hvordan verifiserer du at hver korrigert e-post er intakt? Et script som endrer 40 000 meldinger uten individuell verifisering er et veddemål. Et veddemål på data som brukerne dine ofte anser som uerstattelige.

Artikkelen om tilgjengelige alternativer for å rette datoer etter migrering går gjennom de ulike tilnærmingene, inkludert deres respektive begrensninger.

Hva Redate.io gjør i denne sammenhengen

Redate.io er bygget spesifikt for dette tilfellet: å rette datoer ødelagt av en IMAP-migrering, i stor skala, uten risiko for meldingsintegriteten.

Tjenesten kobler seg direkte til de berørte postkassene (Google Workspace via domenedelegering, Microsoft 365 via Azure AD, eller direkte IMAP), skanner gratis etter meldinger med feil datoer, og anvender deretter en proprietær korreksjonspipeline som håndterer kanttilfellene dokumentert ovenfor. Hver e-post verifiseres individuelt etter korreksjon. Originalene ligger i en synlig sikkerhetskopieringsmappe i 30 dager.

Mønstergjenkjenningen dekker hundrevis av signaturer fra kjente migrasjonsverktøy: BitTitan MigrationWiz, CloudM, imapsync, GSMMO, og deres varianter. Deteksjonen er presis: Redate.io rører ikke e-poster med korrekt dato.

Prismodellen er enkel: engangsbetaling per postkasse, uten abonnement. Diagnostikkskanningen er gratis, noe som lar deg måle skadeomfanget før du bestemmer deg for noe.

Hvis du administrerer postkasser berørt av dette problemet, beskriver denne artikkelen om feil datoer i Outlook etter migrering de vanligste symptomene og hvordan du skiller dem fra andre årsaker.

Klar til å måle omfanget av problemet i postkassene dine? Start en gratis skanning på Redate.io og se nøyaktig hvor mange e-poster som er berørt, før noen korreksjon gjøres.