Исправить даты 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.

Вот хорошая новость: Microsoft 365, Outlook.com и Gmail сохраняют ту дату, которую им передают. Поэтому, если даты оказались неправильными, проблема в другом месте.

Почему даты всё равно могут быть неправильными

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

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

Gmail - особый случай, только когда копирование идёт через собственный API импорта Gmail, а не через IMAP: этот API действительно добавляет строку Received:, датированную днём копирования, и Outlook может показать именно эту дату. imapsync работает через IMAP, поэтому его это не касается.

Dovecot и Cyrus, два самых распространённых IMAP-сервера с открытым исходным кодом, тоже сохраняют дату, переданную при APPEND. Так что, каким бы ни был целевой сервер, вопрос один и тот же: какую дату хранил исходный сервер?

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

Помимо исходных дат, администраторы часто спотыкаются на параметрах командной строки imapsync или винят не те из них. Вот ошибки, которые встречаются чаще всего:

Копирование с источника, чьи даты уже были неправильными

--syncinternaldates включён по умолчанию: imapsync присваивает каждой копии внутреннюю дату, которую хранит исходный сервер (в документации это описано так: "Sets the internal dates on host2 as the same as host1"). Если исходный почтовый ящик сам является результатом более ранней миграции или восстановления, его внутренние даты могут уже быть датами той операции, и imapsync добросовестно копирует неправильную дату. Это самая частая причина, и её проще всего пропустить, потому что в логе видны две одинаковые даты.

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

Некоторые руководства советуют использовать --addheader для добавления собственного заголовка при миграции. Добавление заголовка изменяет сообщение (ещё одна строка сверху), но не дату, которую передаёт imapsync, поэтому оно не объясняет неправильные даты. Просто копия больше не идентична оригиналу, что важно, если вы сравниваете их между собой.

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

Флаги --minage и --maxage отбирают, какие письма переносить, по их возрасту. Они не влияют на то, как обрабатываются даты на целевом сервере. Я видел, как администраторы часами настраивали эти флаги, думая, что это решит проблему с датами. Не решит.

Обвинять TLS в сдвиге дат

При использовании TLS (--ssl1, --ssl2) установка соединения добавляет задержку, и на крупной миграции (50 000+ писем) это может вылиться в часы. На даты это не влияет: каждая копия несёт дату, которую передал imapsync, независимо от того, когда она фактически была записана.

Чтение логов 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. А Microsoft 365, Outlook.com и Gmail сохраняют ту дату, которую им передают. Но две одинаковые даты доказывают лишь то, что копия верна ИСХОДНОЙ дате: если дата на источнике уже была неправильной, оба столбца показывают одну и ту же неправильную дату.

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

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

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

Это один из самых неприятных моментов при разборе проблем с датами: чистый лог-файл, две одинаковые даты, и всё равно неправильная дата в Outlook, потому что ошибка появилась ещё до того, как запустился imapsync.

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

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

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

Можно ли повторно запустить imapsync, чтобы исправить это? Технически да, но imapsync пропустит сообщения, которые уже существуют на целевом сервере (он спроектирован как идемпотентный). Понадобится --delete2, чтобы удалить сообщения на целевом сервере и перенести их снова, что рискованно для рабочего почтового ящика. И если проблема была в исходных датах, повторный запуск снова скопирует те же неправильные даты.

Некоторые администраторы пробуют гибридный подход: сначала запускают imapsync с --dry для теста, потом настоящую миграцию. Но --dry только имитирует перенос: он показывает даты, которые imapsync передал бы, а не то, являются ли они датами, когда письма были отправлены. Ничто не предупредит вас, что исходные даты уже неправильны.

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

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

Некоторые советуют использовать однострочник на Perl, чтобы изменить INTERNALDATE прямо на целевом сервере. Другие рекомендуют экспортировать все письма в формат mbox, изменить даты и импортировать их обратно. Кто-то написал скрипты на Python, которые используют imaplib для получения, изменения и повторной вставки сообщений.

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

И самый главный вопрос, который никто не задаёт, пока не становится слишком поздно: как проверить, что каждое изменённое сообщение осталось целым? Что вложения не повреждены, что цепочки писем всё ещё работают, что та таблица на 85 МБ, которую кто-то отправил в 2020 году, пережила эту манипуляцию?

(Если вам приходилось разбирать необработанные заголовки писем на Perl, вы знаете, что это не самое спокойное занятие для вечера.)

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

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

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

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

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

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

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

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