Czy można zmienić datę odebranego emaila?

Pytanie, które zadają wszyscy (i dlaczego kryją się za nim dwie zupełnie różne sytuacje)

Wpisz „zmiana daty odebranego emaila" w Google. Wyskakują dziesiątki wątków na forach Microsoft Q&A, Reddicie, Quorze. Pytanie jest jasne, ale powody, dla których je zadają różne osoby, są diametralnie różne.

Są tacy, którzy chcą sfałszować datę wstecznie, z przyczyn, których wolałoby się nie zgadywać. I są administratorzy IT, którzy po migracji IMAP widzą, że wszystkie emaile wyświetlają ten sam dzień (datę migracji), i chcą po prostu odzyskać prawdziwe daty. Te dwie sytuacje nie mają ze sobą nic wspólnego, ale prowadzą do tej samej frazy wyszukiwania.

Ten artykuł odpowiada na oba przypadki. Spoiler: w pierwszym przypadku modyfikacja nie jest możliwa w sposób niewykrywalny. W drugim jest całkowicie uzasadniona i właśnie to robi Redate.io.

Najpierw: czym właściwie jest „data" emaila?

Email nie zawiera jednej daty. Zawiera ich kilka, przechowywanych w różnych miejscach, kontrolowanych przez różne podmioty.

Nagłówek Date: (RFC 2822)

To data, którą klient nadawcy wpisuje do wiadomości w momencie wysyłki. Widoczna jest w surowych nagłówkach w takiej formie:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Ten nagłówek jest częścią treści wiadomości. Technicznie można go zmodyfikować, jeśli ma się dostęp do surowego pliku. Ale słowo „technicznie" jest tu kluczowe.

Nagłówki Received:

Każdy serwer pocztowy, przez który przechodzi email, dodaje własny nagłówek Received: ze znacznikiem czasu. Te nagłówki tworzą chronologiczny łańcuch, od serwera nadawcy aż do skrzynki odbiorcy. (Swoją drogą, jeśli kiedykolwiek próbowałeś czytać surowe nagłówki emaila, wiesz, że to nie jest lektura na plaży. Kilkadziesiąt linii metadanych technicznych, w kolejności od najnowszego do najstarszego.)

INTERNALDATE w IMAP

To metadana, która ma największe znaczenie dla zrozumienia, dlaczego niektóre modyfikacje nie dają żadnego widocznego efektu. INTERNALDATE to atrybut przechowywany po stronie serwera IMAP, niezależnie od zawartości wiadomości. To właśnie on jest używany przez większość klientów pocztowych do sortowania emaili w folderach. Outlook go używa. Gmail też. Apple Mail w zdecydowanej większości przypadków również.

INTERNALDATE nie znajduje się w wiadomości. Jest w bazie danych serwera. Nie można go zmienić, edytując plik .eml na swoim dysku.

Co tak naprawdę dzieje się po lokalnej modyfikacji

Edycja pliku .eml

Technicznie plik .eml to plik tekstowy. Można go otworzyć w edytorze, zmienić linię Date:, zapisać. Jeśli ponownie zaimportuje się taki plik do lokalnego klienta pocztowego, wyświetlana data może się zmienić, w zależności od klienta.

Ale oto co się nie zmienia:

• INTERNALDATE na serwerze IMAP (nienaruszony)
• Nagłówki Received: dodane przez pośrednie serwery
• Logi dostarczenia u Google, Microsoft lub innego dostawcy
• Podpis DKIM, jeśli wiadomość go miała

Efekt: na lokalnym komputerze widać inną datę. Ale w Outlooku połączonym z Exchange Online lub w Gmailu w przeglądarce, nic się nie zmieniło.

Zmiana zegara systemowego

Niektóre fora sugerują zmianę zegara stacji roboczej, żeby „oszukać" klienta pocztowego. To nie działa. Outlook i Gmail nie odczytują czasu systemowego przy wyświetlaniu dat odebranych emaili. Czytają INTERNALDATE z serwera albo nagłówki wiadomości. Lokalny zegar nie ma tu żadnego znaczenia.

Manipulacje przez Thunderbirda

Thunderbird oferuje więcej elastyczności niż większość klientów. Za pomocą rozszerzeń lub bezpośredniej manipulacji profilem (pliki mbox, pliki .msf) niektórzy próbują zmieniać wyświetlanie dat. Może to działać w samym Thunderbirdzie, dla emaili przechowywanych lokalnie w trybie POP3. Ale gdy Thunderbird jest połączony przez IMAP, resynchronizuje się z serwerem. „Poprawka" znika przy najbliższej synchronizacji.

DKIM: niewidzialna bariera, o której nikt nie mówi

Większość emaili wysyłanych od 2018 roku jest podpisana DKIM (DomainKeys Identified Mail). Podpis DKIM wygląda tak w nagłówkach:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Pole h= zawiera listę nagłówków objętych podpisem. W powyższym przykładzie Date jest podpisane. Jeśli zmodyfikuje się nagłówek Date: wiadomości, weryfikacja DKIM kończy się niepowodzeniem. Każdy serwer pocztowy, każde narzędzie do analizy forensycznej, może wykryć modyfikację przez ponowne obliczenie podpisu.

