Підробка дати листа: що можливо і що виявляється

Підробка дати листа: про що взагалі йдеться?

Це питання регулярно з'являється на форумах системних адміністраторів і в Slack-групах MSP: чи можна змінити дату листа після відправлення? Коротка відповідь - так, технічно. Але повна відповідь набагато менш втішна для тих, хто хотів би це зробити з підозрілими намірами.

Лист - це не монолітний файл. Це набір текстових заголовків, за якими йде тіло повідомлення. Серед цих заголовків кілька містять інформацію про дату. І деякі з них змінити простіше, ніж інші.

У кожному листі одночасно існують три рівні датування:

• Заголовок Date: (RFC 2822), який поштовий клієнт записує в момент відправлення
• Заголовки Received:, що додаються кожним сервером, який ретранслює повідомлення
• IMAP INTERNALDATE - метадані, що зберігаються на стороні сервера, незалежно від вмісту повідомлення

Кожен із цих рівнів можна змінити. Але жоден - без слідів.

Зміна заголовка 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: взагалі неможливо підробити: зловмисник, який контролює власну поштову інфраструктуру, може сфабрикувати правдоподібні заголовки для ретрансляторів, якими він керує. Але останню ланку він ніколи не контролює: сервер одержувача.

IMAP INTERNALDATE: найтехнічніший випадок

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, відображає дату міграції для всіх повідомлень. Чому листи показують неправильні дати після IMAP-міграції детально пояснює цей механізм.

Оригінальний заголовок 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 о третій ночі при зверненні до API Google - це багаторівневий аналітичний конвеєр із обробкою граничних випадків (S/MIME, PGP, кодування не-ASCII за RFC 2047, складні multipart-структури). Python-скрипт на п'ять рядків не витримає першої виробничої скриньки. Чи можна виправити дати листів після завершення міграції детально пояснює, чому самостійний підхід ризикований на реальних обсягах.

Redate.io безкоштовно сканує поштові скриньки, визначає листи з неправильними датами і виправляє їх через конвеєр валідації, що перевіряє кожне повідомлення окремо. Оригінали зберігаються у видимій резервній папці впродовж 30 днів. Якщо щось піде не так, відкат можливий.

Після міграції дати Ваших листів зсунулись? Запустіть безкоштовне сканування на Redate.io, щоб оцінити масштаб проблеми, перш ніж вирішувати, що робити.