Изменить дату письма: возможно и обнаружимо

Изменить дату письма: о чём вообще речь?

Этот вопрос регулярно всплывает на форумах системных администраторов и в Slack-группах MSP: можно ли изменить дату письма после отправки? Короткий ответ - да, технически. Но полный ответ куда менее обнадёживающий для тех, кто хотел бы сделать это в сомнительных целях.

Письмо - это не монолитный файл. Это набор текстовых заголовков, за которыми следует тело сообщения. Среди этих заголовков несколько содержат информацию о дате. И некоторые из них изменить проще, чем другие.

В каждом письме сосуществуют три уровня датирования:

• Заголовок Date: (RFC 2822), записываемый почтовым клиентом в момент отправки
• Заголовки Received:, добавляемые каждым сервером, через который проходит сообщение
• INTERNALDATE IMAP - метаданные, хранящиеся на стороне сервера, независимые от содержимого сообщения

Каждый из этих уровней можно изменить. Ни один из них - без следов.

Изменение заголовка Date:: самая очевидная манипуляция

Заголовок Date: - это обычный текст в файле .eml. Технически любой hex-редактор или скрипт на Python может переписать его за несколько секунд. Если вы когда-нибудь открывали исходный код письма в Gmail (маленькое меню «Показать оригинал»), вы знаете: это читается без каких-либо инструментов.

Проблема в другом. С 2004 года подавляющее большинство почтовых серверов подписывают исходящие письма с помощью DKIM (DomainKeys Identified Mail). Эта криптографическая подпись явно охватывает несколько заголовков: Date:, From:, Subject: и тело сообщения. Подпись хранится в заголовке DKIM-Signature:.

Изменение Date: после подписания автоматически делает проверку DKIM недействительной. Любой принимающий сервер может проверить подпись, получив публичный ключ из DNS домена отправителя. Если подпись не совпадает, сообщение помечается как изменённое. Gmail, Outlook.com и все крупные провайдеры делают эту проверку автоматически.

(Кстати, если хотите увидеть подпись DKIM своими глазами, откройте исходный код любого письма от Gmail или Office 365: там будет строка DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., которая выглядит как случайный шум, но на самом деле является криптографическим хешем всего сообщения.)

Итог: изменить Date: в письме с подписью DKIM - значит сломать печать. Модификация видна любому администратору, который знает, где искать.

Переписать заголовки Received:: цепочка, которую сложно подделать

Заголовки Received: отслеживают путь письма от отправителя к получателю. Каждый SMTP-сервер, через который проходит сообщение, добавляет свой заголовок с именем, IP-адресом и временной меткой. Письмо, прошедшее через два-три ретранслятора, содержит два-три заголовка Received:, наложенных друг на друга.

Можно ли их изменить? Технически - да, в своей копии сообщения. Но вот в чём ловушка: у получателя тоже есть копия. И его сервер добавил свой заголовок Received: последним. Этот заголовок находится под контролем получателя, а не отправителя. Подделать его снаружи невозможно.

Согласованность цепочки поддаётся проверке. Если временные метки последовательных заголовков Received: противоречат друг другу (например, промежуточный ретранслятор получил сообщение раньше, чем отправитель его отправил), это сразу вызывает подозрение. Инструменты форензики электронной почты вроде MXToolbox или внутренние инструменты команд безопасности проверяют именно это.

Если быть точным, говорить о полной невозможности подделки заголовков Received: не совсем верно: злоумышленник, контролирующий собственную почтовую инфраструктуру, может создать правдоподобные заголовки для тех ретрансляторов, которые он контролирует. Но последнее звено, сервер получателя, ему никогда не подвластно.

INTERNALDATE в IMAP: самый технический случай

INTERNALDATE - это метаданные IMAP, хранящиеся на стороне сервера. Это не заголовок в самом сообщении: это значение, которое сервер связывает с сообщением в своей внутренней базе данных. Именно это значение большинство почтовых клиентов используют для сортировки сообщений в папке «Входящие».

Команда IMAP APPEND позволяет поместить сообщение на сервер, явно указав INTERNALDATE. Это легитимная функция протокола, задокументированная в RFC 3501. Инструменты миграции используют её постоянно: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... все они помещают письма на целевой сервер с указанным значением INTERNALDATE.

Теоретически кто-то с IMAP-доступом к своему почтовому ящику мог бы поместить письмо с любым значением INTERNALDATE. Но эта манипуляция не меняет заголовки сообщения. Исходный Date: остаётся нетронутым, заголовки Received: остаются нетронутыми, подпись DKIM остаётся нетронутой. Меняются только метаданные сортировки на стороне сервера.

Для эксперта, изучающего исходный код сообщения, расхождение между INTERNALDATE и Date: заметно сразу. А если сообщение подписано DKIM, исходная дата криптографически подтверждена.

Message-ID: отпечаток, который сложно подделать

