English
Français
Deutsch
Español
Português
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Türkçe
Ελληνικά
Русский
Polski
Čeština
Українська
Magyar
Română
Български
Hrvatski
Srpski
Slovenčina
Slovenščina
Lietuvių
Latviešu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
Ви відкрили архів Google Takeout, імпортували файл mbox у Thunderbird за допомогою ImportExportTools NG (або в Apple Mail), а потім перетягнули папки до нового облікового запису IMAP. У поштовому клієнті листи лежали акуратно, рік за роком. В обліковому записі призначення всі вони мають сьогоднішню дату. Ця стаття пояснює, що відбувається з імпортованим Takeout mbox, чому показується дата копії, як за кілька хвилин це підтвердити і як виправити дати на стороні сервера.
Спершу найважливіше: ваші листи цілі. Оригінальна дата досі лежить у самому повідомленні. Просто обліковий запис призначення більше не виводить її на перший план.
Типовий сценарій імпорту Takeout mbox
Ви щойно закрили особистий обліковий запис Gmail, відкритий п'ятнадцять років тому. Замовили експорт на takeout.google.com, дочекалися листа від Google (для великої поштової скриньки це два дні) і завантажили чотири zip-архіви. У кожному лежить по одному файлу .mbox на мітку. Ви імпортуєте їх у Thunderbird: локальна папка наповнюється, сортування за датою бездоганне, 2009 рік унизу, вчорашній день угорі.
Далі ви робите те, що зробив би кожен. Виділяєте папки й перетягуєте їх до облікового запису IMAP, куди переїжджаєте: Microsoft 365, хостинг чи Google Workspace. Копіювання триває цілий вечір. У понеділок зранку ви відкриваєте вебпошту.
Проблема? Усі 18 400 листів датовані вихідними, у проміжку в кілька годин. Договір 2014 року лежить поруч із розсилкою минулого тижня, і за хронологією нічого не знайти.
Випадок дуже схожий на той, коли усі старі листи мають однакову дату, але є суттєва різниця: тут жодного інструмента міграції немає. Досить перетягування мишею.
Три дати в одному листі
Щоб це зрозуміти, треба перестати говорити про "дату" листа в однині. Повідомлення, імпортоване з файлу mbox, несе щонайменше три дати, і служать вони для різного.
Заголовок Date: дата відправника
Це заголовок Date:, визначений у RFC 2822 (його повторює RFC 5322). Клієнт відправника записує його в момент надсилання, наприклад Date: Tue, 14 Mar 2017 09:12:45 +0100. Він є частиною повідомлення, подорожує разом із ним, і Takeout зберігає його без змін. Саме він робить виправлення можливим, адже лишається неушкодженим.
Рядок From у файлі mbox: дата для годиться
У файлі mbox перед кожним повідомленням стоїть рядок, що починається з From (з пробілом, без двокрапки). Це не заголовок: це роздільник, властивий формату файлу, і до повідомлення він не належить. Жоден серйозний інструмент не повинен покладатися на нього, щоб датувати лист.
INTERNALDATE: дата, коли лист потрапив на сервер
Третя дата, найнепомітніша: INTERNALDATE, визначена в RFC 3501. Це атрибут, який сервер IMAP зберігає поруч із повідомленням (а не всередині нього), і він відповідає даті, коли повідомлення було покладено в поштову скриньку. Outlook, вебпошта й телефони використовують його для показу та сортування за датою отримання. Докладніше про механізм читайте в статті про INTERNALDATE і неправильні дати в IMAP.
Уточнення щодо заголовків Received:, яких тут часто марно звинувачують. Рядки Received у експортованому листі Gmail розповідають про справжній шлях повідомлення у 2017 році: дати в них старі й цілком законні. Отже, у цьому випадку неправильна дата живе не в повідомленні, а в метаданих, які сервер призначає копії.
Чому обліковий запис призначення показує дату копії
Коли клієнт кладе повідомлення на сервер IMAP, він використовує команду APPEND. Ця команда може, за бажанням, отримати дату для повідомлення. Якщо клієнт її передає, сервер запам'ятовує її як INTERNALDATE. Якщо ні, сервер застосовує правило з RFC 3501: поточні дата й час. Інакше кажучи, показана дата залежить від того, як інструмент записав лист. Інструмент, який не передає оригінальну дату, отримує дату копії.
Наслідок: поки ви перетягуєте папки, кожне повідомлення бере дату власного розміщення. Папка з 3 000 листів, скопійована за 40 хвилин, вкладається у вікно завдовжки 40 хвилин.
А як же локальна папка Thunderbird? Вона виглядала ідеально, бо Thunderbird сортує там за заголовком Date, а не за серверною датою, адже в локальної папки сервера немає. Apple Mail з імпортованими поштовими скриньками поводиться схоже: усе гаразд, доки повідомлення лежать на Mac. Правда випливає тоді, коли іншу програму, наприклад Outlook, підключають до поштової скриньки IMAP.
Насправді не зовсім точно казати, що всі клієнти помиляються щоразу. Деякі версії передають дату, інші ні, а поведінка змінювалася з оновленнями. Тому двоє колег, які роблять те саме, можуть отримати різні результати, і діагностика виходить заплутанішою, ніж здається.
Перетягування не є міграцією. Це копіювання, а копія несе дату свого виготовлення.
Як упізнати цей випадок за п'ять хвилин
Перш ніж шукати рішення, переконайтеся, що ви саме в цьому сценарії, а не в іншому. Досить чотирьох перевірок.
- Порівняйте два місця. Локальна папка Thunderbird (або імпортована поштова скринька Apple Mail) показує правильні дати, а обліковий запис IMAP для тих самих повідомлень показує свіжі.
- Подивіться на діапазон. У папці облікового запису IMAP дати отримання вкладаються в кілька годин, а то й хвилин, навколо моменту, коли ви переносили папки.
- Відкрийте джерело повідомлення. У Thunderbird: Вигляд, далі Джерело повідомлення; в Outlook заголовки є у властивостях повідомлення. Там має бути старий рядок
Date:, хоча на екрані стоїть свіжа дата. - Перевірте порядок. Повідомлення йдуть у тому порядку, в якому клієнт їх копіював, а не в хронологічному.
Ось як виглядає порівняння на реальному листі:
Date: Tue, 14 Mar 2017 09:12:45 +0100 (у повідомленні, без змін)
Дата, яку показує обліковий запис IMAP: день копіювання (метадані сервера)Якщо ці два рядки розповідають різні історії, ви у потрібному місці. А якщо неправильні і показані дати, і сам Date:, це інша, рідкісніша проблема, і ця стаття не про неї.
(До речі, якщо ви ніколи не читали сирі заголовки листа, запасіться кавою: це не зовсім пляжне читання.)
Сортування за датою відправлення: лише пластир
Перша реакція: перемкнути сортування на дату відправлення. В Outlook це більш-менш працює, якщо повторювати для кожної папки й на кожному пристрої. Але пошук, сповіщення, правила за давністю та подання на мобільних досі спираються на дату отримання. Користувач, який на телефоні шукає "лист із вересня минулого року", не побачить нічого логічного.
Ще одна спокуслива ідея: скопіювати все ще раз. У вже використовуваному обліковому записі це дає передусім дублікати поруч із наявними повідомленнями, з тими самими неправильними датами або іншими. Через добру сотню папок у вас не лишається жодної чистої поштової скриньки.
Виправлення на стороні сервера
Добра новина: оригінальна дата нікуди не поділася. Виправлення полягає в тому, щоб обліковий запис призначення її показував, не чіпаючи вмісту ваших листів.
Саме це робить Redate. Сервіс підключається до поштової скриньки (Google Workspace через делегування домену, Microsoft 365, Outlook.com і Hotmail через обліковий запис Microsoft кожного користувача або напряму через IMAP з адресою та паролем). Redate не потрібно знати, який інструмент завдав шкоди: він знаходить листи, дата яких на екрані не збігається з оригінальною, чи причина в перетягуванні з Takeout mbox, чи в чомусь іншому. Сканування безкоштовне і показує масштаб проблеми ще до будь-якого рішення.
Для самого виправлення Redate спирається на власний рушій корекції, багатоетапний конвеєр аналізу, що вивчає ланцюжок заголовків кожного повідомлення й повертає кожному листу його оригінальну дату. Потім кожен виправлений лист перевіряється окремо, з перевіркою відповідності RFC і збереженням структури повідомлення. Оригінали ніколи не видаляються: вони лишаються у видимій папці вашої поштової скриньки, доки ви самі їх не видалите.
Чому виправляти самостійно ризиковано
Зрозуміти проблему - одне. Виправити 15 000 листів, не втративши жодного, - зовсім інше.
Скрипт, що працює на десяти тестових повідомленнях, не переживе робочу поштову скриньку з 30 000 повідомлень. Йому трапляться підписані S/MIME листи, у яких найменша зміна ламає підпис. Зашифровані PGP повідомлення. Вкладені структури multipart/alternative, суперечливі межі MIME, несподівані Content-Transfer-Encoding, заголовки не в ASCII, закодовані за RFC 2047, вкладення по 40 МБ. Потім квоти API, помилка 429 Too Many Requests о третій ночі посеред пакета, мережеві тайм-аути, що обривають операцію на повідомленні 11 874.
А далі? Як переконатися, що кожен лист цілий? Без механізму відкоту помилка залишає дублікати, втрачені вкладення, розірвані ланцюжки листування, зниклі мітки. Redate автоматично контролює кожен лист і тримає оригінал під рукою, саме щоб вам ніколи не довелося ризикувати.
І остання порада, безкоштовна: зберігайте вихідні архіви Takeout, доки поштову скриньку не перевірено. Файл mbox лишається еталонною копією, навіть коли обліковий запис призначення має пристойний вигляд.
Посібники за вашим клієнтом
Залежно від клієнта, яким ви робили копіювання, докладні посібники описують конкретний випадок: виправлення дат ручного копіювання IMAP в Thunderbird і те саме в Apple Mail.
Ваш Takeout уже скопійовано в обліковий запис IMAP, а дати неправильні? Запустіть безкоштовне сканування Redate, щоб побачити, скількох листів це стосується, а потім виправте їх за одноразову оплату, без обмеження розміру поштової скриньки.