Споделен хостинг към Microsoft 365: скритият проблем с датите

Проблемът, за който никой не ви е казал

Току-що сте завършили миграцията на пощата си от OVH, Infomaniak, Ionos или o2switch към Microsoft 365. Съветникът за миграция в Exchange Admin Center (EAC) е работил цяла нощ, всичко е зелено, пощенските кутии са пълни. В понеделник сутринта - първи тикет: "Всичките ми стари имейли показват днешна дата." После втори. После десет.

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

Как IMAP управлява датите (и къде се обърква)

Всеки имейл, съхранен на IMAP сървър, има два различни вида датиране. От една страна, заглавката Date: (дефинирана от RFC 2822), която е вградена в самото тяло на съобщението и показва кога е изпратено или получено. От друга страна - INTERNALDATE, метаданни на ниво сървър, които показват кога точно съобщението е било поставено в пощенската кутия. Тази стойност е тази, която имейл клиенти като Outlook използват по подразбиране за сортиране и показване на имейли.

(Между другото, ако някога сте се опитвали да четете необработени заглавки на имейл в EAC, знаете, че не е точно приятно четиво. Лесно се набират двадесет до тридесет реда заглавки преди да стигнете до съдържанието.)

Когато инструмент за IMAP миграция прехвърля съобщение от една пощенска кутия в друга, трябва да пресъздаде INTERNALDATE на дестинацията. Някои инструменти го правят правилно. Много не го правят, или го правят с ограничения. Сървърът получател, от своя страна, запазва това, което получава: когато копие носи оригиналната си дата, Exchange Online запазва тази дата. Затова когато датите излизат грешни, проблемът е в инструмента, а не в Microsoft 365.

Резултатът: всеки мигриран имейл изглежда като "получен" в деня на миграцията. Без значение дали датира от 2019 г.

Сценарият в две стъпки: защо споделеният хостинг влошава всичко

Ето тук ситуацията става наистина проблематична при миграции от споделен хостинг като OVH, Infomaniak, Gandi, Ionos или o2switch.

Тези хостинг доставчици обикновено използват споделени сървъри с Postfix, Dovecot или cPanel със стандартни IMAP конфигурации. Много малки и средни фирми са натрупали там години имейли, понякога от 2010 или 2012 г. Когато решат да преминат към Microsoft 365, миграцията често се случва в две фази.

Стъпка 1: първото повреждане (преди дори Microsoft 365)

В много случаи имейлите вече са преминали през първа миграция. Фирмата е сменила споделен хостинг веднъж или два пъти с годините: от Gandi към OVH през 2018 г., след това от OVH към Infomaniak през 2022 г., например. Всяко IMAP прехвърляне може да е нулирало оригиналния INTERNALDATE към датата на прехвърлянето (когато инструментът не е предал оригиналната дата), а някои инструменти оставят и собствени заглавки за миграция, датирани от същия ден.

Когато имейлите пристигат в Microsoft 365, те вече носят белези. Оригиналната заглавка Date: е непокътната (тя е част от тялото на съобщението, никой не я докосва), но метаданните за дата вече са били нарушени веднъж.

Стъпка 2: второто повреждане при прехода към Exchange Online

Инструментът за IMAP миграция на EAC, или инструмент на трета страна като BitTitan MigrationWiz, конфигуриран в IMAP режим, поглъща тогава тези вече увредени имейли. Ако този инструмент също не предава оригиналната дата на всеки имейл, Exchange Online записва имейла с датата на прехвърлянето, и точно тя е "дата на получаване", която Outlook показва накрая.

Имейл, изпратен през март 2017 г., може да носи два слоя грешни дати: заглавки за миграция, оставени от преместването през 2022 г., и дата на получаване от миграцията към Microsoft 365 през 2024 г. Outlook показва 2024. Потребителят вижда 2024. Това е грешно на две нива.

Всъщност, за да бъдем напълно точни: не винаги най-скорошната заглавка Received: е тази, която се използва. Outlook определя показаната дата въз основа на комбинация от INTERNALDATE, записан от Exchange Online, и наличните заглавки. Но когато инструментът за миграция не предаде оригиналните дати, преместването към Exchange Online добавя нов слой от грешки върху стария.

Инструменти за миграция и хостинг: рисковите комбинации

Няколко комбинации се срещат много често при миграции от споделен хостинг:

