수신 이메일 날짜 변경: 기술적 한계와 가능성

이메일에는 "날짜"가 하나가 아니라 세 개입니다

"수신 이메일의 날짜를 변경한다"고 하면, 대부분의 사람들은 Windows에서 파일 생성 날짜를 바꾸듯 어딘가의 필드 하나를 수정하면 된다고 생각합니다. 하지만 실제로는 좀 더 복잡합니다. 이메일 하나에는 서로 다른 세 가지 날짜 레이어가 있고, 각각 고유한 규칙과 관리 주체, 그리고 잘못 건드렸을 때의 결과가 따라옵니다.

이 세 가지 레이어를 이해하면, 어떤 수정이 기술적으로 유효하고 어떤 수정이 불가능하거나 즉시 위조로 탐지되는지 알 수 있습니다.

레이어 1: IMAP INTERNALDATE

INTERNALDATE는 서버 측에 저장되는 메타데이터로, 이메일 메시지 자체의 내용에는 포함되지 않습니다. IMAP 서버가 설정하며, 대부분의 이메일 클라이언트가 목록에서 이메일을 정렬할 때 이 값을 사용합니다.

예를 들어 Outlook은 기본적으로 INTERNALDATE 기준으로 메시지를 정렬합니다. Gmail도 특정 상황에서 마찬가지입니다. 따라서 INTERNALDATE가 잘못되어 있으면, 메시지 내부 헤더에 뭐라고 적혀 있든 상관없이 인터페이스에서 모든 이메일이 같은 날짜로 보이게 됩니다.

INTERNALDATE는 메시지가 서버에 저장될 때 결정됩니다. IMAP 프로토콜에서 이를 "수정"하는 유일한 방법은 간접적입니다. APPEND 명령으로 원하는 날짜와 함께 새 메시지 복사본을 저장하는 것입니다. SETINTERNALDATE라는 IMAP 명령은 존재하지 않습니다. 이 점은 잠시 후 중요해집니다.

레이어 2: Date: 헤더 (RFC 2822)

이것은 메시지 원시 헤더에 있는 Date: 필드입니다. 발신 시점에 이메일 클라이언트가 설정하고, 서버에서 서버로 메시지와 함께 전달됩니다. 발신자가 선언한 발송 날짜입니다.

(이메일 원시 헤더를 한 번도 본 적 없다면, 꽤 낯선 읽을거리입니다. 메시지 하나에 99%의 사람들이 평생 본 적 없는 기술적인 줄이 20여 개씩 붙어 있거든요.)

기술적으로 Date: 필드를 과거 또는 미래 날짜로 설정해서 이메일을 보내는 것은 가능합니다. SMTP 서버는 이 필드를 검증하지 않습니다. 하지만 수신 서버는 Received: 헤더에 실제 수신 시각을 기록하므로, 즉시 불일치가 생기고 어떤 이메일 클라이언트나 분석 도구에서도 이를 확인할 수 있습니다.

레이어 3: 쌓이는 Received: 헤더

SMTP 서버가 메시지를 중계할 때마다 타임스탬프가 포함된 Received: 헤더를 맨 위에 추가합니다. 세 서버를 거친 이메일에는 Received: 헤더가 세 개 쌓입니다. 아래에서 위로 읽습니다. 가장 오래된 것이 아래, 가장 최근 것이 위에 있습니다.

바로 여기서 마이그레이션 도구가 문제를 만들어 냅니다. BitTitan MigrationWiz, CloudM, imapsync, GSMMO가 이메일을 마이그레이션할 때, IMAP을 통해 새 서버에 메시지를 다시 주입합니다. 이 과정에서 마이그레이션 시점이 찍힌 새 Received: 항목이 생성됩니다. 결과적으로, 사서함에서 가장 오래된 2019년 이메일이 2024년 11월이라는 Received: 날짜를 갖게 됩니다. 그리고 일부 이메일 클라이언트, 특히 Outlook은 가장 최근 Received:를 표시 날짜로 사용하기 때문에...

15,000개의 이메일이 모두 같은 마이그레이션 날짜로 표시되는 문제가 생깁니다.

이 날짜들을 정말로 "수정"할 수 있을까요?

기술적으로 INTERNALDATE는 수정 가능합니다(단, 제약이 있습니다). Date:는 기술적으로 가능하지만 의미가 없습니다. Received:에 대해서는 좀 더 자세히 살펴볼 필요가 있습니다.

