Rett imapsync datoer

Loftet fra --syncinternaldates (og hvorfor det brister)

Du kjorte imapsync-kommandoen. Du inkluderte --syncinternaldates fordi du leste dokumentasjonen og er grundig slik. Migreringen fullforeres, loggen sier alt overfort, null feil. Sa apner du postkassen i Outlook og hver e-post viser garsadgens dato.

Dette er en av de vanligste frustrasjonene med imapsync, og det har forvirret systemadministratorer siden minst 2017. Flagget --syncinternaldates skal bevare IMAP INTERNALDATE under migrering. Og teknisk sett forsoker det. Men "forsoker" gjor mye tungt arbeid i den setningen.

imapsync er et apent kildekode Perl-verktoy skrevet av Gilles Lamiral, og det er genuint godt pa det det gjor. Det handterer IMAP-til-IMAP postkasseoverforsler med en palitelighet som de fleste kommersielle verktoy misunner. Men datobevaring er ikke helt i imapsyncs hender, og det er der det blir komplisert.

Hvordan IMAP-datoer faktisk fungerer

Det er tre forskjellige "datoer" involvert i hver e-post, og de fleste (inkludert noen IT-administratorer) blander dem sammen:

Date:-headeren (RFC 2822) - datoen som avsenderens e-postklient stemplet da meldingen ble skrevet. Den lever inne i meldingskroppen og endres aldri av e-postservere.
Received:-headere - hver e-postserver som handterer meldingen legger til en med sitt eget tidsstempel. De danner en kjede fra avsender til mottaker. Den overste (nyeste) Received-headeren er det noen e-postklienter bruker for visning.
INTERNALDATE - et IMAP-serversideig tidsstempel som styrer hvordan meldinger sorteres i postkassen. Den settes nar meldingen forst lagres via IMAP APPEND.

Nar imapsync migrerer en melding, leser den meldingen fra kildeserveren (inkludert dens INTERNALDATE) og skriver den til destinasjonsserveren med IMAP APPEND. Flagget --syncinternaldates forteller imapsync a sende kildens INTERNALDATE til destinasjonsserveren under APPEND.

Her er problemet: destinasjonsserveren er ikke forpliktet til a respektere den datoen.

Hvorfor destinasjonsservere ignorerer INTERNALDATE

IMAP-spesifikasjonen (RFC 3501) sier at hvis en dato-tid oppgis med APPEND-kommandoen, BOR serveren bruke den. "BOR" pa RFC-sprak betyr "gjor det med mindre du har en god grunn til a la vaere". Flere store e-postplattformer har bestemt at de har en god grunn.

Microsoft 365 er den storste synderen. Nar en melding ankommer via IMAP APPEND, stempler Exchanges transportpipeline en ny Received-header med gjeldende dato, og setter sa INTERNALDATE basert pa det leveringstidsstempelet. Det spiller ingen rolle hvilken dato imapsync ba om. M365-serveren overskriver den.

Google Workspace (Gmail) oppforer seg annerledes, men kan fortsatt skape problemer. Gmails IMAP-implementasjon respekterer INTERNALDATE fra APPEND i de fleste tilfeller, men legger til sin egen Received-header. Hvis e-postklienten som leser postkassen prioriterer Received-headere over INTERNALDATE for visning (og Outlook gjor akkurat det), ser datoene fortsatt feil ut.

Dovecot og Cyrus, de to vanligste aapne kildekode IMAP-serverne, respekterer generelt INTERNALDATE fra APPEND. Sa imapsync-migreringer mellom to Dovecot-servere bevarer vanligvis datoer korrekt. Problemene begynner nar destinasjonen er en hostet plattform med sin egen transportbehandling.

Vanlige imapsync-kommandolinjefeil som odelegger datoer

Glemme --syncinternaldates helt

Flagget er ikke aktivert som standard. Hvis du kjorer en grunnleggende imapsync --host1 source --host2 dest --user1 user --user2 user uten det, forsoker imapsync overhodet ikke a bevare datoer. Destinasjonsserveren bruker gjeldende tidsstempel for hver melding. Det er den vanligste arsaken, og den enkleste a overse fordi imapsync ikke advarer deg.

Bruke --syncinternaldates med --addheader

Noen veiledninger anbefaler a bruke --addheader for a injisere en tilpasset header under migrering. Hvis du legger til headere, endrer du meldingen, noe som kan utlose at destinasjonsserveren behandler den som en "ny" melding og stempler den deretter. Samspillet mellom disse to flaggene er darlig dokumentert.

Forveksle --minage og --maxage med datobevaring

Flaggene --minage og --maxage filtrerer hvilke meldinger som migreres basert pa alder. De pavirker ikke hvordan datoer handteres ved destinasjonen. Jeg har sett administratorer bruke timer pa a justere disse flaggene i troen pa at det ville lose datoproblemet. Det gjor det ikke.

Tidsstempeldrift fra SSL-forhandling

Ved migrering over TLS med --ssl1 og --ssl2 legger tilkoblingsoppsettet til latens. Ved store migreringer (50 000+ meldinger) akkumuleres denne latensen. Den endrer ikke datoer med dager, men kan gjore at meldinger sendt minutter fra hverandre ankommer med identiske tidsstempler ved destinasjonen, slik at deres innbyrdes rekkefolge gar tapt.

