Selitev GWS v GWS: zakaj se datumi e-pošte pokvarijo

Scenarij, ki ga nihče ne pričakuje

Pravkar ste zaključili selitev enega Google Workspace tenanta v drugega. Prevzem podjetja, sprememba domene, združitev dveh enot, ki sta leta delovali na ločenih G Suite računih. Operacija je potekla gladko, nabiralni predali so na mestu, uporabniki se prijavljajo. V ponedeljek zjutraj prispe prvi zahtevek: "Vsi moji e-poštni sporočili imajo isti datum." Nato drugi. Nato deset.

Takoj pomislite: to je verjetno kakšna IMAP težava, napačno konfiguriran orodje, nekaj neobičajnega. Ne pa selitev Google v Google. Pa ravno tu se to dogaja.

Ta scenarij je verjetno najslabše dokumentiran v panogi. Večina IT skrbnikov, ki ga sreča, porabi več ur iščoč razlago na strani e-poštnega odjemalca, Outlooka ali nastavitev računa, preden ugotovijo, da je težava v glavi e-poštnih sporočil samih.

Zakaj selitev Google v Google pokvari datume

Da razumemo, kaj se dogaja, moramo pogledati mehaniko e-poštnih glav. Vsako sporočilo RFC 2822 vsebuje izvorno polje Date:, ki ga postavi odjemalec ali strežnik pošiljatelja ob pošiljanju. To je "pravi" datum e-pošte, tisti, ki ustreza, kdaj je bilo sporočilo napisano in poslano.

Obstaja pa še en mehanizem: IMAP INTERNALDATE. To je metapodatek, shranjen na strežniku, ki pove, kdaj je bilo sporočilo dostavljeno v nabiralni predal. In tu postane zanimivo.

Ko orodje za selitev prenese e-poštno sporočilo iz enega Google Workspace tenanta v drugega, gre skozi protokol IMAP (čeprav sta oba strežnika pri Googlu). Sporočilo se prebere iz vira in vstavi v cilj. V trenutku te vstavitve ciljni strežnik samodejno doda glavo Received: s časovnim žigom operacije, torej z datumom selitve.

Odjemalci kot je Outlook pa pri prikazu datuma sporočila uporabijo prvo glavo Received: v verigi, ne nujno izvornega polja Date:. Rezultat: vsa e-poštna sporočila prikazujejo datum dneva selitve.

Katera orodja povzročijo težavo

Prizadeta so skoraj vsa orodja, ki se uporabljajo za selitve med Google Workspace tenanti. Ni opaznih izjem:

• GSMMO (Google Workspace Migration for Microsoft Outlook): prvotno zasnovan za selitev iz Exchangea, a se uporablja v nekaterih tokovih GWS v GWS.
• CloudM Migrate: zelo razširjen pri MSP-jih za selitve med Google tenanti, sistematično doda Received: glavo selitve. Oglejte si podrobno analizo CloudM.
• BitTitan MigrationWiz: enako, obnašanje je podrobno opisano v tem članku o BitTitanu.
• imapsync: odprtokodno orodje za skriptiranje IMAP selitev, vključno med dvema Google tenantoma.
• Ročni izvoz/uvoz prek Takeout + IMAP uvoz: manj pogost, a povzroči popolnoma enak učinek.

Razlog je preprost: vsa ta orodja delujejo kot standardni IMAP odjemalci. Nimajo dostopa do kakšne "native" Google poti, ki bi ohranila metapodatke. Čeprav sta oba tenanta pri Googlu, prenos poteka skozi IMAP plast, ta plast pa ne ve, da se pogovarja sama s seboj.

Mehanika glav Received v podrobnostih

(Mimogrede, če ste kdaj poskušali brati surove glave e-pošte v Gmailu ali Outlooku, veste, da to ni ravno prijetno branje. Toda tam se skriva vsa resnica.)

