Thunderbird에서 수동 IMAP 복사 날짜 수정

Thunderbird는 IMAP 계정 간 이메일 마이그레이션을 기만적으로 쉽게 만듭니다. 두 계정을 추가하고, 메시지를 선택하고, 우클릭 후 "복사". 끝입니다. 다만 대상 서버의 날짜는 이제 잘못되었고, Thunderbird는 이에 대해 경고하지 않습니다.

Thunderbird가 대상 IMAP 서버에 메시지를 업로드할 때 원래 INTERNALDATE를 지정하지 않고 APPEND 명령을 발행합니다. 대상 서버는 이런 상황에서 모든 IMAP 서버가 하는 것을 합니다. 업로드 타임스탬프를 INTERNALDATE로 기록하고 현재 날짜의 자체 Received 헤더를 추가합니다. 이메일 본문 내의 원본 Date 헤더는 그대로 유지되지만, 서버 수준의 메타데이터는 영구적으로 덮어쓰여집니다.

여기서 기만적인 부분이 있습니다. Thunderbird의 기본 열 레이아웃은 "날짜" 열을 표시하며, 이것은 아직 올바른 Date 헤더에서 가져옵니다. 그래서 8,000통의 메시지를 복사한 직후 Thunderbird를 확인하면 모든 것이 정상으로 보입니다. 날짜가 정상입니다. 문제 해결, 맞나요?

아닙니다. 서버 측 INTERNALDATE가 손상되었습니다. 그리고 INTERNALDATE가 바로 다른 모든 이메일 클라이언트가 사용하는 것입니다. 같은 계정에 Outlook을 연결하면 모든 이메일에 마이그레이션 날짜가 표시됩니다. Apple Mail을 열어도 같은 문제입니다. Thunderbird 자체에서도 "받은 날짜" 열을 추가하면 진짜 피해가 드러납니다. 서버 측 IMAP 검색 명령(SEARCH SINCE, SEARCH BEFORE)은 Date 헤더가 아닌 INTERNALDATE를 참조합니다. Thunderbird의 기본 보기가 감추고 있지만, 이메일 기록은 프로토콜 수준에서 조용히 깨져 있습니다.

Thunderbird의 기본 설정에서 시각적 피해는 적습니다. "날짜" 열은 여전히 올바르게 보입니다. 하지만 "받은 날짜" 열을 활성화하면 손상이 분명해집니다. 복사된 모든 메시지가 복사 날짜를 표시합니다. 수신 날짜별 서버 측 정렬은 말도 안 되는 시간순서를 만듭니다. Thunderbird의 빠른 필터 바가 날짜 범위로 필터링할 때 서버에 INTERNALDATE를 사용하여 쿼리하므로 복사된 메시지에 대해 부정확한 결과를 반환합니다.

진짜 위험은 Thunderbird를 넘어 확장됩니다. 같은 IMAP 계정에 연결하는 다른 모든 클라이언트(Outlook, Apple Mail, 모바일 이메일 앱)는 기본적으로 잘못된 날짜를 표시합니다. IMAP을 통해 아카이빙하는 백업 도구는 손상된 INTERNALDATE를 캡처합니다. Thunderbird에서 수신 날짜 기반으로 작동하는 메시지 필터는 INTERNALDATE를 사용하여 메시지를 잘못 분류할 수 있습니다. Redate.io의 헤더 체인 분석과 날짜 메타데이터 재구성 프로세스는 서버 자체의 INTERNALDATE를 수정합니다. 이는 이후에 연결하는 모든 클라이언트(Thunderbird, Outlook, 모바일 앱, 백업 도구)가 추가 설정 없이 올바른 날짜를 보게 된다는 뜻입니다.