Takeout mbox 가져오기 후 모든 이메일이 오늘 날짜로 표시될 때

Google Takeout 아카이브를 열고, ImportExportTools NG로 mbox 파일을 Thunderbird에 가져온 다음(또는 Apple Mail에 가져온 다음), 폴더를 새 IMAP 계정으로 끌어다 놓으셨을 겁니다. 메일 클라이언트에서는 이메일이 연도별로 깔끔하게 정리되어 있었습니다. 그런데 대상 계정에서는 전부 오늘 날짜로 표시됩니다. 이 글에서는 Takeout mbox를 가져온 뒤 무슨 일이 벌어지는지, 왜 복사한 날짜가 표시되는지, 몇 분 만에 이를 확인하는 방법과 서버 쪽에서 수정하는 방법을 설명합니다.

먼저 알아 두실 점이 있습니다. 이메일 자체에는 문제가 없습니다. 원래 날짜는 여전히 메시지 안에 들어 있습니다. 다만 대상 계정이 그 날짜를 앞세우지 않을 뿐입니다.

Takeout mbox를 가져왔을 때 흔한 상황

15년 전에 만든 개인 Gmail 계정을 방금 닫았다고 해 보겠습니다. takeout.google.com에서 내보내기를 요청하고, Google의 완료 메일을 기다리고(용량이 큰 메일함이면 이틀), zip 아카이브 네 개를 내려받았습니다. 각 아카이브에는 라벨마다 .mbox 파일이 하나씩 들어 있습니다. 이 파일들을 Thunderbird에 가져오면 로컬 폴더가 채워지고, 날짜순 정렬도 완벽합니다. 맨 아래가 2009년, 맨 위가 어제입니다.

그러면 누구나 하는 일을 하게 됩니다. 폴더를 선택해서 대상 IMAP 계정(Microsoft 365, 호스팅 업체, 또는 Google Workspace)으로 끌어다 놓습니다. 전송은 저녁 내내 이어집니다. 월요일 아침, 웹메일을 엽니다.

문제는요? 이메일 18,400통이 전부 주말 날짜로, 몇 시간 안에 몰려 있습니다. 2014년 계약서가 지난주 뉴스레터 옆에 놓여 있고, 시간순으로는 아무것도 찾을 수 없습니다.

이 경우는 오래된 이메일이 모두 같은 날짜로 표시되는 문제와 매우 비슷하지만 큰 차이가 하나 있습니다. 여기서는 마이그레이션 도구가 원인이 아닙니다. 끌어다 놓기만으로 충분히 생깁니다.

이메일 한 통에 들어 있는 세 가지 날짜

원인을 이해하려면 이메일의 "날짜"라는 표현부터 버려야 합니다. mbox 파일에서 가져온 메시지에는 적어도 세 가지 날짜가 있고, 각각 쓰임이 다릅니다.

Date 헤더: 보낸 사람이 기록한 날짜

RFC 2822(이후 RFC 5322로 계승)에 정의된 Date: 헤더입니다. 보낸 사람의 메일 클라이언트가 발송 시점에 기록하며, 예를 들면 Date: Tue, 14 Mar 2017 09:12:45 +0100 같은 형태입니다. 메시지의 일부로서 메시지와 함께 이동하고, Takeout도 이를 그대로 보존합니다. 이 헤더가 온전히 남아 있기 때문에 수정이 가능합니다.

mbox 파일의 From 줄: 겉모양뿐인 날짜

mbox 파일에서는 각 메시지 앞에 From 으로 시작하는 줄이 붙습니다(공백이 있고 콜론은 없습니다). 이것은 헤더가 아닙니다. 파일 형식 고유의 구분자일 뿐 메시지에 속하지 않습니다. 이메일 날짜를 판단하는 데 이 줄을 믿는 제대로 된 도구는 없습니다.

INTERNALDATE: 서버에 저장된 날짜

세 번째 날짜이자 가장 눈에 띄지 않는 것이 RFC 3501에 정의된 INTERNALDATE입니다. IMAP 서버가 메시지 옆에(안이 아니라) 따로 저장하는 속성으로, 메시지가 메일함에 들어온 날짜에 해당합니다. Outlook, 웹메일, 스마트폰은 이 값을 사용해 받은 날짜를 표시하고 정렬합니다. 메커니즘을 자세히 알고 싶다면 IMAP INTERNALDATE 해설을 참고하세요.

