Ret imapsync datoer

Løftet fra --syncinternaldates (og hvor det stopper)

Du kørte imapsync-kommandoen. Du inkluderede --syncinternaldates, fordi du læste dokumentationen og er omhyggelig på den måde. Migreringen afsluttes, loggen siger at alt er overført, nul fejl. Så åbner du postkassen i Outlook, og hver e-mail viser gårsdagens dato.

Det er en af de mest almindelige frustrationer ved imapsync, og det har forvirret systemadministratorer siden mindst 2017. Flaget --syncinternaldates skal bevare IMAP INTERNALDATE under migreringen. Og det gør det: det giver hver kopi den interne dato, som kildeserveren har. Og lige der ligger fælden.

imapsync er et open source Perl-værktøj skrevet af Gilles Lamiral, og det er oprigtigt godt til det, det gør. Det håndterer IMAP-til-IMAP-postkasseoverførsler med en pålidelighed, som de fleste kommercielle værktøjer misunder. Men imapsync kan kun kopiere de datoer, den finder, og det er dér, det bliver indviklet.

Hvordan IMAP-datoer faktisk fungerer

Der er tre forskellige "datoer" involveret i hver e-mail, og de fleste (inklusive nogle it-administratorer) blander dem sammen:

Date:-headeren (RFC 2822) - datoen som afsenderens e-mailklient stemplede på beskeden, da den blev skrevet. Den ligger inde i selve beskeden og ændres aldrig af mailservere.
Received:-headers - hver mailserver, der behandler beskeden, tilføjer en med sit eget tidsstempel. De danner en kæde fra afsender til modtager. Den øverste (nyeste) Received-header er den, som nogle e-mailklienter bruger til visning.
INTERNALDATE - et tidsstempel på IMAP-serveren, der styrer, hvordan beskeder sorteres i postkassen. Det sættes, når beskeden først gemmes via IMAP APPEND.

Når imapsync migrerer en besked, læser den beskeden fra kildeserveren (inklusive dens INTERNALDATE) og skriver den til destinationsserveren med IMAP APPEND. Flaget --syncinternaldates beder imapsync om at videregive kildens INTERNALDATE til destinationsserveren under APPEND.

Her er den gode nyhed: Microsoft 365, Outlook.com og Gmail bevarer den dato, de får. Så når datoerne ender med at være forkerte, ligger problemet et andet sted.

Hvorfor datoerne stadig kan være forkerte

IMAP-specifikationen (RFC 3501) siger, at hvis der leveres en dato-tid med APPEND-kommandoen, BØR serveren bruge den. "BØR" på RFC-sprog betyder "gør det, medmindre du har en god grund til ikke at gøre det". Microsoft 365, Outlook.com og Gmail gør netop det: en kopi, der bærer sin oprindelige dato, bevarer den.

Det, imapsync videregiver, er dog den dato, KILDESERVEREN har for hver besked, ikke den dato, e-mailen blev sendt. På en sund postkasse stemmer de to overens. På en postkasse, der allerede er migreret én gang eller genoprettet fra en backup, kan kilden holde datoen for den tidligere handling, og imapsync kopierer den, som den er.

Gmail er kun et særtilfælde, når kopien går gennem Gmails egen import-API i stedet for IMAP: den API tilføjer en Received-linje dateret dagen for kopieringen, og Outlook kan vise den dato. imapsync taler IMAP, så det påvirker ikke imapsync.

Dovecot og Cyrus, de to mest udbredte open source IMAP-servere, bevarer også datoen fra APPEND. Så uanset destinationen er spørgsmålet det samme: hvilken dato havde kilden?

Almindelige fejl i imapsync-kommandolinjen, der giver forkerte datoer

Udover kildedatoerne snubler administratorer ofte over imapsyncs kommandolinjetilvalg, eller bebrejder de forkerte. Her er de fejl, jeg ser oftest:

At kopiere fra en kilde, hvis datoer allerede var forkerte

--syncinternaldates er slået til som standard: imapsync giver hver kopi den interne dato, kildeserveren har (dokumentationen siger: "Sets the internal dates on host2 as the same as host1"). Hvis kildepostkassen selv er resultatet af en tidligere migrering eller en gendannelse fra backup, kan dens interne datoer allerede være datoerne for den handling, og imapsync kopierer trofast den forkerte dato videre. Det er den mest almindelige årsag, og den nemmeste at overse, fordi loggen viser to identiske datoer.

At bruge --syncinternaldates sammen med --addheader

Nogle vejledninger anbefaler at bruge --addheader til at indsætte en brugerdefineret header under migreringen. At tilføje en header ændrer beskeden (én linje mere øverst), men ikke den dato, imapsync videregiver, så det forklarer ikke forkerte datoer. Kopien er simpelthen ikke længere identisk med originalen, hvilket har betydning, hvis du sammenligner de to.

At forveksle --minage og --maxage med datobevaring

Flagene --minage og --maxage filtrerer, hvilke beskeder der migreres, baseret på deres alder. De påvirker ikke, hvordan datoerne håndteres på destinationen. Jeg har set administratorer bruge timer på at justere disse flag i troen på, at det ville rette datoproblemet. Det gør det ikke.

At give TLS skylden for forskudte datoer

Over TLS (--ssl1, --ssl2) tilføjer opsætningen af forbindelser latens, og på en stor migrering (50.000+ beskeder) løber det op i timer. Det rører ikke datoerne: hver kopi bærer den dato, imapsync videregiver, uanset hvornår den rent faktisk lander.

At læse imapsync-logfiler: hvad outputtet faktisk fortæller dig

imapsync producerer detaljerede logfiler, hvilket er godt. Men logoutputtet kan være vildledende, når det gælder datoer.

