Valed e-kirjade kuupäevad pärast Zoho migratsiooni Microsoft 365-i

Lugemisaeg 6 min Viimati uuendatud:

Mis juhtus teie postkastiga

Olete äsja lõpetanud oma domeeni migratsiooni Zoho Mailist Microsoft 365-i. Exchange Online'i infrastruktuur on paigas, postkastid on loodud, MX-kirjed on uuendatud. Ja siis, esmaspäeva hommikul, avab üks kasutaja Outlooki ja märkab, et kõik 2021. aasta e-kirjad näitavad tänast kuupäeva. Teine kasutaja avastab, et tema eelmise aasta sõnumid on postkasti tipus, nagu oleksid need just saabunud. Klienditoe piletid hakkavad laekuma.

See ei ole Outlooki viga. Samuti pole see Zohospetsiifiline probleem. See juhtub, kui migratsioonitööriist ei edasta iga e-kirja algset kuupäeva - ja täpselt selle mõistmine on esimene samm probleemi korrektseks lahendamiseks.

Tehniline põhjus: INTERNALDATE ja Received-päised

IMAP-serverile salvestatud e-kiri koosneb kahest eraldiseisvast osast: sõnumi töötlemata sisust (RFC 2822 päised, keha, manused) ja IMAP-serveri hallatavatest salvestusmetaandmetest, sealhulgas INTERNALDATE. Just seda metaandmete väärtust kasutavad meilikliendid sõnumite kuvamiseks ja sortimiseks.

Töötlemata sõnumis määratletud Date:-päis (RFC 2822) näitab kuupäeva, millal saatja sõnumi koostas või saatis. INTERNALDATE on aga kuupäev, millal IMAP-server sõnumi vastu võttis või salvestas. Tavaliselt on need kaks väärtust tervel serveril sarnased. Pärast migratsiooni on lugu hoopis teine.

Kuidas IMAP-migratsioon võib kuupäevi rikkuda

Kui migratsionitööriist (Zoho Migration Wizard, imapsync, BitTitan või mõni muu) edastab sõnumi Zoho Mailist Exchange Online'i, toimub see IMAP-protokolli kaudu. Tööriist ühendub Zohoga, laadib sõnumi alla ja sisestab selle Exchange Online'i IMAP APPEND-käsu abil. Ja siin ongi probleem.

Exchange Online säilitab kuupäeva, mille ta saab: kui tööriist edastab APPEND-käsuga iga sõnumi algse INTERNALDATE väärtuse, säilib see koopial. Mõned migratsioonitööriistad teevad seda. Teised seda ei tee, või teevad seda valesti - sel juhul omistab Exchange Online uueks INTERNALDATE väärtuseks sisestamise hetke, ehk migratsiooni kuupäeva.

Tulemus: olgu tegemist 2019. või 2022. aastal saadetud e-kirjaga, selle INTERNALDATE osutab nüüd migratsiooni nädalale. Outlook loeb seda väärtust esimesena. Sorteerimine läheb katki.

Zoho Migration Wizardi spetsiifilised käitumuslikud omadused

Zoho pakub oma platvormi mahajätmiseks natiivselt migratsioonivahendit: Zoho Migration Wizardi. See tööriist on kasulik lihtsate migratsioonide puhul, kuid administraatorite foorumites on dokumenteeritud käitumine: see ei edasta alati algset INTERNALDATE väärtust sihtserverisse sisestamisel korrektselt.

Täpsemalt öeldes: kui Zoho Migration Wizard edastab algse kuupäeva, säilitab Exchange Online selle ja Outlook näitab õiget kuupäeva. Migratsiooni kuupäeva näitavad need e-kirjad, mille kuupäeva ei edastatud.

