Проблемът - всички имейли показват една и съща дата
След IMAP миграция потребителите отварят пощенската си кутия и откриват тревожна гледка: всеки имейл показва абсолютно една и съща дата. Вместо оригиналната дата на изпращане или получаване, всички съобщения носят датата, на която е извършена миграцията. Години кореспонденция, която изглежда сякаш е пристигнала в един и същи ден.
Това е кошмар за IT администраторите. Тикетите прииждат, потребителите не могат да намерят нищо по дата, а хронологичната история на пощенската кутия на практика е унищожена.
Как изглежда в Outlook
В Microsoft Outlook колоната "Получено" показва датата на миграцията за всеки имейл. Независимо дали съобщението е изпратено през 2018 или 2023 година, Outlook показва една и съща дата - деня, в който инструментът за миграция е обработил пощенската кутия. Входящата поща, изпратените, всяка папка е засегната. Потребителите, които разчитат на сортиране по дата, виждат работния си процес напълно разрушен.
Как изглежда в Apple Mail
Apple Mail на macOS и iOS се държи по подобен начин. Датата, показана до всяко съобщение, отразява времевия печат на миграцията, а не оригиналната дата. Тъй като Apple Mail използва метаданните на IMAP сървъра, за да определи датите за показване, същият основен проблем поражда същия видим резултат. При разглеждане на входящата поща се вижда само стена от идентични дати.
Как изглежда в Gmail (уеб интерфейс)
Уеб интерфейсът на Gmail представя малко по-различна ситуация. Уеб клиентът на Gmail обикновено използва хедъра "Date" на самия имейл, така че съобщенията може да се появят с правилната дата в Gmail. Но IMAP INTERNALDATE остава грешна, което означава, че всеки IMAP клиент, свързан към този Gmail акаунт (Outlook, Thunderbird, Apple Mail), ще показва датата на миграцията. В резултат една и съща пощенска кутия изглежда правилна в един клиент, но грешна в друг. Доста объркващо.
Защо се случва - техническата причина
Основната причина се крие в начина, по който IMAP инструментите за миграция обработват хедърите на имейлите и в начина, по който пощенските клиенти определят коя дата да покажат. Разбирането на това изисква кратък поглед към IMAP протокола и структурата на хедърите.
Как IMAP инструментите за миграция обработват хедърите
Когато имейл се мигрира от един сървър към друг, инструментът за миграция изтегля суровото съобщение от изходния сървър и го качва на целевия сървър чрез IMAP APPEND командата. По време на този процес IMAP протоколът изисква от целевия сървър да добави "Received" хедър към съобщението. Този хедър съдържа времевия печат на момента, в който съобщението е вмъкнато в новия сървър - тоест датата на миграцията.
Хедърът "Received", който разваля всичко
Имейл съобщенията обикновено съдържат няколко "Received" хедъра, всеки добавен от пощенски сървър, обработил съобщението при оригиналното му доставяне. Клиенти като Outlook определят "датата на получаване", като четат най-скорошния "Received" хедър - този в началото на веригата. Когато инструмент за миграция добави нов "Received" хедър с времевия печат на миграцията, той става най-скорошният и пощенските клиенти показват тази дата вместо оригиналната.
Това не е бъг на инструмента за миграция, нито на пощенския клиент. И двата следват правилно IMAP и имейл стандартите. Проблемът идва от факта, че тези стандарти никога не са проектирани за масова миграция, а взаимодействието между IMAP APPEND и логиката за показване на дати поражда този нежелан резултат.
INTERNALDATE срещу хедър Date
IMAP сървърите съхраняват две различни стойности за дата за всяко съобщение. Хедърът "Date" е част от самото имейл съобщение - той записва кога съобщението е съставено и изпратено първоначално. INTERNALDATE е метаданна, съхранявана от IMAP сървъра, представляваща кога съобщението е доставено или вмъкнато в конкретния сървър.
Някои инструменти за миграция опитват да запазят оригиналната INTERNALDATE, като я задават по време на APPEND командата. Но дори когато INTERNALDATE е правилно зададена, добавеният "Received" хедър все пак причинява проблеми в клиентите, които дават приоритет на датата от "Received" пред INTERNALDATE.
Кои инструменти за миграция причиняват този проблем?
Почти всички IMAP инструменти за миграция могат да предизвикат този проблем. Проблемът е присъщ на IMAP протокола, а не е специфичен за конкретен инструмент. Някои обаче са по-често свързвани с проблема поради широкото им използване.
BitTitan MigrationWiz
BitTitan MigrationWiz е един от най-популярните комерсиални инструменти за миграция, използван от MSP и IT консултанти. MigrationWiz добавя "Received" хедър, съдържащ "mx.migrationwiz.com" по време на процеса на миграция. Този хедър става най-скорошният във веригата, което води до показване на датата на миграцията в Outlook и други IMAP клиенти. Вижте подробни ръководства за коригиране на BitTitan дати в Outlook, Microsoft 365, Google Workspace и Exchange Online.
CloudM Migrate
CloudM Migrate (преди Cloud Migrator) се използва широко за миграции към Google Workspace. Като другите инструменти, CloudM добавя собствен "Received" хедър при IMAP вмъкването. Имейлите, мигрирани с CloudM, показват датата на миграцията в клиенти, които се базират на "Received" хедъра. Вижте ръководствата за коригиране на CloudM дати в Gmail, Outlook, Google Workspace и Microsoft 365.
imapsync
imapsync е популярен инструмент с отворен код сред Linux администраторите и хостинг доставчиците. Въпреки че imapsync се опитва да запази INTERNALDATE, целевият сървър все пак добавя "Received" хедър при APPEND операцията. ЧЗВ на imapsync признава това ограничение, но не предлага вградено решение за премахване на добавения хедър след миграцията. Вижте ръководствата за коригиране на imapsync дати в Outlook, Gmail, Microsoft 365 и Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) е собственият инструмент на Google за миграция от Exchange или PST файлове на Outlook към Google Workspace. GSMMO може да предизвика същия проблем с датата, особено когато миграцията включва междинна IMAP стъпка. Вижте ръководствата за коригиране на GSMMO дати в Outlook, Gmail и Apple Mail.
Exchange Admin Center (вграден IMAP импорт)
Административният център на Exchange на Microsoft включва вградена функция за IMAP импорт за миграция към Exchange Online (Microsoft 365). Този вграден инструмент за миграция добавя "Received" хедъри по време на импорта, причинявайки същия проблем с показването на датата. Вижте ръководствата за коригиране на датите от IMAP миграция на Exchange в Outlook и OWA.
Ръчно IMAP копиране
Дори ръчното копиране на имейли между IMAP сървъри чрез клиент като Thunderbird може да предизвика този проблем с датата. Когато пощенски клиент копира съобщение чрез IMAP, целевият сървър го третира като ново вмъкване и добавя собствен "Received" хедър с текущия времеви печат. Вижте ръководствата за коригиране на датите от ръчно IMAP копиране в Outlook, Gmail, Thunderbird и Apple Mail.
Защо обичайните заобиколни решения не работят
Изправени пред този проблем, потребителите и администраторите обикновено опитват няколко подхода, преди да осъзнаят, че нито един от тях не решава наистина проблема.
"Сортирайте по дата на изпращане" - защо не е достатъчно
Най-честият съвет е да се премине от сортиране по дата на "получаване" към дата на "изпращане" в пощенския клиент. Това наистина променя реда на показване, но не коригира основните данни. Резултатите от търсенето продължават да показват грешната дата. Интеграциите с календар, инструментите за съответствие и автоматизираните работни процеси, които зависят от датата на получаване, продължават да не функционират правилно. А потребителите трябва да помнят да променят тази настройка на всяко устройство и във всяка папка.
Повторна миграция - скъпа и рискована
Някои администратори обмислят повторно стартиране на миграцията, надявайки се да избегнат проблема с датата на второто преминаване. Този подход е скъп (500 до 5000 EUR в зависимост от броя пощенски кутии), отнема много време и е рисков. Повторната миграция въвежда същия проблем с "Received" хедъра, удвоява риска от загуба на данни и изисква значително прекъсване на работата. Повторната миграция не решава проблема с датата, освен ако инструментът за миграция не бъде фундаментално модифициран.
Ръчно редактиране на хедъри - изисква достъп до сървъра
Технически погледнато, корекцията включва премахване на "Received" хедъра от миграцията от всеки имейл. Но ръчното правене на това изисква директен достъп до сървъра, познания за структурата на имейл хедърите и персонализирани скриптове. За пощенска кутия от 10000 имейла ръчното редактиране е непрактично и опасно предразположено към грешки. S/MIME подписани имейли, PGP криптирани съобщения, multipart структури с вложени MIME граници, проблеми с Content-Transfer-Encoding, не-ASCII хедъри (RFC 2047), свръхголеми прикачени файлове: всеки от тези случаи може да накара базов скрипт да повреди данни необратимо. Как да потвърдите, че 10000 коригирани имейла са всички непокътнати? Не можете, освен със система за верификация, проектирана специално за това.
Истинското решение - възстановяване на оригиналните дати
Правилният подход е да се идентифицират артефактите от миграцията във веригата хедъри на всеки имейл и да се приложат целенасочени корекции, които възстановяват оригиналния хронологичен ред във всички пощенски клиенти. Това не е просто редакция на хедъри. Процесът включва валидация за съответствие с RFC, запазване на структурата на съобщението и съпоставяне на сигнатури на миграция от база данни с профили на известни инструменти.
Как Redate.io коригира този проблем
Redate.io се свързва с пощенската кутия (Google Workspace, Microsoft 365 или всеки IMAP сървър) и анализира всеки имейл, за да идентифицира съобщенията, засегнати от хедърите на миграцията. Анализът е безплатен и показва точно колко имейла са засегнати преди каквото и да е плащане.
За всеки засегнат имейл собственият коригиращ двигател на Redate.io подава съобщението през многоетапен процес на анализ. Двигателят прилага съпоставяне на сигнатури срещу стотици профили на известни инструменти за миграция, изградени от обработката на големи обеми реални имейл данни. Той обработва проблеми с кодирането, multipart структури, вградени прикачени файлове и десетки специални случаи, които биха накарали DIY скрипт да повреди данните (не е откритието, което искате да направите в понеделник сутрин). Всеки коригиран имейл преминава през проверка на целостта, преди да бъде финализиран. Оригиналното съобщение се премества в видима папка "Redate.io - Originals" (не се изтрива) и се съхранява 30 дни.
Резултатът? Имейлите показват оригиналните си правилни дати във всички клиенти. Сортирането отново работи. Хронологичната история на пощенската кутия е възстановена.
Често задавани въпроси
Могат ли датите да бъдат коригирани месеци след миграцията?
Да. Оригиналният "Date" хедър се запазва вътре в имейл съобщението независимо от момента на миграцията. Redate.io може да коригира датите на имейлите седмици, месеци или дори години след миграцията. Корекцията работи, докато оригиналните хедъри на имейла са непокътнати.
Корекцията ще изтрие ли имейлите ми?
Не. Redate.io никога не изтрива имейли. Оригиналните съобщения се преместват във видима папка, наречена "Redate.io - Originals" в пощенската кутия, където остават достъпни 30 дни. Всеки коригиран имейл се верифицира спрямо оригинала преди финализирането на процеса. Ако верификацията се провали за дадено съобщение, оригиналът остава непокътнат.
Работи ли с споделени пощенски кутии?
Да. Redate.io работи със споделени пощенски кутии в Google Workspace и Microsoft 365. За споделените кутии е необходим достъп на ниво администратор, за да се оторизира връзката. Процесът е идентичен с индивидуалните кутии: анализ, корекция, верификация.
Готови ли сте да възстановите правилните дати? Стартирайте безплатен анализ, за да разберете колко имейла са засегнати във всяка пощенска кутия.