De tre datumen i varje e-postmeddelande
Varje e-postmeddelande lagrat på en IMAP-server bär minst tre distinkta datumvärden. Att förstå hur dessa datum fungerar, och hur e-postklienter väljer vilket som ska visas, är nyckeln till att förstå varför migrering förstör datum. Den här artikeln är en teknisk djupdykning i IMAP:s datumsystem, avsedd för IT-administratörer och alla som vill förstå grundorsaken till datumproblem efter migrering.
1. RFC 2822 "Date"-huvudet
"Date"-huvudet definieras i RFC 2822 (format för internetmeddelanden). Det ställs in av avsändarens e-postklient när meddelandet komponeras och skickas. Det här huvudet är en del av själva meddelandekroppen, det följer med meddelandet och ändras aldrig av e-postservrar längs leveransvägen. Ett typiskt Date-huvud ser ut så här:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Date-huvudet representerar meddelandets "sänddatum". Det är det mest tillförlitliga datumet eftersom det ställs in en gång och aldrig ändras. Däremot speglar det avsändarens klocka, som kan vara felkonfigurerad. I sällsynta fall kan Date-huvudet saknas helt (särskilt i automatiserade systemnotifieringar eller felformaterade meddelanden).
2. IMAP INTERNALDATE
INTERNALDATE definieras i RFC 3501 (IMAP4rev1-protokollet). Det är ett serversidig metadatavärde som representerar datum och tid då meddelandet levererades till servern. Till skillnad från Date-huvudet är INTERNALDATE inte en del av själva e-postmeddelandet. Det lagras separat av IMAP-servern som metadata.
När ett e-postmeddelande levereras normalt (inte migrerat) ställer IMAP-servern INTERNALDATE till aktuell tid vid leverans. Det värdet motsvarar nära Date-huvudet, vanligtvis inom några sekunder eller minuter. E-postklienter använder ofta INTERNALDATE som "mottagningsdatum" eftersom det speglar när servern faktiskt mottog meddelandet.
Och här blir det intressant. När ett meddelande infogas via IMAP APPEND-kommandot (som migreringsverktyg använder) tillåter APPEND-kommandot att klienten anger INTERNALDATE explicit. Väldesignade migreringsverktyg använder den här funktionen för att bevara den ursprungliga INTERNALDATE från källservern. Men även när INTERNALDATE är korrekt satt kan "Received"-huvudproblemet (beskrivet nedan) ändå skriva över det visade datumet i många klienter.
3. "Received"-huvudens kedja
Varje gång ett e-postmeddelande passerar genom en e-postserver lägger den servern till ett "Received"-huvud i början av meddelandet. Det skapar en kedja av Received-huvuden som registrerar e-postmeddelandets resa från avsändare till mottagare. Det senaste (längst upp) visar den sista servern som behandlade meddelandet, och det äldsta (längst ner) visar den första.
Ett normalt e-postmeddelande kan ha 3 till 6 Received-huvuden, som dokumenterar resan från avsändarens utgående server genom reläer till mottagarens inkommande server. Varje Received-huvud inkluderar en tidstämpel. Här är ett förenklat exempel:
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
Hur e-postklienter väljer vilket datum som visas
Outlook (Desktop, Webb, Mobil)
Microsoft Outlook använder en kombination av INTERNALDATE och det senaste "Received"-huvudet för att bestämma "Mottaget"-datumet som visas i inkorgen. I praktiken tenderar Outlook att prioritera det senaste Received-huvudets tidstämpel för kolumnen "Mottaget". Kolumnen "Skickat" använder Date-huvudet. Eftersom Outlook som standard sorterar efter kolumnen "Mottaget" är det Received-huvudets tidstämpel användarna ser först.
Apple Mail
Apple Mail på macOS och iOS använder primärt IMAP INTERNALDATE för att visa datumet. Om INTERNALDATE bevarades korrekt under migreringen kan Apple Mail visa rätt datum, men bara om INTERNALDATE explicit sattes under APPEND-operationen. Om migreringsverktyget inte satte INTERNALDATE använder servern infogningstiden (migreringsdatumet) som standard. För detaljer om påverkan för Apple Mail-användare, se Apple Mail: fel datum efter migrering.
Thunderbird
Mozilla Thunderbird erbjuder mest flexibilitet. Det kan visa både "Datum" (från Date-huvudet) och "Mottaget" (från Received-huvudena). Som standard visar Thunderbird Date-huvudets värde, vilket innebär att datum kan verka korrekta i Thunderbird även när de är felaktiga i Outlook. Kolumnen "Mottaget" i Thunderbird visar alltid migreringsdatumet. Se Thunderbird: fel datum efter migrering för fler detaljer.
Gmails webbgränssnitt
Gmails webbklient använder Date-huvudet för sin primära datumvisning. Det innebär att Gmail-webben ofta visar korrekta datum även efter migrering. Men IMAP INTERNALDATE på Gmail-servern är ändå felaktigt, vilket påverkar varje IMAP-klient som ansluter till det Gmail-kontot. Skillnaden mellan Gmail-webben och Outlook eller Apple Mail är en vanlig källa till förvirring, och en som kostar administratörer många timmars felsökning.
Varför IMAP APPEND förstör datum
Vad som händer under migrering
När ett migreringsverktyg flyttar ett e-postmeddelande från Server A till Server B ansluter verktyget till Server A via IMAP och laddar ner det råa meddelandet, ansluter sedan till Server B och använder APPEND-kommandot för att infoga det. Under infogningen behandlar Server B det inkommande meddelandet och lägger till ett nytt Received-huvud med aktuell tidstämpel: migreringsdatumet. Det här är standard-IMAP-beteende definierat i protokollet. Servern behandlar varje APPEND som en ny meddelandeleverans.
Resultatet: en kontaminerad huvudkedja
Efter migrering ser e-postmeddelandets Received-huvuden ut så här:
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
Migreringsverktygets Received-huvud är nu den översta posten. Varje e-postklient som använder det senaste Received-huvudet för att bestämma visningsdatumet (Outlook i synnerhet) visar "11 april 2025" istället för "15 januari 2024". Det ursprungliga Date-huvudet och de ursprungliga Received-huvudena är fortfarande intakta under, men de är inte längre i den position som e-postklienterna prioriterar.
Även bra INTERNALDATE-hantering förhindrar inte det här
Vissa migreringsverktyg ställer korrekt INTERNALDATE under APPEND. Till exempel bevarar imapsync explicit INTERNALDATE från källservern. Men Received-huvudet läggs till av destinationsservern, inte av migreringsverktyget. Migreringsverktyget har ingen kontroll över detta beteende. Även med perfekt INTERNALDATE-bevarande innehåller det översta Received-huvudet fortfarande migreringsdatumet, och klienter som Outlook visar fortfarande fel datum.
Så, vad kan man konkret göra åt det?
Vilka migreringsverktyg lägger till Received-huvuden
Alla IMAP-migreringsverktyg orsakar det här problemet eftersom Received-huvudet läggs till av destinationsservern, inte av verktyget självt. Innehållet i det tillagda huvudet varierar beroende på verktyg och server.
BitTitan MigrationWiz lägger till ett Received-huvud som innehåller "mx.migrationwiz.com". CloudM Migrate lägger till huvuden som refererar till "cloudm.io". imapsync utlöser ett generiskt Received-huvud från destinationsservern. GSMMO lägger till huvuden med "gmailapi.google.com"-referenser.
Korrigeringen: återställ korrekta datum
De goda nyheterna är att korrekt datuminformation fortfarande finns i varje e-postmeddelande. Det ursprungliga Date-huvudet är intakt. De ursprungliga Received-huvudena är intakta. Problemet är att ett kontaminerande huvud sitter övanpå dem.
Redate.ios proprietära korrigeringsmotor analyserar den fullständiga huvudkedjan i varje drabbat e-postmeddelande, och tillämpar signaturmatchning mot hundratals kända migreringsverktygssignaturer för att identifiera exakt vilka huvuden som behöver korrigering. Den flerstegs analyspipelinen hanterar kantfall som får enklare metoder att misslyckas: S/MIME-signerade meddelanden, PGP-krypterat innehåll, multipart/alternative-strukturer, Content-Transfer-Encoding-problem, icke-ASCII-huvuden (RFC 2047), överstora bilagor och korrupta MIME-gränser.
Efter korrigering genomgår varje e-postmeddelande en integritetskontrollprocess för att bekräfta att meddelandets struktur, innehåll och bilagor är bevarade identiskt. Originalen bevaras i en synlig backupmapp i 30 dagar.
Skulle man kunna skriva ett eget skript för det här? Tekniskt sett ja. Men skillnaden mellan "det fungerar på 95 % av e-postmeddelandena" och "det fungerar på 100 % utan att korruptera ett enda" representerar månaders utveckling. Och när det handlar om någons fullständiga brevlåda innebär en felfrekvens på 5 % hundratals tyst skadade meddelanden utan möjlighet att verifiera vad som gick fel.
Vill du veta hur många e-postmeddelanden i din brevlåda som har felaktiga datum? Kör en gratis analys med Redate.io för en omedelbar räkning av drabbade e-postmeddelanden, utan betalning.