Gmail에서 GSMMO 마이그레이션 날짜 수정

GSMMO(Google Workspace Migration for Microsoft Outlook)는 PST 파일이나 Outlook 프로필에서 Gmail API를 통해 직접 Gmail로 이메일을 업로드합니다. 이 업로드 과정에서 Gmail은 업로드 타임스탬프를 각 메시지의 INTERNALDATE로 기록합니다. 이메일 본문의 원본 Date 헤더는 보존되지만, 서버 수준의 날짜 메타데이터는 마이그레이션 날짜로 덮어쓰여집니다.

이것은 기만적인 상황을 만듭니다. Gmail 웹 인터페이스는 이메일 본문의 Date 헤더를 표시 날짜로 읽기 때문에 브라우저에서 대부분의 이메일이 올바른 날짜를 가진 것으로 보입니다. 모든 것이 정상으로 보입니다. 하지만 내부적으로 Google 서버에 저장된 IMAP INTERNALDATE는 잘못되어 있습니다. 이것이 언제 문제가 될까요? 누군가 Outlook, Thunderbird, Apple Mail 같은 IMAP 클라이언트를 통해 해당 사서함에 접근하거나, 백업 도구, 규정 준수 시스템, 아카이빙 솔루션이 IMAP을 통해 사서함을 쿼리할 때입니다.

GSMMO는 일반적으로 Microsoft Outlook에서 Google Workspace로 전환하는 최종 사용자가 Google의 자체 마이그레이션 문서에 따라 사용합니다. 이 사용자들은 주로 Gmail 웹 인터페이스를 사용하기 때문에 수 주 또는 수개월 동안 문제를 인지하지 못할 수 있습니다. 그러다 어느 날 규정 준수 팀이 Google Vault를 통해 날짜 기반 검색을 실행하거나, IT 부서가 아카이빙용 MailStore를 설정하거나, 사용자가 IMAP을 통해 Gmail에 연결된 Outlook을 설치합니다. 갑자기 40,000통의 이메일이 모두 6개월 전의 같은 날짜를 표시합니다. 그때쯤이면 마이그레이션은 이미 오래 전 일처럼 느껴지고, 근본 원인을 진단하는 것이 퍼즐이 됩니다.

Gmail 웹 사용자에게 시각적 영향은 기만적으로 적습니다. 브라우저에서 날짜가 올바르게 보입니다. 하지만 손상된 INTERNALDATE는 표면 아래에서 시한폭탄과 같습니다. Gmail의 IMAP SEARCH DATE 명령은 INTERNALDATE를 사용하므로 사서함에 대해 날짜 검색을 수행하는 모든 IMAP 기반 도구가 잘못된 결과를 얻습니다. MailStore, Veeam 또는 IMAP을 통해 Gmail을 아카이빙하는 커스텀 Python 스크립트 같은 백업 도구는 잘못된 날짜를 기록합니다. 그 백업은 영구적으로 부정확해집니다.

50,000통의 이메일이 모두 같은 수신 날짜를 공유하는 상태에서 정렬을 시도해 본 적이 있나요? GSMMO로 마이그레이션된 사서함에 연결된 모든 IMAP 클라이언트가 경험하는 상황입니다. Outlook, Apple Mail, Thunderbird 모두 정렬과 표시에 INTERNALDATE를 읽습니다. Google Takeout 내보내기도 파일 이름과 메타데이터에 INTERNALDATE를 참조하여 혼란스러운 아카이브 구조를 만들 수 있습니다. Google Vault 규정 준수 검색도 INTERNALDATE가 실제 이메일 날짜와 일치하지 않으면 오해의 소지가 있는 결과를 반환할 수 있습니다.

Redate.io는 GSMMO 마이그레이션 시그니처를 식별하고 서버 수준에서 날짜 메타데이터 재구성을 수행하는 다단계 헤더 분석 파이프라인을 통해 이 문제를 해결합니다. 프로세스는 날짜 메타데이터만 수정하면서 모든 메시지 내용, 라벨 및 첨부 파일을 보존합니다. 각 메시지는 처리 후 개별적으로 검증됩니다.