Google Workspace에서 CloudM Migrate 마이그레이션 날짜 수정

CloudM Migrate는 특히 Exchange 환경에서 Google Workspace로 사서함을 이전할 때 가장 많이 사용되는 도구 중 하나입니다. 마이그레이션 중 CloudM은 Gmail API를 통해 각 메시지를 업로드합니다. 문제는 Google의 메일 인프라가 업로드된 모든 메시지에 마이그레이션이 발생한 정확한 시점이 기록된 자체 Received 헤더를 추가한다는 것입니다. 이메일이 원래 발신되거나 수신된 날짜가 아닙니다.

여기서 상황이 이상해집니다. Gmail 웹 인터페이스는 표시 목적으로 원본 Date 헤더를 읽기 때문에 브라우저에서 이메일이 완벽하게 정상적으로 보입니다. 하지만 모든 IMAP 클라이언트(Outlook, Apple Mail, Thunderbird)는 대신 INTERNALDATE 값을 읽습니다. 이 값은 마이그레이션 타임스탬프를 반영합니다. 결국 이중 현실이 펼쳐집니다. 사용자의 절반은 전혀 문제가 없다고 보고하고, 나머지 절반은 모든 이메일이 같은 날짜를 표시한다고 주장합니다.

이것이 IT 헬프데스크 티켓에 어떤 영향을 미치는지 생각해 보세요. 관리자가 브라우저에서 Gmail을 열면 올바른 날짜가 보여서 "재현 불가"로 티켓을 닫습니다. 한편 Outlook 사용자는 47,000통의 이메일이 모두 3월 15일로 표시되는 것을 보고 있습니다. Gmail 웹과 IMAP 클라이언트 간의 이런 불일치 때문에 CloudM에서 Google Workspace로의 마이그레이션은 진단이 특히 까다로우며, 종종 수 주 동안 해결이 지연됩니다.

피해는 혼란스러운 사용자를 넘어섭니다. Google Workspace 관리 도구는 정책 시행에 INTERNALDATE를 참조합니다. Google Admin Console에서 구성한 보존 정책, Google Vault 법적 보류, IMAP을 통해 연결하는 서드파티 DLP 솔루션 모두 실제 날짜 대신 마이그레이션 타임스탬프를 기반으로 작동합니다. 3년 보존 정책에 따라 삭제되었어야 할 2019년 이메일이 있다면? Google Workspace는 지난달에 도착한 것으로 인식합니다.

규제 산업(의료, 금융, 법률)에 속한 조직에게 이것은 단순한 불편이 아닙니다. 정확한 이메일 날짜 범위에 의존하는 규정 준수 감사가 신뢰할 수 없는 결과를 생성합니다. 그리고 이 문제는 무기한 지속됩니다. 자동 수정도 없고, 만료도 없고, 자체 복구도 없습니다. 영향을 받은 모든 Google Workspace 사서함에 연결된 모든 IMAP 클라이언트는 기본 메타데이터가 서버 수준에서 수정될 때까지 계속 잘못된 날짜를 표시합니다.