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ä on odotettu, mutta huonosti dokumentoitu, käytös kaikissa IMAP-siirroissa Exchange Onlineen. 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 pilaa 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 lisää jokaiseen vastaanottamaansa viestiin uuden Received:-otsikon viestin alkuun. Tämä otsikko sisältää tarkan lisäysajankohdan, eli siirron päivämäärän. Jotkin siirtotyökalut yrittävät säilyttää alkuperäisen INTERNALDATEn välittämällä sen parametrina APPEND-komennolle. Toiset eivät tee niin, tai tekevät sen virheellisesti, jolloin Exchange Online asettaa automaattisesti vastaanottopäivä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 ongelma koskee erityisesti siirtoja palvelimille, jotka lisäävät Received:-otsikon järjestelmällisesti jokaiseen saapuvaan viestiin, mikä on täsmälleen Exchange Onlinen käytös. Vaikka Zoho Migration Wizard välittäisi alkuperäisen päivämäärän APPEND-parametrilla, Exchange Onlinen luoma Received:-otsikko päätyy ensimmäiseksi otsikkoketjussa, ja Outlook käyttää sitä määrittämään "milloin sähköposti saapui".

Administraattorit, jotka käyttävät yleisiä IMAP-työkaluja kuten imapsynciä Zohosta lähtöön, kohtaavat täsmälleen saman ongelman, joskus pahempana, koska imapsynkin oletuskonfiguraatio ei ole optimoitu Exchange Onlinea varten. (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 yhdistää Microsoft 365 -tenanttisi vakio-Azure AD -oikeuksilla ilman globaalia ylläpitäjäoikeutta. 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, tunnistaa Zoho-siirtotyökalujen (Zoho Migration Wizard tai imapsync Zohosta lähtöön konfiguroituna) erityiset tunnisteet ja rekonstruoi päivämäärämetadatan monivaiheisen validointipipeline-prosessin kautta. Jokainen korjattu sähköposti tarkistetaan yksitellen: sisällön eheys, liitteiden säilyminen, RFC-vaatimustenmukaisuus. Alkuperäiset säilytetään 30 päivää varmuuskopiokansiossa.

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: Exchange Onlinen luoma Received:-otsikko ylikirjoittaa INTERNALDATEn 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, miksi ne eivät riitä välttämään ongelmaa Exchange Onlinessa.

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ä.