cPanel 마이그레이션 이메일 날짜 오류

월요일 아침의 악몽

cPanel 공유 호스팅에서 Google Workspace 또는 Microsoft 365로 마이그레이션을 막 완료했습니다. 작업은 순조롭게 끝났고, 사서함은 정상적으로 접근되며, 사용자들도 로그인했습니다. 그런데 오전 9시 15분쯤, 첫 번째 티켓이 날아옵니다. "오래된 이메일들이 전부 지난 주말 날짜로 표시돼요." 그리고 두 번째, 세 번째... 열 번째까지.

이건 단순한 버그가 아닙니다. cPanel에서 마이그레이션할 때 이메일의 날짜 메타데이터를 제대로 처리하지 않아서 생기는 직접적인 결과입니다.

cPanel, Roundcube, Horde: 특수한 IMAP 환경

cPanel 공유 호스팅은 Dovecot IMAP 서버 위에 Roundcube나 Horde를 웹메일 인터페이스로 얹은 Linux 서버입니다. 구성 자체는 평범합니다. 하지만 엔터프라이즈 플랫폼으로 마이그레이션할 때는 생각보다 훨씬 까다로운 특성이 있습니다.

우선, cPanel 사서함에는 수년, 심지어 10년치 이메일이 쌓여 있는 경우가 많습니다. 2013년부터 공유 호스팅을 사용해 온 고객이라면 방대한 아카이브를 갖고 있을 수 있어요. 이 방대한 양과 마이그레이션 방식이 맞물리면, 날짜 문제가 발생하기 딱 좋은 환경이 만들어집니다.

사용되는 도구도 다양합니다. WHM의 내장 마이그레이션 도구, 명령줄에서 실행하는 imapsync, 또는 Google Workspace로 마이그레이션할 때 사용하는 GSMMO 같은 일반 솔루션이 있습니다.

cPanel 마이그레이션 후 날짜가 깨지는 이유

문제를 이해하려면 두 가지 개념을 구분해야 합니다. 이메일의 Date: 헤더와 IMAP의 INTERNALDATE입니다.

Date: 헤더는 이메일이 전송될 때 RFC 2822 규격에 따라 메시지 원문에 기록됩니다. 이메일이 언제 작성되고 발송됐는지를 나타내며, 의도적으로 메시지를 조작하지 않는 한 절대 변하지 않습니다.

반면 INTERNALDATE는 IMAP 서버가 저장된 각 메시지에 연결하는 메타데이터입니다. 메시지 내용과는 별개입니다. 이메일이 서버에 정상적으로 도착하면, INTERNALDATE는 메시지의 Received: 헤더나 직접 제출 시각을 기준으로 설정됩니다. Outlook, Thunderbird, 그리고 대부분의 메일 클라이언트는 바로 이 값으로 메시지를 정렬합니다.

IMAP 마이그레이션 중에는 메시지가 한 서버에서 다른 서버로 복사됩니다. 문제는 마이그레이션 도구가 대상 서버에 각 메시지를 새로 생성해야 한다는 점입니다. 많은 도구에서 새로 생성된 메시지의 INTERNALDATE는 원본 메시지의 날짜가 아니라 마이그레이션 실행 날짜로 설정됩니다. 동시에 마이그레이션 날짜로 타임스탬프가 찍힌 Received: 헤더가 헤더 체인 맨 앞에 추가되어, 이를 참조해 표시 날짜를 계산하는 메일 클라이언트를 더욱 혼란스럽게 만듭니다.

결과는 이렇습니다. 2019년 이메일이 마이그레이션 날짜로 INTERNALDATE가 설정되고, 어제 날짜의 Received: 헤더를 달고 Google Workspace에 도착합니다. Outlook은 이 메일을 방금 받은 것처럼 받은 편지함에 표시합니다. 아카이브의 모든 시간 순서가 무너지는 거죠.

WHM / cPanel 마이그레이션 도구

WHM에 내장된 cPanel 계정 마이그레이션 도구는 외부 IMAP 서버(Google Workspace, Microsoft 365)로 마이그레이션할 때 이 문제를 거의 필연적으로 일으킵니다. Maildir 내용을 IMAP APPEND로 새 서버에 복사하면서 원본 INTERNALDATE를 보존하지 않기 때문입니다. 각 메시지는 작업 시점의 타임스탬프를 그대로 받게 됩니다.

