Takeout mbox: wszystkie e-maile z dzisiejszą datą

Archiwum Google Takeout zostało otwarte, plik mbox zaimportowany do Thunderbirda przez ImportExportTools NG (albo do Apple Mail), a foldery przeciągnięte na nowe konto IMAP. W kliencie e-maile leżały uporządkowane rok po roku. Na koncie docelowym wszystkie mają dzisiejszą datę. Ten artykuł wyjaśnia, co dzieje się z zaimportowanym Takeout mbox, dlaczego wyświetlana data to data kopiowania, jak potwierdzić to w kilka minut i jak naprawić daty po stronie serwera.

Najpierw rzecz najważniejsza: wiadomości nie zostały naruszone. Oryginalna data wciąż jest w wiadomości. Po prostu konto docelowe przestało ją pokazywać.

Typowy scenariusz: zaimportowany Takeout mbox

Zamknięto właśnie osobiste konto Gmail, założone piętnaście lat temu. Eksport zamówiono na takeout.google.com, na wiadomość od Google czekano (dwa dni przy dużej skrzynce), pobrano cztery archiwa zip. W każdym z nich leży po jednym pliku .mbox na etykietę. Import do Thunderbirda przebiega gładko: folder lokalny się wypełnia, sortowanie po dacie jest bez zarzutu, rok 2009 na samym dole, wczorajsze wiadomości na samej górze.

Potem robi się to, co zrobiłby każdy. Zaznacza się foldery i przeciąga na docelowe konto IMAP, czy to Microsoft 365, czy konto u dostawcy hostingu, czy Google Workspace. Transfer trwa cały wieczór. W poniedziałek rano otwiera się webmail.

Problem? Wszystkie 18 400 e-maili ma datę z weekendu, w przedziale kilku godzin. Umowa z 2014 roku leży obok newslettera z zeszłego tygodnia i nikt nie odnajdzie już niczego w porządku chronologicznym.

Ten przypadek jest bardzo zbliżony do sytuacji, gdy stare e-maile mają tę samą datę, z jedną zasadniczą różnicą: tutaj żadne narzędzie do migracji nie jest winne. Wystarczy przeciągnięcie folderów myszką.

Trzy daty w jednym e-mailu

Żeby to zrozumieć, trzeba przestać mówić o "dacie" e-maila w liczbie pojedynczej. Wiadomość zaimportowana z pliku mbox niesie ich co najmniej trzy, a każda służy do czego innego.

Nagłówek Date: data nadawcy

To nagłówek Date: zdefiniowany w RFC 2822 (przejęty przez RFC 5322). Klient nadawcy zapisuje go w chwili wysyłki, na przykład Date: Tue, 14 Mar 2017 09:12:45 +0100. Jest częścią wiadomości, podróżuje razem z nią, a Takeout zachowuje go bez zmian. To właśnie on umożliwia naprawę, bo pozostaje nienaruszony.

Linia From w pliku mbox: data dla fasady

W pliku mbox każdą wiadomość poprzedza linia zaczynająca się od From (ze spacją, bez dwukropka). To nie jest nagłówek: to separator właściwy dla formatu pliku, niebędący częścią wiadomości. Żadne poważne narzędzie nie powinno na niej polegać przy datowaniu wiadomości.

INTERNALDATE: data złożenia na serwerze

Trzecia data, najdyskretniejsza: INTERNALDATE, zdefiniowana w RFC 3501. To atrybut, który serwer IMAP przechowuje obok wiadomości (nie w niej) i który odpowiada chwili, w której wiadomość trafiła do skrzynki. Outlook, webmaile i telefony używają go do wyświetlania i sortowania daty odbioru. Szczegóły mechanizmu opisuje artykuł o tym, dlaczego INTERNALDATE psuje daty w IMAP.

