imapsync: paivat eivat sailyneet? Nain korjaat ne

--syncinternaldates-lupaus (ja miksi se pettaa)

Suoritit imapsync-komennon. Lisasit --syncinternaldates-lipun, koska luit dokumentaation ja olet huolellinen talla tavalla. Siirto paattyy, loki sanoo kaiken siirtyneen, nolla virhetta. Sitten avaat postilaatikon Outlookissa ja jokainen sahkoposti nayttaa eilisen paivamaaran.

Tama on yksi imapsynci yleisimmista turhauttavista ongelmista, ja se on hammentanyt jarjestelmaanyllapitajia ainakin vuodesta 2017. --syncinternaldates-lippu on tarkoitettu sailyttamaan IMAP INTERNALDATE siirron aikana. Ja teknisesti se yrittaa. Mutta "yrittaa" tekee paljon raskasta tyota tuossa lauseessa.

imapsync on Gilles Lamiralin kirjoittama avoimen lahdekoodin Perl-tyokalu, ja se on aidosti hyva siina mita se tekee. Se kasittelee IMAP-IMAP-postilaatikkosiirtoja luotettavuudella, jota useimmat kaupalliset tyokalut kadehtivat. Mutta paivamaarien sailyttaminen ei ole kokonaan imapsyncin kasissa, ja siina kohtaa asiat muuttuvat monimutkaisiksi.

Miten IMAP-paivamaaarat todella toimivat

Jokaisessa sahkopostissa on kolme erilaista "paivamaaaraa", ja useimmat ihmiset (mukaan lukien jotkut IT-yllapitajat) sekoittavat ne:

• Date:-otsikko (RFC 2822) - paivamaaara, jonka lahettajan sahkopostiohjelma leimasi viestin kirjoitushetkella. Se elaa viestin rungossa eika sahkopostipalvelimet koskaan muuta sita.
• Received:-otsikot - jokainen viestia kasitteleva sahkopostipalvelin lisaa yhden omalla aikaleimallaan. Ne muodostavat ketjun lahettajasta vastaanottajaan. Ylin (uusin) Received-otsikko on se, mita jotkut sahkopostiohjelmat kayttavat naytossa.
• INTERNALDATE - IMAP-palvelimen puolinen aikaleima, joka ohjaa viestien jarjestysta postilaatikossa. Se asetetaan, kun viesti tallennetaan ensimmaisen kerran IMAP APPEND -komennolla.

Kun imapsync siirtaa viestin, se lukee viestin lahdepalvelimelta (mukaan lukien sen INTERNALDATE) ja kirjoittaa sen kohdepalvelimelle kayttaen IMAP APPEND -komentoa. --syncinternaldates-lippu kehottaa imapsncia valittamaan lahteen INTERNALDATE:n kohdepalvelimelle APPEND:n aikana.

Ongelma: kohdepalvelin ei ole velvollinen kunnioittamaan tuota paivamaaaraa.

Miksi kohdepalvelimet ohittavat INTERNALDATE:n

IMAP-maarittely (RFC 3501) sanoo, etta jos APPEND-komennolle annetaan paivaamaara-aika, palvelimen PITAISI kayttaa sita. "PITAISI" RFC-kielella tarkoittaa "tee nain, ellei sinulla ole hyvaa syyta olla tekematta". Useat suuret sahkopostialustat ovat paattaneet, etta niilla on hyva syy.

Microsoft 365 on suurin rikkoja. Kun viesti saapuu IMAP APPEND -komennolla, Exchangen kuljetusputki leimaa uuden Received-otsikon nykyisella paivamaaralla ja asettaa sitten INTERNALDATE:n tuon toimitusaikaleiman perusteella. Ei ole valia mita paivamaaaraa imapsync pyysi. M365-palvelin ylikirjoittaa sen.

Google Workspace (Gmail) kayttaytyy eri tavalla, mutta voi silti aiheuttaa ongelmia. Gmailin IMAP-toteutus kunnioittaa APPEND:n INTERNALDATE:a useimmissa tapauksissa, mutta lisaa oman Received-otsikkonsa. Jos postilaatikkoa lukeva sahkopostiohjelma priorisoi Received-otsikoita INTERNALDATE:n edelle naytossa (ja Outlook tekee juuri niin), paivamaaarat nayttavat silti vaarilta.

