Migracija GWS na GWS: datumi emailova su pokvareni

Scenario koji niko ne bi posumnjao

Upravo ste završili migraciju jednog Google Workspace tenanta na drugi. Akvizicija firme, promena domena, spajanje dve organizacije koje su godinama koegzistirale na odvojenim G Suite nalozima. Operacija je prošla dobro, sanduciće su na mestu, korisnici se prijavljuju. Ponedeljak ujutro, prvi tiket: "Svi moji emailovi imaju isti datum." Zatim drugi. Zatim deset.

Instinktivno pomislite: mora da je problem sa IMAP-om, loše konfigurisan alat, nešto egzotično. Ne migracija sa Googlea na Google. Pa ipak, upravo tu se sve dešava.

Ovaj scenario je verovatno najslabije dokumentovan u industriji. Većina IT administratora koji ga sretnu potroši nekoliko sati tražeći objašnjenje na strani mail klijenta, Outlooka, podešavanja naloga, pre nego što shvate da je problem u samim zaglavljivima emailova.

Zašto migracija Google na Google kvari datume

Da bismo razumeli šta se dešava, moramo se vratiti na mehaniku email zaglavlja. Svaka RFC 2822 poruka sadrži originalno polje Date:, koje postavlja klijent ili server pošiljaoca u trenutku slanja. To je "pravi" datum emaila, onaj koji odgovara kada je poruka napisana i poslata.

Ali postoji i drugi mehanizam: INTERNALDATE u IMAP-u. To je metapodatak koji se čuva na serveru i koji označava kada je poruka deponovana u sandučić. I tu postaje zanimljivo.

Kada alat za migraciju prenosi email sa jednog Google Workspace tenanta na drugi, prolazi kroz IMAP protokol (čak i ako su oba servera kod Googlea). Poruka se čita sa izvora, zatim se ponovo umeće u odredište. U trenutku tog umetanja, odredišni server automatski dodaje zaglavlje Received: sa vremenskim pečatom operacije, tj. datumom migracije.

Klijenti poput Outlooka koriste prvo Received: zaglavlje u lancu za prikaz datuma poruke, a ne nužno originalno polje Date:. Rezultat: svi emailovi prikazuju datum dana migracije.

Koji alati uzrokuju problem

Praktično svi alati koji se koriste za migracije između Google Workspace tenanta su pogođeni. Nema izuzetaka:

• GSMMO (Google Workspace Migration for Microsoft Outlook): prvobitno dizajniran za migraciju sa Exchangea, ali se koristi i u nekim GWS-na-GWS tokovima.
• CloudM Migrate: veoma rasprostranjen kod MSP-ova za migracije između Google tenanta, sistematski dodaje Received: zaglavlje migracije. Pogledajte detaljnu analizu CloudM migracija.
• BitTitan MigrationWiz: isto, ponašanje je opisano u analizi BitTitan migracija.
• imapsync: open source alat koji omogućava skriptovanje IMAP migracija, uključujući između dva Google tenanta.
• Ručni eksporti/importi putem Takeout + IMAP reimport: ređi, ali proizvode tačno isti efekat.

Razlog je jednostavan: svi ovi alati funkcionišu kao standardni IMAP klijenti. Nemaju pristup nekakvom "nativnom" Google putu koji bi sačuvao metapodatke. Čak i ako su oba tenanta kod Googlea, prenos prolazi kroz IMAP sloj, a taj sloj ne zna da razgovara sam sa sobom.

Mehanika Received zaglavlja u detalju

(Inace, ako ste ikada pokušali da čitate sirova zaglavlja emaila u Gmailu ili Outlooku, znate da to nije baš prijatno štivo. Ali tamo se krije sva istina.)

Email koji je normalno putovao sadrži lanac Received: zaglavlja u obrnutom redosledu putanje: poslednji server koji je dotakao poruku nalazi se na vrhu. Nakon migracije, zaglavlje migracije se dakle nalazi na samom vrhu ovog niza.

Ovako to izgleda u poruci migriranoj putem CloudM-a sa jednog GWS tenanta na drugi:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <korisnik@novi-domen.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Polje Date: kaže 2019. Prvo Received: kaže oktobar 2024. Outlook čita prvo Received:. Korisnik vidi oktobar 2024. za email iz 2019.

Originalno polje Date: je netaknuto. Nije se pomerilo. To je dobra vest: podatak je tu, samo čeka da se pravilno iskoristi.

Outlook i Gmail se ne ponašaju isto

Ovo je važna napomena. Korisnici koji pristupaju emailovima putem Gmail web interfejsa često vide ispravne datume, jer Gmail daje prioritet polju Date: po RFC 2822 standardu za prikaz poruka. Problem je manje vidljiv na webu.

S druge strane, korisnici koji konfigurišu svoj Google Workspace sandučić u Outlooku putem IMAP-a (ili putem Exchange ActiveSync sinhronizacije) u potpunosti trpe pogrešan datum, jer se Outlook oslanja na IMAP INTERNALDATE, koji odražava datum prvog Received: zaglavlja dodanog tokom migracije.

Zapravo, da budemo precizni: ponašanje Outlooka varira u zavisnosti od verzije i načina povezivanja. Outlook 2019 i Microsoft 365 (novije verzije) koriste INTERNALDATE kada se povezuju putem IMAP-a. Starije verzije mogu imati blago drugačija ponašanja. Ali u svim slučajevima posmatranim u produkciji, migracija GWS na GWS putem IMAP-a proizvodi pogrešne datume u Outlooku.