Received: 헤더에 대해서도 짚어 두겠습니다. 이 헤더는 여기서 자주 잘못 지목됩니다. 내보낸 Gmail 이메일의 Received 줄은 2017년에 메시지가 실제로 거친 경로를 기록하고 있어서, 오래되었지만 정당한 날짜가 들어 있습니다. 따라서 이 경우 틀린 날짜는 메시지 안이 아니라, 서버가 복사본에 부여한 메타데이터에 있습니다.

대상 계정이 복사한 날짜를 표시하는 이유

클라이언트가 IMAP 서버에 메시지를 올릴 때는 APPEND 명령을 사용합니다. 이 명령은 선택 사항으로 메시지에 붙일 날짜를 받을 수 있습니다. 클라이언트가 날짜를 넘기면 서버는 그것을 INTERNALDATE로 보관합니다. 넘기지 않으면 서버는 RFC 3501이 정한 규칙대로 그 순간의 날짜와 시각을 적용합니다. 다시 말해 표시되는 날짜는 도구가 이메일을 어떻게 기록했느냐에 달려 있습니다. 원래 날짜를 넘기지 않는 도구는 복사한 날짜를 얻게 됩니다.

결과적으로 폴더를 끌어다 놓는 동안 각 메시지는 자신이 올라간 시각을 날짜로 갖게 됩니다. 이메일 3,000통이 든 폴더를 40분 동안 복사하면 전부 40분짜리 구간에 들어갑니다.

그렇다면 Thunderbird의 로컬 폴더는 왜 완벽해 보였을까요? 로컬 폴더에는 서버가 없으므로, Thunderbird는 서버 날짜가 아니라 Date 헤더로 정렬하기 때문입니다. Apple Mail에서 가져온 메일함도 비슷하게 동작합니다. 메시지가 Mac 안에 있는 동안에는 문제가 없습니다. 진실은 다른 프로그램, 예를 들어 Outlook이 IMAP 메일함을 읽는 순간 드러납니다.

사실 모든 클라이언트가 매번 틀린다고 말하는 것은 정확하지 않습니다. 날짜를 넘기는 버전도 있고 그렇지 않은 버전도 있으며, 업데이트를 거치며 동작이 바뀌기도 했습니다. 그래서 같은 방법을 따라 한 동료 두 사람이 서로 다른 결과를 얻을 수 있고, 진단이 생각보다 더 헷갈리게 됩니다.

끌어다 놓기는 마이그레이션이 아닙니다. 복사이고, 복사본에는 만들어진 날짜가 붙습니다.

5분 안에 이 경우인지 확인하는 방법

해결책을 찾기 전에, 정말 이 상황이 맞는지 다른 문제가 아닌지 확인하세요. 네 가지만 살펴보면 충분합니다.

• 두 곳을 비교하세요. Thunderbird의 로컬 폴더(또는 Apple Mail에 가져온 메일함)에는 올바른 날짜가 표시되는데, IMAP 계정에서는 같은 메시지가 최근 날짜로 표시됩니다.
• 날짜의 범위를 보세요. IMAP 계정의 한 폴더 안에서 받은 날짜가 폴더를 옮긴 시점 전후의 몇 시간, 심하면 몇 분 안에 몰려 있습니다.
• 메시지 소스를 여세요. Thunderbird에서는 보기 메뉴의 메시지 소스, Outlook에서는 메시지 속성에서 헤더를 볼 수 있습니다. 화면에는 최근 날짜가 표시되는데 Date: 줄에는 오래된 날짜가 있어야 합니다.
• 순서를 확인하세요. 메시지가 시간순이 아니라 클라이언트가 복사한 순서대로 나타납니다.

실제 메시지로 비교하면 다음과 같습니다.

Date: Tue, 14 Mar 2017 09:12:45 +0100          (메시지 안, 그대로 유지)
IMAP 계정에 표시되는 날짜: 복사한 날          (서버 메타데이터)

이 두 줄이 서로 다른 이야기를 하고 있다면 바로 이 경우입니다. 표시되는 날짜도 틀렸는데 Date:까지 틀렸다면, 더 드문 다른 문제이며 이 글에서 다루지 않습니다.

(그런데 이메일의 원시 헤더를 한 번도 읽어 본 적이 없다면 커피를 준비하세요. 해변에서 읽기 좋은 글은 아니니까요.)

보낸 날짜 정렬은 임시방편일 뿐입니다

