Väärät päivämäärät Zoho-siirrossa Microsoft 365:een

Mitä postilaatikollesi tapahtui

Olet juuri viimeistellyt verkkotunnuksesi siirron Zoho Mailista Microsoft 365:een. Exchange Online -infrastruktuuri on paikallaan, postilaatikot on luotu, MX-tietueet päivitetty. Ja sitten maanantaiaamuna käyttäjä avaa Outlookin ja huomaa, että kaikki hänen vuoden 2021 sähköpostinsa näyttävät tämän päivän päivämäärää. Toinen havaitsee, että viime vuoden viestit ovat nousseet postilaatikon yläosaan ikään kuin ne olisi juuri vastaanotettu. Tukipyynnöt alkavat sataa.

Kyse ei ole Outlookin virheestä. Ei myöskään Zoholle ominaisesta ongelmasta. Tämä tapahtuu, kun siirtotyökalu ei välitä jokaisen sähköpostin alkuperäistä päivämäärää. Sen ymmärtäminen tarkkaan on ensimmäinen askel ongelman kunnolliseen korjaamiseen.

Tekninen juurisyy: INTERNALDATE ja Received-otsikot

IMAP-palvelimelle tallennettu sähköposti koostuu kahdesta erillisestä asiasta: viestin raakasisällöstä (RFC 2822 -otsikot, runko, liitteet) ja IMAP-palvelimen hallinnoimista tallennusmetadatoista, joista tärkein on INTERNALDATE. Juuri tätä metadataa sähköpostiohjelmat käyttävät viestien näyttämiseen ja lajitteluun.

Raakaviestissä määritelty Date:-otsikko (RFC 2822) kertoo, milloin lähettäjä kirjoitti tai lähetti viestin. INTERNALDATE taas on päivämäärä, jolloin IMAP-palvelin vastaanotti tai tallensi viestin. Normaalisti terveellä palvelimella nämä kaksi arvoa ovat lähellä toisiaan. Siirron jälkeen tilanne on toinen.

Miten IMAP-siirto voi pilata päivämäärät

Kun siirtotyökalu (Zoho Migration Wizard, imapsync, BitTitan tai jokin muu) siirtää viestin Zoho Mailista Exchange Onlineen, se tekee sen IMAP-protokollan kautta. Työkalu yhdistää Zohoon, hakee viestin ja lisää sen Exchange Onlineen IMAP APPEND -komennolla. Ja tässä kohtaa asiat menevät pieleen.

Exchange Online säilyttää sille annetun päivämäärän: kun työkalu välittää jokaisen viestin alkuperäisen INTERNALDATEn APPEND-komennon mukana, kopio säilyttää sen. Jotkin siirtotyökalut tekevät niin. Toiset eivät, tai tekevät sen virheellisesti, jolloin Exchange Online asettaa lisäysajankohdan, eli siirron päivämäärän, INTERNALDATEksi.

Tulos: oli kyseessä sitten vuonna 2019 tai 2022 lähetetty sähköposti, sen INTERNALDATE osoittaa nyt siirtoviikkolle. Outlook lukee tämän arvon ensisijaisesti. Lajittelu hajoaa.

Zoho Migration Wizardin erityiskäytös

Zoho tarjoaa oman siirtotyökalunsa alustan jättämiseen: Zoho Migration Wizardin. Työkalu sopii yksinkertaisiin siirtoihin, mutta sillä on administraattorifoorumeilla dokumentoitu käytös: se ei aina välitä alkuperäistä INTERNALDATEa oikein kohdepalvelimelle lisättäessä.

Tarkasti ottaen: kun Zoho Migration Wizard välittää alkuperäisen päivämäärän, Exchange Online säilyttää sen ja Outlook näyttää oikean päivämäärän. Sähköpostit, joissa näkyy siirron päivämäärä, ovat niitä, joiden päivämäärää ei välitetty.

