iCloud-migraatio Office 365:een: väärät päivämäärät

Migraatio, joka rikkoo päivämäärät järjestelmällisesti

iCloud-sähköpostit on siirretty Office 365:een. Kansiot ovat paikallaan, viestit löytyvät, kaikki näyttää olevan kunnossa. Maanantaiaamuna ensimmäinen puhelu tulee: "Kaikki vanhat sähköpostini näyttävät tämän päivän päivämäärää." Sitten toinen puhelu. Sitten kymmenen.

Kyse ei ole yksittäisestä bugista. iCloud Mailin migraatio Office 365:een on yksi parhaiten dokumentoiduista sähköpostipäivämäärien korruptiotapauksista. Syyt ovat teknisesti hyvin tarkkoja ja liittyvät samanaikaisesti Apple Mailin käyttäytymiseen, IMAP-protokollaan sekä siihen, miten Microsoft 365 käsittelee saapuvia viestejä.

Miksi iCloud-migraatio rikkoo päivämäärät

Ongelman ymmärtämiseksi on erotettava kolme asiaa, jotka monet (myös kokeneet IT-ylläpitäjät) sekoittavat keskenään: Date:-otsikko, IMAP INTERNALDATE ja tiedoston luontipäivä.

Date:-otsikko (RFC 2822)

Jokaisessa sähköpostiviestissä on Date:-otsikko, joka kertoo milloin viesti lähetettiin. Tämä otsikko on upotettuna viestin raakasisältöön eikä muutu koskaan, ainakin teoriassa. Se on "alkuperäinen" päivämäärä sanan varsinaisessa merkityksessä.

IMAP INTERNALDATE

IMAP-protokolla (määritelty RFC 3501:ssä) liittää jokaiseen viestiin erillisen metatietokentän nimeltä INTERNALDATE. Useimmat sähköpostiohjelmat käyttävät tätä arvoa viestien lajitteluun ja näyttämiseen saapuneet-kansiossa, eivät Date:-otsikkoa. Outlook nojaa erityisen vahvasti INTERNALDATEen sekä näytössä että lajittelussa.

Ongelma? Kun migraatiotyökalu kopioi viestin IMAP-palvelimelta toiselle, sen pitäisi ihanteellisessa tapauksessa säilyttää INTERNALDATE. Käytännössä näin ei aina käy.

Apple Mailin erikoinen käyttäytyminen

Apple Mail käyttää iCloud-viestejä synkronoidessaan joskus tiedoston palvelinpuolen luontipäivää INTERNALDATEn viitearvona. Tämä ei ole bugi varsinaisessa mielessä, vaan IMAP-spesifikaation tulkinta, joka poikkeaa muiden ohjelmistojen tavasta. (Jos olet joskus yrittänyt debugata INTERNALDATE-ongelmaa lukemalla raakoja IMAP-RFC-dokumentteja, tiedät että spesifikaatio jättää tässä kohtaa aika paljon tulkinnanvaraa.)

Tulos: kun vietät tai siirrät viestejä iCloudista Apple Mailin kautta, INTERNALDATE-arvot voivat olla jo virheellisiä ennen kuin ne edes saapuvat Office 365:een.

Kolme iCloud-migraatiomenetelmää ja niiden ongelmat

Suora IMAP-migraatio

Yleisin tapa on konfiguroida iCloud IMAP-lähteeksi ja Office 365 kohteeksi, sitten ajaa migraatiotyökalu (imapsync, MigrationWiz tai jokin muu vastaava). Työkalu yhdistää molempiin palvelimiin ja kopioi viestit.

Ongelma on kaksitahoinen. Ensinnäkin Applen IMAP-palvelimilla on nopeusrajoituksia, jotka pakottavat työkalut tekemään taukoja. Yhteydet sulkeutuvat ja avautuvat uudelleen, mikä voi synnyttää ylimääräisiä INTERNALDATE-arvoja. Toiseksi, jokainen Exchange Onlineen IMAP APPEND -komennolla kopioitu viesti saa oletuksena tallennusajankohdan päivämäärän, ellei työkalu välitä alkuperäistä INTERNALDATEa nimenomaisesti lisäyskomennon mukana.

Osa työkaluista tekee tämän oikein. Toiset eivät, eivät ainakaan johdonmukaisesti. 40 000 viestin postilaatikossa jo 2 %:n virheprosentti tarkoittaa 800 sähköpostia väärällä päivämäärällä.