E-poštno sporočilo, ki je normalno potovalo, vsebuje verigo glav Received: v obratnem vrstnem redu poti: zadnji strežnik, ki se je dotaknil sporočila, je na vrhu. Po selitvi je torej glava selitve na vrhu tega sklada.

Tako izgleda v sporočilu, migriranem prek CloudM iz enega GWS tenanta v drugega:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <uporabnik@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: pravi 2019. Prva glava Received: pravi oktober 2024. Outlook prebere prvo Received:. Uporabnik vidi oktober 2024 za e-pošto iz leta 2019.

Izvorno polje Date: je nedotaknjeno. Ni se premaknilo. To je dobra novica: podatek je tam, samo čaka, da se pravilno uporabi.

Outlook in Gmail se ne obnašata enako

To je pomembna podrobnost. Uporabniki, ki dostopajo do e-pošte prek Gmailove spletne aplikacije, pogosto vidijo pravilne datume, ker Gmail pri prikazu sporočil daje prednost polju Date: RFC 2822. Na spletni strani je težava manj vidna.

Nasprotno pa uporabniki, ki imajo Google Workspace nabiralni predal konfiguriran v Outlooku prek IMAP (ali prek sinhronizacije Exchange ActiveSync), v celoti trpijo napačni datum, ker se Outlook zanaša na IMAP INTERNALDATE, ki odraža datum prve Received: glave, dodane med selitvijo.

Natančneje: obnašanje Outlooka se razlikuje glede na različico in način povezave. Outlook 2019 in Microsoft 365 (novejše različice) pri IMAP povezavi uporabljajo INTERNALDATE. Starejše različice se lahko obnašajo nekoliko drugače. Toda v vseh primerih, opaženih v produkciji, selitev GWS v GWS prek IMAP v Outlooku povzroči napačne datume.

V organizacijah, ki so migrirale v nov tenant in imajo hibridne uporabnike (nekateri na Gmailovem spletu, drugi na Outlooku), so zahtevki za podporo nedosledni. IT ekipe porabijo čas ugotavljajoč, zakaj so "nekateri prizadeti in drugi ne", čeprav je odgovor preprost: razlika je v e-poštnem odjemalcu.

Prevzemi, združitve, spremembe domene: najpogostejši primeri

Ta vrsta selitve ni redkost. To so scenariji, ki generirajo največ zahtevkov:

Prevzem podjetja

Prevzeto podjetje je imelo lasten Google Workspace tenant (domena @staropodjetje.com). Po prevzemu mora vse preiti na tenant matičnega podjetja (@skupina.com). 250 nabiralnih predalov, arhivi, 8 let e-poštne zgodovine. BitTitan ali CloudM je zadolžen za operacijo. Rezultat: 2,4 milijona e-poštnih sporočil z datumom selitvenega vikenda.

Sprememba domene

Podjetje z novim blagovno-znamčenjem preklopi z @staroime.si na @novoime.si. Isti Google tenant, toda ustvari se nov tenant za čist začetek (pogosta izbira, da se izogne konfiguracijskim artefaktom). Selitev nabiralnih predalov prek imapsync ali GSMMO. Datumi se pokvarijo na popolnoma enak način.

Konsolidacija hčerinskih podjetij

Skupina s 4 hčerinskimi podjetji, vsako na lastnem zgodovinskem G Suite tenantu, se odloči združiti vse na enem tenantu. Štiri vzporedne selitve, štiri skupke e-poštnih sporočil s pokvarjenimi datumi za obdelavo.

V vseh treh scenarijih je težava enaka in rešitev je ista. Kontrolni seznam selitve e-pošte vam pomaga predvideti to vrsto težave pred začetkom selitve.

Zakaj domači skript ni odgovor

Razumeti težavo je ena stvar. Reči si "napišem Python skript, ki očisti glave" in ga uporabiti na 30.000 produkcijskih e-poštnih sporočilih, je pa druga.