Administraattorit, jotka käyttävät yleisiä IMAP-työkaluja kuten imapsynciä Zohosta lähtöön, voivat kohdata saman ongelman: imapsync kopioi päivämäärän, jonka lähdepalvelin antaa jokaiselle viestille, jolloin väärä päivämäärä lähteessä muuttuu vääräksi päivämääräksi kohteessa. (Muuten, jos olet koskaan selaillut imapsync-lokia rivi riviltä etsiessäsi synkronointivirhettä kello kahden aikaan yöllä, tiedät että se on tehokas mutta ei erityisen anteeksiantava reunatapauksissa.)

Miksi Outlook näyttää väärän päivämäärän

Outlook ei käytä pelkästään Date:-otsikkoa sähköpostin päivämäärän näyttämiseen. Useimmissa näkymissä käytetään IMAP/Exchange-palvelimen antamaa INTERNALDATEa erityisesti postilaatikon lajitteluun. Alkuperäinen Date:-otsikko on kyllä tallessa viestissä, koskemattomana, mutta se ohitetaan INTERNALDATEn hyväksi.

Siksi Outlookin "Lajittele lähetyspäivän mukaan" -asetus ei oikeasti ratkaise ongelmaa. Se näyttää eri päivämäärän, totta, mutta lajittelukäytös pysyy epävakaana eri Outlook-versioiden ja näkymätilojen välillä (ryhmitelty vai ei). Lähetyspäivän mukaan lajittelu ei ole ratkaisu. Se on laastari, joka irtoaa ensimmäisessä asiakasohjelmapäivityksessä.

Ongelman todellinen laajuus

Keskikokoisessa Zoho-Microsoft 365 -siirrossa puhutaan helposti 50 000-500 000 vaikutetusta viestistä, riippuen postilaatikoiden iästä ja organisaation koosta. Jokainen siirtoikkunan aikana siirretty sähköposti kantaa samaa pilattua päivämäärää, mikä tekee ongelmasta välittömästi näkyvän käyttäjille heti Outlookin ensimmäisellä avaamisella.

Lähetetyt-kansiot ovat usein kaikkein ongelmallisimpia. Myyntihenkilö, joka etsii maaliskuussa 2022 lähetettyä tarjousta, joutuu selaamaan satoja sähköposteja, jotka näyttävät kaikki siirron päivämäärää. Operatiivinen vaikutus on todellinen, ei pelkästään kosmeettinen.

Ja toisin kuin voisi luulla, ongelma ei häviä ajan myötä. INTERNALDATE kiinnitetään lisäyshetkellä. Se ei korjaudu itsestään. Ilman aktiivista toimenpidettä sähköpostit säilyttävät pilatun päivämääränsä loputtomiin.

Miksi itse korjaaminen on riskialttiimpaa kuin miltä näyttää

Houkutus on ymmärrettävä: koska alkuperäinen Date:-otsikko on edelleen viestissä, riittää vain... metadatan korjaaminen. Paperilla se on loogista. Käytännössä 80 000 sähköpostin tuotantopostilaatikossa se on operaatio, joka voi mennä katastrofaalisesti pieleen.

Tässä muutamia reunatapauksia, joita kotitekoinen skripti ei todennäköisesti käsittele oikein:

• S/MIME-allekirjoitetut sähköpostit, joissa allekirjoitus kattaa kaikki otsikot. Mikä tahansa muutos viestin rakenteeseen mitätöi kryptografisen allekirjoituksen.
• PGP-salatut viestit, joissa sisältö on läpinäkymätön ja MIME-kuorten käsittely voi pilata viestin.
• RFC 2047:n mukaan enkoodatut ei-ASCII-otsikot (lähettäjien nimet erikoismerkkeineen), jotka rikkoutuvat jos skripti ei käsittele enkoodausta oikein.
• Base64-enkoodatut liitteet, joissa on väärin päätetyt rivit, epästandardit MIME-rajat tai sisäkkäiset multipart-rakenteet.
• Sähköpostit ilman kelvollista Date:-otsikkoa (niitä on, erityisesti vanhoissa Zoho-vienneissä), joissa skriptin täytyy päättää mitä tehdä.

