eM Client: грешни дати след импорт PST или Thunderbird

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

Току-що сте завършили импорт на PST файл в eM Client, или сте мигрирали от Thunderbird към новата си пощенска кутия. Импортът е приключил без видима грешка. Но когато отворите входящата поща, нещо не е наред: стотици, понякога хиляди имейли показват една и съща дата, тази на деня на импорта. Имейл от 2019 година изглежда като получен вчера. Договор, подписан преди три години, се появява сякаш току-що е пристигнал.

Първата естествена реакция е да обвините eM Client. Грешна настройка, грешна колона за сортиране, проблем с показването... Търсите в предпочитанията. Превключвате между "Дата на получаване" и "Дата на изпращане". Нищо не се променя. Или по-точно, нещо се променя, но не решава същинския проблем.

Причината е, че проблемът не е в eM Client. Той е в метаданните на сървъра.

Истинската причина: INTERNALDATE на IMAP е презаписан по време на импорта

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

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

• Хедърът Date: (дефиниран от RFC 2822): това е датата, която подателят е записал в съобщението в момента на изпращането. Тя е капсулирана в тялото на съобщението и на теория е неприкосновена.
• INTERNALDATE: метаданна на сървъра, външна спрямо съобщението, която представлява датата, на която съобщението е депозирано в пощенската кутия. Именно тази стойност имейл клиентите използват с приоритет за сортиране и показване на имейлите.

При импорт на PST или миграция от Thunderbird, инструментът за импорт (независимо дали е вграденият модул на eM Client, инструмент на трета страна, или ръчно IMAP копиране) депозира съобщенията на целевия IMAP сървър. И ако инструментът не запази изрично оригиналния INTERNALDATE при депозирането, сървърът автоматично присвоява текущия INTERNALDATE, тоест датата и часа на импорта.

Резултатът: 8000 архивирани имейла от 2017 година, всички с времеви печат "получени" в момента на миграцията ви.

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

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

Объркването идва от едно разграничение, което малко хора познават. В eM Client, както в Outlook или Thunderbird, обикновено има две колони с дати:

• "Дата на получаване" (или "Дата на пристигане"): базирана на INTERNALDATE на сървъра.
• "Дата" или "Дата на изпращане": базирана на хедъра Date: на съобщението.

Много администратори го откриват и мислят, че са намерили решението: превключват на "Дата на изпращане" и проблемът визуално изчезва в eM Client. Но това не е съвсем вярно.

Всъщност, дори да сортирате по дата на изпращане в eM Client, проблемът продължава да съществува за всички останали клиенти и интерфейси, които имат достъп до същата пощенска кутия. Ако потребителите ви преглеждат имейлите си от OWA, от Outlook на работното място, от приложението Gmail на мобилен телефон, или от какъвто и да е друг IMAP клиент, те ще виждат датите на импорта. Настройката за сортиране в eM Client важи само за eM Client и не засяга метаданните, съхранени от страна на сървъра.

Освен това, в Microsoft 365 и Google Workspace, нативният уеб изглед сортира по INTERNALDATE. Това поведение не може да се промени от клиента.

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

Особеният случай на PST импорта

Импортът на PST файлове заслужава отделен параграф. PST файлът (Personal Storage Table) е собствен формат на Microsoft, който съхранява имейли, контакти и календари локално. Когато импортирате PST в eM Client, са възможни два сценария:

• Локален импорт към IMAP акаунт: eM Client чете PST и прехвърля съобщенията на целевия IMAP сървър. Ако датата на депозиране не се запази, INTERNALDATE се презаписва. Това е най-честият случай и точно тук датите се повреждат.
• Импорт към локална папка: съобщенията остават на машината, извън сървъра. INTERNALDATE не съществува в този контекст и eM Client може да показва датата Date: на съобщението. По-малко проблеми с датата тук, но и по-малко практическа полезност.

