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, которому 15 лет. Заказываете экспорт на 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 выглядела идеально? Потому что там сортировка идёт по заголовку Date, а не по серверной дате: у локальной папки сервера просто нет. Apple Mail с импортированными ящиками ведёт себя похоже: пока письма лежат на Mac, всё в порядке. Правда вскрывается, когда другая программа, например Outlook, читает ящик IMAP.
Впрочем, сказать, что все клиенты ошибаются всегда, было бы не совсем верно. Одни версии передают дату, другие нет, а поведение менялось от обновления к обновлению. Поэтому двое коллег, действующих по одной и той же схеме, могут получить разный результат, и диагностика запутывается сильнее, чем кажется.
Перетаскивание - это не миграция. Это копирование, а у копии дата её изготовления.
Как узнать этот случай за пять минут
Прежде чем искать решение, убедитесь, что у вас именно этот сценарий, а не другой. Хватит четырёх проверок.
- Сравните два места. Локальная папка Thunderbird (или импортированный ящик Apple Mail) показывает правильные даты, а аккаунт IMAP для тех же писем - свежие.
- Посмотрите на разброс. В папке аккаунта IMAP даты получения укладываются в несколько часов, а то и минут вокруг момента, когда вы переносили папки.
- Откройте исходный код письма. В Thunderbird это Ctrl+U, в Outlook заголовки есть в свойствах сообщения. Вы должны увидеть старую строку
Date:, тогда как в списке писем указана свежая дата. - Проверьте порядок. Письма идут в том порядке, в каком клиент их копировал, а не в хронологическом.
Вот как выглядит сравнение на реальном письме:
Date: Tue, 14 Mar 2017 09:12:45 +0100 (внутри письма, без изменений)
Дата в аккаунте IMAP: день копирования (метаданные сервера)Если эти две строки рассказывают разные истории, значит, это ваш случай. А если отображаемые даты неверны, но и Date: тоже неверен, перед вами другая, более редкая проблема, и в эту статью она не входит.
(Кстати, если вы ни разу не читали сырые заголовки письма, запаситесь кофе: это не то чтобы чтение для пляжа.)
Сортировка по дате отправки: пластырь
Первое, что приходит в голову, - переключить сортировку на дату отправки. В Outlook это более-менее работает, но только если повторять настройку в каждой папке и на каждом устройстве. При этом поиск, уведомления, правила по давности письма и представления на мобильных устройствах продолжают опираться на дату получения. Пользователь, который на телефоне ищет "письмо за прошлый сентябрь", не увидит ничего логичного.
Другой соблазнительный путь - повторить копирование. На уже используемом аккаунте это в основном плодит дубликаты рядом с существующими письмами, с теми же неверными датами или другими. Сотня папок спустя чистого ящика у вас не остаётся вовсе.
Исправление на стороне сервера
Хорошая новость: оригинальная дата никуда не делась. Исправление состоит в том, чтобы целевой аккаунт показывал именно её, не затрагивая содержимое ваших писем.
Этим и занимается Redate. Сервис подключается к почтовому ящику (Google Workspace через делегирование на уровне домена, Microsoft 365, Outlook.com и Hotmail через учётную запись Майкрософт каждого пользователя, либо напрямую по IMAP с адресом и паролем). Ему не нужно знать, какой инструмент всё испортил: он находит письма, у которых отображаемая дата не совпадает с оригинальной, неважно, из-за чего это случилось - из-за перетаскивания из 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, чтобы увидеть, сколько писем затронуто, а затем исправьте их за разовый платёж, без ограничения на размер почтового ящика.