Lese imapsync-logger: hva utdataen egentlig forteller deg

imapsync produserer detaljerte logger, noe som er bra. Men loggutdataen kan vaere villedende nar det gjelder datoer.

En typisk vellykket overforingslinje ser slik ut:

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. Det betyr at imapsync sendte riktig INTERNALDATE til destinasjonen. Men det betyr ikke at destinasjonsserveren faktisk lagret den datoen. imapsync rapporterer hva den ba om, ikke hva serveren aksepterte.

Vil du verifisere hva som faktisk skjedde? Koble til destinasjonen med en IMAP-klient etter migreringen og sjekk INTERNALDATE direkte:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Hvis den returnerte datoen er migreringsdatoen i stedet for 2019-01-15, ignorerte destinasjonsserveren imapsyncs forespursel. Loggen loy for deg (vel, den fortalte deg hva den ba om, ikke hva den fikk).

Storskala imapsync-migreringer: der datoproblemer multipliseres

En enkelt postkassemigrering med imapsync er irriterende nar datoer gar i stykker. Men MSP-er og IT-avdelinger som kjorer imapsync pa tvers av hundrevis av postkasser star overfor en helt annen skala av problemet.

Ta et typisk bedriftsmigreringsscenario. Du flytter 200 postkasser fra en Zimbra-server til Microsoft 365. Du skriver et wrapper-skript som looper gjennom en CSV med brukere og kaller imapsync for hver. Migreringen kjorer i helgen. Mandag morgen har du 200 postkasser med oadelagte datoer og rundt 1,2 millioner e-poster totalt som viser migreringstidsstempelet.

Kan du kjore imapsync pa nytt med --syncinternaldates hvis du glemte det forste gang? Teknisk sett ja, men imapsync hopper over meldinger som allerede finnes pa destinasjonen (det er designet for a vaere idempotent). Du ville trengt --delete2 for a slette destinasjonsmeldinger og overforere dem pa nytt, noe som er risikabelt pa en produksjonspostkasse. Og selv da, hvis destinasjonsserveren ignorerer INTERNALDATE, er du tilbake til start.

Gjor-det-selv-losninger og deres grenser

Hvis du soker i fora og e-postlister (imapsync-devel-listen pa SourceForge er fortsatt aktiv i begynnelsen av 2026), finner du forslag som spenner fra kreative til farlige.

Noen foreslar a bruke en Perl-enlinjekode for a endre INTERNALDATE pa destinasjonsserveren direkte. Andre anbefaler a eksportere alle meldinger til mbox-format, manipulere datoene og reimportere. Noen har skrevet Python-skript som bruker imaplib for a hente, endre og sette inn meldinger pa nytt.

Alle disse tilnaermingene deler de samme grunnleggende problemene. Hvordan handterer du S/MIME-signerte meldinger uten a bryte signaturen? Hva med multipart MIME-strukturer med nestede grenser? Ikke-ASCII-headere kodet med RFC 2047? PGP-krypterte meldinger der du ikke engang kan inspisere innholdet? Et skript som handterer 50 testmeldinger i et utviklingsmiljo vil kveles pa kanttilfellene i en produksjonspostkasse med 30 000 meldinger.

Og det storste sporsmalet som ingen stiller for det er for sent: hvordan verifiserer du at hver eneste modifiserte melding fortsatt er intakt?

Slik retter Redate.io imapsync-datoproblemer

Den opprinnelige Date:-headeren er alltid intakt etter en imapsync-migrering. imapsync overforer rameldingen trofast; det er destinasjonsserverens metadatahandtering som forarsaker visningsproblemet. Den opprinnelige headeren er det som gjor korreksjon mulig.

Redate.io kobler seg direkte til postkassen (Google Workspace, Microsoft 365 eller enhver IMAP-server), skanner etter e-poster med datoavvik og anvender malrettet metadatakorrigering gjennom en proprietaer headerkjedeanalyse- og datorekonstruksjonspipeline. Korreksjonen handterer de spesifikke monstrene som imapsync-migreringer etterlater, inkludert de karakteristiske Received-headersignaturene fra destinasjonsservere som overskrev INTERNALDATE.

Hver rettet e-post verifiseres individuelt: meldingsintegritet, vedleggsbevaring, mappeplassering, trading, etiketter. Originaler oppbevares i en synlig sikkerhetskopieringsmappe Redate.io - Originals i 30 dager. Hvis noe ser feil ut, er tilbakerulling et klikk unna.

Den gratis skanningen kobler seg til postkassen, identifiserer hver e-post med et datoavvik og rapporterer det eksakte antallet og kostnaden. Intet kredittkort pavkrevd, ingen programvare a installere. For din plattforms detaljer:

Redate.io fungerer ogsa for migreringer som skjedde for maaneder eller aar siden. Date:-headeren utloper ikke, og muligheten til a korrigere heller ikke.

Migrert med imapsync og fast med feil datoer? Kjor en gratis skanning for a se noyaktig hvor mange e-poster som er beroart.

imapsync: datoer ikke bevart? Slik retter du dem