Korjaa imapsync päivämääarät

--syncinternaldates-lupaus (ja missä se pysähtyy)

Ajoit imapsync-komennon. Lisäsit --syncinternaldates-lipun, koska luit dokumentaation ja olet huolellinen tällä tavalla. Siirto päättyy, loki sanoo kaiken siirtyneen, nolla virhettä. Sitten avaat postilaatikon Outlookissa ja jokainen sähköposti näyttää eilisen päivämäärän.

Tämä on yksi imapsyncin yleisimmistä turhauttavista ongelmista, ja se on hämmentänyt järjestelmänvalvojia ainakin vuodesta 2017. --syncinternaldates-lipun on tarkoitus säilyttää IMAP INTERNALDATE siirron aikana. Ja se todella tekee sen: se antaa kullekin kopiolle sisäisen päivämäärän, jonka lähdepalvelin pitää yllä. Juuri siinä piilee ansa.

imapsync on Gilles Lamiralin kirjoittama avoimen lähdekoodin Perl-työkalu, ja se on aidosti hyvä siinä, mitä se tekee. Se käsittelee IMAP-IMAP-postilaatikkosiirtoja luotettavuudella, jota useimmat kaupalliset työkalut kadehtivat. Mutta imapsync voi kopioida vain löytämänsä päivämäärät, ja siinä kohtaa asiat muuttuvat monimutkaisiksi.

Miten IMAP-päivämäärät todella toimivat

Jokaisessa sähköpostissa on kolme erilaista "päivämäärää", ja useimmat ihmiset (mukaan lukien jotkut IT-ylläpitäjät) sekoittavat ne:

Date:-otsikko (RFC 2822) - päivämäärä, jonka lähettäjän sähköpostiohjelma leimasi viestiin sen kirjoitushetkellä. Se elää viestin rungossa, eivätkä sähköpostipalvelimet koskaan muuta sitä.
Received:-otsikot - jokainen viestiä käsittelevä sähköpostipalvelin lisää yhden omalla aikaleimallaan. Ne muodostavat ketjun lähettäjästä vastaanottajaan. Ylin (uusin) Received-otsikko on se, mitä jotkut sähköpostiohjelmat käyttävät näyttämiseen.
INTERNALDATE - IMAP-palvelimen puoleinen aikaleima, joka ohjaa viestien järjestystä postilaatikossa. Se asetetaan, kun viesti tallennetaan ensimmäisen kerran IMAP APPEND -komennolla.

Kun imapsync siirtää viestin, se lukee viestin lähdepalvelimelta (mukaan lukien sen INTERNALDATE) ja kirjoittaa sen kohdepalvelimelle IMAP APPEND -komennolla. --syncinternaldates-lippu kehottaa imapsynciä välittämään lähteen INTERNALDATE:n kohdepalvelimelle APPEND:n aikana.

Hyvä uutinen on, että Microsoft 365, Outlook.com ja Gmail säilyttävät niille annetun päivämäärän. Kun päivämäärät tulevat siis vääriksi, ongelma on muualla.

Miksi päivämäärät voivat silti olla väärät

IMAP-määrittely (RFC 3501) sanoo, että jos APPEND-komennolle annetaan päivämäärä-aika, palvelimen PITÄISI käyttää sitä. "PITÄISI" RFC-kielellä tarkoittaa "tee näin, ellei sinulla ole hyvää syytä olla tekemättä". Microsoft 365, Outlook.com ja Gmail tekevät juuri niin: kopio, joka kantaa alkuperäisen päivämääränsä, säilyttää sen.

Se, mitä imapsync välittää, on kuitenkin päivämäärä, jonka LÄHDEPALVELIN pitää yllä kullekin viestille, ei päivämäärä, jolloin sähköposti lähetettiin. Terveessä postilaatikossa nämä kaksi täsmäävät. Postilaatikossa, joka on jo siirretty kerran tai palautettu varmuuskopiosta, lähde voi pitää yllä sen aiemman toimenpiteen päivämäärää, ja imapsync kopioi sen sellaisenaan.

Gmail on erityistapaus vain, kun kopio kulkee Gmailin oman tuonti-API:n kautta IMAPin sijaan: tämä API lisää Received-rivin, joka on päivätty kopion päivälle, ja Outlook voi näyttää tuon päivämäärän. imapsync puhuu IMAPia, niin siihen tämä ei vaikuta.

Dovecot ja Cyrus, kaksi yleisintä avoimen lähdekoodin IMAP-palvelinta, säilyttävät myös APPEND:n päivämäärän. Joten kohteesta riippumatta kysymys on aina sama: mikä päivämäärä lähteellä oli?

Yleiset imapsync-komentorivivirheet, jotka rikkovat päivämäärät

Lähdepäivämäärien lisäksi ylläpitäjät kompastuvat usein imapsyncin komentorivivalintoihin, tai syyttävät väärää. Tässä yleisimmät virheet, joita näen:

