Rett e-postdatoer etter Google

Datoproblemet etter Google Workspace-migrering

Organisasjoner som migrerer til Google Workspace gjør ofte en ubehagelig oppdagelse: alle e-poster i alle postbokser viser feil dato. I stedet for den opprinnelige sende- eller mottaksdatoen viser hver melding datoen migreringen ble utført. Det spiller ingen rolle om organisasjonen migrerte fra Microsoft Exchange, Office 365, Zimbra, Lotus Notes eller en annen IMAP-server. Tusenvis av e-poster, alle stemplet med en enkelt migreringsdato.

Og dette er ikke spesifikt for et bestemt migreringsverktøy. Det skjer med BitTitan MigrationWiz, CloudM Migrate, GSMMO, imapsync og alle andre verktøy som setter inn e-poster i Google Workspace via IMAP eller Gmail API. Årsaken er et grunnleggende aspekt ved hvordan e-postservere håndterer innsetting av meldinger, og det påvirker alle migreringer til Google Workspace.

Vanlige migreringsstier til Google Workspace

Fra Microsoft Exchange (lokal)

Organisasjoner som kjører lokale Exchange-servere (2010, 2013, 2016 eller 2019) migrerer til Google Workspace for å redusere infrastrukturkostnader og gå over til en skybasert modell. Disse migreringene bruker vanligvis CloudM, BitTitan MigrationWiz eller GSMMO. Migreringsverktøyet kobler seg til Exchange, laster ned hver e-post og laster den opp til brukerens Google Workspace-postboks. Alle opplastede e-poster får en ny "Received"-header med migreringstidsstempelet.

Fra Microsoft 365 (Office 365)

Migreringer fra Microsoft 365 til Google Workspace er vanlige når organisasjoner bytter økosystem. BitTitan MigrationWiz og CloudM er de mest populære verktøyene for denne stien. Migreringsprosessen henter e-poster fra Exchange Online og setter dem inn i Google Workspace. Det samme "Received"-headerproblemet gjelder - alle migrerte e-poster viser migreringsdatoen.

Fra andre IMAP-servere

Migreringer fra Zimbra, Zoho, cPanel-hostet e-post, Dovecot, Courier og andre IMAP-servere til Google Workspace bruker verktøy som imapsync, CloudM eller egendefinerte skript. Destinasjonen (Google Workspace) legger til en "Received"-header under innsettingsoperasjonen uansettt hva kildeplattformen er. Til og med migreringer fra en annen Google Workspace-tenant gir det samme problemet.

Hvorfor datoer ødelegges i Google Workspace

Gmail-nettgrensesnittet vs. IMAP-klienter

Google Workspace presenterer en unik situasjon. Gmails nettgrensesnitt bruker vanligvis e-postens "Date"-header for å vise meldingsdatoen, noe som betyr at e-poster ofte vises med riktig dato i Gmails nettvisning. Men når den samme postboksen brukes gjennom en IMAP-klient (Outlook, Apple Mail, Thunderbird), leser klienten den øverste "Received"-headeren og viser migreringsdatoen.

Dette avviket skaper betydelig forvirring. En administrator som tester migreringen i Gmails nettgrensesnitt ser riktige datoer og antar at migreringen var vellykket. Men når brukere kobler Outlook til sin Google Workspace-konto, rapporterer de at alle e-poster har feil dato. Problemet eksisterer på serveren (e-postheaderne inneholder migreringstidsstempelet), men det blir bare synlig i enkelte klienter. Hvor mange IT-administratorer har lukket et migreringsprosjekt i troen på at alt var i orden, bare for å bli oversvømt med henvendelser neste mandag?

IMAP INTERNALDATE-faktoren

Google Workspace lagrer en INTERNALDATE for hver e-post, som settes under innsettingsprosessen. Noen migreringsverktøy setter denne riktig til den opprinnelige datoen, mens andre lar den stå som migreringsdatoen. Men selv når INTERNALDATE er riktig, viser IMAP-klienter som prioriterer "Received"-headere (som Outlook) fortsatt feil dato. Den fullstendige rettingen krever både fjerning av migrerings-"Received"-headeren og sikring av at INTERNALDATE er satt riktig. For en detaljert teknisk forklaring, se hvorfor e-poster viser feil dato etter IMAP-migrering.

Google Workspace-administrasjonsalternativer (som ikke fungerer)