Received: 헤더를 다시 쓰는 건 간단합니다. 그리고 즉시 탐지됩니다.

Received: 헤더는 메시지 안의 텍스트 한 줄에 불과합니다. 일반 텍스트 파일처럼 편집할 수 있습니다. 보이는 것만큼 단순합니다.

하지만 그 다음에 이런 일이 벌어집니다.

첫 번째 문제: DKIM. DKIM(DomainKeys Identified Mail) 서명은 메시지의 여러 헤더를 기반으로 계산되며, 경우에 따라 Received:도 포함됩니다. 서명된 헤더를 수정하면 서명이 무효화됩니다. DKIM을 검증하는 수신 서버는 즉시 메시지가 변조되었음을 감지합니다. 교묘한 위조가 아니라, 경보가 울리는 겁니다.

두 번째 문제: 내부 식별자. Google Workspace, Microsoft 365 같은 현대 메일 서버는 각 메시지에 순차적으로 증가하는 고유 내부 식별자를 부여합니다. 이 식별자는 INTERNALDATE 및 수신 순서와 연결되어 있습니다. 이런 식별자와 일관성 없이 Received:를 수정하면 감사 도구가 어렵지 않게 불일치를 발견합니다.

세 번째 문제는 좀 더 실용적입니다. 메시지 내용에서 Received:를 수정하더라도, IMAP 저장 시점으로 설정된 INTERNALDATE는 그대로입니다. 이메일 클라이언트는 계속 잘못된 날짜로 정렬합니다. 결국 아무 의미 없이 메시지만 수정한 셈이 됩니다.

요약하자면, 악의적인 목적으로 Received:를 다시 써서 이메일 날짜를 위조하는 건 기술적으로는 간단하지만, 전문가가 몇 초 만에 탐지할 수 있습니다. 진지하게 시도할 수 있는 방법이 아닙니다.

Date: 헤더: 서류상 과거를 바꾸기

Date:도 같은 논리입니다. 메시지 본문에서 수정할 수 있습니다. 하지만 중간 서버들이 인증한 Received: 헤더는 그대로 남아 다른 이야기를 전합니다. 시간적 연쇄가 일관되지 않습니다. 이 필드들을 비교하는 분석가나 법원은 즉시 이를 파악합니다.

정확히 말하면, .eml 파일을 직접 열면 일부 이메일 클라이언트가 수정된 Date:를 표시하기도 합니다. 하지만 인증과 로그가 있는 실제 메일 서버 환경에서는 수정 사실이 그대로 드러납니다.

IMAP 마이그레이션: 날짜 수정이 정당한 유일한 상황

수신 이메일의 날짜를 수정하는 것이 가능할 뿐만 아니라 기술적으로도 정당한 경우가 딱 하나 있습니다. 잘못 처리된 IMAP 마이그레이션으로 인한 손상을 복구하는 것입니다.

구체적인 상황을 생각해 보세요. Exchange 사서함 80개를 Microsoft 365로 마이그레이션했습니다. 금요일 저녁에 마이그레이션이 완료됐습니다. 월요일 아침, 첫 번째 티켓이 들어오기 시작합니다. "모든 이메일이 같은 날짜로 표시돼요", "작년 이메일을 찾을 수가 없어요", "고객과의 이메일 히스토리가 완전히 엉망이에요". 80명의 사용자가 곤란해하고, 담당자는 답을 기다리고 있습니다.

이 상황에서 문제는 문서화되어 있고, 식별 가능하며, 원인도 명확합니다. 마이그레이션 도구가 마이그레이션 날짜가 찍힌 Received:를 추가했고, 일부 이메일 클라이언트가 이 새 헤더를 표시 날짜로 사용하는 것입니다. 각 메시지의 원래 Date: 헤더는 손상되지 않고 그대로 있습니다. 수정된 적이 없습니다. 여전히 정확한 원래 발송 날짜를 담고 있습니다.

따라서 이 수정은 위조가 아닙니다. 복원입니다. 실제 데이터(원래 Date:)를 기반으로 일관된 메타데이터를 재구성하는 것입니다. 2024년 이메일을 2019년 것처럼 보이게 하려는 시도와는 근본적으로 다릅니다.

각 도구별 구체적인 메커니즘에 대해서는, 이 가이드들이 실제 사례를 자세히 설명합니다. Microsoft 365에서 BitTitan 날짜 수정, Outlook에서 CloudM 날짜 수정, Google Workspace에서 imapsync 날짜 수정.

