English
Français
Deutsch
Español
Português
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Türkçe
Ελληνικά
Русский
Polski
Čeština
Українська
Magyar
Română
Български
Hrvatski
Srpski
Slovenčina
Slovenščina
Lietuvių
Latviešu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
Отворили сте архива си от Google Takeout, импортирали сте mbox файла в Thunderbird с ImportExportTools NG (или в Apple Mail) и след това сте плъзнали папките към новия си IMAP акаунт. В клиента имейлите бяха подредени година по година. В акаунта-получател всичките са с днешна дата. Тази статия обяснява какво се случва при импортиран Takeout mbox, защо показаната дата е датата на копирането, как да го потвърдите за няколко минути и как да го поправите от страна на сървъра.
Първото, което трябва да знаете: имейлите ви не са пострадали. Оригиналната дата все още е в съобщението. Просто вече не тя е онази, която акаунтът-получател извежда на преден план.
Типичният сценарий с импортиран Takeout mbox
Току-що сте затворили личен Gmail акаунт, открит преди петнайсет години. Поискали сте експорт от takeout.google.com, изчакали сте съобщението от Google (два дни за голяма пощенска кутия) и сте изтеглили четири zip архива. Във всеки има по един .mbox файл за всеки етикет. Импортирате ги в Thunderbird: локалната папка се пълни, сортирането по дата е безупречно, 2009 е най-долу, вчера е най-горе.
След това правите онова, което би направил всеки. Избирате папките и ги плъзвате към IMAP акаунта-получател, било то Microsoft 365, хостинг доставчик или Google Workspace. Прехвърлянето трае цяла вечер. В понеделник сутринта отваряте уеб пощата.
Проблемът? Всичките 18 400 имейла са с дата от уикенда, в интервал от няколко часа. Договор от 2014 г. стои до бюлетин от миналата седмица и никой вече не може да намери нищо в хронологичен ред.
Случаят е много близък до този на старите имейли, които показват една и съща дата, но с една съществена разлика: тук няма виновен инструмент за миграция. Достатъчно е плъзгането с мишката.
Три дати в един имейл
За да разберете, трябва да спрете да говорите за "датата" на имейла. Съобщение, импортирано от mbox файл, носи най-малко три дати и те не служат за едно и също.
Заглавката Date: датата на подателя
Това е заглавката Date:, определена от RFC 2822 (възприета от RFC 5322). Клиентът на подателя я записва в момента на изпращането, например Date: Tue, 14 Mar 2017 09:12:45 +0100. Тя е част от съобщението, пътува с него, а Takeout я запазва такава, каквато е. Именно тя прави поправката възможна, защото остава непокътната.
Редът From в mbox файла: дата за фасада
В mbox файл всяко съобщение е предшествано от ред, който започва с From (с интервал, без двоеточие). Това не е заглавка: то е разделител, характерен за файловия формат, и не е част от съобщението. Нито един сериозен инструмент не бива да разчита на него, за да датира имейл.
INTERNALDATE: датата на постъпване в сървъра
Третата дата, и най-незабележимата, е INTERNALDATE, определена от RFC 3501. Това е атрибут, който IMAP сървърът съхранява до съобщението (не в него) и който съответства на момента, в който съобщението е постъпило в пощенската кутия. Outlook, уеб пощите и телефоните я ползват, за да показват и сортират датата на получаване. За подробности около механизма вижте статията за INTERNALDATE и грешните дати при IMAP.
Едно уточнение за заглавките Received:, които тук често се обвиняват напразно. Редовете Received на експортиран Gmail имейл разказват истинския път на съобщението през 2017 г.: те носят стари и напълно легитимни дати. В този случай грешната дата не живее в съобщението, а в метаданните, които сървърът приписва на копието.
Защо акаунтът-получател показва датата на копирането
Когато клиент поставя съобщение на IMAP сървър, той използва командата APPEND. Тя приема по избор дата, която да се даде на съобщението. Ако клиентът я подаде, сървърът я запазва като INTERNALDATE. Ако не, сървърът прилага правилото по RFC 3501: датата и часа на момента. С други думи, показаната дата зависи от начина, по който инструментът е записал имейла. Инструмент, който не подава оригиналната дата, получава датата на копирането.
Резултатът: докато плъзгате папките, всяко съобщение взема датата на собственото си поставяне. Папка с 3000 имейла, копирана за 40 минути, попада в прозорец от 40 минути.
А локалната папка на Thunderbird? Изглеждаше перфектно, защото Thunderbird сортира там по заглавката Date, а не по дата на сървъра (локалната папка няма сървър). Apple Mail се държи сходно с импортираните пощенски кутии: всичко е наред, докато съобщенията остават на Mac. Истината излиза наяве, когато друг софтуер, например Outlook, прочете IMAP кутията.
Всъщност не е съвсем точно да се твърди, че всички клиенти грешат всеки път. Някои версии подават датата, други не, а поведението се е променяло с обновленията. Затова двама колеги, следвайки същия метод, могат да получат различни резултати, което прави диагностиката по-объркваща, отколкото изглежда.
Плъзгането не е миграция. То е копиране, а копието носи датата на изработването си.
Как да познаете този случай за пет минути
Преди да търсите решение, уверете се, че сте точно в този сценарий, а не в друг. Достатъчни са четири проверки.
- Сравнете двете места. Локалната папка на Thunderbird (или импортираната кутия на Apple Mail) показва верни дати, а IMAP акаунтът показва скорошни дати за същите съобщения.
- Погледнете интервала. В папка на IMAP акаунта датите на получаване се събират в няколко часа, дори минути, около момента, в който сте местили папките.
- Отворете изходния код на съобщение. В Thunderbird го намирате от менюто за изглед, а в Outlook свойствата на съобщението показват заглавките. Там трябва да откриете стар ред
Date:, докато екранът показва скорошна дата. - Проверете реда. Съобщенията се появяват в реда, в който клиентът ги е копирал, а не в хронологичен ред.
Ето какво дава сравнението при реално съобщение:
Date: Tue, 14 Mar 2017 09:12:45 +0100 (в съобщението, непокътната)
Дата, показана от IMAP акаунта: денят на копирането (метаданна на сървъра)Ако тези два реда не разказват една и съща история, значи сте в този случай. А ако показаните дати са грешни, но и Date: е грешна, това е друг, по-рядък проблем, който излиза извън рамките на статията.
(Между другото, ако никога не сте чели суровите заглавки на имейл, пригответе си кафе: не е точно плажно четиво.)
Сортиране по дата на изпращане: лепенка
Рефлексът е да превключите сортирането на дата на изпращане. В Outlook това горе-долу работи, стига да го направите наново във всяка папка и на всяко устройство. Но търсенето, известията, правилата, базирани на възраст, и изгледите на мобилни устройства продължават да ползват датата на получаване. Потребител, който търси "писмото от миналия септември" на телефона си, няма да види нищо логично.
Друга изкушаваща идея: да повторите копирането. В акаунт, който вече се ползва, това основно създава дубликати до вече наличните съобщения, със същите грешни дати или с други. След стотина папки нямате нито една чиста пощенска кутия.
Поправката от страна на сървъра
Добрата новина е, че оригиналната дата все още е там. Поправката цели акаунтът-получател да я показва, без да се пипа съдържанието на съобщенията ви.
Това прави Redate. Услугата се свързва с пощенската кутия (Google Workspace чрез делегиране на достъпа на ниво домейн, Microsoft 365, Outlook.com и Hotmail с Microsoft акаунта на всеки потребител, или директен IMAP с адрес и парола). Redate няма нужда да знае кой инструмент е причинил проблема: намира имейлите, чиято показвана дата не съответства на оригиналната им дата, независимо дали причината е плъзгане от Takeout mbox или нещо друго. Безплатното сканиране на пощенската кутия ви показва мащаба на щетите, преди да вземете какво да е решение.
За самата поправка Redate разчита на собствен механизъм за корекция, многоетапен аналитичен конвейер, който разглежда веригата от заглавки на всяко съобщение и връща на всеки имейл оригиналната му дата. След това всеки поправен имейл се проверява поотделно, с валидиране за съответствие с RFC и запазване на структурата на съобщението. Оригиналите никога не се изтриват: остават в видима папка на пощенската кутия, докато вие сами не ги изтриете.
Защо самодейното решение е рисковано
Да разберете проблема е едно. Да поправите 15 000 имейла, без да загубите нито един, е съвсем друго.
Скрипт, който работи върху десет тестови съобщения, не оцелява в производствена кутия от 30 000 съобщения. Той се сблъсква със подписани S/MIME имейли, при които и най-малката промяна чупи подписа. С PGP криптирани съобщения. С вложени multipart/alternative структури, непоследователни MIME граници, неочаквани Content-Transfer-Encoding, не-ASCII заглавки, кодирани по RFC 2047, прикачени файлове от 40 МБ. После идват квотите на API, грешката 429 Too Many Requests в три сутринта по средата на партида, мрежовите таймаути, които прекъсват операцията при съобщение 11 874.
И после? Как ще разберете, че всяко съобщение е цяло? Без механизъм за връщане назад една грешка оставя дублирани съобщения, изгубени прикачени файлове, разкъсани нишки, изчезнали етикети. Redate проверява всеки имейл автоматично и държи оригинала подръка, точно за да не се налага никога да залагате на това.
И един последен съвет, безплатен: пазете оригиналните си Takeout архиви, докато пощенската кутия не бъде валидирана. Mbox файлът си остава референтното копие, дори когато акаунтът-получател изглежда наред.
Ръководства според вашия клиент
Според клиента, с който сте копирали, следните подробни ръководства описват конкретния случай: коригиране на дати от ръчно IMAP копиране в Thunderbird и същият случай в Apple Mail.
Takeout архивът ви вече е копиран в IMAP акаунта и датите са грешни? Стартирайте безплатното сканиране на Redate, за да видите колко имейли са засегнати, после ги поправете с еднократно плащане, без ограничение в размера на пощенската кутия.