POP на IMAP: старые письма с сегодняшней датой

Классический сценарий утра понедельника

Вы только что переключили почтовый аккаунт с POP3 на IMAP. Настройка была несложной, провайдер помог, всё прошло гладко. До того момента, как вы снова открыли папку «Входящие». Письма за 2019-й, за 2021-й, архивы прошлого года... все они показывают одну и ту же дату: сегодня. Иногда даже одно и то же время с разницей в несколько секунд.

Это не баг вашего почтового клиента. Это не проблема часового пояса. Это ожидаемое поведение протокола IMAP, и оно затрагивает любого, кто загружает локально сохранённые письма на сервер таким способом.

POP3 против IMAP: принципиальная разница

Чтобы понять, почему возникает проблема, нужно сначала разобраться, как работает POP3, и чем он кардинально отличается от IMAP.

В случае с POP3 сервер служит лишь временным почтовым ящиком. Ваш клиент (Outlook, Thunderbird, Apple Mail) подключается, скачивает сообщения, затем удаляет их с сервера (или оставляет, в зависимости от настроек). После этого письма живут исключительно локально: в файле .pst для Outlook, в локальном профиле Thunderbird, в базе данных на вашем жёстком диске.

С IMAP всё наоборот: письма хранятся на сервере. Клиент только отображает то, что лежит на удалённой стороне. Отсюда и прозрачная синхронизация между всеми устройствами.

Проблема возникает при переходе между двумя режимами. Конкретно: когда вы загружаете старые локальные письма POP на сервер IMAP.

IMAP APPEND: команда, которая всё меняет

Когда почтовый клиент загружает локальное сообщение на сервер IMAP, он использует команду IMAP APPEND. Она говорит серверу: «сохрани это сообщение в такой-то папке».

Сервер получает сообщение, сохраняет его и присваивает временну́ю метку. Эта метка называется INTERNALDATE. Это центральный метаданный параметр IMAP: он указывает, когда сообщение было помещено на сервер. По умолчанию, если клиент не передаёт явную дату в команде APPEND, сервер использует... текущий момент.

Иными словами: неважно, что в заголовках сообщения стоит дата 2018 года. Если никто не говорит серверу «это письмо из 2018-го», сервер решает, что оно поступило прямо сейчас, и присваивает ему сегодняшний INTERNALDATE.

(Кстати, если вы когда-нибудь смотрели на сырые заголовки письма, вы видели строку Date: среди десятка строк Received:. Именно это поле, определённое в RFC 2822, содержит настоящую дату отправки. Но INTERNALDATE в IMAP это отдельный метаданный параметр, хранящийся на стороне сервера, который никак не связан с содержимым самого сообщения.)

Чем это отличается от миграции IMAP-to-IMAP

При классической миграции с одного IMAP-сервера на другой (через BitTitan, CloudM, imapsync и т.д.) проблема немного иная. Инструмент миграции копирует сообщения с сервера на сервер и теоретически может передать оригинальный INTERNALDATE на сервер назначения через команду APPEND. Там проблема в другом: некоторые инструменты добавляют заголовок Received: с датой миграции, что нарушает отображение в таких клиентах, как Outlook.

В вашем случае вы работаете с сугубо локальными данными. Нет исходного INTERNALDATE для копирования. Файл .pst или профиль Thunderbird хранит сообщения в собственном проприетарном формате со своими внутренними метаданными. Когда почтовый клиент считывает эти сообщения для загрузки на IMAP-сервер, он заново собирает команду APPEND из содержимого письма. И в большинстве случаев явную дату не передаёт.

Результат: IMAP-сервер получает сотни или тысячи сообщений за несколько минут и присваивает всем одинаковый временной диапазон: сейчас.

Именно поэтому проблема мгновенно распространяется на все устройства. Телефон, планшет, второй компьютер: все они подключаются к одному IMAP-серверу и видят одно и то же. Исправить это на стороне клиента невозможно.

Какой клиент что показывает и почему

Не все почтовые клиенты ведут себя одинаково. Это то, что многие IT-администраторы обнаруживают постфактум.

Outlook (в последних версиях, особенно после обновлений 2023-2024 годов) использует INTERNALDATE сервера для колонки «Получено». Он отображает дату загрузки, а не оригинальную дату отправки. Подробнее об этом поведении читайте в статье Outlook: дата получения IMAP против даты отправки.

Gmail / Google Workspace и Thunderbird ведут себя немного иначе. Gmail, например, иногда может использовать поле Date: из заголовка сообщения для отображения, что создаёт иллюзию, будто всё в порядке... пока вы не попытаетесь отсортировать по дате и не обнаружите, что порядок совершенно случайный.

