Змінити дату листа: технічні обмеження

У листа три "дати". Не одна.

Коли хтось каже "змінити дату отриманого листа", більшість уявляє щось на кшталт редагування дати створення файлу у Windows. Насправді все складніше. Кожен лист містить три окремі шари датування, кожен із власними правилами, власними обмежувачами і власними наслідками при втручанні.

Зрозуміти ці три шари означає зрозуміти, чому одні виправлення технічно обґрунтовані, а інші або неможливі, або одразу розпізнаються як підробка.

Шар 1: INTERNALDATE у IMAP

INTERNALDATE - це метадані на боці сервера, поза тілом самого листа. Вони не є частиною вмісту повідомлення. Їх встановлює IMAP-сервер, і саме їх більшість поштових клієнтів використовує для сортування листів у списку.

Outlook, наприклад, за замовчуванням сортує повідомлення за INTERNALDATE. Gmail також, у певних контекстах. Тому якщо INTERNALDATE хибна, усі листи здаються однаковою датою в інтерфейсі, незалежно від того, що вказано у внутрішніх заголовках повідомлення.

INTERNALDATE встановлюється в момент доставки повідомлення на сервер. За протоколом IMAP єдиний спосіб її "змінити" є непрямим: треба використати команду APPEND, щоб помістити нову копію повідомлення з потрібною датою. Команди SETINTERNALDATE в IMAP не існує. Цей нюанс стане важливим трохи згодом.

Шар 2: заголовок Date: (RFC 2822)

Це поле Date: у сирих заголовках листа. Його встановлює поштовий клієнт під час надсилання, і воно мандрує разом із повідомленням від сервера до сервера. Це задекларована відправником дата відправлення.

(До речі, якщо Ви ніколи не дивилися на сирі заголовки листа, це досить незвичне читання. Кожне повідомлення тягне за собою близько двадцяти рядків технічних даних, яких 99 % людей ніколи не бачили.)

Технічно ніщо не заважає надіслати лист із заздалегідь зміненою датою у полі Date:. SMTP-сервери це поле не перевіряють. Але сервери-одержувачі фіксують реальний час надходження в заголовках Received:, що одразу створює невідповідність, помітну будь-якому поштовому клієнту або інструменту аналізу.

Шар 3: ланцюжок заголовків Received:

Щоразу, коли SMTP-сервер передає повідомлення далі, він додає заголовок Received: на початок стека з позначкою часу. Лист, що пройшов три сервери, матиме три заголовки Received:. Їх читають знизу вгору: найдавніший знизу, найновіший зверху.

Саме тут інструменти міграції й створюють проблему. Коли BitTitan MigrationWiz, CloudM, imapsync або GSMMO мігрують лист, вони повторно вставляють його на новий сервер через IMAP. Це вставлення генерує новий заголовок Received: з позначкою часу моменту міграції. Результат: найстаріший лист у скриньці, написаний у 2019 році, раптом отримує Received: датований листопадом 2024-го. А оскільки деякі клієнти (насамперед Outlook) використовують найновіший Received: як дату відображення...

Ось і проблема. 15 000 листів показують однакову дату міграції.

Чи справді можна "змінити" ці дати?

Технічно так для INTERNALDATE (з певними обмеженнями). Технічно можливо, але марно для Date:. А щодо Received: - варто зупинитися детальніше.

Переписати заголовок Received: просто. І одразу помітно.

Заголовок Received: - це просто рядок тексту всередині повідомлення. Його можна редагувати як будь-який текстовий файл. Все справді настільки просто, як здається.

Але ось що відбувається далі.

Перша проблема: DKIM. Підпис DKIM (DomainKeys Identified Mail) обчислюється на основі набору заголовків повідомлення, іноді включно з Received:. Зміна підписаного заголовка анулює підпис. Будь-який сервер-одержувач, що перевіряє DKIM, одразу побачить, що повідомлення було змінено. Це не тонка підробка - це сигнал тривоги.

Друга проблема: внутрішні ідентифікатори. Сучасні поштові сервери (Google Workspace, Microsoft 365) присвоюють кожному повідомленню унікальний зростаючий внутрішній ідентифікатор. Ці ідентифікатори пов'язані з INTERNALDATE та порядком надходження. Зміна Received: без узгодженості з цими ідентифікаторами створює невідповідності, які інструменти аудиту виявляють без жодних труднощів.

Третя проблема, суто практична: навіть якщо Ви змінили Received: у тілі повідомлення, INTERNALDATE залишається датою IMAP-вставлення. Поштовий клієнт продовжує показувати хибну дату при сортуванні. Зміну зроблено дарма.

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

Заголовок Date:: змінити минуле на папері

