imapsync 이메일 날짜 문제 수정

--syncinternaldates의 약속 (그리고 왜 작동하지 않는지)

imapsync 명령을 실행했어요. 문서를 읽고 신중하게 --syncinternaldates를 포함했어요. 마이그레이션이 완료되고, 로그에는 모두 전송됨, 오류 0이라고 나와요. 그런데 Outlook에서 메일함을 열면 모든 이메일이 어제 날짜를 표시하고 있어요.

이것은 imapsync에서 가장 흔한 불만 중 하나이며, 최소 2017년부터 시스템 관리자들을 혼란스럽게 해왔어요. --syncinternaldates 플래그는 마이그레이션 중 IMAP INTERNALDATE를 보존하도록 되어 있어요. 그리고 기술적으로 시도해요. 하지만 "시도한다"는 말은 그 문장에서 많은 것을 담고 있어요.

imapsync는 Gilles Lamiral이 작성한 오픈소스 Perl 도구이며, 그 기능에서 정말 뛰어나요. 대부분의 상용 도구가 부러워할 수준의 신뢰성으로 IMAP 간 메일함 전송을 처리해요. 하지만 날짜 보존은 완전히 imapsync의 손에 있지 않고, 여기서 상황이 복잡해져요.

IMAP 날짜가 실제로 작동하는 방식

모든 이메일에는 세 가지 다른 "날짜"가 관여하며, 대부분의 사람들(일부 IT 관리자 포함)이 이를 혼동해요:

Date: 헤더 (RFC 2822) - 발신자의 이메일 클라이언트가 메시지를 작성할 때 찍은 날짜예요. 메시지 본문 안에 존재하며 메일 서버가 절대 수정하지 않아요.
Received: 헤더 - 메시지를 처리하는 각 메일 서버가 자체 타임스탬프와 함께 추가해요. 발신자에서 수신자까지의 체인을 형성해요. 가장 최신 Received 헤더가 일부 이메일 클라이언트가 표시에 사용하는 것이에요.
INTERNALDATE - 메일함에서 메시지 정렬 순서를 제어하는 IMAP 서버 측 타임스탬프예요. IMAP APPEND로 메시지가 처음 저장될 때 설정돼요.

imapsync가 메시지를 마이그레이션할 때, 소스 서버에서 (INTERNALDATE 포함) 읽어서 IMAP APPEND를 사용해 대상 서버에 써요. --syncinternaldates 플래그는 APPEND 중 소스 INTERNALDATE를 대상 서버에 전달하도록 imapsync에 지시해요.

문제는 이거예요: 대상 서버는 그 날짜를 존중할 의무가 없어요.

대상 서버가 INTERNALDATE를 무시하는 이유

IMAP 사양(RFC 3501)에서는 APPEND 명령과 함께 날짜-시간이 제공되면 서버가 사용해야 한다(SHOULD)고 말해요. RFC 언어에서 "SHOULD"는 "좋은 이유가 없는 한 이렇게 하세요"를 의미해요. 여러 주요 이메일 플랫폼이 좋은 이유가 있다고 결정했어요.

Microsoft 365가 가장 큰 문제예요. IMAP APPEND로 메시지가 도착하면, Exchange 전송 파이프라인이 현재 날짜로 새 Received 헤더를 찍고, 그 배달 타임스탬프에 기반해 INTERNALDATE를 설정해요. imapsync가 어떤 날짜를 요청했는지는 중요하지 않아요. M365 서버가 덮어써요.

Google Workspace(Gmail)는 다르게 동작하지만 여전히 문제를 일으킬 수 있어요. Gmail의 IMAP 구현은 대부분의 경우 APPEND의 INTERNALDATE를 존중하지만, 자체 Received 헤더를 추가해요. 메일함을 읽는 이메일 클라이언트가 표시에 INTERNALDATE보다 Received 헤더를 우선시하면(Outlook이 정확히 그래요), 날짜는 여전히 잘못 표시돼요.

날짜를 망가뜨리는 흔한 imapsync 명령줄 실수

--syncinternaldates를 완전히 잊음

플래그는 기본적으로 활성화되어 있지 않아요. 기본 imapsync --host1 소스 --host2 대상 --user1 사용자 --user2 사용자를 플래그 없이 실행하면, imapsync는 날짜 보존을 전혀 시도하지 않아요.