Apple Mail обычно показывает дату из заголовка Date:, но сортировка и поиск в фоновом режиме опираются на INTERNALDATE. В итоге письма визуально «выглядят» правильно датированными, но сортировка перестаёт работать корректно. Подробнее о поведении Apple Mail: Apple Mail: неверная дата после миграции.

Хорошая новость: оригинальная дата цела

Заголовок Date: каждого письма, тот самый, что содержит настоящую дату отправки (или получения), не тронут. Он по-прежнему на месте, внутри сообщения. Именно его вы видите, когда открываете письмо и смотрите детали.

Сервер IMAP «сломал» только INTERNALDATE, этот внешний метаданный параметр сообщения. Само сообщение не пострадало.

Именно это делает исправление возможным. И именно поэтому проблема может какое-то время оставаться незамеченной: письма выглядят правильно, когда вы открываете их по одному. Только глядя на список папки «Входящие», отсортированный по дате, понимаешь, в чём дело. Письма за 2019 год оказываются вверху, как будто только что пришли. Все с одной датой.

Проблема масштаба: 3000 писем это не то же самое, что 3

Возможно, вы думаете: «Удалю и загружу заново, на этот раз правильно». На пяти-десяти тестовых письмах, да, это сработает. На ящике с 8000 сообщений, вложенными папками, объёмными вложениями, письмами с подписью S/MIME и цепочками переписки с 2015 года... это уже совсем другая история.

Самодельный скрипт, который прекрасно работает на тестовой выборке из 50 писем, вполне может создать дубликаты, потерять вложения или сломать цепочки переписки на боевом почтовом ящике. Управление квотами API, сетевые таймауты, сообщения с нестандартными MIME-структурами... это как раз те граничные случаи, с которыми неспециализированный инструмент не справится.

А если что-то пойдёт не так на середине процесса? Без механизма резервного копирования и отката данные будут потеряны безвозвратно.

Эта проблема хорошо знакома администраторам, которые занимаются масштабными миграциями. Понять, почему даты сломались, это одно. Корректно исправить 15 000 писем, сохранив структуру каждого сообщения, это совсем другое. Подробнее о различных подходах и их ограничениях читайте в статье Можно ли исправить даты писем после миграции?

Как Redate.io справляется с этим случаем

Redate.io создан именно для таких ситуаций. Его аналитический модуль выявляет письма, у которых INTERNALDATE не совпадает с датой в заголовках сообщения, будь то миграция POP на IMAP, миграция между IMAP-серверами или ручная загрузка локальных архивов.

Многоступенчатый конвейер анализа проверяет цепочку заголовков каждого сообщения, валидирует соответствие RFC и восстанавливает метаданные даты без изменения содержимого письма: ни текст, ни вложения, ни MIME-структура, ни возможные цифровые подписи не затрагиваются. Каждое исправленное письмо проверяется индивидуально перед подтверждением.

Оригиналы хранятся в видимой резервной папке в течение 30 дней. Если что-то не устраивает, можно восстановить.

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

Redate.io подключается к почтовым ящикам напрямую через Google Workspace (делегирование на уровне домена), Microsoft 365 (Azure AD) или напрямую по IMAP. Никаких локальных установок. Никаких файлов .pst, которые нужно вручную экспортировать и обрабатывать.

Администраторам, которые управляют несколькими ящиками и хотят узнать об опыте работы с такими случаями, будет полезна статья MSP: исправление дат в почте клиентов. А о поведении Thunderbird при переходе POP/IMAP подробнее рассказывает статья Thunderbird: неправильная дата после миграции.

Если миграция ещё впереди: как предотвратить проблему

Если вы ещё не загружали локальные архивы на IMAP-сервер, или планируете перевод других POP-аккаунтов в организации, вот что стоит держать в голове.

• Проверьте, поддерживает ли ваш почтовый клиент явную передачу даты в команде APPEND. У Thunderbird, например, поведение менялось в зависимости от версии.
• Сначала проведите тест на проверочном аккаунте с 50-100 репрезентативными сообщениями: старые письма, письма с вложениями, подписанные письма. Проверьте отображение дат в разных клиентах.
• Запланируйте исправление до того, как конечные пользователи начнут работать с перемещённым ящиком. Исправлять даты на активном ящике сложнее, чем на только что перенесённом.
• Зафиксируйте количество писем до и после миграции. Это единственный способ обнаружить незаметные потери.

Полный чеклист всех проверок до и после миграции есть в статье Чеклист миграции почты: как избежать проблем с датами.

Старые письма показывают сегодняшнюю дату после перехода с POP на IMAP? Запустите бесплатное сканирование на Redate.io, чтобы оценить масштаб проблемы и исправить метаданные дат, не затрагивая содержимое писем.