imapsync-migraatioiden osalta katso myös: korjaa imapsync-siirron päivämäärät Microsoft 365:ssä.

.mbox- tai .eml-vienti ja tuonti

Jotkut käyttäjät vievät iCloud-sähköpostinsa Apple Mailin kautta .mbox-muodossa ja yrittävät sitten tuoda ne Outlookiin. Tämä käsityömäinen menetelmä tuottaa vaihtelevia tuloksia.

.mbox-muoto tallentaa sähköpostit tekstimuotoisena viestijonona. Päivämäärät löytyvät yksittäisten viestien Date:-otsikoista, mutta viestien välinen erotinrivi ("From ") sisältää päivämäärän, jonka jotkin tuontityökalut tulkitsevat luontipäiväksi. Outlook saattaa .mbox:sta .pst:ksi muunnetun tiedoston tuonnissa käyttää tätä erotinrivin päivämäärää eikä viestin omaa Date:-otsikkoa.

Raahaaminen Outlookissa

Tämä menetelmä aiheuttaa eniten vahinkoa. Käyttäjä konfiguroi molemmat tilit Outlookiin (iCloud ja Office 365) ja raahaa viestit kansiosta toiseen. Kuulostaa yksinkertaiselta. Päivämäärien kannalta se on katastrofi.

Kun Outlook siirtää viestin raahaamalla kahden IMAP-tilin välillä, se luo todellisuudessa uuden .EML-tiedoston, lisää sen kohdetilille ja poistaa alkuperäisen. Uusi tiedosto perii luontipäivänään Windows-tiedoston luontiajankohdan, eli juuri sen hetken kun raahaaminen tapahtui. Alkuperäinen Date:-otsikko on yhä viestin runkoon upotettuna, mutta Exchange Online -palvelimelle tallentunut INTERNALDATE vastaa manipuloinnin ajankohtaa. Outlook näyttää sitten tätä migraatiopäivää kaikille siirretyille viesteille.

Tarkasti ottaen tämä käyttäytyminen vaihtelee Outlook-versiosta riippuen. Syksyn 2023 Outlook-päivityksen jälkeen tilanne on parantunut hieman joissakin skenaarioissa, mutta tilien välinen raahaaminen on edelleen dokumentoitu päivämääräkorruption lähde.

Mitä Office 365 ja Outlook lopulta näyttävät

Exchange Online tallentaa sähköpostit INTERNALDATE-arvoineen. Outlook Desktop lukee tämän INTERNALDATEn näyttääkseen päivämäärän "Vastaanotettu"-sarakkeessa ja lajitellakseen saapuneet. Jos INTERNALDATE on ylikirjoitettu migraation aikana, Outlook näyttää migraatiopäivämäärän, piste.

Outlook Web App (OWA) toimii samoin. Mitään "vaihtoehtoista näkymää", joka näyttäisi alkuperäisen Date:-otsikon päivämäärän, ei ole. Päiväsarakkeessa näkyvä arvo on INTERNALDATE.

Alkuperäinen Date:-otsikko on kuitenkin yhä tallessa, ehjänä, luettavissa kun avaat viestin raakaotsikoita. Mutta mikään normaali näkymä ei sitä näytä. Tässä on ongelman ydin: oikea tieto on olemassa, mutta se on saavuttamattomissa ilman teknistä korjausta.

Mitä Microsoft-tuki ei ratkaise

Jos avaat Microsoft-tukipyynnön tästä ongelmasta, saat todennäköisesti seuraavaa: vahvistuksen, että näytetyt päivämäärät vastaavat tallennettuja INTERNALDATE-arvoja, ehdotuksen tarkistaa Outlookin lajitteluasetukset, ja mahdollisesti viittauksen käyttämääsi migraatiotyökaluun.

Kyse ei ole pahasta tahdosta. Microsoftilla ei yksinkertaisesti ole natiivityökalua jo Exchange Onlineen tallennettujen tuhansien viestien INTERNALDATE-arvojen jälkikäteiskorjaukseen. Korjaus edellyttää yksittäisten viestien käsittelyä, otsikoiden analysointia ja päivämäärän metatietojen uudelleenrakentamista, mikä ylittää normaalin tukipalvelun toiminnan rajat.

iCloudin tuki puolestaan katsoo, että viestit on viety oikein ja ongelma on kohdepäässä. Molemmat tukipalvelut syyttelevät toisiaan, ja käyttäjälle jää 12 000 sähköpostia migraatiopäivän päivämäärällä.

