Изменить дату письма: реально?

Вопрос, который задают все (и почему за ним скрываются две совершенно разные ситуации)

Введите в Google «изменить дату полученного письма». Вы найдёте десятки тредов на форумах Microsoft Q&A, обсуждений на Reddit, вопросов на Quora. Запрос понятен, но мотивы у разных людей кардинально отличаются.

Есть те, кто хочет подделать дату задним числом, по причинам, которые лучше не представлять. И есть IT-администраторы, которые после миграции IMAP видят, что все письма получили одну и ту же дату (день миграции), и хотят просто вернуть настоящие даты. Эти две ситуации не имеют ничего общего, но формулировка поискового запроса у них одна.

Эта статья отвечает на оба вопроса. Спойлер: в первом случае незаметно изменить дату практически невозможно. Во втором, это абсолютно законная операция, и именно этим занимается Redate.io.

Сначала: что такое «дата» письма?

Письмо содержит не одну дату. Их несколько, хранятся они в разных местах и контролируются разными участниками процесса.

Заголовок Date: (RFC 2822)

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

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

Этот заголовок является частью тела сообщения. Технически его можно изменить, если получить доступ к сырому файлу. Но «технически» здесь ключевое слово.

Заголовки Received:

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

INTERNALDATE в IMAP

Это наиболее важный параметр для понимания того, почему некоторые изменения не дают никакого видимого эффекта. INTERNALDATE - это атрибут, хранящийся на стороне IMAP-сервера, независимо от содержимого сообщения. Именно его большинство почтовых клиентов используют для сортировки писем по папкам. Outlook использует его. Gmail тоже. Apple Mail в большинстве случаев также.

INTERNALDATE не содержится в самом сообщении. Он хранится в базе данных сервера. Отредактировав файл .eml на диске, вы его не измените.

Что на самом деле происходит при локальном редактировании

Редактирование файла .eml

Технически файл .eml - это текстовый файл. Вы можете открыть его в редакторе, изменить строку Date:, сохранить. Если снова импортировать этот файл в локальный почтовый клиент, отображаемая дата может измениться, в зависимости от клиента.

Но вот что это не меняет:

INTERNALDATE на IMAP-сервере (остаётся нетронутым)
Заголовки Received:, добавленные промежуточными серверами
Логи доставки у Google, Microsoft или вашего провайдера
Подпись DKIM, если она была в сообщении

Результат: на вашей локальной машине вы, возможно, видите другую дату. В Outlook, подключённом к Exchange Online, или в Gmail в браузере, ничего не изменилось.

Изменение системных часов

На некоторых форумах советуют изменить системные часы компьютера, чтобы «обмануть» почтовый клиент. Это не работает. Outlook и Gmail не читают системное время для отображения дат полученных писем. Они читают INTERNALDATE с сервера или заголовки сообщения. Локальные часы в этом процессе не участвуют никак.

Манипуляции через Thunderbird

Thunderbird предоставляет больше гибкости, чем большинство клиентов. С помощью расширений или прямого редактирования профиля (файлы mbox, файлы .msf) некоторые пытаются изменить отображение дат. Это может работать в самом Thunderbird, для писем, хранящихся локально в режиме POP3. Но как только Thunderbird подключён по IMAP, он ресинхронизируется с сервером. «Исправление» исчезает при следующей синхронизации.

DKIM: невидимый барьер, о котором никто не говорит

Большинство писем, отправленных с 2018 года, подписаны с помощью DKIM (DomainKeys Identified Mail). Подпись DKIM в заголовках выглядит так:

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, не имеет юридической силы в суде или при проверке соответствия требованиям ФЗ-152, корпоративным политикам хранения данных или при расследовании инцидентов безопасности.

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

Законный случай: исправление после миграции

Вы только что завершили миграцию 150 почтовых ящиков с Exchange on-premise на Microsoft 365. В понедельник утром начинают поступать тикеты: «все мои старые письма датированы прошлой пятницей». Датой миграции.

Это хорошо задокументированная проблема, полностью отличная от того, что описано выше. Здесь никто не пытается ничего подделать. Настоящие оригинальные даты всегда целы, они по-прежнему в заголовке Date: каждого сообщения. Проблема в другом: инструмент миграции (BitTitan MigrationWiz, CloudM, imapsync или другой) вставил заголовок Received: с датой миграции в начало цепочки. Outlook, который в определённых контекстах ориентируется на самые последние заголовки Received:, а не на INTERNALDATE, и отображает эту дату.

В этом случае «исправление» состоит в том, чтобы восстановить согласованность между тем, что говорит само сообщение (оригинальный заголовок Date:, который никуда не делся), и тем, что думает сервер (INTERNALDATE, установленный в момент миграции). Это не фальсификация. Это восстановление.

Именно это описано в статье о том, почему письма показывают неправильную дату после миграции. И именно это решает Redate.io.

Почему «сделать самому» не работает в масштабе

Понять проблему, это одно. Исправить её в 40 000 писем, распределённых по 150 ящикам, не потеряв ни одного, это совсем другое.

Скрипты с GitHub или Stack Overflow работают на 20 тестовых письмах. В продакшене они сталкиваются с проблемами, которые автор скрипта не предусмотрел:

Письма, подписанные S/MIME или зашифрованные PGP, имеют структуры, которые нельзя обрабатывать как обычные сообщения
Многочастные сообщения с нестандартными MIME-границами вызывают ошибки парсинга
Заголовки, закодированные по RFC 2047 (не-ASCII символы в полях From: или Subject:), ломают наивные парсеры
API Google и Microsoft устанавливают ограничения по частоте запросов: в 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 и узнайте точное количество затронутых писем, прежде чем принимать решение.

Изменить дату полученного письма : правда или миф?