Поправка на дати imapsync

Обещанието на --syncinternaldates (и къде спира)

Стартирали сте командата imapsync. Включили сте --syncinternaldates, защото сте прочели документацията и сте внимателни точно по този начин. Миграцията завършва, логът казва, че всичко е прехвърлено, нула грешки. После отваряте пощенската кутия в Outlook и всеки имейл показва вчерашната дата.

Това е една от най-честите фрустрации с imapsync и обърква системните администратори поне от 2017 година. Флагът --syncinternaldates трябва да запазва IMAP INTERNALDATE по време на миграцията. И го прави: дава на всяко копие вътрешната дата, която сървърът-източник пази. Точно там е капанът.

imapsync е инструмент с отворен код на Perl, написан от Gilles Lamiral, и наистина е добър в това, което прави. Обработва миграции на пощенски кутии от 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 дава на всяко копие вътрешната дата, която сървърът-източник пази (собствената му документация: "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 MB, която някой е изпратил през 2020 г., е преживяла манипулацията?

(Ако някога сте опитвали да парсвате сурови имейл заглавия на Perl, знаете, че не е точно спокойно следобедно занимание.)

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

Оригиналното заглавие Date: винаги е непокътнато след миграция с imapsync. imapsync прехвърля суровото съобщение вярно; грешната дата се намира в метаданните, които копието е получило, не в самото съобщение. Точно това оригинално заглавие прави корекцията възможна.

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

Всеки коригиран имейл се проверява поотделно: целостта на съобщението, запазването на прикачените файлове, разположението в папките, веригата от отговори, етикетите. Оригиналите се пазят във видима резервна папка Redate.io - Originals и остават там, докато сами не ги изтриете. Ако нещо изглежда нередно, връщането назад е на едно кликване разстояние.

Безплатната проверка се свързва с пощенската кутия, идентифицира всеки имейл с аномалия в датата и показва точния брой и цената. Не е необходима кредитна карта, не се инсталира софтуер. За конкретиката на Вашата платформа:

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

Мигрирали сте с imapsync и сте останали с грешни дати? Стартирайте безплатна проверка, за да видите точно колко имейла са засегнати.

imapsync: датите не се запазиха? Как да ги поправите