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

imapsync로 Microsoft 365에 마이그레이션하는 것은 합리적으로 들립니다. 무료이고, 스크립트로 자동화할 수 있으며, 대부분의 시나리오에서 IMAP 간 전송을 잘 처리합니다. 하지만 Microsoft 365에서는, 세부적인 사항 하나가 모든 이메일이 갖게 되는 날짜를 결정합니다.

Exchange Online은 전달받은 날짜를 그대로 유지합니다. imapsync가 IMAP으로 메시지를 쓸 때 각 이메일의 내부 날짜를 함께 전달하며(--syncinternaldates는 기본으로 켜져 있습니다), 복사본은 그 날짜를 그대로 유지합니다. 다만 imapsync가 전달하는 것은 소스 서버가 각 메시지에 대해 가지고 있는 날짜이며, 이메일이 실제로 발송된 날짜가 아닙니다. 정상적인 메일함이라면 둘은 일치합니다. 하지만 이미 한 번 마이그레이션되었거나 백업에서 복원된 메일함이라면, 소스 서버는 그 이전 작업의 날짜를 가지고 있을 수 있고, imapsync는 그 날짜를 그대로 복사합니다.

이것은 Microsoft 365나 imapsync의 버그가 아닙니다. 각 복사본은 부여받은 날짜를 그대로 유지합니다. 원래 날짜가 원본에서 이미 잘못되어 있었다면, 500통이든 500,000통이든 마이그레이션하든 영향을 받은 모든 이메일은 받은 날짜 대신 그 이전 작업의 날짜를 표시합니다.

주말에 실행한 마이그레이션이 6년치 이메일 기록을 단일 날짜로 평탄화시켰다고 IT 이사에게 말하는 상황을 상상해 보세요. 이것이 imapsync로 Microsoft 365에 마이그레이션한 후 관리자가 직면하는 현실입니다. 그리고 Gmail 웹 클라이언트가 문제를 감출 수 있는 Google Workspace와 달리, Microsoft 365는 모든 곳에서 잘못된 날짜를 표시합니다. Outlook 데스크톱, OWA, Outlook 모바일, Microsoft Search 모두요. 클라이언트 측 도피구가 없습니다.

Microsoft 365에서 피해는 전면적이고 가시적입니다. 모든 클라이언트(Windows용 Outlook, Mac용 Outlook, OWA, iOS 및 Android의 Outlook 모바일)가 마이그레이션 타임스탬프를 표시합니다. 사용자는 날짜별 정렬이 불가능하고, 시간순으로 이메일을 찾을 수 없으며, 날짜 범위로 필터링하는 검색 결과를 신뢰할 수 없습니다. 80,000통의 이메일이 모두 "2024년 11월 12일"을 표시하는 사서함은 일상 업무에 사실상 쓸모가 없습니다.

규정 준수 관련 영향은 더 심각합니다. Exchange Online Protection, Microsoft Purview 및 보존 정책 모두 잘못된 배달 타임스탬프를 인덱싱합니다. 7년 이상된 이메일을 삭제하도록 설정된 보존 정책은 잘못된 날짜를 기반으로 작동합니다. 삭제 대상이 되어야 할 2018년 이메일이 이제 2024년 이메일로 표시됩니다. GDPR, HIPAA 또는 SEC 규정 대상 조직은 이메일 보존을 신뢰할 수 없을 때 실질적인 규제 노출에 직면합니다. 그리고 "2023년 3분기 모든 이메일"에 대한 법적 보류 요청이 들어오면 잘못된 날짜 때문에 Purview는 아무것도 반환하지 않습니다. 메타데이터에 따르면 해당 기간의 이메일이 존재하지 않기 때문입니다.

Redate.io는 Microsoft 365에 연결하여 영향을 받은 각 메시지에 헤더 체인 분석과 날짜 메타데이터 재구성 프로세스를 적용합니다. 어떤 도구가 마이그레이션을 수행했는지는 알 필요가 없습니다. 표시된 날짜가 원래 날짜와 일치하지 않는 이메일을 찾아냅니다. 각 메시지는 수정되고 개별 검증되며, 원본은 백업 폴더에 보존됩니다. 사서함 크기에는 제한이 없으며, 이메일이 아무리 많아도 동일하게 처리됩니다.