Administraatorid, kes kasutavad Zoholt lahkumiseks üldiseid IMAP-tööriistu nagu imapsync, võivad kokku puutuda sama probleemiga: imapsync kopeerib kuupäeva, mille lähteserver iga sõnumi kohta hoiab, seega vale kuupäev lähteserveris muutub valeks kuupäevaks ka sihtkohas. (Muide, kui olete kunagi imapsync-logi rida-realt läbi sõelanud, otsides kaks öösel sünkroniseerimisehäiret, siis teate: võimas tööriist, aga piirjuhtumite suhtes mitte eriti andestav.)

Miks Outlook näitab valet kuupäeva

Outlook ei kasuta e-kirja kuupäeva kuvamiseks üksnes Date:-päist. Enamikus vaadetes kasutatakse IMAP/Exchange-serveri poolt edastatud INTERNALDATE väärtust, eriti postkasti sortimiseks. Algne Date:-päis on sõnumis küll olemas ja puutumata, kuid seda eiratakse INTERNALDATE kasuks.

Seetõttu ei lahenda Outlooki valik "Sordi saatmiskuupäeva järgi" tegelikult mitte midagi. See näitab tõesti teist väärtust, aga sortimiskäitumine jääb ebastabiilseks, sõltuvalt Outlooki versioonist ja vaaterežiimist (rühmitatud vestlused või mitte). Saatmiskuupäeva järgi sortimine ei ole parandus. See on plaaster, mis tuleb lahti järgmise kliendiuuenduse järel.

Probleemi tegelik ulatus

Keskmise suurusega Zoho -> Microsoft 365 migratsiooni puhul on tegemist kergesti 50 000 kuni 500 000 mõjutatud sõnumiga, sõltuvalt postkastide vanusest ja organisatsiooni suurusest. Iga e-kiri, mis migratsiooniakna jooksul üle kanti, kannab sama vigast kuupäeva, mistõttu probleem muutub kasutajatele nähtavaks kohe, kui nad Outlooki avavad.

Saadetud kirjade kaustad on tihti kõige halvemad. Müügitöötaja, kes otsib 2022. aasta märtsis saadetud hinnapakkumist, peab läbi kammima sadu e-kirju, mis kõik näitavad migratsiooni kuupäeva. Operatiivne mõju on tõeline, mitte ainult kosmeetiline.

Ja vastupidi sellele, mida võiksite lootma jääda, probleem ei kao aja jooksul. INTERNALDATE on fikseeritud sisestamise hetkel. See ei parane iseenesest. Aktiivse sekkumiseta säilitavad need e-kirjad oma vale kuupäeva tähtajatult.

Miks ise parandamine on riskantsem, kui paistab

Kiusatus on mõistetav: kuna algne Date:-päis on endiselt sõnumis olemas, tuleb lihtsalt... metaandmed parandada. Loogiliselt see kõlab õigesti. Praktikas on see tootmispostkastis 80 000 e-kirjaga operatsioon, mis võib minna katastroofiliselt viltu.

