Змінити дату листа: що реально

Питання, яке задають усі (і чому за ним ховаються дві зовсім різні ситуації)

Введіть у 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, не має доказової сили в суді або під час аудиту безпеки.

Якщо бути точними: навіть адміністратор з делегованим доступом до скриньки не може переписати ці логи заднім числом. Вони недоступні для будь-яких користувачів, навіть привілейованих.

Законний випадок: виправлення після міграції

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

Це добре задокументована проблема, яка зовсім відрізняється від того, що ми щойно описали. Тут ніхто нічого не підробляє. Справжні оригінальні дати досі існують, нетронуті, в заголовку Date: кожного повідомлення. Проблема виникає в іншому місці: інструмент міграції (BitTitan MigrationWiz, CloudM, imapsync або інший) вставив заголовок Received: з датою міграції на початок ланцюжка. Outlook, який у певних контекстах орієнтується на найновіші заголовки Received: а не на INTERNALDATE, відображає саме цю дату.

У цьому випадку «виправлення» полягає у відновленні узгодженості між тим, що говорить повідомлення (оригінальний заголовок Date:, який нікуди не дівся), і тим, що думає сервер (INTERNALDATE, встановлений у момент міграції). Це не фальсифікація. Це відновлення.

Детальніше про те, чому листи показують неправильні дати після IMAP-міграції - і чому це стосується тисяч скриньок. Саме таку проблему вирішує Redate.io.

Чому самостійне виправлення не масштабується

Зрозуміти проблему - одне. Виправити 40 000 листів у 150 скриньках, не втративши жодного, - зовсім інше.

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

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

Змінити дату отриманого листа: правда чи міф?