Outlook에서 Exchange IMAP 마이그레이션 날짜 수정

Microsoft의 자체 IMAP 마이그레이션 도구(Exchange Admin Center와 PowerShell을 통해 이용 가능)는 Exchange Online으로 사서함을 가져오는 안전하고 공식적인 방법으로 여겨집니다. 관리자는 Microsoft의 자사 도구이기 때문에 신뢰합니다. 그래서 마이그레이션된 모든 이메일이 Outlook에서 원래 날짜 대신 마이그레이션 날짜를 표시하면 반응은 대개 당혹감입니다.

내부적으로는 이렇게 작동합니다. Exchange의 IMAP 마이그레이션은 원본 서버에서 각 메시지를 다운로드하고 전송 파이프라인을 통해 대상 Exchange 사서함으로 공급합니다. 그 파이프라인은 수신 메일에 대해 항상 하는 일을 합니다. 현재 처리 타임스탬프가 포함된 Received 헤더를 추가하고 PR_MESSAGE_DELIVERY_TIME 속성을 그에 맞게 설정합니다. 원본 서버의 원래 IMAP INTERNALDATE는 폐기됩니다. 전달되지 않습니다. 시도조차 되지 않습니다.

결과적으로 마이그레이션된 사서함의 모든 이메일은 2012년에 보냈든 2025년에 보냈든 Outlook의 "받은 날짜" 열에 마이그레이션 날짜를 표시합니다. 관리자를 가장 좌절시키는 부분이 있습니다. Exchange의 마이그레이션 문서는 이 동작을 거의 언급하지 않습니다. 500명의 사용자가 월요일 아침에 Outlook을 열고 받은 편지함이 이상해 보인다고 헬프데스크 티켓을 제출할 때 알게 됩니다.

Outlook의 "받은 날짜" 열은 모든 이메일에 대해 마이그레이션 타임스탬프를 표시합니다. 보낸 편지함도 마찬가지입니다. Exchange가 업로드 중 보낸 메시지도 동일한 파이프라인을 통해 처리하기 때문입니다. 회의 관련 이메일(초대장, 참석 확인, 취소)도 마이그레이션 날짜를 가지고 있어 과거 달력 일정의 타임라인을 왜곡합니다.

그런데 진짜 피해는 검색과 자동화에 있습니다. Outlook의 검색창은 Exchange의 서버 측 인덱스를 사용하며, 이 인덱스는 손상된 배달 시간을 참조합니다. 날짜 필터 검색이 잘못된 결과를 반환합니다. 수명 기반으로 이메일을 이동하거나 삭제하는 자동 보관은 모든 메시지가 새것이라고 판단하여 아무것도 보관하지 않습니다. 수신 날짜 기반 규칙이 오작동합니다. 수명별로 이메일에 색상을 입히는 조건부 서식 규칙(높은 이메일 처리량을 다루는 파워 유저 사이에서 흔한 관행)이 완전히 작동을 멈춥니다. 200명 규모의 조직이라면 200개의 깨진 받은 편지함, 200개의 깨진 검색 경험, 그리고 이메일 클라이언트가 실제로 언제 일어났는지 보여주는 것을 더 이상 믿을 수 없는 200명의 사람입니다.