POP до IMAP: старі листи датовані сьогодні

Класичний сценарій понеділкового ранку

Ви щойно перевели поштовий акаунт з POP3 на IMAP. Налаштування було простим, провайдер допоміг, все пройшло гладко. Аж поки Ви знову не відкрили папку «Вхідні». Листи з 2019-го, 2021-го, архіви за минулий рік... всі показують одну й ту саму дату: сьогодні. Іноді навіть той самий час, з точністю до кількох секунд.

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

POP3 проти IMAP: принципова різниця у зберіганні

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

З POP3 сервер служить лише тимчасовою поштовою скринькою. Ваш клієнт (Outlook, Thunderbird, Apple Mail) підключається, завантажує повідомлення, а потім видаляє їх із сервера (або залишає, залежно від налаштувань). Листи після цього живуть виключно локально: у файлі .pst для Outlook, у локальному профілі Thunderbird, у базі даних на жорсткому диску.

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

Проблема виникає саме під час переходу між двома протоколами. Коли Ви завантажуєте старі локальні листи POP на сервер IMAP.

IMAP APPEND: команда, яка змінює все

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

Сервер отримує повідомлення, записує його і присвоює йому мітку часу. Ця мітка і є INTERNALDATE. Це центральний метаданих IMAP: він вказує, коли повідомлення було розміщено на сервері. І якщо клієнт не вказує явно дату в команді APPEND, сервер використовує... поточний момент.

Інакше кажучи: неважливо, що в заголовках повідомлення стоїть дата 2018 року. Якщо ніхто не каже серверу «цей лист датований 2018 роком», сервер вирішує, що він щойно надійшов, і присвоює йому INTERNALDATE сьогоднішнього дня.

(До речі, якщо Ви колись переглядали необроблені заголовки листа, то бачили рядок Date: серед десятка рядків Received:. Саме це поле Date:, визначене стандартом RFC 2822, містить справжню дату відправлення. Але INTERNALDATE в IMAP - це окремий метаданих, що зберігається на стороні сервера і не має нічого спільного з вмістом самого повідомлення.)

Чому це відрізняється від міграції IMAP-до-IMAP

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

У Вашому випадку Ви починаєте з суто локальних даних. Немає вихідного INTERNALDATE для копіювання. Файл .pst або профіль Thunderbird зберігає повідомлення у власному форматі з власними внутрішніми метаданими. Коли поштовий клієнт зчитує ці повідомлення для завантаження на сервер IMAP, він відновлює команду APPEND з вмісту повідомлення. І здебільшого не передає явної дати.

Результат: сервер IMAP отримує сотні або тисячі повідомлень за кілька хвилин і присвоює всім однаковий часовий проміжок: зараз.

Саме тому проблема миттєво поширюється на всі Ваші пристрої. Телефон, планшет, другий комп'ютер: всі підключаються до того самого сервера IMAP і бачать одне й те саме. Ніякого виправлення на стороні клієнта бути не може.

Який клієнт що показує і чому

Не всі поштові клієнти поводяться однаково. Це те, що багато IT-адміністраторів відкривають для себе заднім числом.

Outlook (у нових версіях, особливо після оновлень 2023-2024 років) використовує INTERNALDATE сервера для стовпця «Отримано». Тому відображає дату завантаження, а не оригінальну дату відправлення. Докладніше про цю поведінку Outlook читайте тут: Outlook: дата отримання IMAP vs дата відправлення.

Gmail / Google Workspace і Thunderbird поводяться дещо інакше. Gmail, наприклад, іноді може використовувати поле Date: з заголовка повідомлення для відображення, що створює враження, ніби все гаразд... аж поки Ви не спробуєте відсортувати за датою і не виявите, що порядок повністю хаотичний.

Apple Mail зазвичай відображає дату з заголовка Date:, але сортування і пошук у фоні використовують INTERNALDATE. Тому листи можуть «здаватися» правильно датованими візуально, але функція сортування більше не працює коректно. Детально про поведінку Apple Mail читайте тут: Apple Mail: неправильна дата після міграції.

