Varför imapsync är populärt (och varför datumen ändå går sönder)
imapsync är referensverktyget för e-postmigrering bland Linux-systemadministratörer, hostingleverantörer och alla som föredrar öppen källkod. Skapat av Gilles Lamiral har imapsync aktivt underhållits sedan 2001 och använts för miljontals brevlådemigreringar världen över. Det stödjer praktiskt taget alla IMAP-servrar: Dovecot, Courier, Cyrus, Zimbra, Exchange, Gmail och dussintals andra.
imapsync har rykte om sig att vara komplett och konfigurerbart. Administratörer uppskattar den detaljerade kontrollen över vilka mappar som ska migreras, dubbletthanteringen och mappnamnskonverteringen mellan olika IMAP-servrar. Men trots all denna kontroll kvarstår ett problem: e-postdatumen bevaras ofta inte efter en imapsync-migrering. Användarna öppnar sin brevlåda efter migrering och ser att varje e-postmeddelande visar migreringsdatumet. Det är irriterande, särskilt eftersom imapsync är tänkt att hantera datum korrekt.
Hur imapsync hanterar INTERNALDATE
Försöket att bevara INTERNALDATE
imapsync försöker faktiskt bevara INTERNALDATE för varje e-postmeddelande under migreringen. INTERNALDATE är den tidstämpel som IMAP-servern lagrar som metadata för varje meddelande, separat från e-posthuvudena. När imapsync kopierar ett meddelande från källan till destinationen läser det INTERNALDATE från källservern och skickar den till destinationsservern i IMAP APPEND-kommandot.
I teorin borde detta bevara det ursprungliga datumet. I praktiken beror resultatet på destinationsserverns beteende och hur e-postklienter tolkar de olika datumrelaterade fälten i meddelandet.
Problemet med "Received"-huvudet
Även när imapsync lyckas bevara INTERNALDATE lägger destinationens e-postserver till ett nytt "Received"-huvud på varje meddelande under APPEND-operationen. Det "Received"-huvudet innehåller aktuell tidstämpel, migreringsdatumet. E-postklienter som Outlook, Apple Mail och Thunderbird bestämmer det visade "mottagningsdatumet" genom att läsa det översta "Received"-huvudet, inte INTERNALDATE. Så trots imapsyncs ansträngningar att bevara INTERNALDATE är det synliga datumet i de flesta klienter ändå felaktigt.
Det är denna fundamentala diskrepans som orsakar förvirringen. imapsync bevarar ett datumvärde (INTERNALDATE), men e-postklienter visar ett annat (tidstämpeln från "Received"-huvudet). För en teknisk djupdykning i denna mekanism, se varför e-post visar fel datum efter IMAP-migrering.
Missuppfattningen i imapsyncs FAQ
imapsyncs dokumentation och FAQ tar upp datumproblemet men presenterar det som en inneboende begränsning. FAQ:n antyder att "datum kanske inte bevaras" vid IMAP-migrering och implicerar att det helt enkelt är så IMAP-protokollet fungerar. Även om det är sant att IMAP-protokollet kräver att servrar lägger till "Received"-huvuden vid meddelandeinfogning skapar FAQ:n intrycket att problemet är permanent och irreparabelt.
Det stämmer inte. De "Received"-huvuden som läggs till under migreringen kan identifieras och åtgärdas i efterhand, vilket återställer det ursprungliga datumets visning i e-postklienter. Det ursprungliga "Date"-huvudet (som registrerar när e-postmeddelandet ursprungligen skickades) bevaras alltid av imapsync och fungerar som referens för korrekt datum.
Identifiera imapsyncs migreringshuvud
Så här ser huvudet ut
imapsync lägger inte själv till ett "Received"-huvud, det är destinations-IMAP-servern som gör det. Huvudet som läggs till under en imapsync-migrering liknar vanligtvis ett standard IMAP-infogningshuvud från destinationsservern. Till exempel, vid migrering till en Dovecot-server kan huvudet se ut så här:
Received: from localhost by mail.example.com;
Wed, 15 Jan 2025 09:14:22 +0100Den avgörande identifieraren är att detta "Received"-huvud är det översta i kedjan, dess tidstämpel matchar datumet då imapsync kördes, och det refererar vanligtvis till "localhost" eller destinationsserverns hostname snarare än en extern e-postserver.
Jämföra datum
För att bekräfta problemet jämför du tidstämpeln i det översta "Received"-huvudet med e-postens "Date"-huvud. Om "Received"-huvudet visar januari 2025 men "Date"-huvudet visar mars 2020 är migreringens "Received"-huvud orsaken till den felaktiga datumvisningen. Denna jämförelse kan göras genom att visa meddelandets råkälla i vilken e-postklient som helst.
Varför vanliga imapsync-alternativ inte löser problemet
Flaggan --syncinternaldates
imapsync erbjuder flaggan --syncinternaldates, som ställer INTERNALDATE på destinationsservern till att matcha e-postens "Date"-huvud. Det är användbart när källserverns INTERNALDATE redan är felaktig, men det förhindrar inte destinationsservern från att lägga till ett "Received"-huvud. Det synliga datumet i Outlook och andra klienter förblir migreringsdatumet oavsett INTERNALDATE-värdet.
Alternativet --addheader
imapsync kan lägga till anpassade huvuden på meddelanden under migreringen, men kan inte förhindra destinationsservern från att lägga till sitt eget "Received"-huvud. IMAP-protokollet kräver att servrar registrerar infogningstidstämpeln, och inget imapsync-alternativ kan åsidosätta detta serverbeteende.
Skript efter migreringen
Vissa administratörer skriver anpassade skript efter migreringen för att ta bort oönskade "Received"-huvuden. Det låter rimligt, särskilt för den typen av person som valde imapsync från början (någon bekväm med kommandoraden). Men verkligheten är mycket mer komplex än en sök-och-ersätt på huvudtext. Vad händer när skriptet stöter på en S/MIME-signerad e-post? Eller ett multipart-meddelande med nästlade MIME-gränser och base64-kodade bilagor? Eller ett huvud med icke-ASCII-tecken kodade enligt RFC 2047? En enda felplacerad byte i en MIME-gräns kan tyst korruptera ett helt meddelande, förstöra bilagor eller göra e-postmeddelandet oläsbart. Och hur bekräftar du att 10 000 korrigerade e-postmeddelanden alla är intakta? För tusentals e-postmeddelanden över flera brevlådor utgör DIY-skriptning en påtaglig risk.
Korrigera imapsync-datum med Redate.io
Hur Redate.io hanterar imapsync-migreringar
Redate.ios proprietära korrigeringsmotor är byggd specifikt för denna kategori av problem. Efter anslutning till brevlådan analyserar Redate.io varje e-postmeddelande och kör varje meddelande genom en flerstegs analyspipeline. För imapsync-migreringar upptäcker Redate.io det "Received"-huvud som servern infogade genom att tillämpa signaturmatchning mot hundratals kända migreringsprofiler, analysera den fullständiga huvudkedjan och korsreferera tidstämplar med det ursprungliga "Date"-huvudet.
Det här är inte en enkel huvudredigering. Korrigeringsmotorn hanterar RFC-efterlevnadsvalidering, bevarande av meddelandestruktur (inklusive multipart/alternative-strukturer, infogade bilagor och Content-Transfer-Encoding-variationer) och detektion av digitala signaturer. E-postmeddelanden med S/MIME- eller PGP-signaturer identifieras automatiskt och hanteras på lämpligt sätt för att bevara signaturernas integritet.
Vad du får efter korrigeringen
Varje korrigerat e-postmeddelande visar sitt ursprungliga mottagningsdatum i alla e-postklienter. Den kronologiska ordningen är återställd. Varje korrigering genomgår en integritetskontroll innan den slutförs. Det ursprungliga meddelandet flyttas till en mapp "Redate.io - Originals" och bevaras i 30 dagar som säkerhetsnät.
Kompatibilitet med alla destinationsservrar
Eftersom imapsync används för att migrera till praktiskt taget vilken IMAP-server som helst stödjer Redate.io samma bredd av destinationsplattformar. Oavsett om imapsync-migreringen riktades mot Dovecot, Courier, Cyrus, Zimbra, Google Workspace, Microsoft 365 eller någon annan IMAP-server ansluter Redate.io och korrigerar datumen.
Hur du korrigerar datum efter en imapsync-migrering
Anslut brevlådan
Logga in på Redate.io och lägg till brevlådan. För Google Workspace eller Microsoft 365 använder du alternativet för admindelegering. För andra IMAP-servrar (vanliga i imapsync-scenarier) anger du serveradress, användarnamn och lösenord. Redate.io ansluter via standard-IMAP.
Gratis analys
Kör den gratis analysen för att identifiera drabbade e-postmeddelanden. Analysrapporten visar totalt antal e-postmeddelanden, hur många som har fel datum och vilket migreringsdatum som upptäcktes. Analysen kostar ingenting och ger en tydlig bild innan något åtagande.
Korrigera och verifiera
Välj en plan baserad på antalet drabbade e-postmeddelanden och starta korrigeringen. Framstegen visas i realtid. Efter slutförande verifierar du resultaten genom att kontrollera e-postdatumen i din klient. Datumen borde ha återgått till sina rätta värden.
Plattformsspecifika imapsync-korrigeringsguider
Vanliga frågor
Behöver jag använda --syncinternaldates i imapsync innan Redate.io?
Det är inte nödvändigt. Redate.io ställer in rätt INTERNALDATE under korrigeringsprocessen, oavsett aktuellt värde. Oavsett om imapsync bevarade ursprunglig INTERNALDATE eller inte härleder Redate.io korrekt värde från det ursprungliga "Date"-huvudet.
Kan jag korrigera datum på källservern innan jag migrerar med imapsync?
Om källservern redan har felaktiga datum (till följd av en tidigare migrering) kan Redate.io korrigera dem före eller efter imapsync-migreringen. Men att korrigera datum på destinationsservern efter migrering är det vanligaste och mest praktiska tillvägagångssättet.
Hur många e-postmeddelanden kan Redate.io hantera?
Redate.io hanterar brevlådor av alla storlekar. Planer finns för upp till 100 000 e-postmeddelanden per brevlåda. För organisationer med många brevlådor erbjuder Redate.io volympriser.
imapsync-migreringen har förstört datumen? Kör en gratis analys för att se hur många e-postmeddelanden som är drabbade och korrigera dem med Redate.io.