수신 이메일 날짜 변경 가능 여부

누구나 묻는 질문 (그리고 그 뒤에 숨은 두 가지 전혀 다른 상황)

구글에 "수신 이메일 날짜 변경"을 검색해 보세요. Microsoft Q&A 포럼, Reddit 스레드, Quora 질문들이 수십 개씩 나옵니다. 질문 자체는 명확하지만, 그 이면에 있는 이유는 질문자에 따라 완전히 달라요.

날짜를 소급해서 위조하려는 사람이 있는가 하면, IMAP 마이그레이션 후 모든 이메일이 동일한 날짜(마이그레이션 날짜)로 표시되어 원래 날짜를 되찾고 싶어하는 IT 관리자도 있어요. 두 상황은 전혀 다르지만, 검색어는 똑같습니다.

이 글은 두 경우 모두에 답합니다. 미리 말씀드리면: 첫 번째 경우, 탐지되지 않는 방식으로 날짜를 변경하는 건 사실상 불가능해요. 두 번째 경우는 완전히 합법적인 작업이며, 바로 Redate.io가 하는 일입니다.

먼저: 이메일의 "날짜"란 무엇인가요?

이메일에는 날짜가 하나만 있는 게 아니에요. 서로 다른 위치에, 서로 다른 주체가 관리하는 여러 날짜가 존재합니다.

Date: 헤더 (RFC 2822)

발신자의 메일 클라이언트가 메시지를 보낼 때 삽입하는 날짜예요. 원시 헤더에서 이런 형태로 보입니다:

Date: Mon, 14 Oct 2024 09:32:11 +0200

이 헤더는 메시지 본문의 일부입니다. 원시 파일에 접근할 수 있다면 기술적으로 수정이 가능해요. 하지만 여기서 중요한 단어는 "기술적으로"예요.

Received: 헤더

이메일이 통과하는 각 메일 서버는 타임스탬프가 포함된 자체 Received: 헤더를 추가합니다. 이 헤더들이 발신 서버부터 수신함까지의 시간 순서 체인을 형성해요. (참고로, 이메일의 원시 헤더를 직접 읽어본 적 있다면 그게 얼마나 복잡한지 아실 거예요. 수십 줄의 기술적 메타데이터가 최신 순으로 나열되는데, 읽기 편한 형식은 아닙니다.)

IMAP INTERNALDATE

특정 수정이 왜 아무런 효과도 없는지 이해하려면 이 메타데이터가 가장 중요해요. INTERNALDATE는 메시지 내용과 별개로 IMAP 서버 측에 저장되는 속성입니다. 대부분의 메일 클라이언트가 폴더 내 이메일 정렬에 이 값을 사용하는데, Outlook도, Gmail도, Apple Mail도 대부분의 경우 그렇게 해요.

INTERNALDATE는 메시지 안에 있지 않아요. 서버 데이터베이스에 있습니다. 디스크의 .eml 파일을 편집한다고 변경되지 않아요.

로컬에서 수정할 때 실제로 무슨 일이 일어나나요

.eml 파일 편집

기술적으로 .eml 파일은 텍스트 파일이에요. 편집기로 열어서 Date: 줄을 바꾸고 저장할 수 있습니다. 이 파일을 로컬 메일 클라이언트에 다시 가져오면, 클라이언트에 따라 표시되는 날짜가 바뀔 수도 있어요.

하지만 다음은 변경되지 않아요:

IMAP 서버의 INTERNALDATE (항상 그대로)
중간 서버들이 추가한 Received: 헤더
Google, Microsoft, 또는 메일 제공업체의 전송 로그
메시지에 DKIM 서명이 있었다면 그 서명

결과적으로: 로컬 컴퓨터에서는 다른 날짜가 보일 수도 있어요. 하지만 Exchange Online에 연결된 Outlook이나 브라우저의 Gmail에서는 아무것도 바뀌지 않습니다.

시스템 시계 변경

