eM Client: хибні дати після імпорту PST або Thunderbird

Симптом: всі листи мають однакову дату

Ви щойно завершили імпорт PST в eM Client або перенесли пошту з Thunderbird до нової скриньки. Імпорт пройшов без видимих помилок. Але відкривши вхідні, ви помічаєте щось дивне: сотні, а іноді й тисячі листів відображають однакову дату, а саме день імпорту. Лист із 2019 року виглядає так, ніби його отримали вчора. Контракт, підписаний три роки тому, з'являється як щойно надісланий.

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

Тому що проблема не в eM Client. Вона в метаданих сервера.

Справжня причина: INTERNALDATE IMAP перезаписується під час імпорту

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

Кожне повідомлення на IMAP-сервері має два різних типи дат:

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

Під час імпорту PST або міграції з Thunderbird інструмент імпорту (чи то вбудований модуль eM Client, сторонній інструмент, або ручне копіювання IMAP) розміщує повідомлення на цільовому IMAP-сервері. І якщо інструмент явно не зберігає оригінальний INTERNALDATE під час розміщення, сервер автоматично присвоює поточний INTERNALDATE, тобто дату й час імпорту.

Результат: 8 000 архівних листів, починаючи з 2017 року, всі позначені як "отримані" в момент вашої міграції.

(До речі, якщо Ви колись пробували читати необроблені заголовки листа через Переглянути джерело в eM Client, то могли помітити, що оригінальний заголовок Date: там є, і він цілий. Це ознака того, що проблема в INTERNALDATE сервера, а не в самому повідомленні.)

Чому зміна стовпця сортування не допомагає

Плутанина виникає через розрізнення, про яке мало хто знає. В eM Client, як і в Outlook чи Thunderbird, зазвичай є два стовпці дати:

• "Дата отримання" (або "Дата надходження"): базується на INTERNALDATE сервера.
• "Дата" або "Дата відправлення": базується на заголовку Date: повідомлення.

Багато адмінів виявляють це і думають, що знайшли рішення: перемкнутися на "Дату відправлення", і проблема зникне візуально в eM Client. Але це не зовсім так.

Насправді, навіть сортуючи за датою відправлення в eM Client, проблема залишається для всіх інших клієнтів та інтерфейсів, які мають доступ до тієї самої скриньки. Якщо Ваші користувачі перевіряють пошту через OWA, через Outlook на робочому місці, через додаток Gmail на мобільному або через будь-який інший IMAP-клієнт, вони бачитимуть дати імпорту. Налаштування сортування eM Client застосовується лише до eM Client і не впливає на метадані, що зберігаються на сервері.

Крім того, в Microsoft 365 та Google Workspace вбудований веб-інтерфейс сортує за INTERNALDATE. Змінити цю поведінку на рівні клієнта неможливо.

Сортування за датою відправлення - не рішення. Це пластир, який приховує реальну проблему, не виправляючи її.

Особливий випадок імпорту PST

Імпорт PST-файлів заслуговує окремого абзацу. PST (Personal Storage Table) - це власний формат Microsoft для зберігання листів, контактів і календарів локально. Коли Ви імпортуєте PST в eM Client, можливі два сценарії:

• Локальний імпорт до IMAP-акаунту: eM Client читає PST і надсилає повідомлення на цільовий IMAP-сервер. Якщо дата розміщення не зберігається, INTERNALDATE перезаписується. Це найпоширеніший випадок, і саме тут дати виявляються пошкодженими.
• Імпорт до локальної папки: повідомлення залишаються на машині, поза сервером. INTERNALDATE у цьому контексті не існує, і eM Client може відображати дату Date: з повідомлення. Проблем із датами тут менше, але й практичної користі теж менше.

Для Thunderbird ситуація аналогічна. Якщо Ви використовуєте вбудовану функцію імпорту eM Client (яка читає профілі Thunderbird), або якщо Ви копіювали папки mbox через IMAP, повідомлення повторно розміщуються на сервері без гарантії збереження INTERNALDATE. А сервер, який отримує повідомлення без явної інструкції щодо дати INTERNALDATE, систематично ставить мітку часу в момент отримання.

Яка платформа зачіпається?

Проблема однакова незалежно від цільової платформи, оскільки це стандартна поведінка протоколу IMAP:

• Microsoft 365 / Exchange Online: INTERNALDATE перезаписується під час будь-якого імпорту, який не використовує команду IMAP APPEND з явним параметром дати. Те саме стосується міграції з Exchange on-premise.
• Google Workspace: така сама поведінка. Листи, імпортовані через eM Client або сторонні інструменти, відображають дату імпорту в Gmail та в інтерфейсі адміністратора.
• Класичні IMAP-хостинги (OVH, Infomaniak, Ionos, Hetzner тощо): жодної спеціальної обробки дати при отриманні повідомлення через APPEND. INTERNALDATE буде датою розміщення.

Один клієнт звернувся до нас після міграції близько сотні скриньок з Exchange 2013 на Microsoft 365, використовуючи eM Client як інструмент переходу для деяких VIP-акаунтів. Результат: скриньки, перенесені коректно через MigrationWiz, були в порядку, а ті, що пройшли через eM Client, мали всі дати імпорту. Зайве говорити, що зацікавлені користувачі не оцінили цього.

Чому власний скрипт не вирішить це легко

Технічно, той, хто розуміє протокол IMAP, може подумати про написання скрипту для виправлення INTERNALDATE. Оригінальний заголовок Date: є там, цілий, у кожному повідомленні. Достатньо прочитати його і відповідно відновити метадані сервера, чи не так?

У теорії так. На практиці - це мінне поле.

По-перше, граничні випадки накопичуються дуже швидко на виробничій скриньці. Повідомлення, підписані цифровим підписом S/MIME, особливо чутливі до будь-яких маніпуляцій зі структурою. Повідомлення, зашифровані PGP, теж. Листи з великими вкладеннями, нестандартними границями MIME або незвичайними кодуваннями Content-Transfer-Encoding можуть мовчки пошкодитися, якщо обробка не є ретельною. Скрипт, який працює на 50 тестових листах, не буде надійно працювати на скриньці з 20 000 повідомлень і 6-річною історією.

По-друге, управління квотами API. В Microsoft 365 обмеження швидкості на Graph API або на EWS о 3-й ночі під час пакетного виправлення 8 000 повідомлень - це керовано. Але не само по собі. Некерований скрипт, який зустрічає помилку 429 Too Many Requests на повідомленні №3741, можливо, продовжить роботу, а можливо ні. І Ви не обов'язково знатимете, які повідомлення були оброблені.

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

Виправлення дат в джерелі за допомогою Redate.io

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

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

Виправлення використовує власний рушій, який аналізує повний ланцюжок заголовків кожного повідомлення, застосовує зіставлення шаблонів до сотень сигнатур відомих інструментів імпорту (включно зі специфічною поведінкою eM Client, Thunderbird, імпортів PST) і цільово відновлює метадані дати без зміни вмісту повідомлення, його вкладень чи структури MIME.

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

Тарифікація проста: одноразова оплата за скриньку, виходячи з обсягу листів для виправлення. Без підписки, без повторних платежів. Перегляньте сторінку початку роботи для детальної інформації.

Для наступної міграції: що потрібно перевірити

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

Для імпортів PST до Microsoft 365 сертифіковані Microsoft інструменти (наприклад, MigrationWiz у власних режимах або інструмент міграції Exchange Online) зазвичай забезпечують таке збереження. Для ручних імпортів через eM Client або Thunderbird це рідко буває так. Перевіряйте документацію Вашого інструменту перед запуском імпорту на виробничих скриньках.

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

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

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