Dovecot ja Cyrus, kaksi yleisinta avoimen lahdekoodin IMAP-palvelinta, kunnioittavat yleensa APPEND:n INTERNALDATE:a. Joten imapsync-siirrot kahden Dovecot-palvelimen valilla sailyttavat yleensa paivamaaarat oikein. Ongelmat alkavat, kun kohde on isannoitu alusta omalla kuljetuskasittelylla.

Yleiset imapsync-komentorivivirheet jotka rikkovat paivamaaarat

--syncinternaldates unohtaminen kokonaan

Lippu ei ole oletuksena kaytoossa. Jos suoritat perus imapsync --host1 source --host2 dest --user1 user --user2 user ilman sita, imapsync ei yrita lainkaan sailyttaa paivia. Kohdepalvelin kayttaa nykyista aikaleimaa jokaiselle viestille. Se on yleisin syy ja helpoin ohittaa, koska imapsync ei varoita siita.

--syncinternaldates kayttaminen --addheaderin kanssa

Jotkut oppaat suosittelevat --addheader-lipun kayttamista mukautetun otsikon lisaamiseksi siirron aikana. Jos lisat otsikoita, muutat viestia, mika voi saada kohdepalvelimen kasittelemaan sen "uutena" viestina ja leimaamaan sen sen mukaisesti. Naiden kahden lipun vuorovaikutus on huonosti dokumentoitu.

--minage ja --maxage sekoittaminen paivamaarien sailyttamiseen

--minage- ja --maxage-liput suodattavat mitka viestit siirretaan ian perusteella. Ne eivat vaikuta siihen, miten paivamaaria kasitellaan kohteessa. Olen nahnyt yllapitajien kayttavan tunteja naiden lippujen saatamiseen uskoen, etta se korjaisi paivamaaraongelman. Ei korjaa.

Aikaleiman siirtyminen SSL-neuvottelun takia

Siirrettaessa TLS:n yli --ssl1- ja --ssl2-asetuksilla yhteysmuodostus lisaa viivetta. Suurissa siirroissa (50 000+ viestia) tama viive kasaantuu. Se ei muuta paivia paivilla, mutta voi aiheuttaa sen, etta minuuttien valein lahetetyt viestit saapuvat identtisilla aikaleimoilla kohteeseen, menettaen keskinaisen jarjestyksensa.

imapsync-lokien lukeminen: mita tuloste oikeasti kertoo

imapsync tuottaa yksityiskohtaisia lokeja, mika on hyvaa. Mutta lokituloste voi olla harhaanjohtava paivamaarien osalta.

Tyypillinen onnistunut siirtorivi nayttaa talta:

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

Molemmat paivamaaarat tasmaaavat. Se tarkoittaa, etta imapsync lahetti oikean INTERNALDATE:n kohteeseen. Mutta se ei tarkoita, etta kohdepalvelin todella tallensi tuon paivan. imapsync raportoi mita se pyysi, ei mita palvelin hyvaksyi.

Haluatko varmistaa mita todella tapahtui? Yhdista siirron jalkeen kohteeseen IMAP-asiakasohjelmalla ja tarkista INTERNALDATE suoraan:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Jos palautettu paiva on siirtopaiva eika 2019-01-15, kohdepalvelin ohitti imapsyncin pyynton. Loki valehteli sinulle (no, se kertoi mita se pyysi, ei mita se sai).

Suurten imapsync-siirtojen haasteet

Yksittaisen postilaatikon siirto imapsyncilla on harmillista, kun paivat rikkoutuvat. Mutta MSP:t ja IT-osastot, jotka ajavat imapsyncia satojen postilaatikoiden yli, kohtaavat tasin eri skaalan ongelman.

Ajattele tyypillista yrityssiirtoskenaariota. Siiretaan 200 postilaatikkoa Zimbra-palvelimelta Microsoft 365:een. Kirjoitat wrapper-skriptin, joka kaay lapi kayttaja-CSV:n ja kutsuu imapsyncia jokaiselle. Siirto pyorii viikonlopun yli. Maanantaiaamuna sinulla on 200 postilaatikkoa rikkinaisilla paivamaarilla ja noin 1,2 miljoonaa sahkopostia yhteensa nayttaen siirron aikaleimaa.