Skripti, joka toimii 50 testisähköpostilla, ei toimi Zohosta vuosien historiikin kanssa viedyn tuotantopostilaatikon kanssa. Ja miten voit varmistaa, viesti viestiltä, että jokainen korjaus on ehjä eikä liitteitä ole katkaistu? Tarkistus on vähintään yhtä monimutkainen kuin itse korjaus.

On myös kiintiöiden kysymys. Exchange Online API Microsoft Graphin kautta asettaa tiukat nopeusrajoitukset (kuuluisat 429 Too Many Requests -virheet). Rajoittamaton erä 100 000 viestillä voi laukaista väliaikaisia estoja tai hiljaisia virheitä, joita on vaikea diagnosoida jälkikäteen. Ilman virheestä jatkamisen mekanismia aloitat alusta.

Miten Redate.io korjaa päivämäärät Zoho-siirron jälkeen

Redate.io avaa postilaatikkosi, kun kirjaudut sisään omalla Microsoft-tililläsi, eikä erillistä sovelluksen rekisteröintiä tarvita. Alkukartoitus on ilmainen: Redate.io tunnistaa vaikutetut postilaatikot ja arvioi virheellisillä päivämäärillä varustettujen sähköpostien määrän vertaamalla INTERNALDATEa viestin otsikkoketjun arvoihin.

Korjaus käyttää omaa moottoria, joka analysoi jokaisen viestin koko otsikkoketjun, eikä tarvitse tietää, mikä työkalu siirron teki (Zoho Migration Wizard, imapsync tai jokin muu). Jokainen korjattu sähköposti tarkistetaan yksitellen: sisällön eheys, liitteiden säilyminen, RFC-vaatimustenmukaisuus. Alkuperäiset säilyvät varmuuskopiokansiossa, kunnes poistat ne itse.

Ei uusintasiirtoa. Ei käyttökatkoa. Käyttäjät jatkavat Outlookin käyttöä kun korjaus suoritetaan taustalla.

Hinnoittelu on kertaluonteinen maksu volyymin mukaan, ei tilausta. Yksityiskohdat löytyvät suoraan sivustolta.

Läheiset skenaariot, jotka kannattaa tietää

Jos hallinnoit useita siirtoja samanaikaisesti, tai olet MSP ja hallinnoit Zohosta lähteviä asiakkaita, huomaa, että sama ongelma esiintyy siirroissa muiltakin alustoilta Exchange Onlineen. Mekaniikka on sama: kopio saa työkalun välittämän päivämäärän, lähteestä riippumatta.

Google Workspacesta, paikallisesta Exchangesta tai BitTitan MigrationWizin tai CloudMin kaltaisten työkalujen kautta tehdyissä siirroissa Redate.io:n blogin omistetut artikkelit kuvaavat kunkin työkalun erityiskäytöstä. Väärät päivämäärät Exchange Online -siirron jälkeen -artikkeli antaa yleiskatsauksen kaikista skenaarioista, jotka päätyvät tälle tenantille.

Jos siirtosi sisältää jaettuja postilaatikoita tai Exchange-resursseja (kokoushuoneet, laitteet), ongelma on sama ja samat korjaustyökalut pätevät. IMAP Exchange -siirron korjausohjeet Redate.io:n sivustolla kuvaavat tenanttiisi yhdistämisen vaiheet.

Imapsynciä erityisesti Zohosta lähtöön käyttäville tiimeille imapsync: päivät eivät säilyneet -artikkeli dokumentoi imapsync-konfigurointivaihtoehdot ja sen, mistä väärät päivämäärät todella tulevat.

Näyttääkö Outlook edelleen Zoho-siirron päivämääriä? Skannaa postilaatikkosi ilmaiseksi Redate.io:ssa ja mittaa ongelman tarkka laajuus ennen toimenpiteistä päättämistä.