Mittakaavojen ongelma

Ongelman ymmärtäminen on yksi asia. Päivämäärien manuaalinen korjaaminen tuotantoposti­laatikoissa on ihan toinen juttu.

Jotkut IT-ylläpitäjät yrittävät kirjoittaa korjauskriptin. Perusidea ei ole vaikea käsittää, mutta toteutus oikeilla volyymeillä tuottaa ongelmia, joita kotitekoiset skriptit eivät hallitse:

• S/MIME-allekirjoitettuja tai PGP:llä salattuja sähköposteja ei voi muuttaa ilman kryptografisen allekirjoituksen mitätöintiä
• Monimutkaiset multipart/alternative-rakenteet (HTML + pelkkä teksti + upotetut liitteet) ovat herkkiä käsitellä
• Ei-ASCII-merkistöllä enkoodatut otsikot (RFC 2047, erityisesti japanilaiset, arabiankieliset tai kyrilliset merkit) voivat vioittua työkaluissa, jotka eivät käsittele näitä enkoodauksia oikein
• Microsoft Graph -rajapinnan API-kiintiöt ja Exchange Onlinen nopeusrajoitukset (virhe 429 Too Many Requests) pysäyttävät skriptit, joita ei ole suunniteltu eksponentiaalisen backoff-hallinnan kanssa
• Skripti, joka toimii 500 testiviestin kanssa, pysähtyy kello kolme yöllä oikean postilaatikon 8000. viestin kohdalla ilman minkäänlaista jatkamismekanismia

Ja se ratkaiseva kysymys: miten varmistat, että jokainen korjattu viesti on ehjä korjauksen jälkeen? Että liite on yhä tallessa? Että viestiketju ei ole rikki? Kotitekoinen skripti ei yleensä tee tätä tarkistusta.

Miten Redate.io käsittelee iCloud-migraatiot Office 365:een

Redate.io yhdistää suoraan Office 365:een Microsoft 365 -käyttöoikeuksien (Azure AD) kautta, ilman pääsyä iCloud-palvelimiin. Viestit ovat jo Exchange Onlinessa kun Redate aloittaa työnsä.

Redaten korjausmoottori analysoi jokaisen viestin otsikkoketjun tunnistaakseen alkuperäisen päivämäärän, erottaen migraation aikana lisätyt Received:-otsikot laillisista päivämäärän metatiedoista. Analyysi sisältää tunnettujen migraatiotyökalujen allekirjoitusten kuviovastaavuuden, mikä mahdollistaa ylimääräisten otsikoiden tunnistamisen myös silloin, kun ne eivät ole välittömästi ilmeisiä.

Jokainen korjattu sähköposti tarkistetaan erikseen käsittelyn jälkeen. Alkuperäiset viestit säilytetään näkyvässä varmuuskopiointikapsiossa 30 päivän ajan, mitä mikään kotitekoinen skripti ei tee oletusarvoisesti. Alkuskannauis on ilmainen ja antaa tarkan kuvan vaikutettujen viestien määrästä ennen korjauspäätöstä.

Redate.io tukee myös Google Workspacesta Office 365:een tehtyjä migraatioita sekä korjauksia cPanel-migraatioiden jälkeen. Katso esimerkiksi: sähköpostipäivien korjaus Microsoft 365 -migraation jälkeen tai väärinpäiväiset sähköpostit Exchange Online -migraation jälkeen.

Skannaus ensin, korjaus sitten

Suositeltu lähtökohta kaikissa iCloud-Office 365 -migraatioissa, jotka ovat tuottaneet virheellisiä päivämääriä: aja Redate.io:n ilmainen skannaus kyseisille postilaatikoille. Skannaus osoittaa tarkasti, kuinka monessa viestissä on epäilyttävä INTERNALDATE ja missä kansioissa ne sijaitsevat.

Se vie 12-45 minuuttia volyymin mukaan, ja antaa selkeän kuvan ongelman laajuudesta ennen mitään toimenpiteitä. MSP-palveluntarjoajille, jotka hallinnoivat useita postilaatikoita migraation jälkeen, tämä eräskannaus estää tarpeettomien postilaatikoiden korjaamisen.

Jos sähköpostien päivämäärät ovat virheellisiä iCloud-migraation jälkeen, aloita ilmaisella skannauksella Redate.io:ssa selvittääksesi ongelman laajuuden Office 365 -postilaatikoissasi.