Грешни дати на имейли след миграция към Exchange Online

Класическият сценарий в понеделник сутринта

Току-що сте финализирали IMAP миграцията към Exchange Online. Батчът приключи без грешки в Exchange Admin Center, пощенските кутии са синхронизирани, потребителите могат да влизат. Затваряте лаптопа в петък вечерта с усещането за добре свършена работа.

В понеделник сутринта тикетите започват да идват. "Всичките ми имейли са датирани от петък." "Историята на входящата ми поща е безполезна." "Липсват стари имейли." Всъщност не липсва нищо: имейлите са там, но Outlook ги показва с датата на миграцията вместо с оригиналната дата на изпращане. Имейл от 2019 г. изглежда като изпратен миналия петък. Резултатът: цялата пощенска кутия изглежда, сякаш съдържа само скорошни съобщения.

Това е един от най-разочароващите проблеми при IMAP миграции към Exchange Online, и Microsoft почти систематично го подкрепя с недостатъчна документация.

Защо миграцията чрез EAC разваля датите

Когато използвате Exchange Admin Center (EAC) за конфигуриране на IMAP миграция от локален сървър (Dovecot, Courier, Cyrus, UW-IMAP или друг), Exchange Online се свързва с вашия изходен сървър чрез IMAP, извлича съобщенията и ги инжектира в целевите пощенски кутии чрез вътрешния транспортен pipeline.

Точно тук се създава проблемът.

Всеки имейл, преминаващ през транспортния pipeline на Exchange, автоматично получава заглавие Received: с времеви печат. Това е стандартно поведение на SMTP и IMAP сървъри от десетилетия: всеки сървър, докоснал съобщение, поставя своя времеви подпис. Проблемът е, че Outlook (и по-специално Outlook за Windows в по-новите версии) използва най-новото заглавие Received: като референция за показване, когато останалите метаданни са неясни.

Оригиналното заглавие Date: (което посочва кога имейлът е бил изпратен по смисъла на RFC 2822) е винаги налично в съобщението. То не е изтрито. Но е "засенчено" от новото заглавие Received:, добавено от Exchange при инжектирането.

Успоредно с това, IMAP INTERNALDATE (метаданните, които IMAP сървърите използват за вътрешно датиране на съобщенията и които управляват сортирането в повечето клиенти) се задава на датата на инжектирането, а не на оригиналната дата на имейла. Exchange Online няма никакъв вграден начин да запази INTERNALDATE от изходния сървър при batch миграция чрез EAC.

EAC срещу инструменти на трети страни: важна разлика

Трябва да разграничим две ситуации. При инструменти като BitTitan MigrationWiz или CloudM Migrate проблемът съществува, но тези инструменти понякога имат опции за конфигурация (частично документирани, скрити в разширените настройки), които се опитват да запазят определени метаданни за дата.

Нативната миграция чрез EAC не предлага никаква такава опция. Microsoft не разкрива параметър за контрол на запазването на INTERNALDATE в pipeline-а за batch миграция. Черна кутия: конфигурирате батча, стартирате го, Exchange прави каквото иска вътрешно. А това, което прави систематично, е да датира съобщенията с датата на тяхното инжектиране.

(Между другото, ако сте опитвали да четете необработените заглавия на имейл, мигриран чрез EAC, знаете, че добавеното от Exchange поле Received: е лесно разпознаваемо: съдържа препратки към вътрешни сървъри на Microsoft като *.protection.outlook.com или *.prod.exchangelabs.com, с времеви печат, съответстващ точно на прозореца на миграцията.)

Защо повторното създаване на батча не помага

Инстинктивната реакция на много IT администратори е: "Ако изтрия мигрираните пощенски кутии и стартирам батча отново от нулата, може би този път датите ще бъдат правилни."

Разбираемо. Но не работи.

Проблемът не е в конфигурацията на батча. Не е в параметър, забравен да се отметне. Той е в самата архитектура на транспортния pipeline на Exchange, която е идентична при всяка миграция. Повторното стартиране ще даде точно същия резултат: същите заглавия Received: с новата дата на миграцията и същите неправилни INTERNALDATE. Ще загубите време и потребителите ще бъдат обезпокоени втори път без причина.

Някои администратори опитват и да променят параметрите за сортиране в Outlook ("сортиране по дата на изпращане" вместо "дата на получаване"). Сортирането по дата на изпращане не е решение. Това е пластир. Заглавието Date: и INTERNALDATE остават неправилни за клиентите, които не позволяват тази настройка, за OWA, за Outlook Mobile и за всяко приложение на трета страна, достъпващо пощенската кутия чрез IMAP или EWS.

Какво реално се случва в заглавията

Ето опростен пример за съдържанието на имейл след миграция чрез EAC. Оригиналното заглавие:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@stardomein.bg
Subject: Отчет Q1 2019

