Atgarda imapsync datum

Loftet fran --syncinternaldates (och varfor det brister)

Du korde imapsync-kommandot. Du inkluderade --syncinternaldates for att du laste dokumentationen och ar noggrann sa. Migreringen avslutas, loggen sager allt overforde, noll fel. Sedan oppnar du brevladan i Outlook och varje e-post visar gardagens datum.

Det har ar en av de vanligaste frustrationerna med imapsync, och det har forvirrat systemadministratorer sedan atminstone 2017. Flaggan --syncinternaldates ska bevara IMAP INTERNALDATE under migrering. Och tekniskt sett forsoker den. Men "forsoker" gor tungt arbete i den meningen.

imapsync ar ett Perl-verktyg med oppen kallkod skrivet av Gilles Lamiral, och det ar genuint bra pa det det gor. Det hanterar IMAP-till-IMAP brevladaoverforing med en palitlighet som de flesta kommersiella verktyg avundas. Men datumbevarande ligger inte helt i imapsyncs hander, och dar blir det komplicerat.

Hur IMAP-datum faktiskt fungerar

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

Date:-headret (RFC 2822) - datumet som avsandarens e-postklient stamplade nar meddelandet skrevs. Det lever inuti meddelandekroppen och andras aldrig av e-postservrar.
Received:-headers - varje e-postserver som hanterar meddelandet lagger till ett med sin egen tidsstampel. De bildar en kedja fran avsandare till mottagare. Det oversta (senaste) Received-headret ar vad vissa e-postklienter anvander for visning.
INTERNALDATE - en IMAP-serversidans tidsstampel som styr hur meddelanden sorteras i brevladan. Den satts nar meddelandet forst lagras via IMAP APPEND.

Nar imapsync migrerar ett meddelande laser det meddelandet fran kallservern (inklusive dess INTERNALDATE) och skriver det till destinationsservern med IMAP APPEND. Flaggan --syncinternaldates sager at imapsync att skicka med kallans INTERNALDATE till destinationsservern under APPEND.

Har ar problemet: destinationsservern ar inte skyldig att respektera det datumet.

Varfor destinationsservrar ignorerar INTERNALDATE

IMAP-specifikationen (RFC 3501) sager att om en datum-tid anges med APPEND-kommandot BOR servern anvanda den. "BOR" pa RFC-sprak betyder "gor det om du inte har en bra anledning att inte gora det". Flera stora e-postplattformar har bestamt att de har en bra anledning.

Microsoft 365 ar den storsta boveen. Nar ett meddelande anknder via IMAP APPEND stampar Exchanges transportpipeline ett nytt Received-header med aktuellt datum, och satter sedan INTERNALDATE baserat pa det leveranstidsstamplet. Det spelar ingen roll vilket datum imapsync begarde. M365-servern skriver over det.

Google Workspace (Gmail) beter sig annorlunda men kan anda orsaka problem. Gmails IMAP-implementering respekterar INTERNALDATE fran APPEND i de flesta fall, men lagger till ett eget Received-header. Om e-postklienten som laser brevladan prioriterar Received-headers over INTERNALDATE for visning (och Outlook gor exakt det), ser datumen fortfarande felaktiga ut.

Dovecot och Cyrus, de tva vanligaste IMAP-servrarna med oppen kallkod, respekterar generellt INTERNALDATE fran APPEND. Sa imapsync-migreringar mellan tva Dovecot-servrar bevarar vanligtvis datum korrekt. Problemen borjar nar destinationen ar en hostad plattform med egen transportbearbetning.

Vanliga imapsync-kommandoradsmisstag som forstaor datum

Glomma --syncinternaldates helt

Flaggan ar inte aktiverad som standard. Om du kor ett grundlaggande imapsync --host1 source --host2 dest --user1 user --user2 user utan den, forsoker imapsync inte alls bevara datum. Destinationsservern anvander aktuell tidsstampel for varje meddelande. Det ar den vanligaste orsaken, och den enklaste att missa for att imapsync inte varnar dig.

Anvanda --syncinternaldates med --addheader

Vissa guider rekommenderar att anvanda --addheader for att injicera ett anpassat header under migrering. Om du lagger till headers andrar du meddelandet, vilket kan utlosa att destinationsservern behandlar det som ett "nytt" meddelande och stampar det darefter. Interaktionen mellan dessa tva flaggor ar daligt dokumenterad.

Forvaxla --minage och --maxage med datumbevarande

Flaggorna --minage och --maxage filtrerar vilka meddelanden som migreras baserat pa deras alder. De paverkar inte hur datum hanteras vid destinationen. Jag har sett administratorer lagga timmar pa att justera dessa flaggor i tron att det skulle losa datumproblemet. Det gor det inte.

Tidsstampeldrift fran SSL-forhandling

Vid migrering over TLS med --ssl1 och --ssl2 lagger anslutningsuppsattningen till latens. Vid stora migreringar (50 000+ meddelanden) ackumuleras denna latens. Det andrar inte datum med dagar, men kan gora att meddelanden skickade minuter fran varandra anknder med identiska tidsstamplar vid destinationen, sa att deras inbordes ordning gar forlorad.

