Защо imapsync е популярен (и защо датите все пак се развалят)
imapsync е референтният инструмент за имейл миграция за Linux системни администратори, хостинг доставчици и всеки, който предпочита решения с отворен код. Създаден от Gilles Lamiral, imapsync се поддържа активно от 2001 година и е използван за милиони миграции на пощенски кутии по света. Поддържа практически всеки IMAP сървър: Dovecot, Courier, Cyrus, Zimbra, Exchange, Gmail и десетки други.
imapsync има репутация на цялостен и конфигурируем. Администраторите оценяват гранулирания контрол над папките за миграция, управлението на дубликати и мапването на имена на папки между различни IMAP сървъри. Но въпреки целия този контрол, един проблем продължава да стои: датите на имейлите често не са запазени след imapsync миграция. Потребителите отварят пощенската си кутия след миграция и установяват, че всеки имейл показва датата на миграцията. Дразнещо е, особено защото imapsync се предполага, че обработва датите правилно.
Как imapsync обработва INTERNALDATE
Опитът за запазване на INTERNALDATE
imapsync наистина се опитва да запази INTERNALDATE на всеки имейл по време на миграцията. INTERNALDATE е времевият печат, който IMAP сървърът съхранява като метаданна за всяко съобщение, отделно от хедърите на имейла. Когато imapsync копира съобщение от източника към дестинацията, той чете INTERNALDATE от изходния сървър и я предава на целевия сървър в IMAP APPEND командата.
На теория това трябва да запази оригиналната дата. На практика резултатът зависи от поведението на целевия сървър и от начина, по който пощенските клиенти интерпретират различните полета, свързани с датите в съобщението.
Проблемът с "Received" хедъра
Дори когато imapsync успее да запази INTERNALDATE, целевият пощенски сървър добавя нов "Received" хедър към всяко съобщение по време на APPEND операцията. Този "Received" хедър съдържа текущия времеви печат - датата на миграцията. Пощенски клиенти като Outlook, Apple Mail и Thunderbird определят показваната дата на "получаване", като четат най-горния "Received" хедър, а не INTERNALDATE. Така въпреки усилията на imapsync за запазване на INTERNALDATE, видимата дата в повечето клиенти все пак е грешна.
Тази фундаментална разлика е причината за объркването. imapsync запазва една стойност за дата (INTERNALDATE), но пощенските клиенти показват друга (времевия печат от "Received" хедъра). За техническо потапяне в този механизъм вижте защо имейлите показват грешна дата след IMAP миграция.
Заблудата от ЧЗВ на imapsync
Документацията и ЧЗВ на imapsync разглеждат проблема с датата, но го представят като присъщо ограничение. ЧЗВ предлага, че "датите може да не бъдат запазени" при IMAP миграция и загатва, че просто така работи IMAP протоколът. Въпреки че е вярно, че IMAP протоколът изисква от сървърите да добавят "Received" хедъри при вмъкване на съобщения, ЧЗВ създава впечатлението, че проблемът е постоянен и непоправим.
Това не е точно. "Received" хедърите, добавени по време на миграцията, могат да бъдат идентифицирани и премахнати впоследствие, възстановявайки показването на оригиналната дата в пощенските клиенти. Оригиналният "Date" хедър (който записва кога имейлът е изпратен първоначално) винаги е запазен от imapsync и служи като референция за правилната дата.
Идентифициране на хедъра от imapsync миграция
Как изглежда хедърът
imapsync самият той не добавя "Received" хедър - това прави целевият IMAP сървър. Хедърът, добавен при imapsync миграция, обикновено изглежда като стандартен IMAP хедър за вмъкване от целевия сървър. Например при миграция към Dovecot сървър хедърът може да изглежда така:
Received: from localhost by mail.example.com;
Wed, 15 Jan 2025 09:14:22 +0100Ключовият идентификатор е, че този "Received" хедър е най-горният във веригата, времевият му печат съвпада с датата на изпълнение на imapsync миграцията и обикновено реферира "localhost" или хостнейма на целевия сървър, а не външен пощенски сървър.
Сравняване на датите
За да потвърдите проблема, сравнете времевия печат на най-горния "Received" хедър с "Date" хедъра на имейла. Ако "Received" хедърът показва януари 2025, но "Date" хедърът показва март 2020, "Received" хедърът от миграцията е причината за грешното показване на датата. Това сравнение може да се направи, като прегледате суровия източник на съобщението в който и да е пощенски клиент.
Защо обичайните опции на imapsync не решават проблема
Флагът --syncinternaldates
imapsync предлага флага --syncinternaldates, който задава INTERNALDATE на целевия сървър да съвпадне с "Date" хедъра на имейла. Това е полезно, когато INTERNALDATE на изходния сървър вече е грешна, но не пречи на целевия сървър да добави "Received" хедър. Видимата дата в Outlook и други клиенти остава датата на миграцията, независимо от стойността на INTERNALDATE.
Опцията --addheader
imapsync може да добавя персонализирани хедъри към съобщенията по време на миграцията, но не може да попречи на целевия сървър да добави собствен "Received" хедър. IMAP протоколът изисква от сървърите да записват времевия печат на вмъкване и никоя imapsync опция не може да отмени това поведение на ниво сървър.
Скриптове след миграцията
Някои администратори пишат персонализирани скриптове след миграцията за премахване на нежеланите "Received" хедъри. Звучи разумно, особено за типа хора, избрали imapsync (някой, удобен с командния ред). Но реалността е много по-сложна от търсене-замяна на текст в хедъри. Какво става, когато скриптът попадне на S/MIME подписан имейл? Или multipart съобщение с вложени MIME граници и base64 кодирани прикачени файлове? Или хедър с не-ASCII символи, кодирани по RFC 2047? Един грешен байт в MIME граница може безшумно да повреди цяло съобщение, унищожавайки прикачените файлове или правейки имейла нечетим. А как да потвърдите, че 10000 коригирани имейла са всички непокътнати? За хиляди имейли в множество кутии, DIY скриптирането представлява съществен риск.
Коригиране на imapsync дати с Redate.io
Как Redate.io обработва imapsync миграции
Собственият коригиращ двигател на Redate.io е проектиран специално за тази категория проблеми. След свързване с пощенската кутия, Redate.io анализира всеки имейл и подава всяко съобщение през многоетапен процес на анализ. За imapsync миграции Redate.io открива "Received" хедъра, вмъкнат от сървъра, като прилага съпоставяне на сигнатури срещу стотици известни миграционни профили, анализирайки пълната верига хедъри и кръстосано проверявайки времевите печати с оригиналния "Date" хедър.
Това не е просто редакция на хедъри. Коригиращият двигател обработва валидация за съответствие с RFC, запазване на структурата на съобщението (включително multipart/alternative структури, вградени прикачени файлове и вариации на Content-Transfer-Encoding) и откриване на цифрови подписи. Имейлите с S/MIME или PGP подписи се идентифицират автоматично и се обработват по подходящ начин за запазване на целостта на подписите.
Какво получавате след корекцията
Всеки коригиран имейл показва оригиналната си дата на получаване във всички пощенски клиенти. Хронологичният ред е възстановен. Всяка корекция преминава през проверка на целостта, преди да бъде финализирана. Оригиналното съобщение се премества в папка "Redate.io - Originals" и се съхранява 30 дни като предпазна мрежа.
Съвместимост с всички целеви сървъри
Тъй като imapsync се използва за миграция към практически всеки IMAP сървър, Redate.io поддържа същия обхват от целеви платформи. Независимо дали imapsync миграцията е насочена към Dovecot, Courier, Cyrus, Zimbra, Google Workspace, Microsoft 365 или друг IMAP сървър, Redate.io се свързва и коригира датите.
Как да коригирате датите след imapsync миграция
Свържете пощенската кутия
Влезте в Redate.io и добавете пощенската кутия. За Google Workspace или Microsoft 365 използвайте опцията за администраторско делегиране. За други IMAP сървъри (чести в imapsync сценариите) въведете адреса на сървъра, потребителското име и паролата. Redate.io се свързва чрез стандартен IMAP.
Безплатен анализ
Стартирайте безплатния анализ за идентифициране на засегнатите имейли. Отчетът от анализа показва общия брой имейли, колко имат грешна дата и каква дата на миграция е установена. Този анализ не струва нищо и дава ясна картина преди каквото и да е ангажиране.
Коригирайте и проверете
Изберете план въз основа на броя засегнати имейли и стартирайте корекцията. Прогресът е видим в реално време. След приключване проверете резултатите, като прегледате датите на имейлите в клиента си. Датите трябва да са се върнали на местата си.
Ръководства за корекция на imapsync по платформи
Често задавани въпроси
Трябва ли да използвам --syncinternaldates на imapsync преди Redate.io?
Не е необходимо. Redate.io задава правилната INTERNALDATE по време на процеса на корекция, независимо от текущата стойност. Независимо дали imapsync е запазил оригиналната INTERNALDATE или не, Redate.io извежда правилната стойност от оригиналния "Date" хедър.
Може ли да се коригират датите на изходния сървър преди миграция с imapsync?
Ако изходният сървър вече има грешни дати (вследствие на предишна миграция), Redate.io може да ги коригира преди или след imapsync миграцията. Но коригирането на датите на целевия сървър след миграция е най-честият и практичен подход.
Колко имейла може да обработи Redate.io?
Redate.io обработва пощенски кутии от всякакъв размер. Планове са налични за до 100000 имейла на кутия. За организации с множество кутии Redate.io предлага обемни цени.
imapsync миграцията развали датите? Стартирайте безплатен анализ, за да видите колко имейла са засегнати и ги коригирайте с Redate.io.