Migracija GWS prema GWS: datumi emailova su pokvareni

Scenarij koji nitko ne sumnja

Upravo ste završili migraciju jednog Google Workspace tenanta prema drugom. Preuzimanje tvrtke, promjena domene, spajanje dviju organizacija koje su godinama koegzistirale na odvojenim G Suite računima. Operacija je prošla glatko, sandučići su postavljeni, korisnici se prijavljuju. U ponedjeljak ujutro, prvi tiket: „Svi moji emailovi imaju isti datum." Zatim drugi. Zatim deset.

Instinktivno pomislite: sigurno je problem u IMAP-u, loše konfiguriranom alatu, nečemu egzotičnom. Ne u migraciji Googlea prema Googleu. A upravo se tu to događa.

Ovaj scenarij vjerojatno je najslabije dokumentiran u cijeloj branši. Većina IT administratora koji na njega naiđu potroše nekoliko sati tražeći objašnjenje na strani mail klijenta, Outlooka ili postavki računa, prije nego što shvate da je problem u samim zaglavljima emailova.

Zašto migracija Googlea prema Googleu kvari datume

Da bismo razumjeli što se događa, moramo se vratiti na mehaniku zaglavlja emailova. Svaka RFC 2822 poruka sadrži originalno polje Date: koje postavlja klijent ili poslužitelj pošiljatelja u trenutku slanja. To je „pravi" datum emaila, onaj koji odgovara trenutku kada je poruka napisana i poslana.

Ali postoji i drugi mehanizam: INTERNALDATE u IMAP-u. To je metapodatak pohranjen na poslužitelju koji označava kada je poruka stigla u sandučić. I tu postaje zanimljivo.

Kad alat za migraciju prenosi email s jednog Google Workspace tenanta na drugi, prolazi kroz IMAP protokol (čak i kada su oba poslužitelja kod Googlea). Poruka se čita iz izvora, a zatim umeće u odredište. U trenutku tog umetanja, odredišni poslužitelj automatski dodaje zaglavlje Received: s vremenskim pečatom operacije, odnosno datumom migracije.

A mail 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

Gotovo svi alati koji se koriste za migracije između Google Workspace tenanata su pogođeni. Nema iznimke:

• GSMMO (Google Workspace Migration for Microsoft Outlook): originalno namijenjen migraciji iz Exchangea, ali se koristi u nekim GWS prema GWS tokovima.
• CloudM Migrate: vrlo rasprostranjen kod MSP-ova za migracije između Google tenanata, sustavno dodaje Received: zaglavlje migracije. Pogledajte detaljnu analizu CloudM-a.
• BitTitan MigrationWiz: isto, ponašanje je dokumentirano u ovom članku o BitTitanu.
• imapsync: open source alat koji omogućuje skriptiranje IMAP migracija, uključujući između dva Google tenanta.
• Ručni izvoz/uvoz putem Takeout + IMAP reimport: rjeđi slučajevi, ali proizvode potpuno isti efekt.

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

Mehanika Received zaglavlja u detalju

(Inače, ako ste ikad pokušali čitati sirova zaglavlja emaila iz Gmaila ili Outlooka, znate da to baš nije ugodno štivo. Ali upravo se tamo krije cijela istina.)

Email koji je normalno putovao sadrži lanac Received: zaglavlja u obrnutom redoslijedu putovanja: poslužitelj koji je posljednji dotaknuo poruku je na vrhu. Nakon migracije, zaglavlje migracije nalazi se dakle na samom vrhu stoga.

Evo kako to izgleda u poruci migriranoj putem CloudM-a s 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@nova-domena.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 listopad 2024. Outlook čita prvo Received:. Korisnik vidi listopad 2024. za email iz 2019.

Originalno polje Date: je netaknuto. Nije se pomaknulo. To je dobra vijest: podatak je tamo, samo čeka da se ispravno upotrijebi.

Outlook i Gmail ne ponašaju se jednako

Ovo je važna napomena. Korisnici koji pristupaju emailovima putem Gmail web sučelja često vide ispravne datume, jer Gmail primarno koristi polje Date: prema RFC 2822 za prikaz poruka. Problem je manje vidljiv na webu.

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

Zapravo, da budemo precizni: ponašanje Outlooka varira ovisno o verziji i načinu spajanja. Outlook 2019 i Microsoft 365 (novije verzije) koriste INTERNALDATE pri spajanju putem IMAP-a. Starije verzije mogu imati nešto drugačije ponašanje. Ali u svim slučajevima opaženim u produkciji, migracija GWS prema GWS putem IMAP-a proizvodi netočne datume u Outlooku.

U organizacijama koje su migrirale na novi tenant i koje održavaju hibridne korisnike (jedni na Gmail webu, drugi na Outlooku), tiketi su nekonzistentni. IT timovi troše vrijeme pokušavajući shvatiti zašto su „neki pogođeni, a drugi nisu", dok je odgovor zapravo jednostavan: razlika je u mail klijentu.

Preuzimanja, spajanja, promjene domene: najčešći slučajevi

Ovaj tip migracije nije beznačajan. Evo scenarija koji generiraju najviše tiketa:

Preuzimanje tvrtke