Słowo o nagłówkach Received:, które w tym miejscu często się niesłusznie obwinia. Linie Received w wyeksportowanym e-mailu z Gmaila opisują prawdziwą trasę wiadomości w 2017 roku: mają stare, w pełni uprawnione daty. W tym przypadku błędna data nie żyje więc w samej wiadomości, tylko w metadanych, które serwer przypisuje kopii.

Dlaczego konto docelowe pokazuje datę kopiowania

Kiedy klient składa wiadomość na serwerze IMAP, używa polecenia APPEND. To polecenie przyjmuje opcjonalnie datę, którą należy nadać wiadomości. Jeśli klient ją poda, serwer zapamiętuje ją jako INTERNALDATE. Jeśli nie, serwer stosuje regułę przewidzianą w RFC 3501: bieżącą datę i godzinę. Innymi słowy, wyświetlana data zależy od tego, jak narzędzie zapisało e-mail. Narzędzie, które nie przekazuje oryginalnej daty, dostaje datę kopii.

Efekt: w trakcie przeciągania folderów każda wiadomość dostaje datę własnego złożenia. Folder z 3000 e-maili skopiowany w 40 minut ląduje w oknie czasowym o długości 40 minut.

A lokalny folder w Thunderbirdzie? Wyglądał idealnie, bo Thunderbird sortuje w nim po nagłówku Date, a nie po dacie serwera, skoro folder lokalny żadnego serwera nie ma. Apple Mail zachowuje się z zaimportowanymi skrzynkami podobnie: wszystko jest w porządku, dopóki wiadomości zostają na Macu. Prawda wychodzi na jaw w chwili, gdy inny program, choćby Outlook, odczytuje skrzynkę IMAP.

Właściwie to nie jest do końca precyzyjne twierdzenie, że każdy klient myli się za każdym razem. Niektóre wersje przekazują datę, inne nie, a zachowanie zmieniało się z aktualizacjami. Przez to dwóch współpracowników stosujących tę samą metodę może uzyskać różne wyniki, co czyni diagnozę bardziej zwodniczą, niż się wydaje.

Przeciągnięcie folderów to nie migracja. To kopia, a kopia nosi datę swojego wykonania.

Jak rozpoznać ten przypadek w pięć minut

Zanim zacznie się szukać rozwiązania, warto potwierdzić, że to rzeczywiście ten scenariusz, a nie inny. Wystarczą cztery sprawdzenia.

• Porównanie obu miejsc. Folder lokalny w Thunderbirdzie (albo zaimportowana skrzynka w Apple Mail) pokazuje poprawne daty, a konto IMAP dla tych samych wiadomości daty świeże.
• Przedział dat. W folderze na koncie IMAP daty odbioru mieszczą się w kilku godzinach, a nawet minutach, wokół chwili przenoszenia folderów.
• Źródło wiadomości. W Thunderbirdzie: Widok, następnie Źródło wiadomości; w Outlooku nagłówki widać we właściwościach wiadomości. Powinna tam być stara linia Date:, podczas gdy wyświetlana data jest świeża.
• Kolejność. Wiadomości pojawiają się w kolejności, w jakiej klient je kopiował, a nie w kolejności chronologicznej.

Tak wygląda porównanie na prawdziwej wiadomości:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (w wiadomości, nienaruszona)
Data wyświetlana przez konto IMAP: dzień kopiowania   (metadana serwera)

Jeśli te dwie linie opowiadają różne historie, to jest to właśnie ten przypadek. A jeśli wyświetlane daty są błędne, ale Date: także, to problem innego rodzaju, rzadszy, który wykracza poza ten artykuł.

(Swoją drogą, jeśli nigdy nie czytano surowych nagłówków e-maila, warto zaopatrzyć się w kawę: to nie jest lektura na plażę.)

Sortowanie po dacie wysłania: tylko plaster

Pierwszy odruch to przełączyć sortowanie na datę wysłania. W Outlooku działa to mniej więcej, pod warunkiem że powtórzy się to w każdym folderze i na każdym urządzeniu. Ale wyszukiwanie, powiadomienia, reguły oparte na wieku wiadomości i widoki na telefonie nadal korzystają z daty odbioru. Użytkownik, który na telefonie szuka maila z września zeszłego roku, nie zobaczy niczego logicznego.

