Исправить даты imapsync

Обещание --syncinternaldates (и почему оно не работает)

Вы запустили команду imapsync. Добавили --syncinternaldates, потому что прочитали документацию и подошли к делу ответственно. Миграция завершилась, лог показывает, что всё перенесено, ноль ошибок. Потом открываете почтовый ящик в Outlook и каждое письмо показывает вчерашнюю дату.

Это одно из самых частых разочарований при работе с imapsync, и оно сбивает с толку системных администраторов как минимум с 2017 года. Флаг --syncinternaldates должен сохранять IMAP INTERNALDATE при миграции. Технически он и пытается. Но слово "пытается" делает слишком много работы в этом предложении.

imapsync - это инструмент с открытым исходным кодом на Perl, написанный Жилем Ламиралем, и он действительно хорошо делает свою работу. Он обрабатывает перенос почтовых ящиков IMAP-в-IMAP с надёжностью, которой завидуют большинство коммерческих инструментов. Но сохранение дат зависит не только от imapsync, и именно тут всё усложняется.

Как на самом деле работают даты IMAP

В каждом письме есть три разные "даты", и большинство людей (включая некоторых ИТ-администраторов) их путают:

Заголовок Date: (RFC 2822) - дата, которую почтовый клиент отправителя проставил при создании сообщения. Находится внутри тела сообщения и никогда не изменяется почтовыми серверами.
Заголовки Received: - каждый почтовый сервер, обработавший сообщение, добавляет свой с собственной временной меткой. Они образуют цепочку от отправителя к получателю. Верхний (самый свежий) Received заголовок используется некоторыми почтовыми клиентами для отображения.
INTERNALDATE - серверная временная метка IMAP, определяющая порядок сортировки сообщений в почтовом ящике. Устанавливается при первом сохранении через IMAP APPEND.

Когда imapsync переносит сообщение, он читает его с исходного сервера (включая INTERNALDATE) и записывает на целевой через IMAP APPEND. Флаг --syncinternaldates говорит imapsync передать исходный INTERNALDATE целевому серверу при APPEND.

Вот в чём дело: целевой сервер не обязан принимать эту дату.

Почему целевые серверы игнорируют INTERNALDATE

Спецификация IMAP (RFC 3501) говорит, что если с командой APPEND предоставлена дата-время, сервер ДОЛЖЕН её использовать. "SHOULD" на языке RFC означает "делайте так, если нет веской причины не делать". Несколько крупных почтовых платформ решили, что у них есть веская причина.

Microsoft 365 - главный нарушитель. Когда сообщение поступает через IMAP APPEND, транспортный конвейер Exchange ставит на него новый Received заголовок с текущей датой, а затем устанавливает INTERNALDATE по этой временной метке доставки. Неважно, какую дату запросил imapsync. Сервер M365 её переопределяет.

Google Workspace (Gmail) ведёт себя иначе, но тоже может вызвать проблемы. IMAP-реализация Gmail в большинстве случаев принимает INTERNALDATE из APPEND, но добавляет собственный Received заголовок. Если почтовый клиент приоритизирует Received заголовки над INTERNALDATE для отображения (а Outlook именно это делает), даты всё равно отображаются неправильно.

Dovecot и Cyrus, два самых распространённых IMAP-сервера с открытым исходным кодом, обычно принимают INTERNALDATE из APPEND. Поэтому миграции imapsync между двумя Dovecot серверами обычно корректно сохраняют даты. Проблемы начинаются, когда целевой сервер - hosted платформа с собственной транспортной обработкой.

Частые ошибки командной строки imapsync, ломающие даты

Даже когда целевой сервер готов к сотрудничеству, администраторы часто спотыкаются на параметрах командной строки imapsync. Самые частые ошибки:

Полное отсутствие --syncinternaldates

Флаг не включён по умолчанию. Если запустить базовую команду без него, imapsync даже не пытается сохранять даты. Целевой сервер использует текущую временную метку для каждого сообщения.

Использование --syncinternaldates с --addheader