To nie jest idealna ochrona (złośliwy nadawca kontroluje własny klucz DKIM i może podpisać co chce w chwili wysyłki). Ale w przypadku emaila już odebranego i podpisanego, zmiana nagłówka Date: zostawia wykrywalny ślad.

Logi serwera: prawdziwe źródło prawdy

Nawet gdyby udało się zmodyfikować wszystkie widoczne metadane emaila (nagłówki, INTERNALDATE, wszystko), dostawcy zachowują własne logi.

Google Workspace rejestruje każdą wiadomość w logach audytowych Admin Console. Microsoft 365 robi to samo w centrum zgodności (Purview). Te logi zawierają znaczniki czasu dostarczenia, niezależnie od tego, co jest wyświetlane w klientach pocztowych. Prawnik, dział prawny lub zespół bezpieczeństwa IT może odzyskać te dane. Data widoczna w Outlooku nie ma mocy dowodowej w sądzie ani podczas audytu bezpieczeństwa.

Żeby być precyzyjnym: nawet administrator mający dostęp do skrzynki przez delegowanie domeny nie może wstecznie nadpisać tych logów. Są poza zasięgiem użytkowników, nawet uprzywilejowanych.

Uzasadniony przypadek: korekta po migracji

Właśnie zakończyłeś migrację 150 skrzynek z Exchange on-premise do Microsoft 365. W poniedziałek rano zaczynają spływać zgłoszenia: „wszystkie moje stare emaile mają datę z ubiegłego piątku". Datę migracji.

To dobrze udokumentowany problem, zupełnie inny od tego, co opisaliśmy powyżej. Tu nikt nie chce niczego fałszować. Prawdziwe, oryginalne daty nadal istnieją, nienaruszone, w nagłówku Date: każdej wiadomości. Problem leży gdzie indziej: narzędzie migracyjne (BitTitan MigrationWiz, CloudM, imapsync lub inne) wstawiło nagłówek Received: z datą migracji na początku łańcucha. Outlook, który w pewnych kontekstach kieruje się najnowszymi nagłówkami Received: zamiast INTERNALDATE, wyświetla właśnie tę datę.

W tym przypadku „korekta" polega na przywróceniu spójności między tym, co mówi wiadomość (oryginalny nagłówek Date:, wciąż obecny) a tym, co myśli serwer (INTERNALDATE ustawiony w chwili migracji). To nie jest fałszowanie. To przywracanie stanu pierwotnego.

Dokładnie tak wygląda problem, który źle skonfigurowana migracja narzuca tysiącom skrzynek. I właśnie to rozwiązuje Redate.io.

Dlaczego samodzielne naprawianie zawodzi na dużą skalę

Zrozumieć problem to jedno. Poprawić 40 000 emaili rozłożonych na 150 skrzynek bez utraty ani jednego to zupełnie co innego.

Skrypty znalezione na GitHubie lub Stack Overflow działają na 20 testowych wiadomościach. W środowisku produkcyjnym napotykają problemy, których autor skryptu nie przewidział:

• Emaile podpisane S/MIME lub zaszyfrowane PGP mają struktury, których nie można manipulować jak zwykłymi wiadomościami
• Wiadomości multipart z niestandardowymi granicami MIME powodują błędy parsowania
• Nagłówki zakodowane zgodnie z RFC 2047 (znaki spoza ASCII w polach From: lub Subject:) psują naiwne parsery
• Interfejsy API Google i Microsoft narzucają ograniczenia liczby żądań (rate limiting): o 3 w nocy podczas przetwarzania 30 000 emaili błąd 429 Too Many Requests nie jest obsługiwany, skrypt się zatrzymuje, i nikt nie wie, gdzie dokładnie
• Brak mechanizmu wycofania zmian: jeśli wiadomość zostanie uszkodzona podczas przetwarzania, nie ma możliwości powrotu do stanu sprzed

Redate.io przechowuje kopię każdego oryginalnego emaila w widocznym folderze kopii zapasowej przez 30 dni. Każda korekta jest weryfikowana indywidualnie. Potok analizy obsługuje setki sygnatur znanych narzędzi migracyjnych, a także wszystkie przypadki brzegowe, z którymi domowy skrypt by sobie nie poradził.

Więcej o specyfice poszczególnych narzędzi: BitTitan MigrationWiz i daty emaili albo CloudM Migrate: jak naprawić błędne daty.

Co się zmienia, a co pozostaje niezmienne

Różnica jest wyraźna. Pierwsze trzy wiersze tabeli opisują modyfikacje powierzchowne lub wykrywalne. Ostatni opisuje uprawnioną korektę metadanych, zgodną z oryginalną zawartością wiadomości, po migracji, która wprowadziła niespójność.

Jeśli Twoja sytuacja odpowiada ostatniemu wierszowi, po migracji z użyciem imapsync, BitTitan, CloudM lub innego narzędzia, Redate.io powstało właśnie po to.

Emaile wyświetlają datę migracji zamiast prawdziwych dat? Przeskanuj skrzynki bezpłatnie z Redate.io i sprawdź dokładnie, ile wiadomości jest dotkniętych problemem, zanim podejmiesz decyzję.