Inny kuszący pomysł: powtórzyć kopiowanie. Na koncie, które już jest używane, daje to głównie duplikaty obok wiadomości już obecnych, z tymi samymi błędnymi datami albo innymi. Setkę folderów później nie ma już ani jednej czystej skrzynki.

Naprawa po stronie serwera

Dobra wiadomość jest taka, że oryginalna data wciąż tam jest. Naprawa polega na doprowadzeniu do tego, by konto docelowe ją wyświetlało, bez ingerencji w treść wiadomości.

Tym zajmuje się Redate. Narzędzie łączy się ze skrzynką pocztową (Google Workspace przez delegowanie uprawnień w domenie, Microsoft 365, Outlook.com i Hotmail z kontem Microsoft każdej osoby albo bezpośrednio przez IMAP z adresem i hasłem). Redate nie musi wiedzieć, które narzędzie spowodowało problem: znajduje e-maile, których wyświetlana data nie zgadza się z ich datą oryginalną, niezależnie od tego, czy przyczyną było przeciągnięcie folderów z Takeout mbox, czy coś innego. Skanowanie jest bezpłatne i pokazuje skalę problemu przed jakąkolwiek decyzją.

Samą naprawę wykonuje własny silnik korekty Redate, wieloetapowy potok analizy, który bada łańcuch nagłówków każdej wiadomości i przywraca każdemu e-mailowi jego oryginalną datę. Każdy naprawiony e-mail jest następnie weryfikowany osobno, z walidacją zgodności z RFC i zachowaniem struktury wiadomości. Oryginały nigdy nie są usuwane: zostają w widocznym folderze skrzynki, dopóki użytkownik sam ich nie skasuje.

Dlaczego majsterkowanie na własną rękę jest ryzykowne

Zrozumieć problem to jedno. Naprawić 15 000 e-maili, nie gubiąc ani jednego, to zupełnie co innego.

Skrypt, który działa na dziesięciu wiadomościach testowych, nie przetrwa starcia ze skrzynką produkcyjną liczącą 30 000 wiadomości. Trafi na podpisane e-maile S/MIME, w których najmniejsza zmiana psuje podpis. Na zaszyfrowane wiadomości PGP. Na zagnieżdżone struktury multipart/alternative, niespójne granice MIME, nieoczekiwane Content-Transfer-Encoding, nagłówki spoza ASCII zakodowane według RFC 2047, załączniki po 40 MB. Potem dochodzą limity API, błąd 429 Too Many Requests o trzeciej w nocy w środku partii, timeouty sieciowe, które przerywają operację przy wiadomości 11 874.

I co dalej? Skąd wiedzieć, że każda wiadomość jest cała? Bez mechanizmu wycofania (rollback) jeden błąd zostawia zdublowane wiadomości, zgubione załączniki, rozbite wątki, zniknięte etykiety. Redate kontroluje każdy e-mail automatycznie i trzyma oryginał pod ręką, właśnie po to, żeby nikt nie musiał w tym względzie ryzykować.

Ostatnia rada, gratis: archiwa Takeout warto zachować, dopóki skrzynka nie zostanie zatwierdzona. Plik mbox pozostaje kopią referencyjną, nawet gdy konto docelowe wygląda poprawnie.

Przewodniki dopasowane do klienta

W zależności od klienta użytego do kopiowania, szczegółowe przewodniki opisują konkretny przypadek: naprawa dat po kopiowaniu IMAP w Thunderbirdzie oraz ten sam przypadek w Apple Mail.

Takeout jest już skopiowany na konto IMAP, a daty są błędne? Uruchom bezpłatne skanowanie Redate, żeby zobaczyć, ilu e-maili to dotyczy, a następnie napraw je jednorazową płatnością, bez limitu rozmiaru skrzynki.