Некоторые руководства рекомендуют --addheader для добавления пользовательского заголовка при миграции. Добавление заголовков означает модификацию сообщения, что может побудить целевой сервер обработать его как "новое" сообщение.

Путаница --minage и --maxage с сохранением дат

Флаги --minage и --maxage фильтруют, какие сообщения переносить по возрасту. Они не влияют на обработку дат на целевом сервере.

Задержки SSL, вызывающие дрейф временных меток

При миграции через TLS с --ssl1 и --ssl2 установка соединения добавляет задержку. В больших миграциях (50 000+ сообщений) эта задержка накапливается.

Чтение логов imapsync: что на самом деле говорит вывод

imapsync создаёт подробные логи, и это отлично. Но вывод может быть обманчив в отношении дат.

Типичная строка успешной передачи выглядит так:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Обе даты совпадают. Это означает, что imapsync отправил правильный INTERNALDATE целевому серверу. Но не означает, что целевой сервер действительно сохранил эту дату. imapsync сообщает то, что запросил, а не то, что принял сервер.

Хотите проверить, что произошло на самом деле? После миграции подключитесь к целевому серверу IMAP-клиентом и проверьте INTERNALDATE напрямую:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Если возвращённая дата - дата миграции вместо 2019-01-15, целевой сервер проигнорировал запрос imapsync.

Масштабные миграции imapsync: где проблемы с датами умножаются

Миграция одного почтового ящика с imapsync раздражает, когда ломаются даты. Но MSP и ИТ-отделы, запускающие imapsync на сотнях ящиков, сталкиваются с совершенно другим масштабом проблемы.

Типичный корпоративный сценарий: Вы переносите 200 почтовых ящиков с сервера Zimbra на Microsoft 365. Пишете скрипт-обёртку, проходящий по CSV пользователей и вызывающий imapsync для каждого. Миграция работает выходные. Утром в понедельник у Вас 200 ящиков с битыми датами и около 1,2 миллиона писем с временной меткой миграции.

Самостоятельные исправления и их пределы

Если поискать на форумах и в списках рассылки (список imapsync-devel на SourceForge всё ещё активен в начале 2026), найдёте предложения от креативных до опасных.

Все эти подходы разделяют одни и те же фундаментальные проблемы. Как обработать S/MIME подписанные сообщения, не сломав подпись? Как быть с многосоставными MIME-структурами с вложенными границами? С RFC 2047 кодированными не-ASCII заголовками? Скрипт, работающий на 50 тестовых сообщениях, захлебнётся на крайних случаях production-ящика с 30 000 писем.

Как Redate.io исправляет даты после imapsync

Оригинальный заголовок Date: всегда остаётся нетронутым после миграции imapsync. imapsync точно передаёт сырое сообщение; проблему отображения вызывает обработка метаданных целевым сервером. Этот оригинальный заголовок делает коррекцию возможной.

Redate.io подключается непосредственно к почтовому ящику (Google Workspace, Microsoft 365 или любой IMAP-сервер), сканирует письма с аномалиями дат и применяет точечную коррекцию метаданных через проприетарный конвейер анализа цепочки заголовков и реконструкции дат. Коррекция обрабатывает характерные паттерны, которые оставляют миграции imapsync.

Каждое исправленное письмо проверяется индивидуально: целостность сообщения, сохранность вложений, размещение в папках, цепочки, метки. Оригиналы хранятся в видимой папке Redate.io - Originals 30 дней.

Бесплатное сканирование подключается к ящику, находит каждое письмо с аномалией даты и сообщает точное количество и стоимость. Без кредитной карты, без установки программ. Для деталей по Вашей платформе:

Redate.io работает и с миграциями, произошедшими месяцы или годы назад. Заголовок Date: не устаревает, как и возможность исправить то, что пошло не так.

Мигрировали через imapsync и застряли с неправильными датами? Запустите бесплатное сканирование, чтобы увидеть, сколько писем затронуто.

imapsync: даты не сохранились? Как исправить