Lasa imapsync-loggar: vad utdatan faktiskt beratter

imapsync producerar detaljerade loggar, vilket ar bra. Men loggutdatan kan vara vilseledande nar det galler datum.

En typisk lyckad overforingsrad ser ut sa har:

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

Bada datum stammer. Det betyder att imapsync skickade korrekt INTERNALDATE till destinationen. Men det betyder inte att destinationsservern faktiskt lagrade det datumet. imapsync rapporterar vad den begarde, inte vad servern accepterade.

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

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Om det returnerade datumet ar migreringsdatumet istallet for 2019-01-15 ignorerade destinationsservern imapsyncs begaran. Loggen ljog for dig (ja, den berattade vad den bad om, inte vad den fick).

Storskaliga imapsync-migreringar: dar datumproblem multipliceras

En enskild brevlademigrering med imapsync ar irriterande nar datum gar sonder. Men MSP:er och IT-avdelningar som kor imapsync over hundratals brevlador star infor en helt annan skala av problemet.

Ta ett typiskt foretagsmigreringsscenario. Du flyttar 200 brevlador fran en Zimbra-server till Microsoft 365. Du skriver ett wrapper-skript som loopar genom en CSV med anvandare och anropar imapsync for var och en. Migreringen kors over helgen. Pa mandag morgon har du 200 brevlador med trasiga datum och runt 1,2 miljoner e-postmeddelanden totalt som visar migreringens tidsstampel.

Kan du kora imapsync igen med --syncinternaldates om du glomde det forsta gangen? Tekniskt ja, men imapsync hoppar over meddelanden som redan finns pa destinationen (det ar utformat for att vara idempotent). Du skulle behova --delete2 for att ta bort destinationsmeddelanden och overfora dem igen, vilket ar riskabelt pa en produktionsbrevlada. Och aven da, om destinationsservern ignorerar INTERNALDATE, ar du tillbaka pa ruta ett.

Gor-det-sjalv-losningar och deras granser

Om du soker i forum och e-postlistor (imapsync-devel-listan pa SourceForge ar fortfarande aktiv i borjan av 2026), hittar du forslag som spanner fran kreativa till farliga.

Nagra foreslar att anvanda en Perl-enrading for att andra INTERNALDATE pa destinationsservern direkt. Andra rekommenderar att exportera alla meddelanden till mbox-format, manipulera datumen och aterimportera. Nagra har skrivit Python-skript som anvander imaplib for att hamta, andra och aterinforea meddelanden.

Alla dessa ansatser delar samma grundlaggande problem. Hur hanterar du S/MIME-signerade meddelanden utan att bryta signaturen? Hur ar det med multipart MIME-strukturer med nastlade granser? Icke-ASCII-headers kodade med RFC 2047? PGP-krypterade meddelanden dar du inte ens kan inspektera innehallet? Ett skript som hanterar 50 testmeddelanden i en utvecklingsmiljo kvavs pa kantfallen i en produktionsbrevlada med 30 000 meddelanden.

Och den storsta fragan som ingen staller forran det ar for sent: hur verifierar du att varje andrat meddelande fortfarande ar intakt?

Hur Redate.io atgardar imapsync-datumproblem

Det ursprungliga Date:-headret ar alltid intakt efter en imapsync-migrering. imapsync overfar rameddelandet troget; det ar destinationsserverns metadatahantering som orsakar visningsproblemet. Det ursprungliga headret ar det som gor korrigering mojlig.

Redate.io ansluter direkt till brevladan (Google Workspace, Microsoft 365 eller valfri IMAP-server), skannar efter e-postmeddelanden med datumavvikelser och tillampaar riktad metadatakorrigering genom en proprietar headerkedjeanalys- och datumrekonstruktionspipeline. Korrigeringen hanterar de specifika monster som imapsync-migreringar lamnar efter sig, inklusive de karaktaristiska Received-headersignaturerna fran destinationsservrar som skrev over INTERNALDATE.

Varje korrigerat e-postmeddelande verifieras individuellt: meddelandeintegritet, bilagebevaring, mappplacering, tradning, etiketter. Original bevaras i en synlig sakerhetskopieringsmapp Redate.io - Originals i 30 dagar. Om nagot ser fel ut ar aterstaallning ett klick bort.

Den gratis skanningen ansluter till brevladan, identifierar varje e-post med en datumavvikelse och rapporterar det exakta antalet och kostnaden. Inget kreditkort kravs, ingen programvara att installera. For din plattforms detaljer:

Redate.io fungerar aven for migreringar som skedde for manader eller ar sedan. Date:-headret gar inte ut, och mojligheten att korrigera gora det inte heller.

Migrerat med imapsync och fast med felaktiga datum? Kor en gratis skanning for att se exakt hur manga e-postmeddelanden som ar paverkade.

imapsync: datum inte bevarade? Sa atgardar du dem