Outlook: дата отримання IMAP vs дата відправлення

Симптом, який знають усі

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

Це не баг Outlook. Це пряме наслідок того, як працює протокол IMAP і інструменти міграції. Але щоб зрозуміти чому, потрібно зазирнути під капот.

Три дати в одному листі

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

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

Це дата, яку відправник поставив у повідомленні в момент відправлення. Визначена стандартом RFC 2822, вона виглядає так:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Цей заголовок вплавлений у тіло повідомлення. Він ніколи не змінюється, якщо хтось не редагує необроблений вміст листа. Це і є "дата відправлення" у строгому сенсі.

Заголовок Received: (додається на кожному мережевому стрибку)

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

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Результат: коли інструмент міграції на кшталт BitTitan MigrationWiz, CloudM, imapsync або GSMMO переміщує лист з вихідного сервера на сервер призначення, він теж поводиться як "мережевий стрибок". Він вставляє новий заголовок Received: на самий верх ланцюжка, з датою і часом міграції.

INTERNALDATE IMAP

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

От тут усе й зупиняється.

Чому Outlook показує дату міграції

Outlook використовує INTERNALDATE для відображення стовпця "Отримано". Це його поведінка за замовчуванням, і вона відповідає специфікації IMAP: INTERNALDATE має відображати дату отримання до скриньки. У нормальному потоці (справжній лист, що надходить) INTERNALDATE близька до дати в заголовку Date:. Обидві узгоджені між собою.

Після невдалої міграції INTERNALDATE усіх імпортованих листів вказує на ніч з 14 на 15 червня 2024 року (або яка там була дата міграції). Outlook зчитує це значення, показує його у стовпці "Отримано", і результат катастрофічний: 45 000 листів нібито надійшли того самого вечора.

Якщо бути точним, перший заголовок Received: (найновіший у ланцюжку) також впливає на відображення в деяких конфігураціях. Але INTERNALDATE залишається основним визначальним фактором для стовпця "Отримано" в Outlook у режимі синхронізації IMAP.

Обхідний шлях "Додати стовпець Відправлено" в Outlook

Перше, що роблять більшість IT-адміністраторів, коли виявляють проблему, - шукають обхідний шлях на стороні клієнта. І він справді існує.

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

Щоб зробити це в Outlook (версія для ПК, Microsoft 365): клік правою кнопкою на заголовок стовпця у списку повідомлень, "Параметри перегляду", потім змінити стовпці: прибрати "Отримано" і додати "Дата". Можна розгорнути через GPO для масового розгортання.

Добре. На папері це вирішує візуальну проблему. Насправді це пластир на артерію.

Конкретні обмеження цього обхідного шляху

Мобільні та вебклієнти

Outlook на iOS, Android і Outlook Web App (OWA) не мають таких самих параметрів налаштування. Зміна відображення, розгорнута на Windows-комп'ютерах, не поширюється на них. Користувачі, які переглядають пошту на телефоні, продовжують бачити дату міграції. А в компанії середнього розміру це, мабуть, половина всіх користувачів.

Пошук

Пошук Outlook використовує індекс Windows Search (або індекс Exchange/Microsoft 365 на стороні сервера). Цей індекс будується на основі INTERNALDATE, а не заголовку Date:. Якщо користувач шукає "листи за січень 2022 року", пошук повертає листи, чия INTERNALDATE відноситься до січня 2022 року. Не ті, де заголовок Date: датований січнем 2022 року. Підсумок: старі листи більше не з'являються у фільтрах за датою. Зміна стовпця відображення тут нічого не змінює.

Правила обробки листів

Правила Outlook ("якщо лист отримано до..." або "якщо лист отримано після...") також використовують INTERNALDATE. Правило сортування або архівування на основі діапазонів дат не працюватиме правильно після міграції, якщо INTERNALDATE не виправлено.

Відповідність вимогам і eDiscovery

Мабуть, це найсерйозніший момент. Інструменти для дотримання вимог, юридичного архівування та eDiscovery (наприклад, Microsoft Purview) використовують INTERNALDATE як еталонну дату для юридичних запитів. Якщо ваша компанія підпадає під вимоги щодо зберігання даних або повинна відповідати на запити discovery, пошкоджені INTERNALDATE можуть спричинити реальні юридичні проблеми. Аудит, що запитує "всі листи між такою-то і такою-то датою", не поверне правильних результатів.

Сторонні інструменти

CRM-системи, тікет-інструменти, архіватори... все, що підключається до вашого поштового сервера через IMAP або API Microsoft 365/Google Workspace, читає INTERNALDATE. Зміна відображення в Outlook нічого не виправляє для цих систем.

Єдине справжнє рішення: виправлення на рівні сервера

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

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

У Google Workspace API Gmail надає параметр internalDate, що дозволяє діяти безпосередньо на цей метаданий. У Microsoft 365 механізм інший, але очікуваний результат той самий. На стандартному IMAP-сервері стандарт передбачає, що дату можна задати під час вставки повідомлення.

На практиці виконати цю операцію для десятків тисяч листів у продакшн-середовищі без втрати даних, без дублікатів, без пошкодження гілок обговорення або мітків, з обробкою граничних випадків (повідомлення, підписані S/MIME, складні структури MIME, кодування non-ASCII за RFC 2047, великі вкладення)... це зовсім інша справа. Скрипт, що працює на 50 тестових листах, не витримає на скриньці з 40 000 повідомлень. Обробка помилок 429 (перевищення квоти API), мережевих таймаутів о 2 ночі, повідомлень зі структурою MIME, вже частково пошкодженою після міграції... усе це вимагає серйозної інженерії.

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

Визначення інструменту міграції, що спричинив проблему

Проблема проявляється однаково незалежно від походження міграції, але деталі відрізняються залежно від використаного інструменту. BitTitan MigrationWiz, CloudM, imapsync і GSMMO мають кожен свій підпис у заголовках Received:, які вони вставляють. Конвеєр аналізу Redate.io підтримує базу відповідностей із сотнями підписів відомих інструментів міграції, щоб відрізняти заголовок міграції від решти ланцюжка легітимного транзиту.

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

Для конкретних сценаріїв доступні детальні посібники: виправлення дат imapsync в Outlook, виправлення дат BitTitan в Outlook, або виправлення дат CloudM в Outlook.

Що робити зараз

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

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

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