Хороша новина: оригінальна дата збережена

Заголовок Date: кожного листа, той, що містить справжню дату відправлення (або отримання), не зачеплений. Він досі там, у тілі повідомлення. Саме його Ви бачите, коли відкриваєте лист і дивитеся на деталі.

Сервер IMAP «зламав» лише INTERNALDATE, цей зовнішній метаданих повідомлення. Саме повідомлення не пошкоджене.

Саме це робить виправлення можливим. І саме тому проблема може довго лишатися непоміченою: листи виглядають правильно, коли Ви відкриваєте їх по одному. Проблема стає видимою лише при перегляді списку папки «Вхідні», відсортованого за датою. Листи з 2019 року з'являються вгорі, ніби щойно надійшли. Всі з однією датою.

Проблема масштабу: 3000 листів - це не те саме, що 3

Можливо, Ви думаєте: «Просто видалю і імпортую повторно, цього разу правильно». На п'яти-десяти тестових листах - так, спрацює. На скриньці з 8000 повідомлень із вкладеними папками, великими вкладеннями, листами з підписом S/MIME і гілками листування, що сягають 2015 року... це вже інша справа.

Самописний скрипт, який відпрацьовує на тестовій вибірці з 50 листів, цілком може породжувати дублікати, губити вкладення або ламати гілки листування у продуктивній скриньці. Управління квотами API, мережеві таймаути, повідомлення з нестандартними структурами MIME... все це граничні випадки, з якими неспеціалізований інструмент не справляється.

А якщо щось піде не так у середині процесу? Без механізму резервного копіювання і відкату Ви втратите дані без можливості їх відновити.

Ця проблема добре відома адміністраторам, що керують масштабними міграціями. Зрозуміти, чому дати зламані, - одна річ. Коректно виправити 15 000 листів, зберігши кожну структуру повідомлення, - зовсім інша. Докладніше про це читайте у статті Чи можна виправити дати листів після завершення міграції?.

Як Redate.io обробляє цей конкретний випадок

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

Багатоетапний конвеєр аналізу досліджує ланцюжок заголовків кожного повідомлення, перевіряє відповідність RFC і відновлює метадані дати без зміни вмісту повідомлення: ані тексту, ані вкладень, ані структури MIME, ані цифрових підписів. Кожен виправлений лист перевіряється індивідуально перед підтвердженням.

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

Початкове сканування безкоштовне: Redate аналізує Вашу скриньку, визначає уражені листи і повідомляє точну кількість до того, як Ви приймете будь-яке рішення. Ніякого сліпого зобов'язання.

Redate.io підключається безпосередньо до Ваших скриньок через Google Workspace (делегування домену), Microsoft 365 (Azure AD) або безпосередньо через IMAP. Жодної локальної установки. Жодного ручного маніпулювання файлами .pst.

Адміністраторам, що керують кількома скриньками і хочуть дізнатися більше про такі випадки, стане в пригоді стаття MSP: виправлення дат пошти клієнтів. А щодо особливостей виправлення в Thunderbird, який має власну поведінку під час переходу з POP на IMAP, дивіться Thunderbird: хибна дата після міграції.

Якщо все ще попереду: як уникнути проблеми

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

• Перевірте, чи підтримує Ваш поштовий клієнт явну передачу дати в команді APPEND. Thunderbird, наприклад, поводився по-різному залежно від версії саме в цьому питанні.
• Спочатку зробіть тест на перевірочному акаунті з 50-100 репрезентативними повідомленнями: старі листи, з вкладеннями, підписані листи. Перевірте дати відображення в різних клієнтах.
• Плануйте виправлення до того, як кінцеві користувачі почнуть працювати з мігрованою скринькою. Виправляти дати в активній скриньці складніше, ніж у щойно мігрованій.
• Документуйте кількість листів до і після міграції. Це єдиний спосіб виявити непомітні втрати.

Повний чекліст точок перевірки до і після міграції наведено у статті Чекліст міграції пошти: уникнути проблем з датами.

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