Preuzeta tvrtka imala je vlastiti Google Workspace tenant (domena @staratvrka.com). Nakon preuzimanja, sve mora migrirati na tenant matične kompanije (@grupa.com). Svih 250 sandučića, arhive, 8 godina emailova. BitTitan ili CloudM je angažiran za operaciju. Rezultat: 2,4 milijuna emailova s datumom vikenda migracije.

Promjena domene

Tvrtka koja se rebrandirala prelazi s @staronaziv.hr na @novonaziv.hr. Isti Google tenant, ali se kreira novi tenant za čist početak (čest izbor radi izbjegavanja konfiguracijskih artefakata). Migracija sandučića putem imapsync-a ili GSMMO-a. Datumi se kvare na potpuno isti način.

Konsolidacija podružnica

Grupa s 4 podružnice, svaka na svojem povijesnom G Suite tenantu, koja odlučuje sve objediniti na jednom tenantu. Četiri paralelne migracije, četiri serije emailova s oštećenim datumima za obradu.

U sva tri scenarija problem je identičan i rješenje je isto. Kontrolni popis za migraciju emailova omogućuje anticipiranje ovog tipa problema prije pokretanja migracije.

Zašto ručno pisani skript nije odgovor

Razumjeti problem jedna je stvar. Reći si „napisat ću Python skript koji čisti zaglavlja" i primijeniti ga na 30.000 produkcijskih emailova, to je sasvim druga stvar.

Rubni slučajevi su brojni. Skript koji radi na 50 testnih emailova u čistom okruženju neizbježno će, na produkcijskom sandučiću stvarnih razmjera, naići na:

• Poruke s S/MIME potpisima ili PGP enkriptiranim sadržajem, gdje svaka izmjena strukture poruke poništava kriptografski potpis.
• Emailove s kompleksnim ugniježđenim MIME strukturama (multipart/alternative unutar multipart/mixed s privitcima od nekoliko desetaka megabajta).
• Zaglavlja kodirana prema RFC 2047 (ne-ASCII znakovi), koje loše konfigurirani parseri tiho gutaju.
• Greške 429 Too Many Requests od Google API-ja u 2 sata ujutro, usred serije ispravaka, koje ostavljaju proces u neodređenom stanju.
• Emailove za koje je lanac Received: zaglavlja dvosmislen: nekoliko uzastopnih alata za migraciju svaki je dodao svoje zaglavlje, i nije trivijalno odrediti koje ukloniti.

I najvažnije pitanje: kako provjeriti, email po email, da je svaka ispravljena poruka netaknuta i da ništa nije izgubljeno ili oštećeno? Ručno pisani skript tu provjeru obično ne radi. Redate.io je radi automatski, uz čuvanje originala u vidljivoj sigurnosnoj kopiji 30 dana.

Što Redate.io radi za ovaj tip migracije

Redate.io se spaja na odredišni Google Workspace tenant (putem domenskog delegiranja, bez ručne intervencije sandučić po sandučić) i skenira emailove radi prepoznavanja onih čiji su metapodaci datuma neusklađeni sa sadržajem poruke. Ova faza skeniranja je besplatna i pruža točnu sliku razmjera problema prije bilo kakvog ispravka.

Vlasnički motor za ispravak zatim analizira lanac zaglavlja svake poruke, primjenjuje prepoznavanje uzoraka na poznate potpise alata za migraciju (BitTitan, CloudM, imapsync, GSMMO i drugi manje uobičajeni), te provodi ciljani ispravak metapodataka bez mijenjanja sadržaja poruke. Svaki ispravljeni email se individualno verificira. Originali se čuvaju.

Za migracije između Google Workspace tenanata posebno, pipeline obrađuje slučajeve gdje je bilo više prolaza migracije (na primjer, sandučić migriran prvi put 2021. pa ponovno 2024.), s višestrukim slojevima parazitskih zaglavlja koja treba raspetljati.

Vodiči za specifičan ispravak za CloudM prema Google Workspace i BitTitan prema Google Workspace detaljno opisuju korake spajanja za ovaj tip konfiguracije.

Otkriti problem prije nego što se korisnici počnu žaliti

Najbolji trenutak za otkrivanje oštećenih datuma je odmah nakon migracije, prije go-livea. Brza provjera na nekoliko pilot sandučića putem IMAP klijenta poput Thunderbirda omogućuje usporedbu prikaza datuma s očekivanim vrijednostima. Ako svi uvezeni emailovi izgledaju da imaju isti nedavni datum, to je karakterističan znak problema.

Ali u praksi, otkriće problema često dolazi nekoliko tjedana nakon migracije, kada korisnik traži stari ugovor i shvati da je njegov Gmail sandučić savršeno sortiran... po datumu migracije. Tisuće emailova nagomilane na istom vremenskom pečatu. Pretraživanje po datumu ne funkcionira. Niti razgovori nisu u redu. Čini se kao da je povijest nestala.

Za MSP-ove koji redovito upravljaju migracijama između Google Workspace tenanata, integriranje Redate.io skeniranja u kontrolni popis post-migracije (prije prihvata od strane klijenta) sprječava ovakva iznenađenja.

Upravo ste migrirali između dva Google Workspace tenanta i datumi Vaših emailova su netočni? Pokrenite besplatno skeniranje na Redate.io i izmjerite razmjere problema prije bilo kakvog ispravka.