eM Client: PST 또는 Thunderbird 가져오기 후 날짜 오류

증상: 모든 이메일에 같은 날짜가 표시됩니다

eM Client에서 PST 가져오기를 막 완료했거나, Thunderbird에서 새 메일함으로 마이그레이션을 마쳤어요. 오류 없이 순조롭게 진행됐습니다. 그런데 받은편지함을 열었을 때 뭔가 이상합니다. 수백, 때로는 수천 개의 이메일이 모두 같은 날짜, 즉 가져오기를 실행한 당일 날짜를 표시하고 있어요. 2019년에 받은 이메일이 어제 도착한 것처럼 보이고, 3년 전에 서명한 계약서가 방금 들어온 것처럼 나타납니다.

처음에는 eM Client를 탓하게 됩니다. 잘못된 설정, 잘못된 정렬 열, 표시 버그... 환경설정을 뒤져봅니다. "수신 날짜"와 "발송 날짜" 사이를 오가며 바꿔봐도 달라지지 않아요. 정확히 말하면, 뭔가 바뀌긴 하는데 근본적인 문제는 해결되지 않습니다.

왜냐하면 문제가 eM Client에 있는 게 아니기 때문입니다. 문제는 서버 메타데이터에 있어요.

진짜 원인: 가져오기 과정에서 덮어써진 IMAP INTERNALDATE

무슨 일이 벌어지는지 이해하려면 한 단계 내려가서 IMAP 프로토콜이 이메일을 어떻게 저장하는지 살펴봐야 합니다.

IMAP 서버의 각 메시지에는 서로 다른 두 가지 날짜가 존재합니다.

• Date: 헤더 (RFC 2822 정의): 발신자가 메시지를 보낼 때 메시지 안에 기록한 날짜입니다. 메시지 본문에 캡슐화되어 있어 이론적으로 변경할 수 없어요.
• INTERNALDATE: 메시지 외부에 존재하는 서버 메타데이터로, 메시지가 메일함에 저장된 날짜를 나타냅니다. 메일 클라이언트가 이메일을 정렬하고 표시할 때 우선적으로 사용하는 값이 바로 이것입니다.

PST 가져오기나 Thunderbird에서의 마이그레이션 시, 가져오기 도구(eM Client 내장 모듈이든, 서드파티 도구든, 수동 IMAP 복사든)는 대상 IMAP 서버에 메시지를 저장합니다. 이때 도구가 저장 시점에 원본 INTERNALDATE를 명시적으로 보존하지 않으면, 서버는 자동으로 현재 날짜와 시간, 즉 가져오기가 실행된 시각을 INTERNALDATE로 할당합니다.

결과: 2017년부터 보관해온 이메일 8,000개 전부가 마이그레이션 시점에 "수신"된 것으로 표시됩니다.

(eM Client의 "소스 보기"로 이메일의 원시 헤더를 읽어본 적이 있다면, 원본 Date: 헤더가 여전히 온전히 남아 있다는 걸 확인했을 거예요. 이것이 바로 문제가 메시지 자체가 아니라 서버의 INTERNALDATE에 있다는 증거입니다.)

정렬 열을 바꿔도 소용없는 이유

혼란은 대부분의 사람들이 모르는 구분에서 비롯됩니다. eM Client에서도, Outlook이나 Thunderbird에서도, 날짜 열은 보통 두 가지가 있습니다.

• "수신 날짜" (또는 "도착 날짜"): 서버의 INTERNALDATE를 기반으로 합니다.
• "날짜" 또는 "발송 날짜": 메시지의 Date: 헤더를 기반으로 합니다.

많은 관리자들이 이걸 발견하고 해결책을 찾았다고 생각합니다. "발송 날짜"로 전환하면 eM Client에서는 시각적으로 문제가 사라지거든요. 그런데 정확히는 그렇지 않아요.

다시 말해, eM Client에서 발송 날짜로 정렬해도, 같은 메일함에 접근하는 다른 모든 클라이언트와 인터페이스에서는 문제가 그대로 남아 있습니다. 사용자들이 OWA에서, 사무실의 Outlook에서, 모바일의 Gmail 앱에서, 또는 IMAP으로 설정된 어떤 클라이언트에서든 이메일을 확인한다면, 가져오기 날짜를 보게 됩니다. eM Client의 정렬 설정은 eM Client에만 적용되며, 서버 측에 저장된 메타데이터에는 영향을 미치지 않습니다.

