Всички стари имейли показват една и съща дата: защо?

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

Отваряте Outlook, Gmail или Apple Mail една сутрин. Нещо не е наред. Стотици, понякога хиляди стари имейли показват всички една и съща дата: отпреди няколко дни или няколко седмици. Съобщения от 2021, от 2019, от 2016 изглеждат сякаш са пристигнали вчера. Сортирането по дата вече не означава нищо. Търсите важен имейл от миналата година и той е потопен в блок от хиляди съобщения, които сякаш са пристигнали в един и същи ден.

Новите имейли показват правилни дати. Само старите съобщения са засегнати.

Какво се е случило всъщност?

Първият рефлекс: да обвиним софтуера

Естествено се сещаме за бъг. Outlook се е сринал. Някоя актуализация е минала зле. Файл е повреден. И точно оттук започва търсенето по форуми: „бъг дата Outlook", резултати за OST файлове, за SCANPST.exe, за пресъздаване на профила в Outlook от нулата...

Минават два часа. Проблемът остава.

Между другото, SCANPST е инструмент за поправка на локални файлове с данни на Outlook. Той може да коригира определени повреди във файла, но не докосва данните, съхранявани на сървъра за поща. С други думи, дори да поправите OST файла си перфектно, датите ще останат грешни, защото проблемът не е при вас.

Проблемът е в самите имейли, на сървъра.

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

В почти всички случаи този симптом се появява след миграция на поща. Компанията ви е преминала от стара система към Google Workspace, Microsoft 365 или нов сървър. Някой, някъде, е използвал инструмент за прехвърляне на всички ваши имейли от едно място на друго.

Може да не сте били информирани за това. Или сте знаели, но не сте свързали събитието с проблема с датите. Това е напълно нормално.

Тези инструменти за миграция вършат огромна работа: копират хиляди съобщения, цели папки, прикачени файлове. Но имат един доста коварен страничен ефект. Когато имейл се прехвърля от един сървър на друг, инструментът добавя малък технически ред в имейла, наречен заглавие „Received:", което показва кога съобщението е пристигнало на новия сървър. Тоест: датата на миграцията.

И ето го корена на проблема.

Как пощенският клиент решава коя дата да покаже

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

(Ако някога сте кликнали "Покажи източник" или "Преглед на всички заглавия" на имейл, вероятно сте видели тези криптични редове, които изглеждат като неразбираема стена от текст. Точно това са те.)

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

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

Резултат: 8 000 имейла, които всички изглеждат сякаш са пристигнали в един и същ вторник през ноември.

Кои инструменти причиняват това?

Най-разпространените инструменти за миграция всички се държат така. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (безплатният инструмент на Google за миграция от Outlook), и много други. Всъщност това не е чак недостатък от тяхна страна: то е следствие от начина, по който технически работи имейл протоколът. Тези инструменти добавят това заглавие, защото точно това изисква протоколът, когато съобщение се препредава от един сървър на друг.

Проблемът е, че никой не предупреждава потребителите, че това ще се случи.

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

Погрешни насоки, които да избягвате

Няколко решения, които постоянно се появяват във форумите и не работят:

Поправка на файла с данни чрез SCANPST

Както бе споменато по-горе: SCANPST поправя локални файлове на Outlook (файловете .pst или .ost, съхранени на компютъра Ви). Той не променя имейлите на сървъра. След поправката имейлите Ви ще имат все същите грешни дати, защото тези дати живеят в самите имейли, не в локалния файл.

Пресъздаване на профила в Outlook

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

Сортиране по "дата на изпращане" вместо по "дата на получаване"

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

Преинсталиране на пощенския клиент

Не. Имейлите са на сървъра, не в софтуера. Преинсталирането на Outlook, Gmail, Apple Mail или Thunderbird не променя нищо в данните, съхранени онлайн.

Добрата новина: истинските дати все още са там

Ето нещо важно, което трябва да разберете, и което прави поправката възможна: оригиналната дата на изпращане на всеки имейл не е била изтрита. Тя все още е в имейла, в заглавие с името "Date:", което съответства на датата на изпращане, избрана от подателя. Това е имейл стандарт (определен от техническа спецификация, наречена RFC 2822), който всички инструменти за миграция спазват, защото промяната му би представлявала сериозно нарушение на протокола.

С други думи, ако сте получили имейл на 14 март 2022 г., този имейл все още съдържа тази дата някъде в данните си. Просто вече не е тя, която клиентът Ви показва първо.

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

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

Може да се питате дали някой от ИТ отдела би могъл просто да напише скрипт, за да поправи това. Разбирането на случващото се е едно. Поправянето му чисто в хиляди имейли, без да загубите нито един, е съвсем друго нещо.

Имейлът не е обикновен текстов файл. Той може да съдържа прикачени файлове, цифрови подписи, съдържание, кодирано в сложни формати. Промяната на метаданните на такова съобщение без да се наруши структурата му означава справяне с десетки специфични случаи: съобщения, подписани с S/MIME, имейли, криптирани с PGP, нестандартни кодирания, многочастни структури... Домашен скрипт, който работи на 20 тестови имейла, много вероятно ще се провали на реална пощенска кутия с 15 000 съобщения. И ако нещо се обърка, как проверявате, че нито един имейл не е бил повреден или загубен? Със самостоятелен скрипт: не можете.

Без механизъм за резервно копие и проверка за всяко отделно съобщение, рискът от съпътстващи щети е реален.

Какво прави Redate.io

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

Всеки коригиран имейл се проверява поотделно. Оригиналите се запазват във видима резервна папка в собствената Ви пощенска кутия, докато Вие сами не ги изтриете. Ако нещо изглежда грешно, можете да върнете промените.

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

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

Искате да видите пълния обхват на щетите, преди да се ангажирате? Направете безплатна проверка на пощенската си кутия на Redate.io и разберете за минути колко имейла са засегнати.