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

imapsync로 Microsoft 365에 마이그레이션하는 것은 합리적으로 들립니다. 무료이고, 스크립트로 자동화할 수 있으며, 대부분의 시나리오에서 IMAP 간 전송을 잘 처리합니다. 하지만 Exchange Online은 "대부분의 시나리오"에 해당하지 않습니다.

Exchange Online의 IMAP 게이트웨이는 EWS와 MAPI용으로 설계된 시스템 위에 덧대어진 호환성 레이어입니다. imapsync가 이 게이트웨이를 통해 표준 메일 전송 프로토콜로 메시지를 밀어 넣으면, 메시지는 인터넷에서 수신 메일을 처리하는 것과 동일한 Exchange Online의 전체 전송 파이프라인에 진입합니다. 그 파이프라인은 전송 헤더를 추가하고, 데이터 손실 방지(DLP) 검사를 실행하고, 규정 준수 규칙을 적용하며, 메시지가 서버에 도달한 정확한 시점의 새로운 Received 헤더를 추가합니다. --syncinternaldates 플래그요? Exchange Online의 전송 파이프라인은 이것을 무시합니다. INTERNALDATE는 배달 타임스탬프와 일치하도록 덮어쓰여집니다.

이것은 Microsoft가 수정할 계획인 버그가 아닙니다. Exchange Online의 아키텍처가 작동하는 방식입니다. 전송 파이프라인은 모든 표준 메일 전송 프로토콜 APPEND를 새 메시지 배달로 처리합니다. 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에 연결하여 영향을 받은 각 메시지에 헤더 체인 분석과 날짜 메타데이터 재구성 프로세스를 적용합니다. imapsync 특유의 마이그레이션 도구 시그니처 패턴 매칭으로 마이그레이션 중 주입된 Received 헤더와 원래 배달 체인에 속하는 헤더를 구분합니다. 각 메시지는 수정되고 개별 검증되며, 원본은 백업 폴더에 보존됩니다. Enterprise 플랜은 사서함당 최대 100,000통의 이메일을 처리하며, 관리자는 하나의 대시보드에서 여러 사서함을 처리할 수 있습니다.