• OVH / Infomaniak / Ionos + IMAP инструмент на EAC: Собственият инструмент на Microsoft е удобен, но е известен с това, че не запазва правилно датите при обемни IMAP миграции.
• cPanel (o2switch, LWS и др.) + BitTitan MigrationWiz в IMAP режим: MigrationWiz в IMAP режим добавя собствени заглавки на миграцията. Резултатът е документиран, между другото, на нашата страница коригиране на датите от миграция с BitTitan в Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync е мощен инструмент, но управлението на INTERNALDATE зависи от конфигурацията. Без подходящата опция датите не се запазват. Вижте също imapsync: датите не се запазиха.
• Всяка ръчна миграция чрез влачене и пускане в Outlook: Ако някой е копирал цели папки чрез drag-and-drop между два акаунта конфигурирани в Outlook, INTERNALDATE на всеки имейл се презаписва с датата на копирането. Без изключение.

Общият знаменател: всички тези методи водят до Exchange Online с имейли, чиято показана дата в Outlook вече не съответства на нищо реално.

Защо "да го оправим сами" е лоша идея в голям мащаб

Да разбереш проблема е едно. Да коригираш 8000 имейла разпределени в 40 Exchange Online пощенски кутии, с акаунти със сложни структури от папки, S/MIME подписани имейли, обемисти прикачени файлове и вложени нишки от разговори - е съвсем друго.

PowerShell скрипт, който изглежда работи с десет тестови имейла, може безшумно да се провали на съобщение номер 4237 заради повредена MIME граница или заглавка кодирана по RFC 2047 (онзи формат =?UTF-8?B?...?= за не-ASCII символи в имената на подателите). Без механизъм за индивидуална проверка няма да разберете. Просто ще имате изгубен имейл.

Конкретните рискове от DIY подхода при този тип миграция:

• Дублирани съобщения ако логиката за вмъкване се провали по средата
• Липсващи прикачени файлове ако multipart структурата е лошо реконструирана
• Счупени нишки от разговори в Outlook (разговорите се основават на заглавките References: и In-Reply-To:, които могат да бъдат повредени)
• Грешки 429 (Too Many Requests) от Microsoft Graph API в 3 часа сутринта, които прекъсват обработката без rollback
• Никакъв прост начин да проверите дали всичките 8000 корекции са приложени правилно

И в конкретния случай на миграции от споделен хостинг има допълнителна трудност: имейлите носят няколко слоя паразитни заглавки Received:, не само един. Прост скрипт, който премахва "последната Received:" не е достатъчен. Трябва да се анализира цялата верига, за да се установи коя заглавка съответства на коя миграция, и коя представлява действителната оригинална дата на получаване.

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

Всеки потребител се вписва със своя акаунт в Microsoft, и Redate.io отваря съответната пощенска кутия с достъпа, който този вход предоставя. Първоначалното сканиране е безплатно: Redate.io идентифицира всички имейли, чиято показана дата не съответства на реалната дата, и дава точна оценка по пощенска кутия.

Корекцията се основава на собствен двигател, който анализира пълната верига от заглавки на всяко съобщение, независимо от използвания инструмент за миграция, и реконструира метаданните за дата правилно, дори когато няколко слоя на повреда се наслагват един върху друг. Всеки коригиран имейл се проверява индивидуално. Redate.io никога не изтрива оригиналите. Те остават във видима папка на собствената ви пощенска кутия, докато решите сами да ги изтриете.

За миграции от споделен хостинг, многоетапният анализ на Redate.io обработва изрично сценариите с двойно повреждане: той не разглежда само последната заглавка Received:, а проследява пълната история, за да намери реалната дата на получаване. Вижте също как да коригирате датите след миграция към Microsoft 365 като цяло, и специалния наръчник за повредени INTERNALDATE в IMAP, за да разберете основната механика.

Преди миграция или след: два момента за действие

Две ситуации, два подхода.

Все още не сте мигрирали. Добрата новина: може да се ограничат щетите. Някои инструменти за миграция (MigrationWiz в Exchange режим, CloudM с правилните настройки) запазват по-добре датите от другите. Но дори в най-добрия случай, миграция от споделен хостинг без чиста история вероятно ще остави следи. Планирайте минаване през Redate.io след миграцията, преди да предадете пощенските кутии на потребителите.

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

Мигрирахте от OVH, Infomaniak, Ionos или o2switch към Microsoft 365 и датите са грешни? Създайте акаунт в Redate.io, за да сканирате пощенските кутии безплатно и да видите точно мащаба на проблема, преди да вземете каквото и да е решение.