Чому листи показують неправильні дати після IMAP-міграції

8 min

Універсальна проблема дат міграції

Після IMAP-міграції електронної пошти користувачі відкривають свою поштову скриньку та виявляють, що кожен лист показує одну й ту саму дату - дату міграції. П'ять років листування, тисячі повідомлень, і всі вони виглядають так, ніби надійшли в один і той самий день. Це не помилка конкретного інструменту міграції. Це відбувається з BitTitan MigrationWiz, CloudM, imapsync, Exchange Migration та практично з кожним інструментом, що використовує IMAP для переміщення листів між серверами.

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

Як працюють дати листів

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

Кожен лист містить заголовок "Date", визначений стандартом RFC 2822. Цей заголовок встановлюється поштовим клієнтом відправника в момент відправлення листа. Він фіксує точну дату й час, коли повідомлення було створено. Ось приклад:

Date: Mon, 15 Jan 2024 09:30:00 +0100

Заголовок "Date" є частиною самого повідомлення. Він ніколи не змінюється поштовими серверами під час доставки. Він зберігається всередині заголовків листа протягом усього його існування.

Заголовки "Received"

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

Received: from mail-server-b.example.com by mail-server-c.example.com;
  Mon, 15 Jan 2024 09:30:05 +0100
Received: from mail-server-a.example.com by mail-server-b.example.com;
  Mon, 15 Jan 2024 09:30:02 +0100

Верхній заголовок "Received" (останній доданий) відображає останній стрибок - коли лист досяг кінцевого сервера-одержувача. Це те, що більшість поштових клієнтів використовують як дату "Отримано".

IMAP INTERNALDATE

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

Як поштові клієнти вибирають, яку дату відображати

Різні поштові клієнти використовують різні комбінації цих значень:

  • Microsoft Outlook: Відображає дату "Отримано" на основі верхнього заголовка "Received" та/або INTERNALDATE
  • Gmail: Використовує INTERNALDATE для позиціонування повідомлення в хронології та заголовок "Date" для відображуваної дати
  • Apple Mail: Використовує INTERNALDATE для сортування та заголовок "Date" для відображення
  • Thunderbird: Використовує заголовок "Date" для стовпця "Дата" та заголовок "Received" для стовпця "Отримано"

Що відбувається під час IMAP-міграції

Процес міграції

Під час IMAP-міграції інструмент виконує три основні кроки для кожного листа:

  1. Завантаження: Отримання необробленого повідомлення з вихідного сервера через IMAP FETCH
  2. Обробка: Можливе перетворення формату або модифікація заголовків
  3. Завантаження: Додавання повідомлення на цільовий сервер через IMAP APPEND

Під час кроку завантаження інструмент міграції часто додає новий заголовок "Received" до повідомлення. Цей заголовок містить мітку часу, що відповідає моменту обробки повідомлення міграцією.

Що додає інструмент міграції

Кожен інструмент міграції додає свій характерний заголовок "Received":

BitTitan MigrationWiz:

Received: from mx.migrationwiz.com by destination-server;
  Thu, 11 Apr 2019 14:22:33 +0000

CloudM:

Received: from cloudm-migration-server (processing-node.cloudm.io)
  by destination-server; Wed, 15 May 2024 09:14:22 +0000

imapsync:

Received: from localhost (imapsync) by destination-server;
  Tue, 20 Feb 2024 16:45:11 +0000

Google Workspace Migration:

Received: from gmailapi.google.com by destination-server;
  Fri, 12 Apr 2019 08:33:44 +0000

Проблема INTERNALDATE

На додаток до заголовка "Received", команда IMAP APPEND, що використовується для завантаження листа на цільовий сервер, може встановити INTERNALDATE. Деякі інструменти міграції правильно зберігають оригінальний INTERNALDATE, тоді як інші дозволяють серверу встановити INTERNALDATE на поточний час (час міграції). Коли INTERNALDATE встановлено неправильно, навіть поштові клієнти, які зазвичай ігнорують заголовки "Received", відображають неправильну дату.

Чому кожен інструмент міграції має цю проблему

Це не помилка, а особливість протоколу

Додавання заголовка "Received" при обробці листа відповідає стандартам електронної пошти. RFC 5321 визначає, що кожен поштовий сервер, який обробляє повідомлення, повинен додати заголовок "Received". Інструменти міграції діють як проміжний поштовий сервер під час процесу - вони отримують повідомлення з одного місця та доставляють його в інше. Додавання заголовка "Received" технічно коректне.

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

Чому інструменти міграції не виправляють це

Інструменти міграції зосереджені на переміщенні даних, а не на збереженні дат. З технічної точки зору вони виконують свою основну функцію: кожен лист успішно доставлений від вихідного до цільового сервера. Проблема з датами - це побічний ефект переміщення, а не помилка в процесі.