Siin on mõned piirjuhtumid, millega kodutehtud skript tõenäoliselt hästi hakkama ei saa:

  • S/MIME allkirjastatud e-kirjad, kus allkiri katab kogu päisestruktuuri. Sõnumis mistahes muutmine tühistab krüptograafilise allkirja.
  • PGP-krüpteeritud sõnumid, kus sisu on läbipaistmatu ja MIME-ümbrike manipuleerimine võib sõnumi rikkuda.
  • Mitte-ASCII päised, mis on kodeeritud RFC 2047 järgi (saatja nimed erimärkidega), mis lähevad katki, kui skript ei käsitle kodeeringut korrektselt.
  • Base64-kodeeritud manused vigaste rea lõputähistega, mittestandardsete MIME-piiridega või pesastatud mitmeosaliste struktuuridega.
  • E-kirjad, kus puudub kehtiv Date:-päis (need on olemas, eriti vanemates Zoho eksportides), kus skript peab otsustama, mida teha.
  • Skript, mis toimib 50 testkirja peal, ei toimi tootmises oleval Zoho postkastil aastate ajalooga. Ja kuidas te kontrollite, sõnum sõnumi järel, et igaüks parandatud e-kirjadest on terve ja et manuseid ei kärbitud? Kontrollimine on vähemalt nii keeruline kui parandamine ise.

    Lisandub ka kvoodiprobleem. Exchange Online API, Microsoft Graphi vahendusel, kehtestab ranged määrapiirangud (klassikaline vealiik 429 Too Many Requests). Kontrollimatu partii üle 100 000 sõnumi võib käivitada ajutisi blokeeringuid või vaikseid vigu, mida on tagantjärele peaaegu võimatu diagnoosida. Korraliku uuestikatsemismehhanismita tuleb kõik otsast peale alustada.

    Kuidas Redate.io parandab kuupäevad pärast Zoho migratsiooni

    Redate.io ühendub teie Microsoft 365 postkastiga hetkel, mil logite sisse oma Microsofti kontoga, ei ole vaja registreerida Azure rakendust, ei ole vaja eelnevalt seadistada administraatori nõusoleku etappi. Esialgne skannimine on tasuta: Redate.io tuvastab mõjutatud postkastid ja hindab valede kuupäevadega e-kirjade mahtu, võrreldes INTERNALDATE väärtust sõnumi päisteahelas kantud väärtustega.

    Parandus kasutab Redate'i välja töötatud mootorit, mis analüüsib igal sõnumil kogu päisteahelat, ei vaja teadmist, milline tööriist migratsiooni tegi (Zoho Migration Wizard, imapsync või mistahes muu), ja taastab kuupäeva metaandmed mitmeetapilise valideerimisprotsessi kaudu. Iga parandatud e-kiri kontrollitakse individuaalselt: sisu terviklikkus, manuste säilimine, RFC-vastavus. Originaalid jäävad nähtavasse kausta teie oma postkastis, kuni te need ise kustutate.

    Ei ole vaja uut migratsiooni. Ei ole seisakuid. Kasutajad jätkavad tööd Outlookis, samal ajal kui parandus töötab taustal.

    Hinnastamine on mahupõhine ühekordne makse, tellimust ei ole. Täpsemad andmed on saadaval otse veebisaidil.

    Kui haldate korraga mitut migratsiooni või olete MSP, kes tegeleb Zoho-st lahkuvate klientidega, pange tähele, et sama probleem tekib ka teistelt platvormidelt Exchange Online-i migreerimisel. Mehaanika on identne: koopia saab kuupäeva, mille tööriist edastab, olenemata lähtekohast.

    Google Workspace'ist, kohapealsest Exchange'ist või tööriistade, nagu BitTitan MigrationWiz või CloudM, vahendusel toimuvate migratsioonide jaoks käsitlevad Redate.io blogi eraldi artiklid iga tööriista konkreetset käitumist. Artikkel Vale e-kirja kuupäev pärast Exchange Online-i migratsiooni annab täieliku ülevaate kõigist stsenaariumidest, mis sellel tenantis lõpevad.

    Kui teie migratsioon hõlmab jagatud postkaste või Exchange'i ressursse (ruumid, seadmed), on probleem sama ja kehtivad samad parandustööriistad. Exchange IMAP migratsiooni kuupäeva parandamise juhendid Redate.io veebisaidil käsitlevad tenandi ühendamise etappe.

    Meeskondadele, kes kasutavad Zoho-st lahkumiseks konkreetselt imapsync-i, dokumenteerib juhend imapsync: kuupäevad ei säili imapsync-i seadistusvalikuid ja seda, kust valed kuupäevad tegelikult tulevad.

    Näete endiselt oma Zoho migratsiooni kuupäevi Outlookis? Skannige oma postkastid tasuta Redate.io-s, et mõõta probleemi täpset ulatust enne otsustamist, kuidas edasi tegutseda.

    Seotud artiklid