Виправити дати 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) її використати. "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 дає кожній копії внутрішню дату, яку зберігає джерельний сервер (за документацією: "Встановлює внутрішні дати на host2 такими ж, як на 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 - Originals і залишаються там, доки ви самі їх не видалите. Якщо щось виглядає не так, повернення назад - одне натискання.

Безкоштовне сканування підключається до поштової скриньки, визначає кожен лист з аномалією дати і повідомляє точну кількість та вартість. Без потреби в кредитній картці, без встановлення програм. Для деталей вашої платформи:

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

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

imapsync: дати не збереглися? Як виправити