일부 포럼에서는 워크스테이션 시계를 바꿔서 메일 클라이언트를 "속이는" 방법을 제안해요. 작동하지 않습니다. Outlook과 Gmail은 수신 이메일 날짜를 표시할 때 시스템 시간을 읽지 않아요. 서버에서 INTERNALDATE를 읽거나 메시지 헤더를 읽습니다. 로컬 시계는 이 과정 어디에도 관여하지 않아요.

Thunderbird를 통한 조작

Thunderbird는 대부분의 클라이언트보다 유연해요. 확장 프로그램이나 프로필 파일(mbox 파일, .msf 파일)을 직접 조작해서 날짜 표시를 바꾸려는 시도도 있습니다. POP3 방식으로 로컬에 저장된 이메일에 한해서는 Thunderbird 내에서 작동할 수도 있어요. 하지만 Thunderbird가 IMAP으로 연결되어 있으면, 서버와 재동기화됩니다. "수정"은 다음 동기화 때 사라져요.

DKIM: 아무도 언급하지 않는 보이지 않는 장벽

2018년 이후 발송된 대부분의 이메일에는 DKIM(DomainKeys Identified Mail) 서명이 있어요. 헤더에서 이런 형태로 보입니다:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

h= 필드는 서명이 적용된 헤더 목록입니다. 위 예시에서는 Date가 서명 대상에 포함되어 있어요. Date: 헤더를 수정하면 DKIM 검증이 실패합니다. 어떤 메일 서버든, 어떤 포렌식 분석 도구든 서명을 재계산해서 수정 여부를 탐지할 수 있어요.

물론 완벽한 보호는 아닙니다. 악의적인 발신자는 자신의 DKIM 키를 제어하므로 발송 시점에 원하는 내용으로 서명할 수 있어요. 하지만 이미 수신되어 서명된 이메일의 Date: 헤더를 변경하면 탐지 가능한 흔적이 남습니다.

서버 로그: 진짜 진실의 원천

이메일의 모든 가시적 메타데이터(헤더, INTERNALDATE, 전부)를 수정하는 데 성공했다 해도, 서비스 제공업체는 자체 로그를 보관합니다.

Google Workspace는 Admin Console의 감사 로그에 모든 메시지를 기록해요. Microsoft 365도 Purview 규정 준수 센터에서 동일하게 합니다. 이 로그에는 클라이언트에 표시되는 내용과 무관하게 전송 타임스탬프가 포함돼요. 변호사, 법무팀, 또는 보안 팀이 이 데이터를 가져올 수 있어요. Outlook에 표시된 날짜는 법정이나 보안 감사에서 증거로 인정되지 않습니다.

정확히 말씀드리면: 도메인 위임을 통해 사서함 접근 권한이 있는 관리자조차 이 로그를 소급해서 덮어쓸 수 없어요. 권한이 있는 사용자라도 손이 닿지 않는 영역입니다.

합법적인 경우: 마이그레이션 후 날짜 수정

온프레미스 Exchange에서 Microsoft 365로 150개 사서함 마이그레이션을 방금 완료했다고 상상해 보세요. 다음 주 월요일, 티켓이 쏟아집니다: "오래된 이메일이 전부 지난 금요일 날짜로 표시돼요." 마이그레이션 날짜로요.

이건 충분히 문서화된 문제이고, 앞서 설명한 것과는 완전히 다른 상황이에요. 여기서는 아무도 뭔가를 위조하려는 게 아닙니다. 진짜 원래 날짜는 여전히 각 메시지의 Date: 헤더에 그대로 살아있어요. 문제는 다른 곳에서 비롯됩니다. 마이그레이션 도구(BitTitan MigrationWiz, CloudM, imapsync, 또는 다른 도구)가 헤더 체인 맨 앞에 마이그레이션 날짜가 담긴 Received: 헤더를 삽입한 거예요. 특정 상황에서 Outlook은 INTERNALDATE보다 최근 Received: 헤더를 우선시하기 때문에, 그 날짜를 표시하게 됩니다.

