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

imapsync는 IMAP 간 사서함 마이그레이션을 위한 대표적인 도구이며, 그럴 만한 이유가 있습니다. 폴더 매핑, 플래그 보존, 증분 동기화를 대부분의 대안보다 잘 처리합니다. 하지만 대상이 Gmail인 경우, 경험 많은 시스템 관리자도 놀랄 만큼 날짜 보존이 불안정해집니다.

--syncinternaldates 플래그가 이 문제를 해결해야 합니다. 이 플래그는 imapsync에게 APPEND 시 원본 메시지의 INTERNALDATE를 대상 서버에 전달하도록 지시합니다. 표준 IMAP 서버에서는 작동합니다. Gmail에서는요? 항상 그렇지는 않습니다. Gmail의 IMAP 구현은 수신 메시지를 자체 내부 처리 파이프라인(스팸 필터링, 보안 스캔, 콘텐츠 인덱싱)을 통해 실행합니다. 이 처리 중에 Gmail이 요청된 INTERNALDATE를 덮어쓰고 업로드 타임스탬프를 대신 찍을 수 있습니다. 또한 업로드 시점의 날짜가 기록된 Received 헤더(일반적으로 "gmailapi.google.com" 또는 IMAP 게이트웨이 식별자 포함)도 추가합니다.

정말 짜증나는 부분은 이것이 모든 메시지에 일어나는 것이 아니라는 것입니다. 마이그레이션된 사서함의 일부 이메일은 올바른 INTERNALDATE를 받습니다. 다른 것들은 업로드 날짜를 받습니다. 명확한 패턴이 없습니다. 2018년 메시지는 괜찮은데 바로 옆의 같은 날 메시지는 마이그레이션 날짜가 찍혀 있을 수 있습니다. 결국 이메일의 30-70%가 잘못된 날짜를 가지며 폴더와 시간대에 걸쳐 무작위로 흩어진 사서함이 됩니다.

규정 준수 담당자에게 11,000통의 마이그레이션된 이메일 중 4,200통이 잘못된 수신 날짜를 표시하지만 나머지 6,800통은 괜찮은 이유를 설명해 본 적이 있나요? 그 패턴을 찾는 것은 행운을 빕니다.

Gmail 웹 인터페이스는 사실 문제를 감춥니다. Gmail 웹은 INTERNALDATE가 아닌 Date 헤더 값을 표시하므로 대부분의 영향을 받은 이메일이 브라우저에서 정상적으로 보입니다. 이것은 위험한 잘못된 안전감을 만듭니다. 마이그레이션 관리자가 Gmail 웹을 확인하고 올바른 날짜를 보고 티켓을 닫습니다.

그런 다음 사용자가 Outlook, Apple Mail, Thunderbird를 새 Gmail 계정에 연결하기 시작합니다. 이 클라이언트들은 날짜 열에 IMAP INTERNALDATE를 읽습니다. 갑자기 무작위 이메일이 마이그레이션 날짜를 표시하고 다른 것들은 올바른 날짜를 보여줍니다. Gmail 웹과 데스크톱 클라이언트 간의 불일치가 혼란스러운 지원 티켓을 생성합니다. 서버 측 IMAP 검색 명령(SEARCH SINCE, SEARCH BEFORE)은 INTERNALDATE를 참조하여 불완전하거나 부정확한 결과를 반환합니다. IMAP을 통해 아카이빙하는 서드파티 백업 도구는 손상된 날짜를 영구적으로 캡처합니다. Google Vault 및 Workspace 규정 준수 도구는 날짜 기반 보류에 INTERNALDATE를 참조하여 법적 증거 수집에 잠재적으로 영향을 미칠 수 있습니다. Redate.io의 마이그레이션 도구 시그니처 패턴 매칭은 날짜 손상을 나타내는 특정 Gmail Received 헤더를 식별한 다음, 모든 라벨, 별표, 읽음/안 읽음 상태를 보존하면서 영향을 받은 모든 메시지에 정밀 메타데이터 보정을 적용합니다.