cPanel에서 imapsync를 이용한 수동 마이그레이션

imapsync는 강력한 도구이지만, 기본 설정으로는 날짜를 항상 보존하지 않습니다. 올바른 파라미터(와 적합한 버전) 없이는 4만 개의 메시지를 스크립트 실행 날짜로 모두 복사할 수 있습니다. (25,000개 메시지가 담긴 사서함에서 날짜 문제를 진단하려고 imapsync 로그를 한 줄씩 뒤진 경험이 있다면, 두 번 다시 겪고 싶지 않은 일이라는 걸 아실 거예요.)

정확히 말하면, imapsync에는 날짜 보존을 시도하는 옵션이 있습니다. 하지만 이 옵션은 소스 서버와 대상 서버에 따라 동작이 달라지며, 모든 cPanel / Dovecot 구성에서 효과가 보장되지는 않습니다.

GSMMO 및 일반 마이그레이션 도구

Google Workspace Migration for Microsoft Outlook(GSMMO)은 원래 Outlook에서 마이그레이션하도록 설계된 도구입니다. Outlook에 IMAP 계정으로 cPanel을 추가해서 마이그레이션하는 방식을 쓰면, 날짜도 동일한 문제를 겪습니다. Google Workspace의 INTERNALDATE가 마이그레이션 날짜로 설정되는 것이죠. GSMMO 마이그레이션 후 이메일 날짜 오류 수정 방법에서 이 문제를 별도로 다루고 있을 만큼 매우 흔한 사례입니다.

어떤 메일 클라이언트가 영향을 받나요?

날짜 오류는 사용하는 클라이언트에 따라 다르게 나타납니다.

Outlook이 가장 크게 영향을 받습니다. Outlook은 폴더 정렬의 기준으로 INTERNALDATE(또는 마이그레이션 Received: 헤더)를 사용합니다. cPanel 마이그레이션이 잘못 처리되면, Outlook 사서함의 수천 개 아카이브 이메일이 마이그레이션 주말 날짜로 표시될 수 있습니다. Outlook에서 imapsync 마이그레이션 날짜 수정은 가장 많이 요청되는 수정 작업 중 하나입니다.

Gmail(Google Workspace)은 대체로 이메일 목록에서 Date: 헤더의 날짜를 표시합니다. 하지만 경우에 따라 INTERNALDATE가 정렬에 영향을 줄 수 있고, 날짜 기준 검색과 정렬에서 예상치 못한 동작이 나타난다는 사용자 보고도 있습니다.

Apple Mail과 Thunderbird는 좀 더 복잡한 동작을 보이지만, 특히 마이그레이션 Received: 헤더가 체인 맨 앞에 있을 때는 두 클라이언트 모두 문제를 피하지 못합니다.

좋은 소식: 원본 날짜는 여전히 그대로 있습니다

모든 것을 바꾸는 기술적 핵심이 바로 여기 있습니다. 메시지의 원본 Date: 헤더는 이메일 원문에 기록되어 있습니다. 마이그레이션이 이 값을 건드리지 않습니다. 영향받은 이메일을 열고 원본 헤더를 확인해 보세요(Gmail에서는 "원본 보기", Outlook에서는 파일 > 속성). 원본 Date:가 온전히 남아 있고, 그 뒤에 마이그레이션 날짜가 찍힌 하나 이상의 Received: 헤더가 이어지는 것을 볼 수 있습니다.

이 정보는 항상 존재합니다. 그리고 이를 활용해 메타데이터를 수정할 수 있습니다. 바로 그게 Redate.io의 수정 엔진이 하는 일입니다.

"직접 수정"이 생각보다 위험한 이유

유혹은 충분히 이해합니다. 문제가 단순해 보이니까요. 원본 날짜를 읽고, 메타데이터를 수정하고, 다음 메시지로 넘어가면 끝일 것 같습니다. 하지만 메커니즘을 이해하는 것과, 프로덕션 환경에서 12,000개의 이메일을 단 하나도 잃지 않고 수정하는 것 사이에는 엄청난 차이가 있습니다.

