Всі старі листи мають однакову дату: що сталося?

Симптом: усі старі листи згруповані під однією датою

Ви відкриваєте Outlook, Gmail або Apple Mail одного ранку. Щось одразу кидається у вічі. Сотні, а то й тисячі старих листів відображають одну й ту саму дату: кілька днів тому або кілька тижнів тому. Повідомлення з 2021, 2019, 2016 року виглядають так, ніби їх отримали вчора. Сортування за датою втрачає будь-який сенс. Шукаєте важливий лист з минулого року, а він загубився в масиві тисяч повідомлень, що нібито надійшли в один день.

Нові листи відображають правильні дати. Проблема стосується виключно старих повідомлень.

Що ж могло статися?

Перша реакція: звинуватити програму

Звичайно, думаєш на баг. Outlook завис. Оновлення пройшло криво. Файл пошкоджений. І тут починається справжнє пригодницьке кіно: шукаєш "баг дата Outlook", натрапляєш на форуми про файли OST, SCANPST.exe, відтворення профілю Outlook з нуля...

Дві години спроб. Проблема нікуди не ділася.

До речі, SCANPST - це інструмент для відновлення локальних файлів даних Outlook. Він може виправити певні пошкодження файлів, але не торкається даних, що зберігаються на поштовому сервері. Тобто навіть якщо Ви відновите файл OST ідеально, дати залишаться хибними, бо проблема не у Вас на комп'ютері.

Проблема в самих листах, на сервері.

Що насправді сталося: міграція

У переважній більшості випадків цей симптом з'являється після міграції пошти. Ваша компанія перейшла зі старої системи на Google Workspace, Microsoft 365 або новий сервер. Хтось, десь, використав інструмент для перенесення всіх листів з одного місця в інше.

Можливо, Вас навіть не попередили. Або попередили, але Ви не пов'язали це з проблемою дат. Це цілком нормально.

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

Ось у чому вся справа.

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

Лист насправді містить кілька різних дат, прихованих у його технічних даних. Є оригінальна дата відправлення (та, яку Ви зазвичай бачите), а також заголовки "Received:", що фіксують кожен етап шляху повідомлення в інтернеті.

(Якщо Ви колись натискали "Переглянути джерело" або "Показати всі заголовки" в листі, то, мабуть, бачили ці незрозумілі рядки, схожі на суцільний блок тексту. Саме вони.)

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

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

Результат: 8000 листів, що нібито надійшли в одне й те саме листопадове вівторення.

Які інструменти спричиняють цю проблему?

Найпоширеніші інструменти міграції мають таку поведінку. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (безкоштовний інструмент Google для міграції з Outlook) та багато інших. Це не зовсім їхній недолік: це наслідок технічного устрою поштового протоколу. Інструменти додають цей заголовок, бо протокол саме так і передбачає перенесення повідомлення з сервера на сервер.

Проблема в тому, що користувачів про це ніхто не попереджає.

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

Хибні шляхи, яких варто уникати

Кілька рішень, які часто зустрічаються на форумах і які не працюють:

Відновлення файлу даних за допомогою SCANPST

Ми вже згадували: SCANPST відновлює локальні файли Outlook (файли .pst або .ost, що зберігаються на Вашому комп'ютері). Він не змінює листи на сервері. Після відновлення Ваші листи матимуть ті самі хибні дати, бо ці дати знаходяться в самих листах, а не в локальному файлі.

Відтворення профілю Outlook

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

Сортування за "датою відправлення" замість "дати отримання"

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

Перевстановлення поштового клієнта

Ні. Листи знаходяться на сервері, а не в програмі. Перевстановлення Outlook, Gmail, Apple Mail або Thunderbird не змінює дані, що зберігаються онлайн.

Хороша новина: справжні дати ще там

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

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

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

Чому не варто намагатися виправити це самостійно?

Можливо, Ви думаєте, що ІТ-спеціаліст може просто написати скрипт для виправлення проблеми. Зрозуміти, що відбувається, - це одне. Виправити це акуратно на тисячах листів без втрати жодного - зовсім інша справа.

Лист - не простий текстовий файл. Він може містити вкладення, цифрові підписи, вміст, закодований у складних форматах. Змінити метадані такого повідомлення, не зруйнувавши його структуру, означає впоратися з десятками особливих випадків: листи з електронним підписом (S/MIME), зашифровані повідомлення (PGP), нестандартні кодування, багаточастинні структури... Скрипт, що працює на 20 тестових листах, майже напевно не впорається з виробничою поштовою скринькою з 15 000 повідомлень. І якщо щось піде не так, як переконатися, що жоден лист не пошкоджений і не загублений? Зі скриптом власного виробництва: ніяк.

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

Що робить Redate.io

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

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

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

Тарифікація - одноразовий платіж, розрахований на основі обсягу листів для виправлення. Жодних підписок. Платите один раз, проблема вирішена.

Хочете побачити масштаб проблеми, перш ніж зробити вибір? Запустіть безкоштовне сканування Вашої поштової скриньки на Redate.io і дізнайтеся за кілька хвилин, скільки листів уражено.