Каждое письмо получает уникальный идентификатор - заголовок Message-ID:. Этот идентификатор формируется SMTP-сервером отправителя в момент отправки, как правило путём объединения временной метки, случайного идентификатора и доменного имени сервера.

Типичный Message-ID выглядит так: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Временная метка нередко закодирована прямо в идентификаторе. Изменение даты письма при сохранении Message-ID с несовместимой временной меткой создаёт несоответствие, которое заметно сразу.

Кроме того, Message-ID индексируются крупными почтовыми системами. Google, Microsoft и другие игроки ведут логи, позволяющие отследить, когда именно сообщение реально проходило через их инфраструктуру. В правовом или форензическом контексте эти логи доступны через судебные процедуры.

На практике: кто может обнаружить попытку манипуляции?

Поставим вопрос конкретно. Вы получили письмо, и подозреваете, что дата в нём изменена. Что может сделать IT-администратор или юрист с минимальным техническим багажом?

• Проверка DKIM: в Gmail меню «Показать оригинал» сразу отображает результат проверки DKIM в верхней части страницы. «PASS» подтверждает целостность сообщения с момента отправки. «FAIL» или «SOFTFAIL» сигнализирует об изменении.
• Анализ заголовков: инструменты вроде MXToolbox Header Analyzer или Google Admin Toolbox автоматически разбирают цепочку заголовков Received: и сообщают о временных несоответствиях.
• Согласованность Message-ID и Date: аналитик может сравнить временную метку, закодированную в Message-ID, со значением объявленного Date:.
• Серверные логи: если письмо прошло через сервер, которым Вы администрируете, SMTP-логи содержат реальные дату и время принятия сообщения, независимо от любых заголовков.

Словом, инструменты обнаружения доступны, бесплатны и не требуют продвинутой форензической экспертизы. Любопытный IT-администратор может проверить целостность письма менее чем за две минуты.

Единственный законный случай массового изменения дат: миграция IMAP

Существует сценарий, при котором сотни тысяч писем получают неправильные даты без каких-либо злых умыслов: миграция IMAP.

Вы только что завершили миграцию 150 почтовых ящиков Exchange на Google Workspace. В понедельник утром посыпались тикеты. Пользователи сообщают, что все старые письма отображаются с одной датой - датой выходных, когда проходила миграция. Папки «Входящие» нечитаемы.

То, что произошло, задокументировано и предсказуемо: инструмент миграции (BitTitan, CloudM, imapsync - неважно) поместил письма на Google Workspace через IMAP APPEND, указав INTERNALDATE, соответствующий дате миграции, а не исходной дате письма. В результате Outlook, сортирующий по INTERNALDATE по умолчанию, показывает дату миграции для всех сообщений. Почему письма показывают неправильную дату после миграции объясняет этот механизм подробно.

Исходный заголовок Date: в каждом сообщении нетронут. Подписи DKIM нетронуты. Содержимое не изменилось. Некорректна только INTERNALDATE на стороне сервера.

Эта проблема затрагивает BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO и все инструменты, использующие IMAP APPEND без корректного сохранения INTERNALDATE. Статья, посвящённая BitTitan MigrationWiz, охватывает особенности этого инструмента. Чеклист миграции почты перечисляет, что нужно проверить до и после миграции, чтобы избежать подобных проблем.

Разница между исправлением и подделкой

Исправление, которое выполняет Redate.io, - полная противоположность попытке фальсификации. Проприетарный движок коррекции анализирует цепочку заголовков каждого сообщения, определяет исходную дату, закодированную в заголовке Date: (RFC 2822) - который никогда не изменялся, и исправляет метаданные даты, приводя их в соответствие с этой подлинной информацией, уже присутствующей в сообщении.

Заголовок Date: - это источник истины. Он был записан почтовым клиентом отправителя в момент отправки. Он охвачен подписью DKIM. Redate.io его не изменяет. Исправляется несоответствие, внесённое инструментом миграции, а не исходная дата.

Исправить 47 000 писем после неудачной миграции, не потеряв ни одного, не сломав цепочки переписки, не повредив вложения, не получив ошибку 429 в три часа ночи при обращении к Google API - это многоступенчатый аналитический конвейер с обработкой пограничных случаев (S/MIME, PGP, не-ASCII-кодировки по RFC 2047, сложные multipart-структуры). Пятистрочный Python-скрипт не выживет на первом же производственном ящике. Можно ли исправить даты писем после миграции объясняет, почему DIY-подход рискован на реальных объёмах.

Redate.io бесплатно сканирует почтовые ящики, определяет письма с неправильными датами и исправляет их через конвейер валидации, проверяющий каждое сообщение индивидуально. Оригиналы хранятся в видимой резервной папке в течение 30 дней. Если что-то пойдёт не так, откат возможен.

Миграция сдвинула даты Ваших писем? Запустите бесплатное сканирование на Redate.io, чтобы оценить масштаб проблемы перед принятием решения.