Kopioiminen lähteestä, jonka päivämäärät olivat jo väärät

--syncinternaldates on käytössä oletusarvoisesti: imapsync antaa kullekin kopiolle sisäisen päivämäärän, jonka lähdepalvelin pitää yllä (sen dokumentaatio: "Sets the internal dates on host2 as the same as host1"). Jos lähdepostilaatikko on itse aiemman siirron tai palautuksen tulos, sen sisäiset päivämäärät voivat olla jo tuon aiemman toimenpiteen päivämääriä, ja imapsync kopioi uskollisesti väärän päivämäärän. Tämä on yleisin syy, ja helpoin jäädä huomaamatta, koska loki näyttää kaksi identtistä päivämäärää.

--syncinternaldates käyttäminen --addheaderin kanssa

Jotkut oppaat suosittelevat --addheader-lipun käyttämistä mukautetun otsikon lisäämiseksi siirron aikana. Otsikon lisääminen muuttaa viestiä (yksi rivi lisää ylös), mutta ei päivämäärää, jonka imapsync välittää, niin se ei selitä vääriä päivämääriä. Kopio ei ole yksinkertaisesti enää identtinen alkuperäisen kanssa, mikä on merkityksellistä, jos vertaat näitä kahta.

--minage ja --maxage sekoittaminen päivämäärien säilyttämiseen

--minage- ja --maxage-liput suodattavat, mitkä viestit siirretään niiden iän perusteella. Ne eivät vaikuta siihen, miten päivämääriä käsitellään kohteessa. Olen nähnyt ylläpitäjien käyttävän tunteja näiden lippujen säätämiseen uskoen, että ne korjaisivat päivämääräongelman. Eivät korjaa.

TLS:n syyttäminen siirtyneistä päivämääristä

TLS:n yli (--ssl1, --ssl2) yhteyksien muodostaminen lisää viivettä, ja suuressa siirrossa (50 000+ viestiä) se kasautuu tunneiksi. Se ei kosketa päivämääriä: kukin kopio kantaa päivämäärän, jonka imapsync välittää, saapui se todellisuudessa milloin tahansa.

imapsync-lokien lukeminen: mitä tuloste oikeasti kertoo

imapsync tuottaa yksityiskohtaisia lokeja, mikä on hyvä asia. Mutta lokituloste voi olla harhaanjohtava päivämäärien osalta.

Tyypillinen onnistunut siirtorivi näyttää tältä:

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

Molemmat päivämäärät täsmäävät. Se tarkoittaa, että imapsync lähetti oikean INTERNALDATE:n kohteeseen. Ja Microsoft 365, Outlook.com ja Gmail säilyttävät kaikki niille annetun päivämäärän. Mutta kaksi identtistä päivämäärää todistaa vain, että kopio on uskollinen LÄHTEELLE: jos lähteen päivämäärä oli jo väärä, molemmat sarakkeet näyttävät samaa väärää päivämäärää.

Haluatko varmistaa, mitä todella tapahtui? Yhdistä siirron jälkeen kohteeseen IMAP-asiakasohjelmalla ja tarkista INTERNALDATE suoraan:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Jos palautettu päivämäärä ei ole päivämäärä, jolloin sähköposti lähetettiin, katso samaa viestiä lähteestä: löydät saman väärän päivämäärän siellä. Loki ei valehdellut, se kopioi sen, mitä sille annettiin.

Tämä on yksi turhauttavimmista puolista päivämääräongelmien selvittämisessä: puhdas lokitiedosto, kaksi identtistä päivämäärää, ja silti väärä päivämäärä Outlookissa, koska virhe oli olemassa ennen kuin imapsync ajettiin.

Suurten imapsync-siirtojen haasteet

Yksittäisen postilaatikon siirto imapsyncilla on harmillista, kun päivämäärät rikkoutuvat. Mutta MSP:t ja IT-osastot, jotka ajavat imapsynciä satojen postilaatikoiden yli, kohtaavat täysin toisenlaisen mittakaavan ongelman.

Ajattele tyypillistä yrityssiirtoskenaariota. Siirrät 200 postilaatikkoa Zimbra-palvelimelta Microsoft 365:een. Kirjoitat wrapper-skriptin, joka käy läpi käyttäjien CSV-tiedoston ja kutsuu imapsynciä jokaiselle. Siirto ajaa viikonlopun yli. Maanantaiaamuna sinulla on 200 postilaatikkoa väärillä päivämäärillä, ja noin 1,2 miljoonaa sähköpostia yhteensä näyttää siirron aikaleimaa.

