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

imapsync는 Google Workspace로 사서함을 마이그레이션할 때 가장 많이 사용되는 도구입니다. 오픈소스이고, 스크립트로 자동화할 수 있으며, 수천 건의 마이그레이션에서 검증되었습니다. 하지만 문제가 있습니다. Google Workspace의 IMAP 게이트웨이는 날짜 처리에 있어 표준 IMAP 서버처럼 작동하지 않습니다.

imapsync가 --syncinternaldates 플래그와 함께 표준 메일 전송 프로토콜을 통해 메시지를 업로드하면, Google에게 원본 서버의 원래 INTERNALDATE를 보존하도록 요청합니다. Google Workspace는 일부 메시지에 대해 이 요청을 수락하지만 다른 메시지에 대해서는 조용히 덮어씁니다. 덮어쓰기는 메시지가 Gmail의 내부 처리 파이프라인(스팸 필터, 규정 준수 검사, 헤더 유효성 검사)을 통과하는 방식에 따라 달라집니다. 각 단계에서 INTERNALDATE를 현재 타임스탬프로 재설정할 수 있습니다. 경고도, 오류 로그도, 날짜가 변경되었다는 표시도 없습니다.

하지만 INTERNALDATE는 문제의 절반에 불과합니다. Google Workspace는 업로드된 모든 메시지에 마이그레이션 날짜가 찍힌 새로운 Received 헤더도 추가합니다. 이 Received 헤더가 헤더 체인의 맨 위에 위치하며, 사서함을 읽는 모든 IMAP 클라이언트(Outlook, Apple Mail, Thunderbird)가 원래 날짜 대신 이 마이그레이션 타임스탬프를 표시합니다. 결과적으로 47,000통의 이메일이 모두 2025년 3월 15일에 도착한 것으로 보이는 사서함이 됩니다.

Google Workspace를 특히 기만적으로 만드는 것은 Gmail 웹 인터페이스가 표시에 Date 헤더를 사용한다는 것입니다. imapsync는 이것을 수정하지 않습니다. 그래서 관리자가 브라우저에서 Gmail을 확인하면 모든 곳에서 올바른 날짜가 보이고 마이그레이션이 성공했다고 가정합니다. 한편 Outlook으로 접속하는 200명의 직원은 동일한 날짜의 이메일 벽을 보고 있습니다. CFO에게 사서함의 모든 이메일이 왜 어제 날짜를 표시하는지 설명해 본 적이 있나요?

Gmail 대 IMAP의 분열은 같은 조직 내에 이중 현실을 만듭니다. Gmail 웹 인터페이스의 사용자는 아무 문제도 보지 못합니다. Outlook, Apple Mail 또는 모바일 IMAP 클라이언트의 사용자는 마이그레이션된 모든 이메일이 마이그레이션 날짜로 찍혀 있는 것을 봅니다. 팀원이 "지난 10월 그 이메일"을 언급하면 동료들은 사용하는 클라이언트에 따라 다른 날짜를 봅니다. 혼란이 전체 메일 시스템에 대한 불신으로 변합니다.

그리고 규정 준수 측면이 있습니다. 조직이 법적 보류와 eDiscovery를 위해 의존하는 Google Vault은 손상된 날짜에 대해 예측할 수 없게 작동합니다. 일부 Vault 검색은 Date 헤더를 참조하고 다른 것은 INTERNALDATE를 사용합니다. "2024년 1월에서 3월 사이의 모든 이메일"에 대한 법적 증거 수집 요청은 INTERNALDATE가 메시지가 2025년에 배달되었다고 표시하기 때문에 불완전한 결과를 반환할 수 있습니다. 규제 산업(의료, 금융, 법률)의 조직에게 이것은 불편이 아닙니다. 법적 책임입니다.

Redate.io는 도메인 전체 위임을 통해 Google Workspace에 연결하고 영향을 받은 사서함에 독자적인 보정 엔진을 실행합니다. 엔진은 다단계 헤더 분석을 수행하여 imapsync 마이그레이션 시그니처를 식별한 후, 실제 메시지 내용을 변경하지 않고 정밀 메타데이터 보정을 적용합니다. 수정된 모든 이메일은 원본이 백업 라벨로 이동되기 전에 개별 검증됩니다. 관리 대시보드는 모든 사서함의 진행 상황을 실시간으로 추적합니다. 50개 사서함이든 500개 사서함이든 동일하게 확장됩니다.