--syncinternaldates와 --addheader 함께 사용

일부 가이드에서 마이그레이션 중 사용자 정의 헤더를 삽입하기 위해 --addheader 사용을 권장해요. 헤더를 추가하면 메시지를 수정하는 것이며, 대상 서버가 "새" 메시지로 취급하게 될 수 있어요.

--minage와 --maxage를 날짜 보존과 혼동

--minage와 --maxage 플래그는 나이에 따라 마이그레이션할 메시지를 필터링해요. 대상에서의 날짜 처리에는 영향을 주지 않아요.

타임스탬프 드리프트를 유발하는 SSL 협상

--ssl1과 --ssl2로 TLS를 통해 마이그레이션할 때, 연결 설정이 지연을 추가해요. 대규모 마이그레이션(50,000통 이상)에서 이 지연이 누적돼요.

imapsync 로그 읽기: 출력이 실제로 말하는 것

imapsync는 상세한 로그를 생성하는데, 날짜에 관해서는 로그 출력이 오해를 불러일으킬 수 있어요.

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

양쪽 날짜가 일치해요. 이는 imapsync가 올바른 INTERNALDATE를 대상에 보냈다는 뜻이에요. 하지만 대상 서버가 실제로 그 날짜를 저장했다는 뜻은 아니에요. imapsync는 요청한 것을 보고하지, 서버가 수락한 것을 보고하지 않아요.

대규모 imapsync 마이그레이션: 날짜 문제가 증폭되는 곳

imapsync로 단일 메일함 마이그레이션은 날짜가 깨지면 성가시지만, 수백 개의 메일함에서 imapsync를 실행하는 MSP와 IT 부서는 완전히 다른 규모의 문제에 직면해요.

자체 수정과 그 한계

포럼과 메일링 리스트(SourceForge의 imapsync-devel 리스트는 2026년 초 기준 아직 활발해요)를 검색하면 창의적인 것부터 위험한 것까지 다양한 제안을 찾을 수 있어요.

대상 서버에서 직접 INTERNALDATE를 수정하기 위한 Perl 한 줄짜리를 제안하는 사람도 있어요. 모든 메시지를 mbox 형식으로 내보내 날짜를 조작하고 다시 가져오기를 권장하는 사람도 있어요. imaplib를 사용해 메시지를 가져와서 수정하고 다시 삽입하는 Python 스크립트를 작성한 사람도 있어요.

이러한 접근 방식은 모두 같은 근본적인 문제를 공유해요. S/MIME 서명된 메시지를 서명을 깨뜨리지 않고 어떻게 처리하나요? 중첩된 경계가 있는 멀티파트 MIME 구조는요? RFC 2047로 인코딩된 비ASCII 헤더는요?

Redate.io가 imapsync 날짜 문제를 수정하는 방법

원본 Date: 헤더는 imapsync 마이그레이션 후에도 항상 손상되지 않아요. imapsync는 원시 메시지를 충실히 전송해요. 표시 문제를 일으키는 것은 대상 서버의 메타데이터 처리예요. 그 원본 헤더가 수정을 가능하게 만들어요.

Redate.io는 메일함(Google Workspace, Microsoft 365 또는 모든 IMAP 서버)에 직접 연결하여 날짜 이상이 있는 이메일을 스캔하고, 독자적인 헤더 체인 분석 및 날짜 재구성 파이프라인을 통해 타겟팅된 메타데이터 수정을 적용해요.

수정된 각 이메일은 개별적으로 검증돼요: 메시지 무결성, 첨부파일 보존, 폴더 배치, 스레드, 라벨. 원본은 보이는 Redate.io - Originals 백업 폴더에 30일간 보관돼요.

Redate.io는 몇 달 전이나 몇 년 전에 수행된 마이그레이션에도 작동해요. Date: 헤더는 만료되지 않으며, 잘못된 것을 수정하는 능력도 마찬가지예요.

imapsync로 마이그레이션하고 잘못된 날짜가 남았나요? 무료 스캔을 실행하여 영향받은 이메일 수를 정확히 확인하세요.

imapsync 날짜 보존 안 됨? 수정 방법 안내