Robni primeri so nešteti. Skript, ki deluje na 50 testnih e-poštnih sporočilih v čistem okolju, bo na produkcijskem nabiralnem predalu resnične velikosti neizogibno naletel na:

• Sporočila s S/MIME podpisi ali PGP šifrirano vsebino, kjer vsaka sprememba strukture sporočila razveljavi kriptografski podpis.
• E-pošto s kompleksnimi gnezdenimi MIME strukturami (multipart/alternative znotraj multipart/mixed s prilogami velikimi več deset megabajtov).
• Glave kodirane po RFC 2047 (znaki, ki niso ASCII), ki jih napačno konfigurirani razčlenjevalniki tiho požrejo.
• Napake 429 Too Many Requests Google API-ja ob 2h zjutraj, sredi serije popravkov, ki pustijo proces v nedoločenem stanju.
• E-pošto, pri kateri je veriga Received: dvoumna: več zaporednih orodij za selitev je vsako dodalo svojo glavo, in ni trivialno določiti, katero odstraniti.

Najpomembnejše vprašanje: kako preveriti, e-pošto za e-pošto, da je vsako popravljeno sporočilo celovito in da ni bilo ničesar izgubljenega ali poškodovanega? Domači skript te preveritve običajno ne opravlja. Redate.io jo izvede samodejno, z ohranitvijo izvirnikov v vidni varnostni kopiji mape 30 dni.

Kaj Redate.io naredi pri tej vrsti selitve

Redate.io se poveže z ciljnim Google Workspace tenantom (prek domenskega delegiranja, brez ročnega posega v posamezne nabiralne predale) in pregleda e-poštna sporočila, da identificira tista, katerih datumski metapodatki niso skladni z vsebino sporočila. Ta faza pregledovanja je brezplačna in daje natančno sliko obsega težave pred vsakim popravkom.

Lastniški korekcijski mehanizem nato analizira verigo glav vsakega sporočila, izvede ujemanje vzorcev glede na znane podpise orodij za selitev (BitTitan, CloudM, imapsync, GSMMO in drugih manj pogostih), ter izvede ciljni popravek metapodatkov brez poseganja v vsebino sporočila. Vsako popravljeno e-poštno sporočilo se preveri posamično. Izvirniki se ohranijo.

Za selitve med Google Workspace tenanti pipeline posebej obravnava primere, kjer je prišlo do večkratnih selitvenih prehodov (na primer, nabiralni predal, migriran prvič leta 2021 in nato spet leta 2024), z večimi plastmi motečih glav za razpletanje.

Za ta tip konfiguracije si oglejte vodiča za popravek: CloudM v Google Workspace in BitTitan v Google Workspace.

Zaznajte težavo, preden se nanjo pritožijo uporabniki

Najboljši čas za zaznavanje pokvarjenih datumov je takoj po selitvi, pred zagonom v produkcijo. Hiter pregled na nekaj pilotnih nabiralnih predalih prek IMAP odjemalca kot je Thunderbird omogoča primerjavo prikaza datumov s pričakovanim. Če se zdi, da imajo vsa uvožena e-poštna sporočila isti nedavni datum, je to značilen znak težave.

V praksi pa se odkritje težave pogosto zgodi več tednov po selitvi, ko uporabnik išče staro pogodbo in ugotovi, da je njegov Gmail nabiralni predal popolnoma urejen... po datumu selitve. Tisoče e-poštnih sporočil nagromaženih ob istem časovnem žigu. Iskanje po datumu ne deluje več. Konverzacijske niti so v neredu. Zdi se, da je zgodovina izginila.

Za MSP-je, ki redno upravljajo selitve med Google Workspace tenanti, vključitev pregledovanja Redate.io v kontrolni seznam po selitvi (pred validacijo s stranko) prepreči tovrstna presenečenja.

Ste pravkar migrirali med dvema Google Workspace tenantoma in datumi vaše e-pošte niso pravilni? Zaženite brezplačni pregled na Redate.io in ocenite obseg težave pred vsakim popravkom.