Antydatowanie emaila: co jest możliwe i wykrywalne

Antydatowanie emaila: o czym właściwie mówimy?

To pytanie wraca regularnie na forach administratorów systemów i w grupach Slack dla MSP: czy można zmienić datę emaila po jego wysłaniu? Krótka odpowiedź brzmi: tak, technicznie. Ale pełna odpowiedź jest znacznie mniej uspokajająca dla tych, którzy chcieliby to zrobić w nieuczciwych celach.

Email to nie jest jednolity plik. To zbiór nagłówków tekstowych, po których następuje treść wiadomości. Wśród tych nagłówków kilka zawiera informacje o dacie. Jedne są łatwiejsze do zmiany niż inne.

W każdym emailu współistnieją trzy warstwy datowania:

• Nagłówek Date: (RFC 2822), zapisywany przez klienta pocztowego w momencie wysłania
• Nagłówki Received:, dodawane przez każdy serwer, który przekazuje wiadomość
• INTERNALDATE w IMAP, metadana przechowywana po stronie serwera, niezależna od treści wiadomości

Każda z tych warstw jest modyfikowalna. Żadna nie jest, bez pozostawiania śladów.

Zmiana nagłówka Date: : najbardziej oczywista manipulacja

Nagłówek Date: to czysty tekst w pliku .eml. Technicznie, każdy edytor szesnastkowy lub skrypt w Pythonie może go nadpisać w kilka sekund. Jeśli kiedykolwiek otwierałeś surowe nagłówki emaila w Gmailu (małe menu „Pokaż oryginał"), wiesz, że jest to czytelne dla każdego.

Problem? Od 2004 roku zdecydowana większość serwerów pocztowych podpisuje wychodzące emaile za pomocą DKIM (DomainKeys Identified Mail). Ten podpis kryptograficzny obejmuje wprost kilka nagłówków: Date:, From:, Subject: i treść wiadomości. Podpis jest przechowywany w nagłówku DKIM-Signature:.

Zmiana Date: po złożeniu podpisu mechanicznie unieważnia weryfikację DKIM. Każdy serwer odbierający może sprawdzić podpis, pobierając klucz publiczny z DNS domeny nadawcy. Jeśli podpis nie pasuje, wiadomość jest oznaczana jako zmieniona. Gmail, Outlook.com i wszyscy wielcy dostawcy przeprowadzają tę weryfikację automatycznie.

(Swoją drogą, jeśli chcesz zobaczyć podpis DKIM w praktyce, otwórz surowe nagłówki emaila otrzymanego z Gmaila lub Office 365: znajdziesz tam linię DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., która wygląda jak szum, ale jest tak naprawdę kryptograficznym hashem całej wiadomości.)

Wynik: zmiana Date: w emailu podpisanym DKIM to zerwanie pieczęci. Modyfikacja jest widoczna dla każdego administratora, który wie, czego szukać.

Przepisywanie nagłówków Received: : łańcuch trudny do sfałszowania

Nagłówki Received: śledzą drogę emaila między nadawcą a odbiorcą. Każdy serwer SMTP, który dotyka wiadomości, dodaje jeden taki nagłówek z nazwą, adresem IP i znacznikiem czasu. Email przechodzący przez dwa lub trzy przekaźniki zawiera zatem dwa lub trzy nałożone na siebie nagłówki Received:.

Czy można je zmodyfikować? Technicznie, tak, na własnej kopii wiadomości. Ale tu jest pułapka: odbiorca też ma swoją kopię. A jego serwer jako ostatni dodał własny nagłówek Received:. Ten nagłówek jest pod kontrolą odbiorcy, nie nadawcy. Nie można go sfałszować z zewnątrz.

Spójność łańcucha jest weryfikowalna. Jeśli znaczniki czasu kolejnych nagłówków Received: są niespójne (pośredni przekaźnik miałby odebrać wiadomość zanim nadawca ją wysłał, na przykład), to jest to natychmiast podejrzane. Narzędzia do forensycznej analizy emaili, takie jak MXToolbox czy wewnętrzne narzędzia zespołów bezpieczeństwa, sprawdzają dokładnie to.

Właściwie, nie do końca ścisłe jest twierdzenie, że nagłówki Received: są niemożliwe do całkowitego sfałszowania: atakujący, który kontroluje własną infrastrukturę pocztową, może skonstruować wiarygodne nagłówki dla przekaźników, które kontroluje. Ale nigdy nie kontroluje ostatniego ogniwa: serwera odbiorcy.

INTERNALDATE w IMAP: najbardziej techniczny przypadek

INTERNALDATE to metadana IMAP przechowywana po stronie serwera. Nie jest to nagłówek w samej wiadomości: to wartość, którą serwer przypisuje wiadomości w swojej wewnętrznej bazie danych. To właśnie tej wartości większość klientów pocztowych używa do sortowania wiadomości w skrzynce odbiorczej.

Polecenie IMAP APPEND pozwala na umieszczenie wiadomości na serwerze z jawnym podaniem wartości INTERNALDATE. To uzasadniona funkcja protokołu, udokumentowana w RFC 3501. Narzędzia migracyjne stale z niej korzystają: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... wszystkie umieszczają emaile na serwerze docelowym z podaną wartością INTERNALDATE.

Teoretycznie ktoś z dostępem IMAP do własnej skrzynki mógłby umieścić email z dowolną wartością INTERNALDATE. Ale ta manipulacja nie zmienia nagłówków wiadomości. Oryginalny Date: pozostaje nienaruszony, nagłówki Received: pozostają nienaruszone, podpis DKIM pozostaje nienaruszony. Zmienia się wyłącznie metadana sortowania po stronie serwera.

Dla eksperta analizującego surową wiadomość rozbieżność między INTERNALDATE a Date: jest natychmiast widoczna. A jeśli wiadomość jest podpisana DKIM, oryginalna data jest kryptograficznie potwierdzona.

Message-ID: odcisk palca trudny do sfałszowania

Każdy email generuje unikalny identyfikator, nagłówek Message-ID:. Identyfikator ten jest tworzony przez serwer SMTP nadawcy w momencie wysyłania, zazwyczaj łącząc znacznik czasu, losowy identyfikator i nazwę domeny serwera.

Typowy Message-ID wygląda tak: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Znacznik czasu jest często zakodowany bezpośrednio w identyfikatorze. Zmiana daty wiadomości przy pozostawieniu Message-ID z niezgodnym znacznikiem czasu tworzy niespójność natychmiast zauważalną.

Co więcej, Message-ID są indeksowane przez wielkie systemy pocztowe. Google, Microsoft i inni gracze prowadzą logi, które pozwalają odtworzyć, kiedy wiadomość faktycznie krążyła po ich infrastrukturach. W kontekście prawnym lub forensycznym logi te są dostępne w drodze postępowań sądowych.

W praktyce: kto może wykryć próbę manipulacji?

Postawmy pytanie konkretnie. Otrzymujesz email, w którym podejrzewasz, że data została zmieniona. Co może zrobić administrator IT lub prawnik z minimalnym bagażem technicznym?

• Weryfikacja DKIM: w Gmailu menu „Pokaż oryginał" wyświetla bezpośrednio wynik weryfikacji DKIM na górze strony. „PASS" potwierdza integralność wiadomości od momentu wysłania. „FAIL" lub „SOFTFAIL" sygnalizuje naruszenie.
• Analiza nagłówków: narzędzia takie jak MXToolbox Header Analyzer lub Google Admin Toolbox automatycznie parsują łańcuch nagłówków Received: i sygnalizują niespójności czasowe.
• Spójność Message-ID / Date: analityk może porównać znacznik czasu zakodowany w Message-ID z wartością zadeklarowaną w nagłówku Date:.
• Logi serwera: jeśli email przeszedł przez serwer, którego jesteś administratorem, logi SMTP zawierają rzeczywistą datę i godzinę przyjęcia wiadomości, niezależnie od jakichkolwiek nagłówków.

Mówiąc krótko, narzędzia do wykrywania są dostępne, bezpłatne i nie wymagają zaawansowanej wiedzy forensycznej. Administrator IT z odrobiną ciekawości może sprawdzić integralność emaila w mniej niż dwie minuty.

Jedyny uzasadniony przypadek masowej zmiany dat: migracja IMAP

Istnieje jeden scenariusz, w którym setki tysięcy emaili mają nieprawidłowe daty bez żadnych złośliwych intencji: migracja IMAP.

Wyobraź sobie: właśnie zakończyłeś migrację 150 skrzynek Exchange do Google Workspace. W poniedziałek rano zaczyna się lawina zgłoszeń. Użytkownicy raportują, że wszystkie ich stare emaile wyświetlają tę samą datę, datę weekendu migracji. Skrzynki odbiorcze są nieczytelne.

To, co się stało, jest udokumentowane i przewidywalne: narzędzie migracyjne (BitTitan, CloudM, imapsync, nieważne które) umieściło emaile w Google Workspace za pomocą polecenia IMAP APPEND. Podało wartość INTERNALDATE odpowiadającą dacie migracji, nie oryginalnej dacie emaila. Wynik: Outlook, który domyślnie sortuje według INTERNALDATE, wyświetla datę migracji dla wszystkich wiadomości. Artykuł Dlaczego emaile pokazują złą datę po migracji wyjaśnia ten mechanizm szczegółowo.

Oryginalny nagłówek Date: jest nienaruszony w każdej wiadomości. Podpisy DKIM są nienaruszone. Treść się nie zmieniła. Jedynie INTERNALDATE po stronie serwera jest nieprawidłowa.

Ten problem dotyczy BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO i wszystkich narzędzi, które korzystają z IMAP APPEND bez prawidłowego zachowania wartości INTERNALDATE. Artykuł poświęcony BitTitan MigrationWiz opisuje specyfikę tego narzędzia. Checklista migracji email zawiera punkty do sprawdzenia przed migracją i po niej, żeby uniknąć tego rodzaju problemów.

Różnica między korektą a fałszowaniem

Korekta wykonywana przez Redate.io jest czymś zupełnie przeciwnym do próby fałszowania. Autorski silnik korekcji analizuje łańcuch nagłówków każdej wiadomości, identyfikuje oryginalną datę zakodowaną w nagłówku Date: (RFC 2822), który nigdy nie został zmieniony, i koryguje metadane daty, dopasowując je do tej autentycznej informacji już obecnej w wiadomości.

Nagłówek Date: jest źródłem prawdy. Został zapisany przez klienta pocztowego nadawcy w momencie wysyłania. Jest objęty podpisem DKIM. Redate.io go nie modyfikuje. To, co jest korygowane, to rozbieżność wprowadzona przez narzędzie migracyjne, nie oryginalna data.

Skorygowanie 47 000 emaili po nieudanej migracji bez utraty ani jednego, bez zrywania wątków dyskusji, bez uszkadzania załączników, bez wywoływania błędu 429 o 3:00 w nocy na API Google: to wieloetapowy potok analizy z obsługą przypadków granicznych (S/MIME, PGP, kodowania non-ASCII w RFC 2047, złożone struktury multipart). Pięciolinijkowy skrypt w Pythonie nie przeżyłby pierwszej produkcyjnej skrzynki. Artykuł o tym, czy można naprawić daty emaili po migracji, wyjaśnia szczegółowo, dlaczego DIY jest ryzykowne przy rzeczywistych wolumenach.

Redate.io skanuje skrzynki pocztowe bezpłatnie, identyfikuje emaile z nieprawidłowymi datami i koryguje je za pomocą potoku walidacji, który weryfikuje każdą wiadomość indywidualnie. Oryginały są przechowywane w widocznym folderze kopii zapasowej przez 30 dni. Jeśli coś pójdzie nie tak, przywrócenie poprzedniego stanu jest możliwe.

Migracja przesunęła daty Twoich emaili? Uruchom bezpłatne skanowanie w Redate.io i sprawdź skalę problemu, zanim zdecydujesz, co zrobić.