Åtgärda imapsync datum

Löftet från --syncinternaldates (och var det slutar)

Du körde imapsync-kommandot. Du inkluderade --syncinternaldates eftersom du läste dokumentationen och är noggrann på det sättet. Migreringen slutförs, loggen säger att allt överfördes, noll fel. Sedan öppnar du brevlådan i Outlook och varje e-postmeddelande visar gårdagens datum.

Det här är en av de vanligaste frustrationerna med imapsync, och det har förvirrat systemadministratörer sedan åtminstone 2017. Flaggan --syncinternaldates ska bevara IMAP INTERNALDATE under migreringen. Och det gör den: den ger varje kopia det interna datum källservern har. Det är precis där fällan sitter.

imapsync är ett Perl-verktyg med öppen källkod, skrivet av Gilles Lamiral, och det är genuint bra på det som det gör. Det hanterar IMAP-till-IMAP-överföring av brevlådor med en tillförlitlighet som de flesta kommersiella verktyg avundas. Men imapsync kan bara kopiera de datum den hittar, och det är där det blir komplicerat.

Hur IMAP-datum egentligen fungerar

Det finns tre olika "datum" inblandade i varje e-postmeddelande, och de flesta (inklusive vissa IT-administratörer) blandar ihop dem:

Date:-headret (RFC 2822) - datumet som avsändarens e-postklient stämplade på meddelandet när det skrevs. Det ligger inuti meddelandet och ändras aldrig av e-postservrar.
Received:-headrar - varje e-postserver som hanterar meddelandet lägger till ett med sin egen tidsstämpel. De bildar en kedja från avsändare till mottagare. Det översta (senaste) Received-headret är vad vissa e-postklienter använder för visning.
INTERNALDATE - en tidsstämpel på IMAP-serverns sida som styr hur meddelanden sorteras i brevlådan. Den sätts när meddelandet först lagras via IMAP APPEND.

När imapsync migrerar ett meddelande läser den meddelandet från källservern (inklusive dess INTERNALDATE) och skriver det till destinationsservern med IMAP APPEND. Flaggan --syncinternaldates säger åt imapsync att skicka källans INTERNALDATE till destinationsservern under APPEND.

Här är den goda nyheten: Microsoft 365, Outlook.com och Gmail behåller det datum de får. Så när datumen blir fel, ligger problemet någon annanstans.

Varför datumen kan vara fel ändå

IMAP-specifikationen (RFC 3501) säger att om ett datum-och-tid anges med APPEND-kommandot BÖR servern använda det. "BÖR" på RFC-språk betyder "gör det om du inte har en bra anledning att inte göra det". Microsoft 365, Outlook.com och Gmail gör det: en kopia som bär sitt ursprungliga datum behåller det.

Vad imapsync skickar med är däremot det datum KÄLLservern har för varje meddelande, inte datumet meddelandet skickades. På en frisk brevlåda stämmer de två. På en brevlåda som redan migrerats en gång eller återställts från en säkerhetskopia kan källan hålla datumet för den tidigare operationen, och imapsync kopierar det som det är.

Gmail är ett specialfall bara när kopian går via Gmails egen import-API istället för IMAP: det API:et lägger till en Received-rad daterad kopieringsdagen, och Outlook kan visa det datumet. imapsync talar IMAP, så det påverkas inte.

Dovecot och Cyrus, de två vanligaste IMAP-servrarna med öppen källkod, behåller också datumet från APPEND. Så oavsett destination är frågan densamma: vilket datum hade källan?

Vanliga misstag i imapsync-kommandoraden som förstör datum

Utöver källdatumen snubblar administratörer ofta på imapsyncs kommandoradsflaggor, eller skyller på fel flaggor. Här är de misstag jag ser oftast:

Att kopiera från en källa vars datum redan var fel

--syncinternaldates är aktiverad som standard: imapsync ger varje kopia det interna datum källservern har (dess egen dokumentation: "Sets the internal dates on host2 as the same as host1"). Om källbrevlådan i sig är resultatet av en tidigare migrering eller en återställning kan dess interna datum redan vara de från den operationen, och imapsync kopierar troget det felaktiga datumet. Det här är den vanligaste orsaken, och den lättaste att missa, eftersom loggen visar två identiska datum.

Att använda --syncinternaldates med --addheader

Vissa guider rekommenderar att använda --addheader för att lägga till ett anpassat header under migreringen. Att lägga till ett header ändrar meddelandet (en rad till högst upp) men inte det datum imapsync skickar med, så det förklarar inte felaktiga datum. Kopian är helt enkelt inte längre identisk med originalet, vilket spelar roll om du jämför de två.

Att blanda ihop --minage och --maxage med datumbevarande

Flaggorna --minage och --maxage filtrerar vilka meddelanden som migreras baserat på deras ålder. De påverkar inte hur datum hanteras vid destinationen. Jag har sett administratörer lägga timmar på att justera dessa flaggor i tron att det skulle lösa datumproblemet. Det gör det inte.

Att skylla på TLS för förskjutna datum

Över TLS (--ssl1, --ssl2) lägger uppkopplingen till latens, och vid en stor migrering (50 000+ meddelanden) blir det timmar sammanlagt. Det rör inte datumen: varje kopia bär det datum imapsync skickar med, oavsett vilken tid den faktiskt landar.

Att läsa imapsync-loggar: vad utskriften faktiskt säger dig

imapsync producerar detaljerade loggar, vilket är bra. Men loggutskriften kan vara vilseledande när det gäller datum.