더불어 Microsoft 365와 Google Workspace의 웹 인터페이스는 기본적으로 INTERNALDATE로 정렬합니다. 클라이언트 측에서 이 동작을 바꿀 방법은 없어요.

발송 날짜 정렬은 해결책이 아닙니다. 실제 문제를 고치지 않고 덮어두는 임시방편일 뿐입니다.

PST 가져오기의 특수한 경우

PST 파일 가져오기는 별도로 설명할 필요가 있습니다. PST(Personal Storage Table) 파일은 이메일, 연락처, 캘린더를 로컬에 저장하는 Microsoft 전용 형식입니다. eM Client에서 PST를 가져올 때는 두 가지 시나리오가 가능합니다.

• IMAP 계정으로 가져오기: eM Client가 PST를 읽어 대상 IMAP 서버에 메시지를 올립니다. 저장 날짜가 보존되지 않으면 INTERNALDATE가 덮어써집니다. 가장 흔한 경우이며, 날짜가 손상되는 것도 바로 이 경우입니다.
• 로컬 폴더로 가져오기: 메시지가 서버 외부에, 로컬 머신에만 남아 있습니다. 이 컨텍스트에서는 INTERNALDATE가 존재하지 않고, eM Client가 메시지의 Date: 헤더를 표시할 수 있습니다. 날짜 문제는 덜하지만, 실용성도 떨어집니다.

Thunderbird의 경우도 비슷합니다. eM Client 내장 가져오기 기능(Thunderbird 프로필을 읽음)을 사용하거나, IMAP을 통해 mbox 폴더를 복사했다면, 메시지는 INTERNALDATE 보존 보장 없이 서버에 다시 저장됩니다. INTERNALDATE에 대한 명시적인 날짜 지시 없이 메시지를 수신한 서버는 수신 시각으로 타임스탬프를 자동으로 찍습니다.

어떤 플랫폼이 영향을 받나요?

IMAP 프로토콜의 표준 동작이기 때문에, 대상 플랫폼과 관계없이 문제는 동일하게 발생합니다.

• Microsoft 365 / Exchange Online: 날짜 파라미터를 명시한 IMAP APPEND 명령을 사용하지 않는 모든 가져오기에서 INTERNALDATE가 덮어써집니다. Exchange 온프레미스에서 마이그레이션할 때도 마찬가지입니다.
• Google Workspace: 동일한 동작입니다. eM Client나 서드파티 도구를 통해 가져온 이메일은 Gmail과 관리자 콘솔에서 가져오기 날짜를 표시합니다.
• 일반 IMAP 호스팅 (카페24, 가비아, 후이즈 등): APPEND로 수신한 메시지의 날짜를 특별히 처리하지 않습니다. INTERNALDATE는 저장 시각이 됩니다.

Exchange 2013에서 Microsoft 365로 약 100개의 메일함을 마이그레이션하면서 일부 VIP 계정의 전환 도구로 eM Client를 사용했다가 문의해온 고객이 있었습니다. MigrationWiz로 제대로 마이그레이션된 메일함은 정상이었지만, eM Client를 거친 메일함은 전부 가져오기 날짜가 찍혀 있었어요. 해당 사용자들의 반응이 좋지 않았음은 말할 것도 없습니다.

직접 만든 스크립트로 쉽게 해결할 수 없는 이유

IMAP 프로토콜을 이해하는 사람이라면 INTERNALDATE를 수정하는 스크립트를 작성하면 되지 않을까 생각할 수 있습니다. 원본 Date: 헤더는 각 메시지 안에 온전히 남아 있고, 그걸 읽어서 서버 메타데이터를 재구성하면 되는 것 아닌가요?

이론적으로는 그렇습니다. 실제로는, 지뢰밭입니다.

