Пресъздаване на профил Outlook: защо датите се променят

Стандартната поправка, която разваля датите

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

До следващата сутрин, когато потребителят отваря пощата си и открива, че 8 години кореспонденция показват една и съща дата: днес.

Точно същият симптом като при неуспешна IMAP миграция. И по същите причини.

Какво се случва технически

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

Всеки имейл съдържа в RFC 2822 заглавните си редове поле Date:, което показва кога е изпратено съобщението. Това поле се записва от имейл клиента на подателя в момента на изпращане и след това преминава непроменено през всички сървъри до пощенската кутия. Никога не се променя. Имейл, изпратен на 14 март 2019 г. в 09:32 ч., ще има винаги това поле Date: непокътнато, независимо какво се случи след това.

IMAP INTERNALDATE е нещо друго. Това е метаданни, управлявани от пощенския сървър, независими от съдържанието на съобщението. Тя показва кога съобщението е "постъпило" в кутията. При нормални условия, когато имейл пристигне чрез SMTP, сървърът записва часа на получаване като INTERNALDATE. Имейл, получен на 14 март 2019 г., ще има INTERNALDATE, съответстваща на датата му на изпращане.

Outlook по подразбиране сортира и показва имейлите според INTERNALDATE, предаден от IMAP сървъра, а не според полето Date: на самото съобщение. (Между другото, ако сте отваряли пълните свойства на имейл в Outlook, за да видите суровите заглавни редове, знаете, че това рядко е приятно четиво.)

Какво задейства изтриването на OST файла

Когато Outlook използва IMAP акаунт, поддържа локална база данни: OST файлът (Offline Storage Table). Този файл е локално огледало на имейлите, съхранявани на сървъра, заедно с техните метаданни, статуси за четене, категории и прочее.

Изтриването на OST файла е равносилно на изтриване на това локално огледало. Outlook трябва да изтегли всичко наново от IMAP сървъра.

Проблемът? Когато Outlook изтегля наново съобщение чрез IMAP, използва командата FETCH, за да вземе съдържанието. Но не използва систематично командата FETCH INTERNALDATE, за да вземе и запази оригиналната IMAP дата. При определени конфигурации и версии на Outlook клиентът възстановява локалния си индекс, използвайки датата, на която е изтеглил съобщението, вместо INTERNALDATE, съхранен на сървъра.

И така всички имейли в кутията получават датата на деня на презареждането.

Не всички версии на Outlook се държат еднакво

Уточнение: това поведение не засяга всички версии на Outlook по идентичен начин, и точно тук диагностиката се усложнява.

Outlook 2016 и 2019 в IMAP режим имат документирани случаи на некоректно възстановяване на индекс след изтриване на кеша. Новият Outlook (базиран на уеб, разгръщан постепенно от края на 2023 г.) управлява кеша по различен начин и може да дава непредсказуеми резултати. Outlook с Exchange или Microsoft 365 акаунт, конфигуриран в Exchange режим, е по-малко изложен на този конкретен проблем, тъй като протоколът MAPI/Exchange управлява синхронизацията по различен начин от IMAP.

Но ако потребителят ви е с IMAP акаунт, конфигуриран в класическия Outlook, и техник е изтрил OST файла или е пресъздал профила: рискът е реален.

Как да различим този случай от истинска миграция

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

Случаят с IMAP миграция

При IMAP миграция (BitTitan, CloudM, imapsync и др.) инструментът копира имейлите от един сървър на друг. За всяко копирано съобщение създава нов запис на целевия сървър. Ако инструментът не посочи изрично оригиналния INTERNALDATE, целевият сървър записва текущия час като INTERNALDATE. Освен това някои инструменти добавят заглавен ред Received: с датата на миграцията, което влошава ситуацията при определени клиенти. Детайлите за този механизъм са описани в статията ни за IMAP INTERNALDATE и разваляне на дати.

Случаят с пресъздаване на профил

Тук имейлите са все още на същия сървър, със същите оригинални INTERNALDATE. Нищо не е променено от страна на сървъра. Само локалният кеш на Outlook е възстановен с неправилни дати. Видимият симптом е идентичен (всички имейли показват същата скорошна дата), но причината е различна.

