Ret imapsync datoer

Loftet fra --syncinternaldates (og hvorfor det brister)

Du korte imapsync-kommandoen. Du inkluderede --syncinternaldates, fordi du laeste dokumentationen og er omhyggelig pa den made. Migreringen afslutter, loggen siger alt overfort, nul fejl. Sa abner du postkassen i Outlook, og hver e-mail viser gars dato.

Det er en af de mest almindelige frustrationer med imapsync, og det har forvirret systemadministratorer siden mindst 2017. Flaget --syncinternaldates skal bevare IMAP INTERNALDATE under migrering. Og teknisk set forsoger det. Men "forsoger" lofter tungt i den saetning.

imapsync er et open source Perl-vaerktoj skrevet af Gilles Lamiral, og det er oprigtigt godt til det, det gor. Det handterer IMAP-til-IMAP postkasseooverforssler med en palidelighed, som de fleste kommercielle vaerktojer misunder. Men datobevaring er ikke helt i imapsyncs haender, og der bliver det 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, da beskeden blev skrevet. Den lever inde i beskeden og aendres aldrig af mailservere.
Received:-headers - hver mailserver der behandler beskeden tilfojer en med sit eget tidsstempel. De danner en kaede fra afsender til modtager. Den overste (nyeste) Received-header er det, som nogle e-mailklienter bruger til visning.
INTERNALDATE - et IMAP-serverside tidsstempel der styrer, hvordan beskeder sorteres i postkassen. Det saettes, nar beskeden forst gemmes via IMAP APPEND.

Nar imapsync migrerer en besked, laeser den beskeden fra kildeserveren (inklusive dens INTERNALDATE) og skriver den til destinationsserveren via IMAP APPEND. Flaget --syncinternaldates fortaeller imapsync at videregive kildens INTERNALDATE til destinationsserveren under APPEND.

Her er problemet: destinationsserveren er ikke forpligtet til at respektere den dato.

Hvorfor destinationsservere ignorerer INTERNALDATE

IMAP-specifikationen (RFC 3501) siger, at hvis en dato-tid leveres med APPEND-kommandoen, BOR serveren bruge den. "BOR" pa RFC-sprog betyder "gor det, medmindre du har en god grund til ikke at gore det". Flere store e-mailplatforme har besluttet, at de har en god grund.

Microsoft 365 er den storste synder. Nar en besked ankommer via IMAP APPEND, stempler Exchange-transportpipelinen en ny Received-header med den aktuelle dato og saetter derefter INTERNALDATE baseret pa det leveringstidsstempel. Det er ligegyldigt, hvilken dato imapsync bad om. M365-serveren overskriver den.

Google Workspace (Gmail) opforer sig anderledes, men kan stadig skabe problemer. Gmails IMAP-implementering respekterer INTERNALDATE fra APPEND i de fleste tilfaelde, men tilfojer sin egen Received-header. Hvis e-mailklienten der laeser postkassen prioriterer Received-headers over INTERNALDATE til visning (og Outlook gor netop det), ser datoerne stadig forkerte ud.

Dovecot og Cyrus, de to mest udbredte open source IMAP-servere, respekterer generelt INTERNALDATE fra APPEND. Sa imapsync-migreringer mellem to Dovecot-servere bevarer normalt datoer korrekt. Problemerne begynder, nar destinationen er en hostet platform med sin egen transportbehandling.

Almindelige imapsync-kommandolinjefejl der odelagger datoer

Glemme --syncinternaldates helt

Flaget er ikke aktiveret som standard. Hvis du korer et basalt imapsync --host1 source --host2 dest --user1 user --user2 user uden det, forsoger imapsync slet ikke at bevare datoer. Destinationsserveren bruger det aktuelle tidsstempel til hver besked. Det er den mest udbredte arsag, og den nemmeste at overse, fordi imapsync ikke advarer dig om det.

Bruge --syncinternaldates med --addheader

Nogle vejledninger anbefaler at bruge --addheader til at injicere en brugerdefineret header under migrering. Hvis du tilfojer headers, aendrer du beskeden, hvilket kan fa destinationsserveren til at behandle den som en "ny" besked og stemple den derefter. Interaktionen mellem disse to flag er darligt dokumenteret.

Forveksle --minage og --maxage med datobevaring

Flagene --minage og --maxage filtrerer hvilke beskeder der migreres baseret pa deres alder. De pavirker ikke, hvordan datoer handteres pa destinationen. Jeg har set administratorer bruge timer pa at justere disse flag i troen pa, at det ville lose datoproblemet. Det vil det ikke.

Tidsstempeldrift fra SSL-forhandling

