English
Francais
Deutsch
Espanol
Portugues
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Turkce
Ellinika
Russkij
Polski
Cestina
Ukrajinska
Magyar
Romana
Bulgarski
Hrvatski
Srpski
Slovencina
Slovenscina
Lietuviu
Latviesu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
모든 이메일에 담긴 세 개의 날짜
IMAP 서버에 저장된 모든 이메일에는 최소 세 개의 서로 다른 날짜 값이 존재합니다. 이 날짜들이 어떻게 작동하는지, 그리고 메일 클라이언트가 그중 어느 것을 화면에 표시하는지 이해하면 마이그레이션이 날짜를 깨뜨리는 근본 원인을 파악할 수 있습니다. 이 글은 IT 관리자와 마이그레이션 후 날짜 문제의 원인을 이해하고자 하는 사람들을 위한 기술 심층 분석입니다.
1. RFC 2822 "Date" 헤더
"Date" 헤더는 RFC 2822(인터넷 메시지 형식)에 정의되어 있습니다. 발신자의 메일 클라이언트가 메시지를 작성하고 보내는 순간에 설정됩니다. 이 헤더는 이메일 메시지 본문 자체의 일부이며, 메시지와 함께 이동하고 전달 경로의 메일 서버에 의해 수정되지 않습니다. 일반적인 Date 헤더는 다음과 같습니다.
Date: Mon, 15 Jan 2024 09:32:17 +0100
Date 헤더는 메시지의 "발송 날짜"를 나타냅니다. 한 번 설정된 후 변경되지 않기 때문에 가장 신뢰할 수 있는 날짜입니다. 다만 발신자의 시스템 시계를 반영하므로, 시계가 잘못 설정되어 있으면 부정확할 수 있습니다. 드물게 자동 시스템 알림이나 형식이 잘못된 메시지에서는 Date 헤더 자체가 없는 경우도 있습니다.
2. IMAP INTERNALDATE
INTERNALDATE는 RFC 3501(IMAP4rev1 프로토콜)에 정의되어 있습니다. 메시지가 서버에 전달된 날짜와 시간을 나타내는 서버 측 메타데이터 값입니다. Date 헤더와 달리 INTERNALDATE는 이메일 메시지 자체의 일부가 아니며, IMAP 서버가 메타데이터로 별도 저장합니다.
이메일이 정상적으로(마이그레이션 없이) 전달되면 IMAP 서버는 전달 시점의 현재 시각을 INTERNALDATE로 설정합니다. 이 값은 대개 Date 헤더와 몇 초 또는 몇 분 이내로 거의 일치합니다. 메일 클라이언트는 INTERNALDATE가 서버가 실제로 메시지를 수신한 시점을 반영하기 때문에 이를 "수신 날짜"로 사용하는 경우가 많습니다.
여기서 흥미로운 부분이 등장합니다. 메시지가 IMAP APPEND 명령(마이그레이션 도구가 사용하는 방식)으로 삽입될 때는 클라이언트가 INTERNALDATE 값을 직접 지정할 수 있습니다. 잘 설계된 마이그레이션 도구는 이 기능을 이용해 원본 서버의 INTERNALDATE를 그대로 보존합니다. 그러나 INTERNALDATE가 올바르게 설정되어도, 뒤에서 설명할 "Received" 헤더 문제 때문에 많은 메일 클라이언트에서 표시되는 날짜가 여전히 뒤바뀔 수 있습니다.
3. "Received" 헤더 체인
이메일이 메일 서버를 거칠 때마다 그 서버는 메시지 앞에 "Received" 헤더를 추가합니다. 이렇게 만들어진 Received 헤더의 연쇄는 발신자에서 수신자까지 이메일이 지나온 경로를 기록합니다. 가장 최근(최상단) Received 헤더는 메시지를 마지막으로 처리한 서버를 보여주고, 가장 오래된(최하단) 헤더는 첫 번째 서버를 보여줍니다.
일반적인 이메일은 발신자의 발신 서버부터 중계 서버, 수신자의 수신 서버까지 여정을 기록하는 3~6개의 Received 헤더를 가집니다. 각 Received 헤더에는 타임스탬프가 포함됩니다. 다음은 간단한 예시입니다.
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
메일 클라이언트가 표시할 날짜를 선택하는 방식
Outlook(데스크톱, 웹, 모바일)
Microsoft Outlook은 받은 편지함에 표시하는 "수신" 날짜를 결정할 때 INTERNALDATE와 최상단 "Received" 헤더를 조합해서 사용합니다. 실제로는 Outlook이 "수신" 열에 가장 최근 Received 헤더의 타임스탬프를 우선하는 경향이 있습니다. "보낸 날짜" 열은 Date 헤더를 사용합니다. Outlook은 기본적으로 "수신" 열을 기준으로 정렬하기 때문에, 사용자가 가장 먼저 보게 되는 값은 Received 헤더의 타임스탬프입니다.
Apple Mail
macOS와 iOS의 Apple Mail은 날짜 표시에 주로 IMAP INTERNALDATE를 사용합니다. 마이그레이션 중 INTERNALDATE가 올바르게 보존되었다면 Apple Mail이 정확한 날짜를 표시할 수도 있지만, 이는 APPEND 작업 시 INTERNALDATE가 명시적으로 설정된 경우에만 가능합니다. 마이그레이션 도구가 INTERNALDATE를 설정하지 않았다면, 서버는 기본값으로 삽입 시점(즉 마이그레이션 날짜)을 사용합니다. 이 문제가 Apple Mail 사용자에게 어떤 영향을 주는지는 Apple Mail 날짜 오류 수정 문서를 참고하세요.
Thunderbird
Mozilla Thunderbird는 가장 유연한 방식을 제공합니다. Date 헤더에서 가져온 "Date"와 Received 헤더에서 가져온 "Received"를 모두 표시할 수 있습니다. 기본적으로 Thunderbird는 Date 헤더 값을 보여주므로, Outlook에서는 날짜가 틀려도 Thunderbird에서는 올바르게 보이는 경우가 있습니다. 다만 Thunderbird의 "Received" 열은 여전히 마이그레이션 날짜를 보여줍니다. 자세한 내용은 Thunderbird 날짜 오류 수정을 참고하세요.
Gmail 웹 인터페이스
Gmail 웹 클라이언트는 기본 날짜 표시에 Date 헤더를 사용합니다. 그래서 마이그레이션 후에도 Gmail 웹에서는 올바른 날짜가 표시되는 경우가 많습니다. 그러나 Gmail 서버에 저장된 IMAP INTERNALDATE는 여전히 잘못되어 있으며, 이는 해당 Gmail 계정에 연결하는 모든 IMAP 클라이언트에 영향을 줍니다. Gmail 웹과 Outlook 또는 Apple Mail 사이의 이러한 차이는 흔한 혼란의 원인이며, 관리자의 문제 해결 시간을 많이 낭비하게 만듭니다.
IMAP APPEND가 날짜를 깨뜨리는 이유
마이그레이션 중 일어나는 일
마이그레이션 도구가 서버 A에서 서버 B로 이메일을 옮길 때, 도구는 IMAP으로 서버 A에 연결해 원본 메시지를 내려받은 뒤, 서버 B에 연결해 APPEND 명령으로 메시지를 삽입합니다. 이 삽입 과정에서 서버 B는 들어온 메시지를 처리하면서 현재 타임스탬프, 즉 마이그레이션 날짜가 담긴 새로운 Received 헤더를 추가합니다. 이는 많은 IMAP 서버에서 흔히 나타나는 동작으로, 서버는 모든 APPEND를 새로운 메시지 전달로 취급합니다.
결과: 오염된 헤더 체인
마이그레이션 후 이메일의 Received 헤더는 다음과 같은 형태가 됩니다.
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
이제 마이그레이션 도구가 추가한 Received 헤더가 최상단에 위치합니다. 표시할 날짜를 결정할 때 최상단 Received 헤더를 사용하는 메일 클라이언트(특히 Outlook)는 "2024년 1월 15일" 대신 "2025년 4월 11일"을 보여주게 됩니다. 원래의 Date 헤더와 원래의 Received 헤더들은 그 아래에 그대로 남아 있지만, 더 이상 메일 클라이언트가 우선적으로 참조하는 위치에 있지 않습니다.
INTERNALDATE를 잘 처리해도 막을 수 없는 문제
일부 마이그레이션 도구는 APPEND 시 INTERNALDATE를 올바르게 설정합니다. 예를 들어 imapsync는 원본 서버의 INTERNALDATE를 명시적으로 보존합니다. 그러나 Received 헤더는 마이그레이션 도구가 아니라 대상 서버가 추가하는 것입니다. 마이그레이션 도구는 이 동작을 제어할 수 없습니다. INTERNALDATE를 완벽하게 보존해도 최상단 Received 헤더에는 여전히 마이그레이션 날짜가 담겨 있으며, Outlook 같은 클라이언트는 계속 잘못된 날짜를 표시합니다.
그렇다면 실제로 이 문제를 해결할 방법이 있을까요?
어떤 마이그레이션 도구가 Received 헤더를 추가하는가
모든 IMAP 마이그레이션 도구는 이 문제를 일으킵니다. Received 헤더가 마이그레이션 도구 자체가 아니라 대상 서버에 의해 추가되기 때문입니다. 다만 추가되는 헤더의 내용은 도구와 서버에 따라 다릅니다.
BitTitan MigrationWiz는 "mx.migrationwiz.com"이 포함된 Received 헤더를 추가합니다. CloudM Migrate는 "cloudm.io"를 참조하는 헤더를 추가합니다. imapsync는 대상 서버에서 일반적인 Received 헤더를 발생시킵니다. GSMMO는 "gmailapi.google.com"을 참조하는 헤더를 추가합니다.
해결책: 올바른 날짜 복원하기
다행히도 올바른 날짜 정보는 모든 이메일 안에 그대로 남아 있습니다. 원래의 Date 헤더도 온전하고, 원래의 Received 헤더들도 온전합니다. 문제는 그 위에 오염을 일으키는 헤더가 하나 더 얹혀 있다는 것뿐입니다.
Redate.io의 독자적인 보정 엔진은 영향을 받은 각 이메일의 전체 헤더 체인을 분석하여, 날짜 값들 사이의 이상 징후를 근거로 어떤 헤더를 수정해야 하는지 정확히 식별합니다. 이 방식은 특정 마이그레이션 도구에 의존하지 않기 때문에 어떤 도구로 마이그레이션했는지와 관계없이 작동합니다. 다단계 분석 파이프라인은 단순한 접근 방식으로는 처리하기 어려운 예외 상황도 다룹니다. S/MIME 서명 메시지, PGP 암호화 콘텐츠, multipart/alternative 구조, Content-Transfer-Encoding 문제, 비ASCII 헤더(RFC 2047), 대용량 첨부 파일, 손상된 MIME 경계 등이 여기에 포함됩니다.
보정이 끝나면 모든 이메일은 메시지 구조, 본문, 첨부 파일이 정확히 그대로 유지되었는지 확인하는 무결성 검증 과정을 거칩니다. 원본은 삭제되지 않으며, 메일함 안에서 눈에 보이는 백업 폴더로 이동되어 고객이 직접 삭제하기 전까지 그대로 보관됩니다.
직접 이런 스크립트를 작성해 볼 수도 있지 않을까요? 기술적으로는 가능합니다. 하지만 "이메일의 95%에서 작동한다"와 "단 한 건도 손상시키지 않고 100%에서 작동한다"의 차이에는 수개월에 걸친 엔지니어링이 들어갑니다. 그리고 누군가의 메일함 전체를 다룰 때는, 그 5%의 실패율이 곧 무엇이 잘못되었는지 확인할 방법도 없이 조용히 손상된 수백 통의 메시지를 의미합니다.
메일함에 날짜가 깨진 이메일이 몇 통이나 있는지 확인하고 싶으신가요? Redate.io로 무료 분석 실행하기를 통해 영향을 받은 이메일 수를 결제 없이 바로 확인할 수 있습니다.