Та сама логіка стосується і Date:. Його можна змінити у тілі повідомлення. Але заголовки Received:, автентифіковані проміжними серверами, залишаться недоторканими і розкажуть іншу історію. Часова послідовність стає невідповідною. Будь-який аналітик або суд, що порівнює ці поля, побачить це одразу.

Якщо бути точним: це не заважає деяким поштовим клієнтам відображати змінений Date:, якщо їм напряму підсунути файл .eml. Але в контексті живого поштового сервера з автентифікацією та журналами зміна стає прозорою.

Міграція IMAP: єдиний контекст, де виправлення дат виправдане

Є один, і лише один випадок, коли зміна дати отриманого листа не просто можлива, а технічно обґрунтована: виправлення пошкоджень, спричинених некоректно проведеною IMAP-міграцією.

Ось конкретна ситуація. Ви щойно перенесли 80 поштових скриньок Exchange до Microsoft 365. Міграція завершилась у п'ятницю ввечері. У понеділок вранці починають надходити перші заявки: "Всі листи мають однакову дату", "Не можу знайти лист річної давності", "Вся переписка з цим клієнтом повністю зламана". У Вас 80 заблокованих користувачів і керівник, який чекає відповіді.

У цьому контексті проблема задокументована, ідентифікована, причина зрозуміла: інструмент міграції додав Received: датований днем міграції, і деякі поштові клієнти використовують цей новий заголовок як дату відображення. При цьому оригінальний заголовок Date: у кожному листі залишився недоторканим. Він ніколи не змінювався. Він досі містить правильну оригінальну дату відправлення.

Тому виправлення - це не підробка, а відновлення. Відправна точка - достовірні дані (оригінальний Date:), на основі яких реконструюються узгоджені метадані. Це принципово відрізняється від спроби видати лист 2024 року за лист 2019-го.

Для детальнішого розгляду механізмів, специфічних для кожного інструменту, ось відповідні посібники: виправлення дат BitTitan у Microsoft 365, виправлення дат CloudM в Outlook, або виправлення дат imapsync у Google Workspace.

Чому писати скрипт самостійно ризиковано

Базова логіка доступна. Будь-який IT-адмін, що провів достатньо часу на IMAP-форумах, може відтворити загальний підхід. Це не проблема.

Проблема - це прірва між скриптом, що працює на 50 тестових листах, і скриптом, який обробляє 40 000 повідомлень у продакшн-середовищі без втрати жодного листа, без пошкодження жодного вкладення і без порушення жодного ланцюжка розмов.

Кілька конкретних випадків, з якими саморобні скрипти зазвичай не справляються:

• Листи з підписом S/MIME: підпис охоплює вміст і заголовки. Будь-яка зміна структури повідомлення анулює підпис. Невміло виправлений підписаний лист доходить до одержувача як "недійсний підпис".
• Зашифровані PGP-повідомлення: та сама родина проблем, з потенційно гіршими наслідками залежно від реалізації.
• Не-ASCII-кодування в заголовках: RFC 2047 описує кодування спеціальних символів у заголовках. Скрипт, що маніпулює заголовками без урахування цих випадків, тихо пошкодить теми листів з акцентами, японськими символами або арабськими іменами.
• Ліміти API: Google Workspace і Microsoft 365 реалізують агресивне обмеження запитів. О третій ночі пакет із 10 000 листів, що наштовхнувся на помилку 429 Too Many Requests без обробки exponential backoff, залишить половину скриньок напіввиправленими.
• Пошкоджені MIME-межі: multipart-повідомлення із вкладеннями мають точні MIME-межі. Їх неправильна регенерація робить вкладення нечитабельними.

І питання, на яке жоден саморобний скрипт не відповідає: як перевірити, що кожен виправлений лист цілісний? Скрипт, що змінює 40 000 повідомлень без індивідуальної перевірки, - це азартна гра. Гра з даними, які Ваші користувачі часто вважають незамінними.

Стаття про доступні варіанти виправлення дат після міграції розглядає різні підходи, включно з їхніми відповідними обмеженнями.

Що робить Redate.io у цьому контексті

Redate.io розроблений спеціально для цього випадку: виправлення дат, пошкоджених IMAP-міграцією, у великих масштабах, без ризику для цілісності повідомлень.

Сервіс підключається напряму до потрібних скриньок (Google Workspace через делегування домену, Microsoft 365 через Azure AD або напряму через IMAP), безкоштовно сканує повідомлення з некоректними датами, а потім застосовує власний конвеєр виправлення, що обробляє граничні випадки, описані вище. Кожен лист перевіряється індивідуально після виправлення. Оригінали зберігаються у видимій резервній папці протягом 30 днів.

Розпізнавання охоплює сотні сигнатур відомих інструментів міграції: BitTitan MigrationWiz, CloudM, imapsync, GSMMO та їхні варіанти. Виявлення точне: Redate.io не чіпає листи з коректними датами.

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

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

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