Ved migrering over TLS med --ssl1 og --ssl2 tilfojer forbindelsesopsaetningen latens. Ved store migreringer (50.000+ beskeder) akkumuleres denne latens. Den aendrer ikke datoer med dage, men kan medforere, at beskeder sendt minutter fra hinanden ankommer med identiske tidsstempler pa destinationen, sa deres indbyrdes raekkefolge ga tabt.

Laes imapsync-logfiler: hvad outputtet faktisk fortaeller dig

imapsync producerer detaljerede logfiler, hvilket er godt. Men logoutputtet kan vaere vildledende nar det galder datoer.

En typisk vellykket overforselslinje ser sadan 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 det korrekte INTERNALDATE til destinationen. Men det betyder ikke, at destinationsserveren faktisk gemte den dato. imapsync rapporterer, hvad den bad om, ikke hvad serveren accepterede.

Vil du verificere, 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 er migreringsdatoen i stedet for 2019-01-15, ignorerede destinationsserveren imapsyncs anmodning. Loggen loj for dig (altsa, den fortalte dig hvad den bad om, ikke hvad den fik).

Storskalerede imapsync-migreringer: hvor datoproblemer multipliceres

En enkelt postkassemigrering med imapsync er irriterende, nar datoer gar i stykker. Men MSP'er og IT-afdelinger der korer imapsync pa tvaers af hundredvis af postkasser star over for en helt anden skala af problemet.

Tag et typisk virksomhedsmigreringsscenario. Du flytter 200 postkasser fra en Zimbra-server til Microsoft 365. Du skriver et wrapper-script der looper gennem en CSV med brugere og kalder imapsync for hver. Migreringen korer i weekenden. Mandag morgen har du 200 postkasser med odte datoer og omkring 1,2 millioner e-mails i alt der viser migreringstidsstemplet.

Kan du kore imapsync igen med --syncinternaldates, hvis du glemte det forste gang? Teknisk set ja, men imapsync springer beskeder over der allerede eksisterer pa destinationen (det er designet til at vaere idempotent). Du ville have brug for --delete2 til at slette destinationsbeskeder og overfor dem igen, hvilket er risikabelt pa en produktionspostkasse. Og selv da, hvis destinationsserveren ignorerer INTERNALDATE, er du tilbage ved start.

Gor-det-selv-losninger og deres graenser

Hvis du soger i fora og mailinglister (imapsync-devel-listen pa SourceForge er stadig aktiv i starten af 2026), finder du forslag der spander fra kreative til farlige.

Nogle foreslar at bruge en Perl-oneliner til at aendre INTERNALDATE pa destinationsserveren direkte. Andre anbefaler at eksportere alle beskeder til mbox-format, manipulere datoerne og genimportere. Nogle har skrevet Python-scripts der bruger imaplib til at hente, aendre og genindsaette beskeder.

Alle disse tilgange deler de samme fundamentale problemer. Hvordan handterer du S/MIME-signerede beskeder uden at bryde signaturen? Hvad med multipart MIME-strukturer med indlejrede graenser? 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 udviklingsmiljo vil ga i sta pa kanttilfaeldene i en produktionspostkasse med 30.000 beskeder.

Og det storste sporgsmal som ingen stiller for det er for sent: hvordan verificerer du, at hver eneste aendrede besked stadig er intakt?

Sadan retter Redate.io imapsync-datoproblemer

Den originale Date:-header er altid intakt efter en imapsync-migrering. imapsync overforer den ra besked trofast; det er destinationsserverens metadatahandtering der foarsager visningsproblemet. Den originale header er det der gor korrektion mulig.

Redate.io forbinder direkte til postkassen (Google Workspace, Microsoft 365 eller enhver IMAP-server), scanner for e-mails med datoanomalier og anvender malrettet metadatakorrektion gennem en proprietaer headerkaedeanalyse- og datorekonstruktionspipeline. Korrektionen handterer de specifikke monstre som imapsync-migreringer efterlader, herunder de karakteristiske Received-headersignaturer fra destinationsservere der overskrev INTERNALDATE.

Hver rettet e-mail verificeres individuelt: beskedintegritet, vedhaeftningsbevaelse, mappeplacering, threading, labels. Originaler opbevares i en synlig sikkerhedskopieringsmappe Redate.io - Originals i 30 dage. Hvis noget ser forkert ud, er tilbagerulning et klik vaek.

Den gratis scanning forbinder til postkassen, identificerer hver e-mail med en datoanomali og rapporterer det praecise antal og prisen. Intet kreditkort kradvet, ingen software at installere. For din platforms specifikationer:

Redate.io virker ogsa for migreringer der skete for maneder eller ar siden. Date:-headeren udlober ikke, og muligheden for at rette heller ikke.

Migreret med imapsync og fast med forkerte datoer? Kor en gratis scanning for at se praecist, hvor mange e-mails der er berort.

imapsync: datoer ikke bevaret? Sadan retter du dem