Outlook: дата на миграция IMAP срещу дата на изпращане

Симптомът, който всички познават

Току-що завършихте IMAP миграция към Microsoft 365 или Google Workspace. В понеделник сутринта тикетите се сипят: "Всичките ми имейли имат еднаква дата", "Историята ми е разбита", "Не мога да намеря нищо в пощата си". Отваряте Outlook и наистина - хиляди имейли показват датата от миналия уикенд. Не датата, на която са били изпратени. Датата, на която е извършена миграцията.

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

Три дати в един имейл

Един имейл е по-сложен, отколкото изглежда. Хедъри, тяло на съобщението, прикачени файлове... и няколко различни времеви маркировки, които съществуват едновременно. (Ако някога сте се опитвали да четете необработени имейл хедъри, знаете, че това не е точно лека литература за плажа.)

Хедърът Date: (RFC 2822)

Това е датата, която подателят е сложил в съобщението в момента на изпращане. Дефинирана от RFC 2822, тя изглежда така:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Този хедър е отлят в масата на съобщението. Никога не се променя, освен ако някой директно редактира необработеното съдържание. Това е "датата на изпращане" в строгия смисъл.

Хедърът Received: (добавян при всеки мрежов прескок)

Всеки сървър, който обработва имейл в транзит, добавя хедър Received: в началото на съобщението с неговата собствена дата. Имейл, преминал през три сървъра, натрупва три хедъра Received:. Най-новият е винаги пръв. Изглежда приблизително така:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Резултатът: когато инструмент за миграция като BitTitan MigrationWiz, CloudM, imapsync или GSMMO премества имейл от изходен сървър към целеви, той също се държи като "мрежов прескок". Инжектира нов хедър Received: най-отгоре в стека с датата и часа на миграцията.

IMAP INTERNALDATE

Това е третата дата и тя е причината за проблема. INTERNALDATE е метаданни, съхранявани на страната на IMAP сървъра, независимо от съдържанието на съобщението. Тя представлява датата, на която имейлът е бил доставен (или вмъкнат) в пощенската кутия. Когато инструмент за миграция вмъква имейл чрез IMAP командата за добавяне, той решава каква стойност да зададе на INTERNALDATE. И в много случаи инструментите използват датата на самата миграция. Не оригиналната дата.

Точно тук всичко се разпада.

Защо Outlook показва датата на миграцията

Outlook използва INTERNALDATE, за да показва колоната "Получено". Това е поведението му по подразбиране и е съобразено с IMAP спецификацията: INTERNALDATE трябва да представлява датата на получаване в пощенската кутия. При нормален поток (реален имейл, който пристига), INTERNALDATE е близо до датата в хедъра Date:. Двете са съвместими.

След неуспешна миграция, INTERNALDATE на всички импортирани имейли сочи към нощта на 14-ти срещу 15-ти юни 2024 г. (или каквато е датата на миграцията). Outlook чете тази стойност, показва я в колоната "Получено" и резултатът е катастрофален: 45 000 имейла изглеждат получени в една и съща вечер.

По-точно казано, първият хедър Received: (най-новият в стека) също влияе на показването в определени конфигурации. Но INTERNALDATE остава главният определящ фактор за колоната "Получено" в Outlook при синхронизиран IMAP режим.

Заобикалянето "Добавяне на колона Изпратено" в Outlook

Първото нещо, което повечето IT администратори правят когато открият проблема, е да потърсят заобиколен път от страната на клиента. И такъв действително съществува.

В Outlook може да се промени изгледът на колоните на папка, за да се замени (или допълни) колоната "Получено" с колоната "Дата" или "Изпратено". Колоната "Дата" чете директно хедъра Date: на съобщението, не INTERNALDATE. Тъй като хедърът Date: не е бил засегнат от миграцията, оригиналните дати се появяват отново.

Как се прави в Outlook (десктоп, версия Microsoft 365): десен бутон на мишката върху заглавието на колоната в списъка с съобщения, "Настройки за изглед", след което се редактират колоните - премахва се "Получено" и се добавя "Дата". Може да се разгърне чрез GPO за масово внедряване.

Добре. На хартия това решава визуалния проблем. На практика е лейкопласт върху артерия.

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

Мобилните и уеб клиенти

Outlook за iOS, Android и Outlook Web App (OWA) нямат същите опции за персонализация. Промяната на изгледа, която сте разгърнали на Windows машините, не се разпространява към тях. Потребителите, които проверяват имейлите си на телефона, продължават да виждат датата на миграцията. А в средно голяма компания това вероятно е половината от потребителите.

Търсенето