Zbog toga, u organizacijama koje su migrirale na novi tenant i koje održavaju hibridne korisnike (neki na Gmail webu, drugi na Outlooku), prijave tiketa su nekonzistentne. IT timovi provode vreme pokušavajući da razumeju zašto su "neki pogođeni, a drugi nisu", a odgovor je jednostavno: razlika je u mail klijentu.

Akvizicije, spajanja, promene domena: najčešći slučajevi

Ovaj tip migracije nije retka pojava. Evo scenarija koji generišu najviše tiketa:

Akvizicija kompanije

Preuzeta firma imala je sopstveni Google Workspace tenant (domen @starakompanija.com). Nakon akvizicije, sve mora da migrira na tenant matične firme (@grupa.com). Sva 250 sandučića, arhive, 8 godina email istorije. BitTitan ili CloudM su angažovani za operaciju. Rezultat: 2,4 miliona emailova sa datumom vikenda migracije.

Promena domena

Rebrandovana kompanija prelazi sa @staronaziv.rs na @novonaziv.rs. Isti Google tenant, ali se kreira novi tenant radi čistog starta (čest izbor kako bi se izbegli konfigurišni artefakti). Migracija sandučića putem imapsync ili GSMMO. Datumi se kvare na potpuno isti način.

Konsolidacija podružnica

Korporacija sa 4 podružnice, svaka na sopstvenom istorijskom G Suite tenantu, koja odlučuje da sve spoji na jedan jedinstven tenant. Četiri migracije paralelno, četiri serije emailova sa pokvarenim datumima za obradu.

U sva tri scenarija, problem je identičan i rešenje je isto. Kontrolna lista za migraciju emaila omogućava da se ovakav problem predvidi pre pokretanja migracije.

Zašto skript napisan od ruke nije odgovor

Razumeti problem je jedna stvar. Reći sebi "napisaću Python skript koji čisti zaglavlja" i primeniti ga na 30.000 emailova u produkciji, to je sasvim druga priča.

Rubni slučajevi su brojni. Skript koji radi na 50 test emailova u čistom okruženju neizbežno će naići, na stvarnom produkcijskom sandučiću, na:

• Poruke sa S/MIME potpisima ili PGP šifrovanim sadržajem, gde svaka izmena strukture poruke poništava kriptografski potpis.
• Emailove sa složenim ugnježdenim MIME strukturama (multipart/alternative unutar multipart/mixed sa prilozima od nekoliko desetina megabajta).
• Zaglavlja enkodovana po RFC 2047 standardu (ne-ASCII karakteri), koja loše konfigurisani parseri tiho gutaju.
• Greške 429 Too Many Requests od Google API-ja u 2 ujutro, usred batch korekcije, koje ostavljaju proces u neodređenom stanju.
• Emailove za koje je lanac Received: zaglavlja ambiguozan: više sukcesivnih alata za migraciju je svaki dodao sopstveno zaglavlje, i nije trivijalno odrediti koje ukloniti.

I najvažnije pitanje: kako proveriti, email po email, da je svaka ispravljena poruka netaknuta i da ništa nije izgubljeno ili oštećeno? Skript napisan od ruke obično ne vrši ovu verifikaciju. Redate.io to radi automatski, uz čuvanje originala u vidljivom backup folderu tokom 30 dana.

Šta Redate.io radi za ovaj tip migracije

Redate.io se povezuje na odredišni Google Workspace tenant (putem delegacije domena, bez ručne intervencije sandučić po sandučić) i skenira emailove kako bi identifikovao one čiji metapodaci datuma nisu konzistentni sa sadržajem poruke. Ova faza skeniranja je besplatna i daje tačnu sliku obima problema pre bilo kakve korekcije.

Vlasničke engine za korekciju zatim analizira lanac zaglavlja svake poruke, primenjuje prepoznavanje obrazaca na poznate potpise alata za migraciju (BitTitan, CloudM, imapsync, GSMMO i drugi manje uobičajeni), i vrši ciljanu korekciju metapodataka bez izmene sadržaja poruke. Svaki ispravljen email se verifikuje pojedinačno. Originali se čuvaju.

Za migracije između Google Workspace tenanta specifično, pipeline obrađuje slučajeve gde je došlo do više prolaza migracije (na primer, sandučić migriran prvi put 2021. pa ponovo 2024.), sa više slojeva parazitskih zaglavlja koje treba razrešiti.

Vodiči za specifičnu korekciju CloudM ka Google Workspace i BitTitan ka Google Workspace detaljno opisuju korake za povezivanje za ovaj tip konfiguracije.

Otkrivanje problema pre nego što se korisnici požale

Najbolji trenutak za otkrivanje pokvarenih datuma je odmah nakon migracije, pre go-livea. Brza provera na nekoliko pilot sandučića putem IMAP klijenta kao što je Thunderbird omogućava poređenje prikaza datuma sa onim što bi se očekivalo. Ako svi uvezeni emailovi izgledaju kao da imaju isti nedavni datum, to je karakteristični znak problema.

Ali u praksi, problem se često otkriva nekoliko nedelja nakon migracije, kada korisnik traži stari ugovor i shvati da je njegov Gmail sandučić savršeno sortiran... po datumu migracije. Hiljade emailova nagomilanih na istom vremenskom pečatu. Pretraga po datumu više ne radi. Niti razgovora su u neredu. Istorija kao da je nestala.

Za MSP-ove koji redovno upravljaju migracijama između Google Workspace tenanta, integracija Redate.io skeniranja u post-migracioni kontrolni spisak (pre klijentske validacije) sprečava ovakva iznenađenja.

Upravo ste migrirali između dva Google Workspace tenanta i datumi Vaših emailova su pogrešni? Pokrenite besplatno skeniranje na Redate.io i utvrdite obim problema pre bilo kakve korekcije.