Импорт PST в Outlook: защо датите стават днешни

Симптомът: всички имейли показват днешната дата

Току-що сте приключили с импорт на PST файл в Outlook. Лентата за напредък достигна 100%, всичко изглеждаше наред. После отваряте входящата поща... и всеки импортиран имейл показва днешната дата. Съобщение от 2019 г., друго от 2021 г., архив от пет години - всички носят едно и също число. Деня на импорта.

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

PST файл срещу IMAP: два коренно различни свята

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

PST файлът (Personal Storage Table) е патентован формат на Microsoft. Той съхранява имейлите заедно с пълните им метаданни: дата на изпращане, дата на получаване, прикачени файлове, категории, индикатори за прочитане. Тези метаданни се управляват директно от Outlook, извън всякакъв пощенски протокол. Когато разглеждате PST в Outlook без връзка към сървър, показваните дати идват направо от вътрешните полета на файла. До тук всичко е наред.

Проблемът се появява, когато се опитате да прехвърлите съдържанието към пощенска кутия на IMAP сървър - Microsoft 365, Google Workspace или какъвто и да е стандартен хостинг. Там напускате света на PST и влизате в света на IMAP, а правилата се менят коренно.

IMAP APPEND и INTERNALDATE: сърцето на проблема

В IMAP всяко съобщение, съхранено на сървъра, има два вида данни за дата:

• Заглавието Date: (RFC 2822), което е част от самото съдържание на съобщението. Това е датата, вписана в съобщението от подателя.
• INTERNALDATE - метаданни, управлявани от IMAP сървъра. Те представляват момента, в който съобщението е постъпило на сървъра. Именно тази стойност Outlook използва за сортиране в изглед "Дата на получаване".

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

Когато имейл пристигне нормално на сървъра, пощенският сървър автоматично задава INTERNALDATE на точния момент на получаване. Резултатът: показваната дата в Outlook съответства на момента, в който сте получили съобщението.

Когато Outlook импортира PST файл към IMAP кутия, той използва командата IMAP APPEND, за да изпрати всяко съобщение към сървъра. IMAP стандартът позволява да се подаде явна стойност на INTERNALDATE при APPEND. Но Outlook не го прави. Изпраща съобщенията, без да указва INTERNALDATE. IMAP сървърът, при липса на инструкция, прилага правилото по подразбиране: INTERNALDATE се задава на текущия момент, тоест момента на импорта.

Резултатът: 8000 импортирани имейла, 8000 имейла с днешната дата.

Защо Outlook се държи по този начин

Това не е пропуск от страна на Microsoft. Това е избор на имплементация, който вероятно е изглеждал разумен по онова време: при оригиналния сценарий за импорт на PST, потребителят архивира съобщения локално и ги „импортира" в текущата си кутия. Релевантната дата за сортиране е оригиналната дата на получаване... но Microsoft е избрал да не пренася INTERNALDATE при операцията по импорт.

За да бъдем точни: това поведение засяга импорта на PST чрез вградения асистент на Outlook (Файл > Отвори и експортирай > Импортиране/Експортиране). Други методи на импорт, като някои инструменти на трети страни или миграции чрез Exchange Admin Center, могат да се държат различно в зависимост от тяхната имплементация на IMAP APPEND.

Това поведение е известно и документирано в Microsoft форумите от години. Не се е променило с Outlook 2016, нито с Outlook 2019, нито с актуалните версии на Microsoft 365. Потребител, който импортира PST днес, ще срещне абсолютно същия проблем, както и през 2015 г.

Каква е разликата от класическата IMAP миграция

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

При типична IMAP миграция - например с BitTitan MigrationWiz или imapsync - имейлите преминават от изходен IMAP сървър към целеви IMAP сървър. Инструментът за миграция извлича съобщенията и ги реинжектира чрез IMAP APPEND. Някои инструменти запазват правилно INTERNALDATE, други - не. Но във всички случаи съобщенията вече имат добавено заглавие Received: с датата на миграцията, което може да наруши показването в Outlook независимо от INTERNALDATE.

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

Това разграничение има пряко следствие за корекцията: подходът не е съвсем един и същ в зависимост от това дали третираме IMAP миграция или PST импорт. Вижте също защо INTERNALDATE причинява счупени дати за подробно обяснение и в двата случая.

Защо настройките за изглед в Outlook не помагат

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

Сортирането по дата на изпращане не е решение. Това е лепенка.

Ето защо: дори да промените сортирането, за да се показва колоната "Дата" (която съответства на заглавието Date: на съобщението, тоест оригиналната дата), няколко проблема остават:

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

С други думи, промяната на изгледа решава показването за конкретен потребител, на конкретен клиент, при конкретна конфигурация. Тя не коригира проблема в основата му.

Ресинхронизацията на OST също не помага

Друг класически опит: изчистване на OST кеша и принудителна пълна ресинхронизация от сървъра. Идеята е, че проблемът може да идва от локалния кеш на Outlook, а не от сървъра.

Грешна посока. OST файлът е локален кеш, отразяващ състоянието на IMAP сървъра. Ако INTERNALDATE е грешен на сървъра, ще бъде грешен и в OST след ресинхронизацията. Изтриването на OST не променя нищо в данните, съхранени на Exchange Online или Google Workspace. Сървърът е авторитетният източник.

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

Проблемът с мащаба: 1 имейл е тривиален. 15000 е друга история

Технически, ако разбирате проблема, бихте могли да си представите скрипт, който преминава през кутията, чете заглавието Date: на всяко съобщение и коригира INTERNALDATE съответно. Да разбереш проблема е едно. Да го коригираш на 15000 имейла, без да изгубиш нито един, е съвсем друго.

Няколко реалности от практиката:

• Microsoft Graph и Gmail API налагат ограничения на скоростта (rate limits). Наивен скрипт ще генерира грешки 429 Too Many Requests, ще прекъсне изпълнението си по средата на корекцията и ще ви остави с частично коригирана кутия - без да знаете кои имейли са обработени и кои не.
• Някои имейли в PST файл може да имат деформирани или липсващи заглавия Date:. Скрипт без обработка на тези гранични случаи може да повреди тези съобщения или да ги пропусне мълчаливо.
• Подписаните (S/MIME) или криптираните (PGP) имейли имат допълнителни ограничения за цялостност. Промяната на метаданните им без предпазни мерки може да анулира криптографския подпис.
• Структурите multipart/alternative със сложни MIME граници понякога реагират непредсказуемо на операции по промяна.
• Никакъв механизъм за връщане назад. Ако нещо се обърка по средата на обработката, как се връщате към началното състояние?

Скрипт, който работи на 10 тестови имейла, няма да работи на производствена кутия с 50000 съобщения. Миналата година клиент с PST архив от 40 GB опита да коригира това с Python скрипт от Stack Overflow. Резултатът: 3000 имейла в дубликат, 200 съобщения с недостъпни прикачени файлове и две седмици ръчно почистване.

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

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

Всеки коригиран имейл се проверява поотделно. Оригиналите се съхраняват в видима резервна папка в продължение на 30 дни преди окончателна промяна. Корекцията работи на трите основни платформи: Microsoft 365 (чрез Azure AD), Google Workspace (чрез делегиране на домейн) и директен IMAP за стандартни хостинг доставчици.

Първоначалното сканиране е безплатно. То показва точно колко имейла са засегнати и каква е разпределението на грешните дати, преди да вземете каквото и да е решение.

Вижте също:

• Коригиране на имейл дати след миграция към Microsoft 365
• Outlook: дата на миграция IMAP срещу дата на изпращане
• Могат ли датите на имейлите да се коригират след миграция?

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