Крім того, виправлення проблеми з датами вимагає складної логіки: виявлення, які заголовки "Received" були додані під час міграції (а не під час оригінальної доставки), видалення лише тих заголовків та повторне додавання повідомлення з правильним INTERNALDATE. Ці операції виходять за рамки того, що робить інструмент міграції.

Які поштові клієнти зачеплені

Microsoft Outlook

Outlook найбільше зачеплений, оскільки він значною мірою покладається на заголовок "Received" та INTERNALDATE для стовпця "Отримано". Після міграції кожен лист показує дату міграції в цьому стовпці. Для детальної інформації про виправлення дат Outlook, див. виправлення неправильної дати в Outlook після міграції.

Веб-інтерфейс Gmail

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

Apple Mail

Apple Mail використовує INTERNALDATE для сортування та заголовок "Date" для відображення. Після міграції листи можуть відображати правильну дату відправлення, але з'являтися в неправильному порядку сортування, створюючи заплутану невідповідність між відображуваною датою та позицією в списку повідомлень.

Thunderbird

Thunderbird дозволяє користувачам вибирати між відображенням заголовка "Date" або "Received" у стовпці дати. Користувачі, які відображають стовпець "Отримано", побачать дату міграції. Користувачі, які відображають стовпець "Дата", побачать оригінальну дату відправлення, але порядок сортування може все одно базуватися на неправильному INTERNALDATE.

Технічне виправлення

Що потрібно зробити

Виправлення проблеми з датами вимагає двох змін для кожного ураженого листа:

  1. Видалення заголовка "Received", доданого міграцією: Заголовок "Received", вставлений інструментом міграції, потрібно видалити з ланцюжка заголовків. Це дозволяє поштовим клієнтам повернутися до наступного легітимного заголовка "Received".
  2. Корекція INTERNALDATE: INTERNALDATE потрібно скинути до оригінальної дати доставки (отриманої з оригінального заголовка "Date" або легітимного заголовка "Received").

Чому це складніше, ніж здається

Видалення заголовка "Received" з листа - це не просте видалення рядка з текстового файлу. Листи мають складну структуру:

  • Кодування MIME: Листи можуть використовувати різні типи Content-Transfer-Encoding (base64, quoted-printable, 7bit, 8bit), і модифікація заголовків потребує коректної обробки для збереження декодування тіла
  • Багаточастинні межі: Листи з вкладеннями або HTML-контентом використовують MIME-межі для розділення частин. Одна неправильна зміна може зрушити межі та зробити вкладення нечитабельними
  • Цифрові підписи: S/MIME-підписані листи включають криптографічний підпис, що охоплює частину заголовків. Неправильна обробка може зламати перевірку підписів
  • Кодування символів: Заголовки можуть використовувати RFC 2047-кодування для не-ASCII символів (наприклад, тем листів іншими мовами). Парсинг заголовків повинен правильно обробляти це кодування

Як Redate.io це обробляє

Пропрієтарний механізм корекції Redate.io створено для обробки всієї складності форматів електронної пошти. Redate.io аналізує повний ланцюжок заголовків кожного повідомлення, застосовує зіставлення шаблонів для виявлення заголовків "Received", доданих міграцією (з використанням бази даних сотень відомих сигнатур інструментів міграції), та виконує виправлення з повною перевіркою цілісності. Кожне виправлене повідомлення порівнюється з оригіналом для підтвердження нульової втрати даних.

Профілактика проти лікування

Чи можна запобігти проблемі дат під час міграції?

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

Що якщо міграція вже відбулася?

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

Часті запитання

Чи всі інструменти міграції спричиняють цю проблему?

Практично всі інструменти IMAP-міграції додають заголовок "Received" під час обробки. Це включає BitTitan MigrationWiz, CloudM, imapsync, Exchange Migration, Google Workspace Migration та багато інших. Конкретний вплив залежить від інструменту та конфігурації, але основна проблема є універсальною.

Чому заголовок "Date" не виправляє відображення?

Заголовок "Date" фіксує дату відправлення, а не отримання. Більшість поштових клієнтів відображають дату "Отримано" на основі заголовка "Received" або INTERNALDATE. Навіть якщо заголовок "Date" правильний, відображувана дата "Отримано" базується на інших значеннях - які були змінені під час міграції.

Чи може поштовий сервер виправити дати автоматично?

Ні. Ні Google Workspace, ні Microsoft 365, ні будь-який IMAP-сервер не надають вбудованої функції масової корекції дат. Поштові сервери зберігають повідомлення як є після доставки (або міграції). Зміна збережених заголовків або INTERNALDATE вимагає зовнішнього інструменту, який повторно додає повідомлення з правильними значеннями.

Чи втрачається коли-небудь оригінальна інформація про дату?

Ні. Заголовок "Date" є частиною тіла повідомлення згідно RFC 2822 і ніколи не модифікується поштовими серверами або інструментами міграції. Поки оригінальний лист існує на сервері, оригінальна інформація про дату доступна для відновлення. Ось чому виправлення працює місяцями та роками після міграції.

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