Търсенето в Outlook използва индекса на Windows Search (или индекса на Exchange/Microsoft 365 от страна на сървъра). Този индекс е изграден от INTERNALDATE, не от хедъра Date:. Ако потребител търси "имейли от януари 2022", търсенето връща имейлите, чийто INTERNALDATE е от януари 2022. Не тези, чийто хедър Date: е от януари 2022. Резултатът: старите имейли не се появяват при филтриране по дата. Промяната на колоната за показване не решава нищо тук.

Правилата за съобщения

Правилата в Outlook ("ако имейлът е получен преди...", "ако имейлът е получен след...") също използват INTERNALDATE. Правило за сортиране или архивиране, базирано на дати, няма да работи правилно след миграция, ако INTERNALDATE не е коригиран.

Съответствие и eDiscovery

Това може би е най-сериозният момент. Инструментите за съответствие, правно архивиране и eDiscovery (Microsoft Purview, например) използват INTERNALDATE като еталон за дата при правни заявки. Ако вашата компания е обвързана с изисквания за задържане на данни или трябва да отговаря на discovery заявки, повредените INTERNALDATE могат да създадат реални правни проблеми. Одит, изискващ "всички имейли между дата X и дата Y", няма да върне правилните резултати.

Инструменти на трети страни

CRM системи, ticketing инструменти, архиватори... всичко, което се свързва с вашия пощенски сървър чрез IMAP или Microsoft 365/Google Workspace API, чете INTERNALDATE. Промяната на изгледа в Outlook не поправя нищо за тези системи.

Единственото истинско решение: корекция на ниво сървър

Сортирането по дата на изпращане в Outlook не е решение. Това е лейкопласт. Истинската корекция трябва да се извърши на ниво метаданни на сървъра, не на ниво клиентски изглед.

Конкретно, това означава коригиране на INTERNALDATE на всеки имейл, така че да съответства на оригиналната дата от хедъра Date:. Оригиналният хедър Date: винаги присъства в съобщението (не е бил изтрит от миграцията), което прави корекцията възможна. Там се съдържа реалната информация за датата.

В Google Workspace, Gmail API разкрива параметър internalDate, позволяващ директна работа с тези метаданни. В Microsoft 365 механизмът е различен, но очакваният резултат е същият. На стандартен IMAP сървър стандартът предвижда, че датата може да бъде зададена при вмъкване на съобщение.

На практика, извършването на тази операция върху десетки хиляди имейли в производствена среда, без загуба на данни, без дублирани съобщения, без счупени нишки на разговори или етикети, управлявайки граничните случаи (S/MIME подписани съобщения, сложни MIME структури, не-ASCII кодирания по RFC 2047, обемисти прикачени файлове)... е съвсем друга история. Скрипт, работещ с 50 тестови имейла, няма да издържи при пощенска кутия с 40 000 съобщения. Управлението на грешки 429 (надвишена API квота), мрежови прекъсвания в 2 часа през нощта, съобщения с вече частично повредена MIME структура след миграция... всичко това изисква сериозно инженерство.

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

Идентифициране на отговорния инструмент за миграция

Проблемът се проявява по един и същи начин независимо от произхода на миграцията, но детайлите варират според използвания инструмент. BitTitan MigrationWiz, CloudM, imapsync и GSMMO имат всеки свой подпис в хедърите Received:, които инжектират. Аналитичният pipeline на Redate.io поддържа база с кореспонденции на стотици сигнатури на познати инструменти за миграция, за да разграничи хедъра на миграцията от останалата легитимна транзитна верига.

Ако не знаете кой инструмент е използван за вашата миграция (случва се, особено когато поемате управление след друг MSP), безплатното сканиране на Redate.io идентифицира засегнатите пощенски кутии и дава оценка на обема за корекция преди всякакъв ангажимент.

За конкретни контексти са налични подробни ръководства: коригиране на дати след imapsync в Outlook, коригиране на дати след BitTitan в Outlook или коригиране на дати след CloudM в Outlook.

Какво да направите сега

Ако четете тази статия след миграция, добрата новина е, че оригиналният хедър Date: е непокътнат във всеки един от вашите имейли. Реалната информация за датата е там, присъства в всяко съобщение. Проблемът е в метаданните, не в съдържанието. А метаданните могат да се коригират.

Можете също да прочетете статията IMAP INTERNALDATE: защо датите се развалят за по-задълбочено разбиране на механиката на проблема, или пълното ръководство за грешни дати в Outlook след миграция ако искате общ преглед на различните сценарии.

Готови ли сте да коригирате датите на вашите пощенски кутии? Стартирайте безплатно сканиране в Redate.io, за да идентифицирате засегнатите имейли и да оцените обема преди всяка корекция.