Voitko ajaa imapsyncin uudelleen korjataksesi sen? Teknisesti kyllä, mutta imapsync ohittaa viestit, jotka ovat jo kohteessa (se on suunniteltu idempotentiksi). Tarvitsisit --delete2-lipun kohdeviestien poistamiseksi ja uudelleensiirtämiseksi, mikä on riskialtista tuotantopostilaatikossa. Ja jos lähteen päivämäärät olivat ongelma, toinen ajo kopioi samat väärät päivämäärät uudelleen.

Jotkut ylläpitäjät kokeilevat hybridilähestymistapaa: ajavat imapsyncin ensin --dry-lipulla testiksi, sitten oikean siirron. Mutta --dry vain simuloi siirtoa: se näyttää päivämäärät, jotka imapsync välittäisi, ei sitä, ovatko ne päivämääriä, jolloin sähköpostit lähetettiin. Mikään ei varoita sinua siitä, että lähteen päivämäärät ovat jo väärät.

Tee-se-itse-korjaukset ja niiden rajat

Jos etsit foorumeilta ja postituslistoilta (imapsync-devel-lista SourceForgessa on yhä aktiivinen vuoden 2026 alussa), löydät ehdotuksia luovista vaarallisiin.

Jotkut ehdottavat Perl-yksirivisen komennon käyttämistä INTERNALDATE:n muuttamiseksi suoraan kohdepalvelimella. Toiset suosittelevat kaikkien viestien viemistä mbox-muotoon, päivämäärien muokkaamista ja uudelleentuontia. Muutamat ovat kirjoittaneet Python-skripteja, jotka käyttävät imaplib-kirjastoa viestien hakemiseen, muokkaamiseen ja uudelleenlisäämiseen.

Kaikilla näillä lähestymistavoilla on samat perusongelmat. Miten käsittelet S/MIME-allekirjoitettuja viestejä rikkomatta allekirjoitusta? Entä moniosaiset MIME-rakenteet sisäkkäisillä rajoilla? RFC 2047:llä koodatut ei-ASCII-otsikot? PGP-salatut viestit, joiden sisältöä et voi edes tarkastaa? Skripti, joka käsittelee 50 testiviestiä kehitysympäristössä, tukehtuu tuotantopostilaatikon 30 000 viestin reunatapauksiin.

Ja suurin kysymys, jota kukaan ei kysy ennen kuin on liian myöhäistä: miten varmistat, että jokainen muokattu viesti on yhä ehjä? Että liitteet eivät vioittuneet, että ketjutus toimii yhä, että jonkun vuonna 2020 lähettämä 85 megatavun laskentataulukko selvisi muokkauksesta?

(Jos olet joskus yrittänyt jäsentää raakoja sähköpostiotsikoita Perlissä, tiedät, ettei se ole täysin rentouttava iltapäiväpuuha.)

Miten Redate.io korjaa imapsyncin päivämääräongelmat

Alkuperäinen Date:-otsikko on aina ehjä imapsync-siirron jälkeen. imapsync siirtää raa'an viestin uskollisesti; väärä päivämäärä on kopion saamassa metatiedossa, ei viestissä itsessään. Tuo alkuperäinen otsikko on se, joka tekee korjauksen mahdolliseksi.

Redate.io yhdistää suoraan postilaatikkoon (Google Workspace, Microsoft 365 tai mikä tahansa IMAP-palvelin), tarkistaa sähköpostit, joissa on päivämääräpoikkeamia, ja soveltaa kohdennettua metatietojen korjausta Redaten kehittämän otsikkoketjuanalyysin ja päivämäärien rekonstruointiprosessin avulla. Sen ei tarvitse tietää, mikä työkalu teki siirron: se löytää sähköpostit, joiden näytetty päivämäärä ei vastaa niiden alkuperäistä päivämäärää.

Jokainen korjattu sähköposti varmennetaan yksilöllisesti: viestin eheys, liitteiden säilyminen, kansiosijoitus, ketjutus, tarrat. Alkuperäiset säilytetään näkyvässä Redate.io - Originals -varmuuskopiokansiossa, ja ne pysyvät siellä, kunnes poistat ne itse. Jos jokin näyttää väärältä, palautus on yhden napsautuksen päässä.

Ilmainen tarkistus yhdistää postilaatikkoon, tunnistaa jokaisen sähköpostin, jossa on päivämääräpoikkeama, ja raportoi tarkan määrän ja hinnan. Ei luottokorttia, ei asennettavaa ohjelmistoa. Alustasi tarkempia tietoja varten:

Redate.io toimii myös siirroissa, jotka tapahtuivat kuukausia tai vuosia sitten. Date:-otsikko ei vanhene, eikä myöskään kyky korjata se, mikä meni pieleen.

Siirrettiinkö imapsyncilla ja jäitkö kiinni vääriin päivämääriin? Suorita ilmainen tarkistus nähdäksesi täsmälleen, kuinka monta sähköpostia asia koskee.

imapsync: päivät eivät säilyneet? Näin korjaat ne