직접 스크립트를 작성하면 안 되는 이유

기본 논리는 이해할 수 있습니다. IMAP 포럼에서 시간을 보낸 IT 관리자라면 일반적인 접근 방식을 파악할 수 있습니다. 그건 문제가 아닙니다.

문제는 테스트 이메일 50개에서 작동하는 스크립트와, 프로덕션 환경의 이메일 40,000개를 이메일 하나도 잃지 않고, 첨부 파일 하나도 손상시키지 않고, 대화 스레드 하나도 망가뜨리지 않고 처리하는 스크립트 사이의 간극입니다.

직접 만든 스크립트가 일반적으로 처리하지 못하는 구체적인 사례들을 보면:

• S/MIME 서명 이메일: 서명은 내용과 헤더를 포함합니다. 메시지 구조를 수정하면 서명이 무효화됩니다. 서툴게 수정된 서명 이메일은 수신자에게 "서명 유효하지 않음"으로 도착합니다.
• PGP 암호화 메시지: 같은 종류의 문제이고, 구현 방식에 따라 결과가 더 심각할 수 있습니다.
• 헤더의 비ASCII 인코딩: RFC 2047은 헤더의 특수 문자 인코딩 방식을 정의합니다. 이런 경우를 처리하지 못하는 스크립트는 악센트 문자, 한국어 문자나 아랍어 이름이 있는 이메일 제목을 조용히 손상시킵니다.
• API 요청 제한: Google Workspace와 Microsoft 365는 엄격한 스로틀링을 적용합니다. 새벽 3시에 이메일 10,000개 배치가 지수 백오프 처리 없이 429 Too Many Requests 오류를 만나면, 사서함 절반이 반만 수정된 채로 남습니다.
• 손상된 MIME 경계: 첨부 파일이 있는 멀티파트 메시지에는 정확한 MIME 경계가 있습니다. 이를 잘못 재생성하면 첨부 파일을 열 수 없게 됩니다.

그리고 어떤 직접 만든 스크립트도 해결하지 못하는 질문이 있습니다. 수정된 이메일 하나하나가 온전하다는 걸 어떻게 검증할 건가요? 40,000개의 메시지를 개별 검증 없이 수정하는 스크립트는 도박입니다. 사용자들이 대체 불가능하다고 여기는 데이터를 건 도박입니다.

마이그레이션 후 날짜 수정 방법과 각 접근법의 한계를 다룬 글에서 다양한 옵션을 살펴볼 수 있습니다.

이 상황에서 Redate.io가 하는 일

Redate.io는 정확히 이런 경우를 위해 설계되었습니다. IMAP 마이그레이션으로 손상된 날짜를 대규모로, 메시지 무결성을 해치지 않고 수정하는 것입니다.

Redate.io는 해당 사서함에 직접 연결하고(Google Workspace는 도메인 위임 방식, Microsoft 365는 Azure AD, 또는 직접 IMAP), 날짜가 잘못된 메시지를 무료로 스캔한 다음, 위에서 설명한 엣지 케이스들을 처리하는 독자적인 수정 파이프라인을 적용합니다. 각 이메일은 수정 후 개별적으로 검증됩니다. 원본은 30일 동안 눈에 보이는 백업 폴더에 보관됩니다.

패턴 매칭은 BitTitan MigrationWiz, CloudM, imapsync, GSMMO 및 그 변형을 포함한 수백 가지 알려진 마이그레이션 도구 서명을 커버합니다. 탐지는 정밀합니다. 날짜가 올바른 이메일에는 Redate.io가 손대지 않습니다.

요금 구조는 단순합니다. 사서함당 일회성 결제이며, 구독이 없습니다. 진단 스캔은 무료로 제공되어, 어떤 결정을 내리기 전에 피해 규모를 먼저 파악할 수 있습니다.

이 문제로 영향받은 사서함을 관리하고 있다면, 마이그레이션 후 Outlook의 잘못된 날짜에 관한 글에서 가장 흔한 증상과 다른 원인과 구분하는 방법을 자세히 확인할 수 있습니다.

사서함의 문제 규모를 직접 확인하고 싶으신가요? Redate.io에서 무료 스캔을 시작하세요. 어떤 수정도 하기 전에 영향받은 이메일이 정확히 몇 개인지 확인할 수 있습니다.