이 경우의 "수정"은 메시지가 실제로 말하는 것(항상 존재하는 원래 Date: 헤더)과 서버가 인식하는 것(마이그레이션 시점에 설정된 INTERNALDATE) 사이의 일관성을 회복하는 작업이에요. 위조가 아닙니다. 복원입니다.

IMAP 마이그레이션 후 이메일 날짜가 바뀌는 이유에서 이 문제가 수천 개의 사서함에 어떻게 영향을 미치는지 자세히 설명하고 있어요. 그리고 이것이 바로 Redate.io가 해결하는 문제입니다.

직접 수정이 대규모에서 실패하는 이유

문제를 이해하는 건 한 가지예요. 150개 사서함에 걸쳐 40,000개의 이메일을 단 하나도 잃지 않고 수정하는 건 전혀 다른 문제입니다.

GitHub이나 Stack Overflow에서 찾을 수 있는 스크립트들은 테스트 이메일 20개에서는 잘 작동해요. 하지만 실제 운영 환경에서는 스크립트 작성자가 예상하지 못한 이유로 문제가 생깁니다:

S/MIME 서명이나 PGP 암호화된 이메일은 일반 메시지와 다른 구조를 가지고 있어요
비표준 MIME 경계가 있는 멀티파트 메시지는 파싱 오류를 일으킵니다
RFC 2047로 인코딩된 헤더(From:이나 Subject:에 비 ASCII 문자)는 단순한 파서를 망가뜨려요
Google과 Microsoft API는 속도 제한(rate limiting)을 적용합니다. 새벽 3시에 이메일 30,000개를 처리하는 배치 중 429 Too Many Requests 오류가 발생하면, 스크립트가 중단되고 어디서 멈췄는지 아무도 모릅니다
롤백 메커니즘이 없어요. 처리 중에 메시지가 손상되면 되돌아갈 방법이 없습니다

Redate.io는 원본 이메일 각각의 사본을 30일간 눈에 보이는 백업 폴더에 보관합니다. 모든 수정은 개별적으로 검증되고, 분석 파이프라인은 수백 가지 알려진 마이그레이션 도구 시그니처와 직접 만든 스크립트라면 처리하지 못할 모든 엣지 케이스를 처리해요.

사용한 도구별 구체적인 내용이 궁금하다면: BitTitan MigrationWiz 이메일 날짜 오류 수정이나 CloudM Migrate 잘못된 이메일 날짜 수정을 참고하세요.

변경되는 것과 절대 변경되지 않는 것

작업	로컬 클라이언트 표시	서버 INTERNALDATE	제공업체 로그	DKIM 검증
.eml 파일 편집	경우에 따라 변경됨	변경 없음	변경 없음	Date: 서명된 경우 무효
시스템 시계 변경	효과 없음	변경 없음	변경 없음	변경 없음
Thunderbird 조작 (IMAP)	일시적으로 변경됨	변경 없음	변경 없음	변경 없음
Redate.io 수정 (마이그레이션 후)	수정됨	수정됨	변경 없음	유지됨

구분이 명확하죠. 표의 첫 세 줄은 피상적이거나 탐지 가능한 수정을 설명합니다. 마지막 줄은 마이그레이션으로 인해 발생한 불일치를, 메시지 원본 내용에 맞춰 메타데이터를 정당하게 수정하는 작업을 설명해요.

imapsync, BitTitan, CloudM, 또는 다른 도구를 사용한 마이그레이션 후 표의 마지막 줄에 해당하는 상황이라면, Redate.io가 바로 그 문제를 위해 만들어졌습니다.

이메일에 원래 날짜 대신 마이그레이션 날짜가 표시되고 있나요? Redate.io로 사서함을 무료로 스캔하고 결정을 내리기 전에 몇 개의 이메일이 영향을 받았는지 정확히 확인해 보세요.

수신 이메일 날짜 변경: 가능한가, 불가능한가?