IMAP импорти в Exchange и датите на Вашите имейли
Exchange Online дава на всяко съобщение в пощенска кутия дата, и точно тази дата Outlook показва и по нея сортира. За имейл, който пристига от интернет, това е моментът на доставката. За имейл, копиран чрез миграция, това е датата, която миграцията е дала на копието: оригиналната, когато миграцията я предава нататък, датата на импорта, когато не го прави.
Оттук идва повредата на датите при IMAP импорти в Exchange. Exchange Online не заменя дадената му дата. Но когато импортът не пренася оригиналната дата на всеки имейл, копието на 7-годишно съобщение получава датата на импорта, сякаш току-що е било доставено.
Резултатът? Импортирате 4000 имейла от стар IMAP сървър в Exchange Online, и имейлите показват датата на импорта вместо своята собствена. Имейли от 2018, 2020, 2023 г., датирани от днес. Потребителите Ви отварят Outlook в понеделник сутрин и виждат стена от съобщения с еднакви дати.
Как работи съветникът за миграция на Exchange Admin Center
Exchange Admin Center (EAC) включва вграден съветник за миграция за IMAP импорти. Това е графичният интерфейс, към който повечето администратори на Exchange се обръщат първи: отивате в Recipients, после Migration, създавате нова партида, избирате "Migrate to Exchange Online", посочвате IMAP като източник, качвате CSV файл с картографиране на пощенски кутии и стартирате партидата.
Зад кулисите съветникът за миграция на EAC създава New-MigrationBatch с тип на крайната точка, зададен на IMAP. Exchange се свързва с изходния IMAP сървър, чете всяко съобщение и го записва в целевата пощенска кутия в Exchange Online. На теория е достатъчно просто.
Но точно тук администраторите се сблъскват с проблем. Microsoft не документира как миграцията определя датата на всяко копирано съобщение, а администратори съобщават за имейли, които се получават с датата на синхронизацията, а не с датата, на която са получени. Outlook, OWA и всеки друг клиент, свързан с тази пощенска кутия, след това използва тази дата за показване и сортиране.
Оригиналното заглавие Date: от 2019 г.? Все още е там, скрито в заглавията на съобщението. Но Exchange не го използва за реда на сортиране във Вашата входяща кутия.
Date: Fri, 22 Nov 2019 16:08:33 +0100
PowerShell: New-MailboxImportRequest и същият проблем
Администраторите, които предпочитат командния ред, често се обръщат към New-MailboxImportRequest за импортиране на PST файлове, или към New-MigrationBatch с IMAP крайни точки за миграции сървър-към-сървър. Очакването е, че PowerShell дава повече контрол. И наистина дава, за някои неща. Но не за датите.
New-MailboxImportRequest импортира PST файлове в пощенски кутии на Exchange Online. PST файлът съдържа оригиналните времеви маркери за всяко съобщение. Но командата на PowerShell няма параметър, който да управлява коя дата получава всяко импортирано съобщение. Няма флаг -PreserveDates (и повярвайте ми, администраторите са търсили такъв).
New-MigrationBatch -SourceEndpoint с IMAP крайна точка работи подобно на съветника в EAC, само без графичния интерфейс. Същата IMAP връзка, същият резултат за датите. Командата предлага параметри за филтриране по период от дати (-StartAfter, -CompleteAfter) и за изключване на папки, но нищо, което да управлява как Exchange обработва времевия маркер на постъпващото съобщение.
За по-голяма точност, това засяга основно показваната дата и реда на сортиране. Съдържанието на съобщението, включително оригиналното заглавие Date, пристига непокътнато. Само датата, дадена на копието, е грешна, и точно тя стои зад всичко видимо за потребителя.
Директен IMAP импорт срещу инструменти на трети страни
Има ли значение дали използвате нативния IMAP импорт на Exchange, или инструмент на трета страна като BitTitan MigrationWiz или CloudM? Краткият отговор: проблемът с датите се случва и в двата случая, но по малко различни причини.
При нативния IMAP импорт на Exchange (съветника в EAC или PowerShell) самият Exchange се свързва с изходния IMAP сървър и извлича съобщенията. Как се задава датата на всяко копие зависи от Microsoft и не е документирано.
При инструментите на трети страни, инструментът за миграция действа като посредник. Той чете от източника, потенциално преобразува съобщението и записва в Exchange Online. Когато инструментът записва през IMAP, Exchange Online запазва датата, която инструментът предава: ако инструментът изпраща оригиналната дата на всеки имейл, копието я запазва; ако не го прави, копието получава датата на миграцията. Някои инструменти добавят и свое собствено заглавие Received: по време на препредаването.
Практическата разлика? Оставените заглавия не са еднакви от инструмент до инструмент, така че поправката не може да се основава на един фиксиран образец. Основният проблем е идентичен: показаната дата не е оригиналната дата на имейла.
Защо правилата за поток на пощата на Exchange Online влошават нещата
Ето нещо, което изненадва даже опитни администратори на Exchange. Exchange Online има транспортни правила (наричани вече "правила за поток на пощата" в административния център), които могат да се задействат върху импортирани съобщения. Ако Вашата организация има правила, които добавят заглавия, добавят декларации за отказ от отговорност или изменят съобщения въз основа на условия, тези правила могат да обработят и импортираните имейли.
Това означава, че имейл от 2020 г. може да получи добавен долен колонтитул с декларация за отказ от отговорност, или заглавие X, поставено от правило за съответствие, което не е съществувало, когато оригиналният имейл е бил изпратен. Повредата на датата е най-видимият симптом, но транспортните правила могат да създадат допълнителни неочаквани промени.
Можете ли да изключите транспортните правила по време на импорта? Да, временно. Но повечето администратори не се сещат да го направят, защото първоначално не очакват транспортният конвейер да обработва мигрирани съобщения. Докато осъзнаят какво се е случило, партидата за импорт вече е завършена и щетата е нанесена.
Какво означават грешните дати за средите на Exchange
Средите на Exchange обикновено са бизнес среди. Адвокатски кантори, финансови институции, здравни организации, държавни агенции. Това не са лични Gmail акаунти, където грешна дата е леко досадна. Това са пощенски кутии, в които времевите маркери на имейлите имат правно и регулаторно значение.
Съдебно задържане (litigation hold) в Exchange запазва имейли въз основа на периоди от дати. Ако всеки импортиран имейл показва датата на импорта вместо оригиналната дата, задържането обхваща грешния набор от съобщения. Търсене в eDiscovery за "всички комуникации между януари и март 2022 г." не връща резултат, защото тези имейли сега показват април 2026 г.
Политиките за задържане се сблъскват със същия проблем. Организация с 3-годишна политика за задържане може по погрешка да изтрие имейли, които изглеждат от 2026 г. (и затова са "нови"), докато всъщност са от 2019 г. и трябва да бъдат запазени. Или обратното: имейли, които трябвало да бъдат изчистени по политиката за задържане, остават, защото видимата им дата е скорошна.
Един случай от края на 2025 г.: доставчик на управлявани услуги (MSP) мигрира около 200 пощенски кутии от хостван Exchange доставчик към Microsoft 365, използвайки съветника за миграция на EAC. Три седмици по-късно служителят по съответствие на клиента отбеляза, че тримесечните отчети за архивиране на имейли показват всяко архивирано съобщение с една и съща дата. Целият архив на имейлите, връщащ се 5 години назад, изглеждаше все едно е пристигнал в един-единствен вторник през ноември.
Поправяне на датите от IMAP импорт в Exchange
Оригиналното заглавие Date: преживява импорта непокътнато. Импортът не изменя оригиналните заглавия по RFC 2822 вътре в съобщението. Тази оригинална дата е опорната точка за поправката.
Redate.io се свързва с пощенската кутия в Exchange Online (всеки влиза със своя собствен акаунт в Microsoft), проверява за съобщения с аномалии в датите, причинени от IMAP импорта, и прилага собствен двигател за корекция, който извършва валидиране на съответствието с RFC, запазване на структурата на съобщението и целенасочена реконструкция на метаданните. Redate не се нуждае да знае кой инструмент е извършил импорта: намира имейлите, чиято показвана дата не съответства на оригиналната им дата.
Всяко поправено съобщение се проверява поотделно: целостта на съдържанието, контролните суми на прикачените файлове, разположението в папки и групирането на разговорите. Оригиналите остават във видима резервна папка на Вашата собствена пощенска кутия, докато Вие сами не ги изтриете. Ако нещо изглежда грешно, връщането назад е на един клик разстояние.
Защо да не се поправи със скрипт на PowerShell? Защото разбирането на проблема със заглавието Received е лесната част. Поправянето на 8000 имейла в 50 пощенски кутии, без да се повредят подписани с S/MIME съобщения, да се счупят вложени MIME структури, да се обезобразят не-ASCII заглавия по RFC 2047 или да се загубят присвояванията на папки, е трудната част. Как проверявате, че всяко отделно поправено съобщение в производствена среда е непокътнато, че никой прикачен файл не е загубен, че никоя нишка на разговор не е прекъсната? Скрипт, който работи на тестова пощенска кутия с 30 съобщения, ще се задъне при реалните гранични случаи. Онзи договор с прикачен файл от 42 MB и три вградени изображения в структура multipart/mixed, вложена в обвивка multipart/alternative? Успех.
Ръководства по платформи
Поправката на датите се прилага на нивото на пощенската кутия в Exchange Online, но потребителите достигат до имейлите си през различни клиенти. Всеки от тях показва датите по различен начин:
- Поправка на датите от IMAP импорт в Exchange в Outlook
- Поправка на датите от IMAP импорт в Exchange в OWA (Outlook on the Web)
Търсите по-широк контекст за проблемите с датите в Microsoft 365 при различни инструменти за миграция? Вижте пълното ръководство за поправка на датите на имейлите след миграция на Microsoft 365.
IMAP импортът в Exchange остави пощенските Ви кутии с грешни дати? Започнете с безплатна проверка, за да видите колко имейла са засегнати и колко ще струва поправката, без да е необходима кредитна карта.