직접 만든 스크립트가 보통 처리하지 못하는 현실들입니다:

S/MIME 서명 또는 PGP 암호화 이메일: 메시지 구조를 수정하면 암호화 서명이 무효화됩니다. 수정 전에는 서명 검증을 통과하던 이메일이 수정 후에는 통과하지 못합니다. 법무법인, 금융, 의료 등 규정 준수가 필요한 환경에서는 최악의 순간에 이 사실을 발견하게 됩니다.
비ASCII 헤더와 RFC 2047 인코딩: cPanel 사서함에는 다양한 메일 클라이언트에서 온 수년치 이메일이 쌓여 있습니다. 일부 헤더는 RFC 2047 방식으로 인코딩된 문자를 포함합니다. 헤더를 재구성하는 스크립트가 잘못 작성되어 있으면 이 인코딩을 눈에 보이지 않게 손상시킬 수 있습니다.
중첩된 MIME 구조: 세 개의 첨부 파일과 HTML 대체 본문이 있는 이메일은 복잡한 multipart 구조를 가집니다. MIME 경계에서 사소한 오류가 발생하면 메시지를 읽을 수 없게 되거나, 더 나쁜 경우 오류 메시지도 없이 첨부 파일이 사라집니다.
API 할당량과 속도 제한: Google Workspace와 Microsoft 365는 분당 IMAP 작업 수에 엄격한 제한을 둡니다. 지수적 백오프를 제대로 구현하지 않은 스크립트는 새벽 3시에 429 오류를 유발하고, 마이그레이션이 어디서 멈췄는지도 모른 채 절반만 완료된 상태로 아침을 맞이하게 됩니다.
롤백 불가: 중간에 문제가 생기면 어떤 상태로 돌아가야 할까요? 원본은 아직 있나요? 중복 메시지가 생겼나요? Redate.io는 정확히 이런 상황을 피하기 위해 원본을 30일 동안 눈에 보이는 백업 폴더에 보관합니다.

개발 환경에서 테스트 이메일 50개로 잘 돌아가는 스크립트가, 2011년부터 cPanel 호스팅을 사용해 온 사서함의 18,000개 프로덕션 메시지에서도 잘 동작한다는 보장은 없습니다.

Redate.io가 cPanel 마이그레이션 후 날짜를 수정하는 방법

Redate.io는 대상 사서함에 직접 연결합니다(Google Workspace는 도메인 위임, Microsoft 365는 Azure AD, 또는 직접 IMAP 서버). 먼저 무료 스캔을 통해 원본 Date: 헤더와 날짜 메타데이터가 일치하지 않는 이메일을 찾아냅니다.

이후 다단계 분석 파이프라인이 Received: 헤더 서명에 대한 패턴 매칭을 적용해 마이그레이션 도구가 삽입한 헤더를 식별하고(정상적인 헤더와 구분), 메시지 내용을 변경하지 않고 메타데이터를 정밀하게 수정합니다. 텍스트, 첨부 파일, 원본 헤더, 모든 것이 그대로 유지됩니다. 수정된 이메일은 작업이 확정되기 전에 개별적으로 검증됩니다.

특히 cPanel 마이그레이션의 경우, 수정 엔진은 Dovecot-to-IMAP 마이그레이션과 imapsync 스크립트의 전형적인 서명을 인식합니다. 한국 및 유럽의 공유 호스팅 업체에서 흔히 쓰이는 설정 변형도 포함해서요.

마이그레이션 대상 플랫폼별 가이드

cPanel 마이그레이션의 대상 플랫폼에 따라 아래 가이드에서 구체적인 단계를 확인할 수 있습니다:

cPanel에서 마이그레이션한 후 사용자들이 잘못된 날짜를 보고 있나요? Redate.io에서 무료 스캔을 시작해 보세요. 어떤 수정도 하기 전에, 정확히 몇 개의 이메일이 영향을 받았는지 먼저 확인할 수 있습니다.

cPanel 마이그레이션 후 이메일 날짜 오류