En typisk vellykket overførselslinje ser sådan ud:

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

Begge datoer stemmer overens. Det betyder, at imapsync sendte den korrekte INTERNALDATE til destinationen. Og Microsoft 365, Outlook.com og Gmail bevarer alle den dato, de får. Men to identiske datoer beviser kun, at kopien er trofast mod KILDEN: hvis kildedatoen allerede var forkert, viser begge kolonner den samme forkerte dato.

Vil du bekræfte, hvad der faktisk skete? Forbind til destinationen med en IMAP-klient efter migreringen, og kontroller INTERNALDATE direkte:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Hvis den returnerede dato ikke er datoen, e-mailen blev sendt, så kig på den samme besked på kilden: du finder den samme forkerte dato der. Loggen løj ikke, den kopierede blot det, den fik.

Det er en af de mest frustrerende sider af at fejlsøge datoproblemer: en ren logfil, to identiske datoer, og alligevel den forkerte dato i Outlook, fordi fejlen var der, før imapsync kørte.

Storskala imapsync-migreringer: hvor datoproblemer multipliceres

En enkelt postkassemigrering med imapsync er irriterende, når datoerne går i stykker. Men MSP'er og it-afdelinger, der kører imapsync på tværs af hundredvis af postkasser, står over for en helt anden skala af problemet.

Forestil dig et typisk virksomhedsmigreringsscenarie. Du flytter 200 postkasser fra en Zimbra-server til Microsoft 365. Du skriver et wrapper-script, der løber gennem en CSV med brugere og kalder imapsync for hver enkelt. Migreringen kører over en weekend. Mandag morgen har du 200 postkasser med forkerte datoer, og omkring 1,2 millioner e-mails i alt, der viser migreringstidsstemplet.

Kan du køre imapsync igen for at rette det? Teknisk set ja, men imapsync springer beskeder over, der allerede findes på destinationen (det er designet til at være idempotent). Du ville få brug for --delete2 til at fjerne destinationsbeskeder og overføre dem igen, hvilket er risikabelt på en produktionspostkasse. Og hvis kildedatoerne var problemet, kopierer en ny kørsel de samme forkerte datoer igen.

Nogle administratorer prøver en hybrid tilgang: køre imapsync med --dry først for at teste, og derefter den rigtige migrering. Men --dry simulerer kun overførslen: den viser de datoer, imapsync ville videregive, ikke om det er de datoer, e-mailene blev sendt. Intet advarer dig om, at kildedatoerne allerede er forkerte.

Gør-det-selv-løsninger og deres grænser

Hvis du søger i fora og mailinglister (imapsync-devel-listen på SourceForge er stadig aktiv i starten af 2026), finder du forslag, der spænder fra kreative til farlige.

Nogle foreslår at bruge en Perl-oneliner til at ændre INTERNALDATE direkte på destinationsserveren. Andre anbefaler at eksportere alle beskeder til mbox-format, manipulere datoerne og genimportere. Nogle har skrevet Python-scripts, der bruger imaplib til at hente, ændre og genindsætte beskeder.

Alle disse tilgange deler de samme grundlæggende problemer. Hvordan håndterer du S/MIME-signerede beskeder uden at bryde signaturen? Hvad med multipart MIME-strukturer med indlejrede grænser? Ikke-ASCII-headers kodet med RFC 2047? PGP-krypterede beskeder, hvor du ikke engang kan inspicere indholdet? Et script, der klarer 50 testbeskeder i et udviklingsmiljø, går i stå på kanttilfældene i en produktionspostkasse med 30.000 beskeder.

Og det største spørgsmål, som ingen stiller, før det er for sent: hvordan bekræfter du, at hver eneste ændrede besked stadig er intakt? At vedhæftninger ikke blev beskadiget, at threading stadig fungerer, at det 85 MB store regneark, som nogen sendte i 2020, overlevede manipulationen?

(Hvis du nogensinde har forsøgt at parse rå e-mailheaders i Perl, ved du, at det ikke ligefrem er en afslappende fritidsaktivitet.)

Sådan retter Redate.io imapsync-datoproblemer

Den oprindelige Date:-header er altid intakt efter en imapsync-migrering. imapsync overfører den rå besked trofast; den forkerte dato ligger i metadataen, kopien fik, ikke i selve beskeden. Den oprindelige header er det, der gør korrektionen mulig.

Redate.io forbinder direkte til postkassen (Google Workspace, Microsoft 365 eller enhver IMAP-server), gennemgår e-mails for datoanomalier og anvender målrettet metadatakorrektion gennem en egenudviklet analyse af headerkæder og en pipeline til datorekonstruktion. Det behøver ikke vide, hvilket værktøj der stod for migreringen: det finder de e-mails, hvis viste dato ikke stemmer med deres oprindelige dato.

Hver rettet e-mail verificeres individuelt: beskedintegritet, bevarelse af vedhæftninger, mappeplacering, threading, labels. De oprindelige e-mails opbevares i en synlig sikkerhedskopieringsmappe, Redate.io - Originals, og forbliver der, indtil du selv sletter dem. Hvis noget ser forkert ud, er en tilbagerulning kun et klik væk.

Den gratis gennemgang forbinder til postkassen, identificerer hver e-mail med en datoanomali og viser det nøjagtige antal og prisen. Intet kreditkort krævet, ingen software at installere. For detaljerne til din platform:

Redate.io virker også på migreringer, der fandt sted for måneder eller år siden. Date:-headeren udløber ikke, og det gør muligheden for at rette det, der gik skævt, heller ikke.

Migreret med imapsync og fast med forkerte datoer? Kør en gratis gennemgang for at se præcist, hvor mange e-mails der er berørt.

imapsync: datoer ikke bevaret? Sådan retter du dem