가장 먼저 떠오르는 방법은 정렬 기준을 보낸 날짜로 바꾸는 것입니다. Outlook에서는 어느 정도 통하지만, 폴더마다 기기마다 다시 설정해야 합니다. 게다가 검색, 알림, 오래된 정도를 기준으로 한 규칙, 모바일 보기는 계속 받은 날짜를 사용합니다. 휴대폰에서 "지난 9월에 온 메일"을 찾는 사용자는 어디서도 논리적인 결과를 보지 못합니다.

또 다른 유혹은 복사를 처음부터 다시 하는 것입니다. 이미 사용 중인 계정에서는 기존 메시지 옆에 중복 메일만 생기고, 날짜는 여전히 틀리거나 또 다르게 틀립니다. 폴더 백 개쯤을 다시 옮기고 나면 깨끗한 메일함은 하나도 남지 않습니다.

서버 쪽에서 수정하기

다행히 원래 날짜는 여전히 남아 있습니다. 수정이란 메시지 내용은 건드리지 않고 대상 계정이 그 날짜를 표시하도록 만드는 일입니다.

Redate가 바로 이 일을 합니다. Redate는 메일함에 연결합니다(Google Workspace는 도메인 전체 위임, Microsoft 365, Outlook.com과 Hotmail은 각자의 Microsoft 계정, 또는 이메일 주소와 비밀번호로 IMAP에 직접 연결). 어떤 도구가 문제를 일으켰는지 알 필요가 없습니다. Takeout mbox에서 끌어다 놓은 것이든 다른 원인이든, 표시된 날짜가 원래 날짜와 맞지 않는 이메일을 찾아냅니다. 메일함 스캔은 무료이며, 결정을 내리기 전에 문제의 규모를 보여 줍니다.

수정 자체에는 Redate 고유의 수정 엔진이 쓰입니다. 여러 단계로 이루어진 분석 파이프라인이 각 메시지의 헤더 체인을 살펴 이메일마다 원래 날짜를 되돌려 줍니다. 수정된 이메일은 하나하나 개별적으로 검증하며, RFC 준수 여부 확인과 메시지 구조 보존도 함께 이루어집니다. 원본 메일은 삭제되지 않고, 직접 지우실 때까지 메일함의 눈에 보이는 폴더에 남아 있습니다.

직접 해결하려는 시도가 위험한 이유

문제를 이해하는 것과, 이메일 15,000통을 한 통도 잃지 않고 수정하는 것은 전혀 다른 일입니다.

테스트 메시지 열 통에서 잘 돌아가는 스크립트는 메시지 30,000통이 든 실제 메일함에서 버티지 못합니다. 조금만 바꿔도 서명이 깨지는 S/MIME 서명 메일을 만나고, PGP로 암호화된 메시지를 만납니다. 중첩된 multipart/alternative 구조, 일관되지 않은 MIME 경계, 예상치 못한 Content-Transfer-Encoding, RFC 2047로 인코딩된 비ASCII 헤더, 40MB짜리 첨부 파일도 나옵니다. 그다음에는 API 할당량이 기다립니다. 새벽 3시 배치 도중에 뜨는 429 Too Many Requests 오류, 11,874번째 메시지에서 작업을 끊어 버리는 네트워크 타임아웃 같은 것들입니다.

그럼 그다음은요? 모든 메시지가 온전한지 어떻게 알 수 있을까요? 롤백 장치가 없으면 오류 하나가 중복 메시지, 사라진 첨부 파일, 끊어진 대화 스레드, 없어진 라벨을 남깁니다. Redate는 모든 이메일을 자동으로 검증하고 원본을 가까이에 보관합니다. 그런 위험에 직접 돈을 걸 일이 없도록 하기 위해서입니다.

마지막으로 무료 조언을 하나 드립니다. 메일함 검증이 끝날 때까지는 원래의 Takeout 아카이브를 보관하세요. 대상 계정이 정상으로 보이더라도 mbox 파일은 여전히 기준이 되는 사본입니다.

사용하신 클라이언트별 관련 가이드

복사에 사용하신 클라이언트에 따라, 다음 가이드에서 해당 사례를 자세히 다룹니다. Thunderbird에서 한 IMAP 복사의 날짜 수정과 Apple Mail에서 같은 경우입니다.

Takeout이 이미 IMAP 계정에 복사되었고 날짜가 잘못되어 있나요? Redate 무료 스캔을 시작해서 영향받은 이메일이 몇 통인지 확인하세요. 그런 다음 일회성 결제로 수정하시면 되며, 메일함 크기 제한은 없습니다.