Google Admin Console

Google Admin Console gir omfattende kontroller for Google Workspace-administrasjon, men inkluderer ingen funksjon for å korrigere e-postdatoer etter migrering. Ingen masseverktøy for headerredigering. Ingen datokorreksjonsfunksjon. Ingen måte å endre INTERNALDATE på eksisterende e-poster gjennom administrasjonsgrensesnittet.

Google Apps Script

Google Apps Script kan automatisere mange Gmail-operasjoner, men kan ikke endre rå e-postheadere. GmailApp- og Gmail API-tjenestene eksponert gjennom Apps Script tillater lesing av meldinger, endring av etiketter og redigering av metadata, men de støtter ikke erstatning av det rå RFC 2822-innholdet i en melding. Rettingen krever arbeid på et mye dypere nivå enn det Apps Script eksponerer.

Google Data Migration Service

Googles egen datamigrasjonstjeneste (tilgjengelig i Admin Console) er laget for å migrere e-poster til Google Workspace, ikke for å rette headere etter migrering. Å kjøre en ny migrering med dette verktøyet ville legge til enda en "Received"-header, noe som gjør problemet verre.

Rette Google Workspace-datoer med Redate.io

Hvordan administrasjonsdelegering fungerer

Redate.io bruker Google Workspaces domeneomfattende delegeringsfunksjon for å få tilgang til postbokser. Administratoren oppretter en tjenestekonto i Google Cloud Console, gir den de nødvendige Gmail API-tilgangene og aktiverer domenedelegering. Dette lar Redate.io behandle alle postbokser i organisasjonen uten å kreve individuelle brukeropplysninger.

Delegeringsoppsettet tar omtrent 10 minutter og følger den samme prosessen som brukes av andre Google Workspace-migrerings- og administrasjonsverktøy. Når det er konfigurert, kan administratoren skanne og rette et vilkårlig antall postbokser fra Redate.io-dashbordet.

Kom i gang

Opprett en tjenestekonto. I Google Cloud Console, opprett et nytt prosjekt (eller bruk et eksisterende), aktiver Gmail API og opprett en tjenestekonto med domenedelegering aktivert.

Gi API-tilganger. I Google Workspace Admin Console, naviger til Sikkerhet, deretter API-kontroller, deretter Domenedelegering. Legg til tjenestekontoens klient-ID og gi Gmail API-tilgangene som kreves av Redate.io.

Koble til i Redate.io. Logg inn på Redate.io, velg "Google Workspace" som plattform og last opp tjenestekontoens JSON-nøkkelfil. Redate.io validerer tilkoblingen og lister tilgjengelige postbokser.

Skann postbokser. Velg postboksene som skal skannes (eller skann alle). Den gratis skanningen identifiserer hvor mange e-poster i hver postboks som har feil datoer. Ingen betaling kreves for skanning.

Rett. Gjennomgå skanningsresultatene, velg en plan og start rettingen. Redate.io sin proprietære korreksjonsmotor behandler hver postboks og kjører alle e-poster gjennom en flertrinns analysepipeline som håndterer kodingsproblemer, flerdelte meldingsstrukturer, digitale signaturer og titalls unntakstilfeller som ville fått et gjør-det-selv-skript til å ødelegge data. Fremdrift er synlig i sanntid. Opprinnelige meldinger bevares i en "Redate.io - Originals"-etikett i 30 dager.

Etter rettingen

Når Redate.io har fullført rettingen, viser e-poster den riktige datoen i alle klienter: Gmail på nett, Outlook, Apple Mail, Thunderbird og alle andre IMAP-tilkoblede applikasjoner. Rettingen er permanent. Ingen løpende vedlikehold eller abonnement kreves. Brukere kan sortere etter dato, søke etter datointervall og bruke samsvarsverktøy med tillit til at tidsstemplene er nøyaktige. Postboksen fungerer slik den burde ha fungert fra dag en.

Verktøyspesifikke veiledninger for Google Workspace

For detaljerte instruksjoner basert på det spesifikke migreringsverktøyet som ble brukt, se disse plattformspesifikke veiledningene:

Migrerte til Google Workspace og alle e-poster viser feil dato? Start en gratis skanning med Redate.io for å se hvor mange e-poster som er berørt på tvers av alle postbokser og gjenopprett riktige datoer.

Rett e-postdatoer etter Google Workspace-migrering