Google Workspace에서 BitTitan MigrationWiz 마이그레이션 날짜 수정

BitTitan MigrationWiz는 Gmail API 또는 IMAP을 통해 Google Workspace로 이메일을 업로드합니다. 업로드 과정에서 Google의 메일 인프라는 삽입 타임스탬프를 메시지의 INTERNALDATE로 기록합니다. BitTitan은 또한 마이그레이션 날짜가 찍힌 Received 헤더를 추가합니다. 이메일 본문 내의 원래 Date 헤더는 그대로 유지되지만, INTERNALDATE는 마이그레이션 타임스탬프로 덮어쓰여집니다.

그런데 Google Workspace는 다른 플랫폼과 다르게 작동합니다. Gmail 웹 인터페이스는 표시용으로 Date 헤더를 읽기 때문에 브라우저에서 이메일을 확인하면 날짜가 정상적으로 보입니다. 하지만 IMAP INTERNALDATE는 마이그레이션 날짜로 영구적으로 설정됩니다. 해당 Google Workspace 계정에 연결하는 모든 IMAP 클라이언트, 즉 Outlook, Thunderbird, Apple Mail에서는 INTERNALDATE를 읽어 마이그레이션 날짜를 대신 표시합니다.

이것은 매우 혼란스러운 이중 날짜 문제를 만듭니다. 같은 이메일이 웹 Gmail에서는 정확한 날짜를 보여주지만 같은 계정에 연결된 Outlook에서는 잘못된 날짜를 보여줍니다. IT 관리자에게는 상반된 보고가 들어옵니다. "내 이메일은 정상이에요." "내 이메일이 전부 잘못됐어요." 두 사용자 모두 맞는 말을 하고 있습니다. 단지 다른 클라이언트를 사용하고 있을 뿐입니다.

예를 들면 이런 상황입니다. MigrationWiz를 사용해 온프레미스 Exchange에서 Google Workspace로 85개 사서함을 마이그레이션했습니다. 팀의 절반은 Gmail 웹 인터페이스를 사용하고 아무 문제도 느끼지 못합니다. 나머지 절반은 IMAP을 통해 Outlook을 사용하며 하루 아침에 85건의 지원 티켓을 제출합니다. MigrationWiz 콘솔이나 Gmail 관리 패널에서는 문제가 보이지 않기 때문에 진단하는 데 수 시간이 걸립니다.

이중 날짜 문제는 여러 클라이언트를 통해 메일에 접근하는 조직에서 가장 큰 타격을 줍니다. Gmail 웹은 정상적으로 보입니다. Outlook은 깨져 보입니다. Apple Mail도 깨져 보입니다. 모바일 IMAP 클라이언트도 마찬가지입니다. 오직 웹 인터페이스만 문제를 감추고 있습니다.

하지만 문제는 화면 표시보다 더 깊습니다. Google Vault(법적 보존 및 eDiscovery에 사용되는 규정 준수 및 아카이빙 솔루션)은 특정 작업에서 INTERNALDATE를 참조합니다. 날짜 기반 법적 증거 수집 검색이 부정확한 결과를 반환할 수 있습니다. IMAP을 통해 연결하는 서드파티 백업 도구는 마이그레이션 날짜를 메시지 날짜로 아카이빙하여 백업 기록에 영구적인 부정확성을 만듭니다. Gmail 자체의 IMAP SEARCH DATE 명령도 Date 헤더가 아닌 INTERNALDATE를 사용합니다.

Redate.io는 이메일 내용이나 첨부 파일을 건드리지 않고 INTERNALDATE와 마이그레이션 헤더를 수정하는 다단계 헤더 분석 파이프라인을 통해 이 문제를 해결합니다. Gmail 웹 경험(이미 정상적으로 표시되던)은 변경 없이 유지되고, IMAP 클라이언트, Vault, 백업 도구 모두 올바른 날짜를 읽게 됩니다. 마이그레이션 도구 시그니처에 대한 패턴 매칭으로 BitTitan이 주입한 헤더만 정확히 대상으로 합니다.