При Thunderbird ситуацията е подобна. Ако използвате вградената функция за импорт на eM Client (която чете профилите на Thunderbird), или ако сте копирали mbox папки чрез IMAP, съобщенията се депозират на сървъра без гаранция за запазване на INTERNALDATE. А сървър, който получава съобщение без изрична инструкция за дата на INTERNALDATE, систематично ще поставя времеви печат в момента на получаването.

Коя платформа е засегната?

Проблемът е идентичен независимо от целевата платформа, тъй като става дума за стандартно поведение на IMAP протокола:

• Microsoft 365 / Exchange Online: INTERNALDATE се презаписва при всеки импорт, който не използва командата IMAP APPEND с изричен параметър за дата. Същото важи и за миграция от Exchange on-premise.
• Google Workspace: идентично поведение. Имейлите, импортирани чрез eM Client или инструменти на трети страни, показват датата на импорта в Gmail и в административния интерфейс.
• Класически IMAP хостинг провайдъри (OVH, Infomaniak, Ionos, и др.): никаква специална обработка на датата при получаване на съобщение с APPEND. INTERNALDATE ще бъде датата на депозирането.

Един клиент се свърза с нас след като беше мигрирал около сто пощенски кутии от Exchange 2013 към Microsoft 365, използвайки eM Client като преходен инструмент за някои VIP акаунти. Резултатът: кутиите, мигрирани правилно чрез MigrationWiz, бяха наред, но всички кутии, минали през eM Client, имаха датите на импорта. Излишно е да казваме, че засегнатите потребители не бяха доволни.

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

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

На теория, да. На практика, това е минно поле.

Първо, крайните случаи се натрупват бързо в производствена пощенска кутия. Цифрово подписаните S/MIME съобщения са особено чувствителни към всякаква манипулация на структурата. Същото важи за PGP криптираните съобщения. Имейли с обемни прикачени файлове, нестандартни MIME граници, или необичайни Content-Transfer-Encoding кодирания могат да се повредят безшумно, ако обработката не е прецизна. Скрипт, който работи на 50 тестови имейла, няма да функционира надеждно върху пощенска кутия с 20 000 съобщения и 6 години история.

След това идва управлението на API квотите. В Microsoft 365, ограниченията на скоростта на Graph API или EWS в 3 часа сутринта при пакет от 8000 съобщения за коригиране, трябва да се управляват. Но те не се управляват сами. Неконтролиран скрипт, срещнал грешка 429 Too Many Requests при съобщение номер 3741, може да продължи или не. И не е сигурно, че ще знаете кои съобщения са обработени.

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

Коригирайте датите от корена с Redate.io

Redate.io се справя с проблема там, където е: на ниво сървърни метаданни, не на ниво имейл клиент.

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

Корекцията използва собствен двигател, който анализира пълната верига от хедъри на всяко съобщение, прилага съпоставяне на образци спрямо стотици подписи на известни инструменти за импорт (включително специфичните поведения на eM Client, Thunderbird и PST импорта), и реконструира метаданните за дата по целенасочен начин, без да променя съдържанието на съобщението, прикачените му файлове, нито неговата MIME структура.

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

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

За следващата миграция: какво да проверите

Ако планирате миграция и искате да избегнете този проблем предварително, контролната точка е проста: инструментът, който използвате, запазва ли изрично INTERNALDATE при депозирането на съобщенията на целевия сървър?

За PST импорти към Microsoft 365, сертифицираните от Microsoft инструменти (като MigrationWiz в нативните му режими) обикновено обработват това запазване. За ръчни импорти чрез eM Client или Thunderbird, това рядко е така. Проверете документацията на вашия инструмент, преди да стартирате импорт върху производствени пощенски кутии.

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

За администратори, които редовно управляват миграции за своите клиенти, статията за коригиране на имейл дати от страна на MSP и тази за функционирането на IMAP INTERNALDATE дават по-пълна представа за проблема.

Датите на имейлите ви са повредени след импорт в eM Client? Стартирайте безплатно сканиране в Redate.io, за да измерите обхвата на проблема, преди да решите какво да правите.