След миграцията съобщението получава в началото на веригата нещо подобно:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook вижда това заглавие Received: първо (добавено е в горната част на блока с заглавия), интерпретира го като най-новата дата на обработка на съобщението и го показва като дата на получаване. Оригиналното заглавие Date: от 2019 г. е там, непокътнато, няколко реда по-надолу. Но Outlook не го използва за показване в списъка със съобщения.

За да бъдем точни: поведението варира леко според версията на Outlook. Версиите след 2021 г. (и особено новият Outlook за Windows, разгърнат от края на 2023 г.) са особено чувствителни към този проблем, тъй като разчитат повече на метаданните от Exchange Graph, отколкото на необработеното заглавие Date:. Това означава, че миграции, които не са причинявали видим проблем с Outlook 2016, сега могат да го причинят с новия Outlook.

Кой реално е засегнат

Най-честите IMAP изходни сървъри при такъв тип миграция са Dovecot (много разпространен в Linux/cPanel среди) и Courier. И двата излагат INTERNALDATE чрез IMAP, което EAC не запазва. Ако мигрирате от Exchange on-premises към Exchange Online (хибридна или cutover миграция), поведението е различно, защото Microsoft използва вътрешен транспортен протокол (MAPI/EWS), който запазва по-добре метаданните. Проблемът е специфичен за общата IMAP миграция чрез EAC.

Най-засегнати са потребителите с пощенски кутии с дълга история (5 и повече години) и голям обем съобщения. Потребител с 300 имейла ще се оправи бързо. Търговски директор с 12000 имейла, наредени по дата, от които зависи ежедневно, за да намери клиентски кореспонденции, е напълно блокиран.

Защо скрипт "направи си сам" е лоша идея тук

Някои IT администратори, разбиращи техническия проблем, са изкушени да напишат PowerShell или Python скрипт за ръчно коригиране на заглавията. Основната концепция може да изглежда проста, след като идентифицирате механизма. Но реалността на корекцията в производствена среда е съвсем друга работа.

Първо, граничните случаи. Имейлите с S/MIME подпис и PGP криптираните съобщения имат структура, която не търпи модификация на заглавията без да се обезсили подписът. Съобщенията multipart/alternative с неправилно оформени MIME граници (чести на стари Courier сървъри) могат да бъдат повредени от скрипт, модифициращ съобщението без правилно да възстанови структурата. Не-ASCII заглавията, кодирани по RFC 2047 (имена на подателите с акцентирани символи или японски знаци, например), са класически извор на грешки.

После, обемът. Скрипт, работещ на 50 тестови имейла в среда за разработка, не се справя с ограниченията на скоростта на Exchange Online API в производство. Грешката 429 Too Many Requests в 2 часа сутринта по време на batch от 8000 съобщения, без механизъм за възстановяване, означава безсънна нощ и евентуално дублирани или изгубени съобщения.

И най-важното: как ще проверите, че всеки коригиран имейл е непокътнат? Че никой прикачен файл не е бил отрязан, нито един разговор не е счупен, а папките и етикетите са запазени? Без индивидуален механизъм за валидация просто се надявате, че всичко е минало добре.

Коригирането на дати след миграция е проблем, който изглежда като скрипт от 50 реда, но изисква хиляди, за да бъде надежден в производство.

Какво прави Redate.io по различен начин

Redate.io се свързва с Exchange Online чрез Microsoft 365 API (Azure Active Directory, делегирани разрешения на ниво tenant) и сканира засегнатите пощенски кутии, за да идентифицира имейлите, чиито метаданни за дата са повредени от миграцията. Тази стъпка на сканиране е безплатна и дава точна представа за мащаба на проблема: брой засегнати съобщения, засегнати пощенски кутии, диапазон на повредените дати.

Собственият механизъм за корекция на Redate.io обработва след това всеки имейл поотделно чрез многоетапен pipeline за анализ, включващ разпознаване на сигнатури от известни инструменти за миграция (включително транспортния pipeline на Exchange Online), валидация на RFC съответствие и проверка на структурната цялост на съобщението преди и след корекция. S/MIME подписани имейли, сложни MIME структури, нестандартни кодирания: всички се обработват по специфични пътища на обработка.

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

Ценообразуването е базирано на обема, с еднократно плащане за пощенска кутия. Без абонамент, без повтарящи се такси. Поправяте проблема веднъж и е готово.

Специално за миграции към Exchange Online, Redate.io поддържа свързване чрез разрешения за приложение в Azure AD (без да се налага да създавате индивидуални идентификационни данни за всяка пощенска кутия), което прави обработката на големи флоти от пощенски кутии много по-лесна за организиране от IT администратор или MSP.

Ако управлявате няколко клиента, преминали през такъв тип миграция, вижте също пълното ръководство за коригиране на дати след миграция към Microsoft 365 за преглед на различните обхванати сценарии.

Имейлите са там, оригиналните дати също. Стартирайте безплатно сканиране в Redate.io, за да видите точно колко съобщения са засегнати в пощенските ви кутии в Exchange Online, преди да решите какво да правите.