En typisk lyckad överföringsrad ser ut så här:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Båda datumen stämmer. Det betyder att imapsync skickade rätt INTERNALDATE till destinationen. Och Microsoft 365, Outlook.com och Gmail behåller alla det datum de får. Men två identiska datum bevisar bara att kopian är trogen KÄLLan: om källdatumet redan var fel visar båda kolumnerna samma felaktiga datum.

Vill du verifiera vad som faktiskt hände? Anslut till destinationen med en IMAP-klient efter migreringen och kontrollera INTERNALDATE direkt:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Om det returnerade datumet inte är det datum e-postmeddelandet skickades, titta på samma meddelande på källan: du hittar samma felaktiga datum där. Loggen ljög inte, den kopierade det den fick.

Det här är en av de mest frustrerande aspekterna av att felsöka datumproblem: en ren loggfil, två identiska datum, och ändå fel datum i Outlook, eftersom felet fanns där innan imapsync ens körde.

Storskaliga imapsync-migreringar: där datumproblem multipliceras

En enskild brevlådemigrering med imapsync är irriterande när datumen går sönder. Men MSP:er och IT-avdelningar som kör imapsync över hundratals brevlådor står inför en helt annan skala av problem.

Tänk dig ett typiskt migreringsscenario för ett företag. Du flyttar 200 brevlådor från en Zimbra-server till Microsoft 365. Du skriver ett wrapper-skript som loopar genom en CSV med användare och anropar imapsync för var och en. Migreringen körs över en helg. Måndag morgon har du 200 brevlådor med felaktiga datum, och runt 1,2 miljoner e-postmeddelanden totalt som visar migreringens tidsstämpel.

Kan du köra imapsync igen för att fixa det? Tekniskt ja, men imapsync hoppar över meddelanden som redan finns på destinationen (det är byggt för att vara idempotent). Du skulle behöva --delete2 för att ta bort destinationsmeddelanden och överföra dem igen, vilket är riskabelt på en produktionsbrevlåda. Och om källdatumen var problemet kopierar en andra körning samma felaktiga datum igen.

Några administratörer försöker en hybridlösning: köra imapsync med --dry först för att testa, sedan den riktiga migreringen. Men --dry simulerar bara överföringen: den visar de datum imapsync skulle skicka med, inte om det är de datum e-postmeddelandena faktiskt skickades. Ingenting varnar dig att källdatumen redan är fel.

Gör-det-själv-lösningar och deras gränser

Om du söker i forum och e-postlistor (imapsync-devel-listan på SourceForge är fortfarande aktiv i början av 2026) hittar du förslag som sträcker sig från kreativa till farliga.

Några föreslår en rad Perl-kod för att ändra INTERNALDATE direkt på destinationsservern. Andra rekommenderar att exportera alla meddelanden till mbox-format, manipulera datumen och importera på nytt. Ett fåtal har skrivit Python-skript som använder imaplib för att hämta, ändra och åter infoga meddelanden.

Alla dessa metoder delar samma grundläggande problem. Hur hanterar du S/MIME-signerade meddelanden utan att förstöra signaturen? Vad gäller multipart MIME-strukturer med nästlade gränser? Icke-ASCII-headrar kodade med RFC 2047? PGP-krypterade meddelanden där du inte ens kan inspektera innehållet? Ett skript som hanterar 50 testmeddelanden i en utvecklingsmiljö kvävs av gränsfallen i en produktionsbrevlåda med 30 000 meddelanden.

Och den största frågan som ingen ställer förrän det är för sent: hur verifierar du att varje enskilt ändrat meddelande fortfarande är intakt? Att bilagor inte blev skadade, att trådningen fortfarande fungerar, att kalkylbladet på 85 MB som någon skickade 2020 överlevde manipulationen?

(Om du någon gång försökt tolka råa e-posthuvuden i Perl vet du att det inte precis är en avkopplande eftermiddagsaktivitet.)

Hur Redate.io fixar imapsyncs datumproblem

Det ursprungliga Date:-headret är alltid intakt efter en imapsync-migrering. imapsync överför det råa meddelandet troget; det felaktiga datumet ligger i metadatan kopian fick, inte i meddelandet. Det är det ursprungliga headret som gör det möjligt att fixa datumet.

Redate.io ansluter direkt till brevlådan (Google Workspace, Microsoft 365 eller valfri IMAP-server), söker igenom den efter e-postmeddelanden med datumavvikelser och fixar dem riktat med en egenutvecklad kedjeanalys av headrar och en pipeline för datumrekonstruktion. Den behöver inte veta vilket verktyg som gjorde migreringen: den hittar de e-postmeddelanden vars visade datum inte stämmer med deras ursprungliga datum.

Varje fixat e-postmeddelande verifieras individuellt: meddelandets integritet, bilagor, mappplacering, trådning, etiketter. Originalen bevaras i en synlig säkerhetskopiemapp, Redate.io - Originals, och stannar där tills du själv tar bort dem. Om något ser fel ut är det bara ett klick bort att återställa originalen.

Den kostnadsfria genomsökningen ansluter till brevlådan, identifierar varje e-postmeddelande med en datumavvikelse och rapporterar det exakta antalet och kostnaden. Inget kreditkort krävs, ingen programvara att installera. För detaljerna för din plattform:

Redate.io fungerar även på migreringar som skedde månader eller år sedan. Date:-headret går inte ut, och det gör inte heller möjligheten att fixa det som gick fel.

Migrerade med imapsync och fast med felaktiga datum? Kör en kostnadsfri genomsökning för att se exakt hur många e-postmeddelanden som är påverkade.

imapsync: datum inte bevarade? Så åtgärdar du dem