Voitko ajaa imapsyncin uudelleen --syncinternaldates-lipulla, jos unohdit sen ensimmaaisella kerralla? Teknisesti kylla, mutta imapsync ohittaa viestit, jotka ovat jo kohteessa (se on suunniteltu idempotentiksi). Tarvitsisit --delete2-lipun kohdeviestien poistamiseksi ja uudelleensiirtamiseksi, mika on riskialtista tuotantopostilaatikossa. Ja silloinkin, jos kohdepalvelin ohittaa INTERNALDATE:n, olet takaisin lahtopisteessa.

Tee-se-itse-korjaukset ja niiden rajat

Jos etsit foorumeilta ja postituslistoilta (imapsync-devel-lista SourceForgessa on yha aktiivinen alkuvuodesta 2026), loydat ehdotuksia luovista vaarallisiin.

Jotkut ehdottavat Perl-yksirivista INTERNALDATE:n muuttamiseksi suoraan kohdepalvelimella. Toiset suosittelevat kaikkien viestien vientia mbox-muotoon, paivien muokkaamista ja uudelleentuontia. Muutamat ovat kirjoittaneet Python-skripteja, jotka kayttavat imaplib-kirjastoa viestien hakemiseen, muokkaamiseen ja uudelleenlisaamiseen.

Kaikki nama lahestymistavat jakavat samat perusonglemaat. Miten kasittelet S/MIME-allekirjoitettuja viesteja rikkomatta allekirjoitusta? Enta moniosaisia MIME-rakenteita sisakkaisilla rajoilla? RFC 2047 -koodattuja ei-ASCII-otsikoita? PGP-salattuja viesteja, joiden sisaltoa et voi edes tarkastaa? Skripti joka kasittelee 50 testiviestia kehitysymparistossa tukehtuu tuotantopostilaatikon 30 000 viestin reunatapauksiin.

Ja suurin kysymys, jota kukaan ei kysy ennen kuin on liian myohaista: miten varmistat, etta jokainen muokattu viesti on yha ehjaa?

Miten Redate.io korjaa imapsyncin paivamaaraongelmat

Alkuperainen Date:-otsikko on aina ehjaa imapsync-siirron jalkeen. imapsync siirtaa raa'an viestin uskollisesti; kohdepalvelimen metatietojen kasittely aiheuttaa nayttoongelman. Tuo alkuperainen otsikko mahdollistaa korjauksen.

Redate.io yhdistaa suoraan postilaatikkoon (Google Workspace, Microsoft 365 tai mika tahansa IMAP-palvelin), skannaa sahkopostit joissa on paivamaarapoikkeamia ja soveltaa kohdistettua metatietojen korjausta patentoidun otsikoketjuanalyysin ja paivamaarien rekonstruointiprosessin kautta. Korjaus kasittelee imapsync-siirtojen jattamat erityiset kaavat, mukaan lukien kohdepalvelimien tyypilliset Received-otsikkotunnisteet jotka ylikirjoittivat INTERNALDATE:n.

Jokainen korjattu sahkoposti varmennetaan yksilollisesti: viestin eheys, liitteiden sailyminen, kansioon sijoittaminen, ketjutus, tarrat. Alkuperaiset sailytetaan nakyvassa Redate.io - Originals -varmuuskopiokansiossa 30 paivaa. Jos jokin nayttaa vaaralta, palautus on yhden napsautuksen paassa.

Ilmainen skannaus yhdistaa postilaatikkoon, tunnistaa jokaisen sahkopostin jossa on paivamaarapoikkeama ja raportoi tarkan maaran ja hinnan. Ei luottokorttia, ei asennettavaa ohjelmistoa. Alustasi yksityiskohtia varten:

• Korjaa imapsync-paivat Outlookissa
• Korjaa imapsync-paivat Gmailissa
• Korjaa imapsync-paivat Microsoft 365:ssa
• Korjaa imapsync-paivat Google Workspacessa

Redate.io toimii myos siirroissa, jotka tapahtuivat kuukausia tai vuosia sitten. Date:-otsikko ei vanhene, eika kyky korjata myoskaan.

Siirretty imapsyncilla ja kiinni vaarissa paivamaarissa? Suorita ilmainen skannaus nahdaksesi tarkasti kuinka monta sahkopostia on vaikutettu.