우선, 프로덕션 메일함에서는 예외 케이스가 빠르게 쌓입니다. S/MIME 디지털 서명 메시지는 구조 조작에 특히 민감합니다. PGP 암호화 메시지도 마찬가지예요. 용량이 큰 첨부파일이 있거나, 비표준 MIME 경계가 있거나, 비일반적인 Content-Transfer-Encoding이 사용된 이메일은 처리가 엄밀하지 않으면 조용히 손상될 수 있습니다. 테스트 이메일 50개에서 잘 작동하는 스크립트가 6년치 기록을 담은 이메일 20,000개짜리 메일함에서는 신뢰할 수 있게 작동하지 않아요.

다음으로 API 쿼터 관리 문제가 있습니다. Microsoft 365에서 새벽 3시에 8,000개 수정 배치 작업을 돌리다가 Graph API나 EWS에서 속도 제한에 걸리는 건 대처할 수 있는 문제입니다. 하지만 혼자 대처되지는 않아요. 감독 없이 돌아가는 스크립트가 3,741번째 메시지에서 429 Too Many Requests 오류를 만나면 계속 진행될 수도, 아닐 수도 있습니다. 어떤 메시지까지 처리됐는지 파악하지 못할 수도 있어요.

그리고 무엇보다: 처리 후 각 이메일이 온전한지 어떻게 검증할 건가요? 직접 만든 스크립트에는 보통 개별 검증 메커니즘이 없습니다. Redate.io는 이것을 각 메시지마다 자동으로 수행합니다.

Redate.io로 날짜를 근본부터 수정하기

Redate.io는 문제가 있는 곳, 즉 메일 클라이언트가 아닌 서버 메타데이터 수준에서 문제를 해결합니다.

먼저 무료 스캔 단계부터 시작합니다. Redate.io가 해당 메일함에 연결하고(Microsoft 365는 Azure AD, Google Workspace는 도메인 위임, 일반 호스팅은 IMAP 직접 연결) 메시지 내용과 날짜 메타데이터가 일치하지 않는 이메일을 식별합니다. 결제 전에 결과를 먼저 확인할 수 있습니다.

수정은 독자적인 엔진을 통해 이루어집니다. 각 메시지의 전체 헤더 체인을 분석하고, eM Client, Thunderbird, PST 가져오기의 특정 동작을 포함한 수백 가지 알려진 가져오기 도구 시그니처에 대한 패턴 매칭을 적용하며, 메시지 내용, 첨부파일, MIME 구조를 변경하지 않으면서 날짜 메타데이터를 정밀하게 재구성합니다.

수정된 각 이메일은 개별적으로 검증됩니다. 원본은 30일간 눈에 보이는 백업 폴더에 보관됩니다. 직접 만든 스크립트는 기본적으로 이런 기능이 없어요.

요금 체계는 단순합니다. 수정할 이메일 볼륨에 따른 메일함당 일회성 결제입니다. 구독도, 반복 요금도 없습니다. 자세한 내용은 시작 페이지에서 확인하세요.

다음 마이그레이션을 위해: 확인해야 할 사항

마이그레이션을 계획 중이고 이 문제를 사전에 방지하고 싶다면, 확인 포인트는 하나입니다. 사용하는 도구가 대상 서버에 메시지를 저장할 때 INTERNALDATE를 명시적으로 보존하나요?

Microsoft 365로의 PST 가져오기의 경우, Microsoft 공인 도구(기본 모드의 MigrationWiz나 Exchange Online 마이그레이션 도구 등)는 일반적으로 이 보존 처리를 수행합니다. eM Client나 Thunderbird를 통한 수동 가져오기는 대부분 그렇지 않습니다. 프로덕션 메일함에서 가져오기를 시작하기 전에 반드시 사용 중인 도구의 문서를 확인하세요.

좋은 이메일 마이그레이션 체크리스트에는 항상 마이그레이션 후 샘플 메일함에서 날짜를 확인하는 단계가 포함됩니다. 더 자세히 알고 싶다면 이메일 마이그레이션 체크리스트에서 이 부분을 상세히 다루고 있습니다.

고객사의 마이그레이션을 정기적으로 처리하는 관리자라면 MSP를 위한 이메일 날짜 문제 해결법과 IMAP INTERNALDATE 해설 글이 문제 전체를 파악하는 데 도움이 될 거예요.

eM Client 가져오기 후 이메일 날짜가 손상됐나요? Redate.io에서 무료 스캔을 시작해서 어떻게 할지 결정하기 전에 문제의 규모를 먼저 파악해 보세요.