„Zoho Mail" ir datų problema
„Zoho Mail" yra populiari el. pašto platforma mažoms ir vidutinėms įmonėms - ekonomiška alternatyva „Google Workspace" ir „Microsoft 365". Daugelis organizacijų migruoja į „Zoho" norėdamos sumažinti kaštus. Kitos migruoja iš „Zoho", kai pereina prie didesnės platformos.
Abiem kryptimis migracijos procesas gali sugadinti el. laiškų datas. Kiekvienas pašto dėžutės pranešimas žymimas migracijos data vietoj originalios išsiuntimo ar gavimo datos. Tai erzina, ir taip nutinka kur kas dažniau, nei dauguma administratorių įsivaizduoja.
Dažni „Zoho" migracijos scenarijai
Migracija į „Zoho Mail"
Organizacijos, pereinančios prie „Zoho Mail", paprastai migruoja iš „Google Workspace", „Microsoft 365" ar bendro IMAP prieglobos (cPanel, Plesk, Dovecot). „Zoho" pateikia savo migracijos vedlį, palaikantį IMAP importą iš daugumos el. pašto teikėjų. Vedlys prisijungia prie šaltinio serverio, atsisiunčia el. laiškus per IMAP ir įterpia juos į „Zoho Mail" paskyras. Šio įterpimo metu „Zoho" serveriai prideda „Received" antraštę su migracijos laiko žyma kiekvienam pranešimui. Ši nauja antraštė tampa aukščiausiu įrašu grandinėje, todėl el. pašto klientai rodo migracijos datą.
Migracija iš „Zoho Mail"
Kai organizacijos peraugą „Zoho" arba reikia „Google Workspace" ar „Microsoft 365" išskirtinių funkcijų, jos migruoja. Tokie įrankiai kaip BitTitan MigrationWiz, imapsync ar net rankinis IMAP kopijavimas per „Thunderbird" yra dažnai naudojami. Kiekvienas iš šių metodų atsisiunčia el. laiškus iš „Zoho" ir iš naujo įterpia juos į paskirties serverį per IMAP APPEND, sukeldamas tą pačią „Received" antraštės problemą. Konkretiems įrankių vadovams žr. BitTitan, imapsync ar rankinis IMAP kopijavimas.
Migracija tarp „Zoho" paskyrų
Net migracija tarp „Zoho Mail" paskyrų (įmonės restruktūrizavimo ar domeno keitimo metu) gali sukelti datų problemas. Kiekvieną kartą, kai el. laiškai atsiunčiami ir iš naujo įterpiami per IMAP, paskirties serveris prideda savo „Received" antraštę. Nesvarbu, ar šaltinis ir paskirties vieta yra abu „Zoho" paskyros.
Kaip „Zoho Mail" tvarko IMAP datas
„Zoho" IMAP implementacija
„Zoho Mail" palaiko standartą IMAP4rev1 (RFC 3501). Kai pranešimas įterpiamas per IMAP APPEND, „Zoho" serveris seka protokolo specifikaciją: prideda „Received" antraštę su esama laiko žyma ir saugo pranešimą su INTERNALDATE. Jei APPEND komanda apima aiškų INTERNALDATE parametrą, „Zoho" jį gerbia. Tačiau „Received" antraštė vis tiek pridedama nepriklausomai nuo visko.
„Zoho" žiniatinklio paštas ir IMAP klientai
Ir čia situacija komplikuojasi.
„Zoho" žiniatinklio pašto sąsaja rodo datas pagal el. laiško „Date" antraštę, panašiai kaip „Gmail" žiniatinklio sąsaja. Todėl datos gali atrodyti teisingos peržiūrint el. laiškus per „Zoho" žiniatinklio paštą. Tačiau bet kuris IMAP klientas, prisijungiantis prie „Zoho" paskyros („Outlook", „Apple Mail", „Thunderbird"), naudos „Received" antraštę ar INTERNALDATE, rodydamas migracijos datą vietoj originalios datos.
Administratorius gali patikrinti „Zoho" žiniatinklio paštą, pamatyti teisingas datas ir daryti išvadą, kad migracija pavyko. Tuo tarpu naudotojai, prisijungiantys per „Outlook" ar „Apple Mail", praneša, kad visi jų el. laiškai rodo tą pačią datą. Norėdami daugiau sužinoti, kaip skirtingi klientai tvarko datas, žr. IMAP INTERNALDATE: kodėl datos sugenda.
Problemos identifikavimas „Zoho Mail"
Patikrinkite el. pašto antraštes
Norėdami patvirtinti, kad migracijos „Received" antraštės sukelia datų problemą, atidarykite paveiktą el. laišką „Zoho" žiniatinklio pašte ir peržiūrėkite neapdorotas antraštes. Paspauskite el. laiško trijų taškų meniu ir pasirinkite „Rodyti originalą". Žiūrėkite aukščiausią „Received" antraštę. Jei ji turi laiko žymą, atitinkančią migracijos datą, ir nurodo migracijos įrankį ar serverį, kuris nebuvo originalaus pristatymo kelio dalis, problema patvirtinta.
Palyginkite datas tarp klientų
Atidarykite tą patį el. laišką „Zoho" žiniatinklio pašte ir IMAP kliente kaip „Outlook". Jei „Zoho" žiniatinklio paštas rodo „2024 m. sausio 15 d.", bet „Outlook" rodo „2025 m. balandžio 11 d." (migracijos datą), „Received" antraštės problema yra priežastis.
„Zoho Mail" datų taisymas su Redate.io
Prisijungimas per IMAP
Redate.io prisijungia prie „Zoho Mail" paskyrų per standartinį IMAP. Prisijungimui prie „Zoho Mail" paskyros reikia IMAP serverio adreso (imap.zoho.com arba imap.zoho.eu, priklausomai nuo duomenų centro), el. pašto adreso ir programai skirto slaptažodžio. „Zoho" reikalauja programoms skirtų slaptažodžių IMAP prisijungimams, kai aktyvuota dviejų faktorių autentifikacija (rekomenduojama saugumo konfigūracija).
Programai skirtam slaptažodžiui „Zoho" sugeneruoti: eikite į „Zoho" paskyros nustatymus, Sauga, tada Programoms skirti slaptažodžiai ir sugeneruokite naują slaptažodį Redate.io. Šis slaptažodis suteikia IMAP prieigą neatskleisdamas pagrindinio paskyros slaptažodžio.
Analizės ir taisymo procesas
Prisijungus, Redate.io analizuoja visą „Zoho" pašto dėžutę ir identifikuoja el. laiškus su migracijos „Received" antraštėmis. Analizė patikrina kiekvieną aplanką (Gautieji, Išsiųstieji, Juodraščiai ir individualūs aplankai) ir suskaičiuoja paveiktų el. laiškų skaičių. Analizė nemokama.
Redate.io nuosavybinis taisymo variklis tada analizuoja kiekvieno paveikto el. laiško visą antraščių grandinę, taikydamas parašų atitikimą šimtams žinomų migracijos įrankių parašų. Daugiapakopis konvejeris tvarko kodavimo problemas, daugiadales pranešimų struktūras, įdėtus priedus, skaitmeninius parašus ir dešimtis specialių atvejų, kuriuos rankinis metodas praleis. Kiekvienas pataisytas el. laiškas praeina vientisumo patikrą prieš originalo perkėlimą į matomą atsarginės kopijos aplanką „Redate.io - Originals" 30 dienų.
Kodėl tiesiog neparašyti scenarijaus patiems? Nes specialūs atvejai yra ten, kur viskas griūna. S/MIME pasirašyti el. laiškai, sugadintos MIME ribos, ne ASCII antraštės, koduotos pagal RFC 2047, įdėtos daugiadlės struktūros, pranešimai visai be „Date" antraštės. Scenarijus, kuris tvarko 90 % el. laiškų ir tyliai sugadina likusius 10 %, yra blogesnis nei joks scenarijus (ne tas atradimas, kurį norėtumėte padaryti pirmadienio rytą).
„Zoho" specifiniai aspektai
„Zoho" IMAP užklausų limitai
„Zoho Mail" taiko užklausų limitus IMAP prisijungimams, kad būtų išvengta piktnaudžiavimo. Redate.io gerbia šiuos limitus, sulėtindamas taisymo procesą, kad liktų „Zoho" leidžiamų užklausų normose. Pašto dėžutėms su dideliu el. laiškų skaičiumi taisymas gali užtrukti ilgiau nei platformose su dosnesniais limitais.
„Zoho" nemokamas ir mokami planai
Nemokamas „Zoho Mail" planas nepalaiko IMAP prieigos. IMAP prieinamas tik mokamuose „Zoho Mail" planuose (Mail Lite ir aukštesniuose). Jei atitinkama „Zoho" paskyra yra nemokamame plane, IMAP turi būti aktyvuotas pereinant prie mokamo plano prieš Redate.io prisijungimą.
„Zoho" duomenų centro vieta
„Zoho" valdo duomenų centrus keliuose regionuose (JAV, ES, Indija, Australija, Japonija). IMAP serverio adresas skiriasi priklausomai nuo regiono: imap.zoho.com (JAV), imap.zoho.eu (ES), imap.zoho.in (Indija), imap.zoho.com.au (Australija). Prisijungdami prie Redate.io, naudokite teisingą regioninį serverio adresą.
„Zoho Mail" rodo klaidingas datas po migracijos? Paleiskite nemokamą analizę su Redate.io ir sužinokite tiksliai, kiek el. laiškų paveikta.