За потвърждение: влезте в кутията чрез уеб интерфейс (Gmail, Outlook.com или уеб пощата на вашия хостинг доставчик). Ако датите в уеб интерфейса са правилни, проблемът е изцяло локален за Outlook. Ако датите са грешни и в уеб интерфейса, проблемът е от страна на сървъра (миграция или промяна на INTERNALDATE директно на сървъра).

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

Добрата новина: и в двата случая (миграция или пресъздаване на профил) оригиналните дати не са загубени.

Заглавният ред Date: по RFC 2822 е неразделна част от съобщението. Той е също толкова непроменим, колкото текстът или прикачените файлове. Имейл, изпратен през 2017 г., съдържа в суровия си текст нещо от вида:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Този ред присъства в съобщението, съхранено на сървъра. Той не е бил променян. Това, което Outlook показва (неправилно), е метаданни, външни спрямо съдържанието на съобщението.

Именно това прави корекцията възможна. Механизмът на Redate.io анализира веригата от заглавни редове на всяко съобщение, за да извлече реалната оригинална дата, след което извършва насочена корекция на метаданните, без да променя съдържанието на съобщението. INTERNALDATE, видим от Outlook, се реконструира въз основа на тази автентична информация, която винаги присъства в съобщението.

Капанът на "чистото" пресъздаване

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

Три дни по-късно потребителят се обажда отново: търси имейл от доставчик от миналата година, но в Outlook всичките му имейли от 2023 г. се появяват като получени "вчера". Не може да намери нищо. Автоматичното архивиране вероятно е класирало скорошни имейли като стари. А шефът му иска имейл кореспонденция от септември 2022 г. за съдебен спор.

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

Привидните решения, които не помагат

Сортирането на имейли по "Дата на изпращане" вместо "Дата на получаване" в Outlook е първото нещо, което потребителите опитват. И изглежда, че работи... докато не осъзнаят, че сортирането по дата на изпращане е налично само за определени папки, изчезва при смяна на изгледа, и че другите приложения (мобилни, уеб интерфейс, правила за автоматично сортиране) продължават да използват неправилния INTERNALDATE.

Сортирането по дата на изпращане не е решение. Това е пластир, прикриващ симптома, без да докосва реалния проблем. Разглеждаме го подробно в статията Сортирането по дата на изпращане не е решение.

Пресъздаване на профила втори път? Не помага, ако Outlook продължава да възстановява кеша с текущата дата.

Експортиране и реимпортиране като PST? Внимание. Експортирането на PST от Outlook с грешни дати експортира и повредените метаданни. PST файлът ще съдържа грешните дати. Реимпортирането не коригира нищо и може дори да влоши ситуацията, като създаде дублирани съобщения с непоследователни дати. Тази тема е разгледана отделно в статията за импорт на PST в Outlook и датите, които стават днешни.

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

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

Redate.io се свързва директно с пощенската кутия (Google Workspace, Microsoft 365 или директен IMAP), сканира всички съобщения, за да идентифицира тези с неправилни метаданни, след което прилага своя многоетапен pipeline за анализ, за да коригира всеки имейл поотделно. Всяка корекция се верифицира. Оригиналните съобщения се запазват в видима резервна папка и Redate.io никога не ги изтрива, освен ако Вие не го направите сами.

Процесът се справя с крайните случаи, с които домашните скриптове системно се затрудняват: S/MIME подписани съобщения, имейли с non-ASCII кодировки в заглавните редове (RFC 2047), сложни multipart структури, заглавни редове Date: с нестандартни или неправилно форматирани часови зони. Скрипт, работещ правилно върху 50 тестови имейла в разработческа кутия, може да повреди необратимо 2000 съобщения в продукционна среда. В IMAP няма вградено отменяне, след като съобщение е заменено без предварително архивиране.

За случаи, свързани конкретно с Outlook, страницата за корекция коригиране на дати от IMAP копиране в Outlook описва стъпките за свързване на кутията и стартиране на анализа.

Предотвратяване на проблема при следващи интервенции

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

Преди да изтриете OST файл или да пресъздадете профил, проверете показваните дати в уеб интерфейса. Ако са правилни, отбележете го в тикета. След пресъздаването, влезте отново в уеб интерфейса и сравнете датите с тези в Outlook. Ако се появи разлика, проблемът се идентифицира незабавно, преди потребителят да се оплаче три дни по-късно.

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

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