Zmiana daty odebranego maila: ograniczenia techniczne

Email ma trzy "daty". Nie jedną.

Gdy mowa o "zmianie daty odebranego maila", większość osób wyobraża sobie modyfikację jakiegoś pola, podobnie jak zmienia się datę utworzenia pliku w Windowsie. Rzeczywistość jest nieco bardziej złożona. Email przenosi tak naprawdę trzy odrębne warstwy datowania, każdą z własnymi regułami, własnymi strażnikami i własnymi konsekwencjami, jeśli się w nie ingeruje.

Zrozumienie tych trzech warstw to zrozumienie, dlaczego pewne korekty są technicznie uzasadnione, a inne są albo niemożliwe, albo natychmiast wykrywalne jako fałszerstwo.

Warstwa 1: INTERNALDATE w IMAP

INTERNALDATE to metadana przechowywana po stronie serwera, poza samą treścią wiadomości. Nie stanowi części zawartości emaila. Definiuje ją serwer IMAP i to właśnie jej większość klientów pocztowych używa do sortowania wiadomości na liście.

Outlook domyślnie wyświetla wiadomości posortowane według INTERNALDATE. Gmail też, w pewnych kontekstach. Jeśli więc INTERNALDATE jest błędna, wszystkie emaile w interfejsie wyglądają na wysłane tego samego dnia, niezależnie od tego, co mówią wewnętrzne nagłówki wiadomości.

INTERNALDATE jest ustawiana w momencie dostarczenia wiadomości na serwer. W protokole IMAP jedynym sposobem jej "modyfikacji" jest ścieżka pośrednia: trzeba użyć polecenia APPEND, żeby wgrać nową kopię wiadomości z żądaną datą. Polecenie SETINTERNALDATE w IMAP po prostu nie istnieje. Ten szczegół będzie ważny za chwilę.

Warstwa 2: nagłówek Date: (RFC 2822)

To pole Date: w surowych nagłówkach wiadomości. Ustawiany przez klienta pocztowego w momencie wysyłki, podróżuje z wiadomością od serwera do serwera. Jest to data wysyłki zadeklarowana przez nadawcę.

(Swoją drogą, jeśli nigdy nie zaglądałeś do surowych nagłówków emaila, to dość osobliwa lektura. Każda wiadomość ciągnie ze sobą z dwadzieścia linii technicznych, których 99% użytkowników nigdy nie widziało.)

Technicznie nic nie stoi na przeszkodzie, żeby wysłać email z wstecznie datowanym lub przyszłym polem Date:. Serwery SMTP nie walidują tego pola. Ale serwery docelowe odnotowują rzeczywistą godzinę przybycia w nagłówkach Received:, co natychmiast tworzy niespójność widoczną w każdym kliencie pocztowym lub narzędziu analizy.

Warstwa 3: nagłówki Received: ułożone w stos

Za każdym razem, gdy serwer SMTP przekazuje wiadomość, dodaje nagłówek Received: na wierzchu stosu, ze znacznikiem czasu. Email przesłany przez trzy serwery będzie miał trzy nagłówki Received:. Czyta się je od dołu ku górze: najstarszy jest na dole, najnowszy na górze.

I właśnie tutaj narzędzia migracyjne tworzą problem. Gdy BitTitan MigrationWiz, CloudM, imapsync lub GSMMO migrują email, wstrzykują go na nowy serwer przez IMAP. To wgranie generuje nowy wpis Received: z datą migracji. Efekt: najstarszy email w skrzynce, wiadomość z 2019 roku, ląduje z nagłówkiem Received: datowanym na listopad 2024. A ponieważ pewne klienty pocztowe (Outlook w szczególności) używają najnowszego Received: jako daty wyświetlania...

No właśnie. 15 000 emaili pokazuje tę samą datę migracji.

Czy naprawdę można "zmodyfikować" te daty?

Technicznie tak, jeśli chodzi o INTERNALDATE (z pewnymi ograniczeniami). Technicznie możliwe, ale bezcelowe w przypadku Date:. A jeśli chodzi o Received:, warto się temu przyjrzeć bliżej.

Nadpisanie nagłówka Received: jest proste. I natychmiast wykrywalne.

Nagłówek Received: to tylko linia tekstu w wiadomości. Można go edytować jak każdy plik tekstowy. Dokładnie tak prosto, jak to wygląda.

Ale oto, co się dzieje potem.

Pierwszy problem: DKIM. Podpis DKIM (DomainKeys Identified Mail) jest obliczany na podstawie zestawu nagłówków wiadomości, czasem też Received:. Modyfikacja podpisanego nagłówka unieważnia podpis. Każdy serwer docelowy weryfikujący DKIM natychmiast zobaczy, że wiadomość została zmieniona. To nie jest subtelne fałszerstwo, to alarm.

Drugi problem: wewnętrzne identyfikatory. Nowoczesne serwery pocztowe (Google Workspace, Microsoft 365) przypisują każdej wiadomości rosnący, unikalny identyfikator wewnętrzny. Identyfikatory te są powiązane z INTERNALDATE i kolejnością odbierania. Modyfikacja Received: bez spójności z tymi identyfikatorami tworzy rozbieżności, które narzędzia audytu wykrywają bez trudu.

Trzeci problem, bardziej praktyczny: nawet jeśli zmienisz Received: w treści wiadomości, nie tknąłeś INTERNALDATE, która nadal odpowiada dacie wgrania przez IMAP. Klient pocztowy dalej wyświetla błędną datę do sortowania. Zmodyfikowałeś wiadomość bez żadnego skutku.

Mówiąc krótko: nadpisywanie Received: w celu sfałszowania daty emaila dla złośliwych celów jest technicznie proste, ale wykrywalne w kilka sekund przez specjalistę. To nie jest poważna droga.

Nagłówek Date:: zmienianie przeszłości na papierze

To samo rozumowanie dotyczy Date:. Można go zmienić w treści wiadomości. Ale nagłówki Received: uwierzytelnione przez pośrednie serwery pozostają nienaruszone i opowiadają inną historię. Łańcuch czasowy jest niespójny. Każdy analityk lub sąd porównujący te pola zobaczy to natychmiast.

Precyzyjnie rzecz ujmując, nie przeszkadza to niektórym klientom pocztowym wyświetlać zmodyfikowanego Date:, jeśli podsuniemy im bezpośrednio plik .eml. Ale w kontekście działającego serwera pocztowego, z uwierzytelnianiem i dziennikami zdarzeń, modyfikacja jest przezroczysta.

Migracja IMAP: jedyny kontekst, w którym korekta dat jest uzasadniona

Jest jeden, i tylko jeden przypadek, gdzie modyfikacja daty odebranego emaila jest nie tylko możliwa, ale technicznie uzasadniona: korekta szkód spowodowanych przez źle przeprowadzoną migrację IMAP.

Konkretna sytuacja. Właśnie zmigrowano 80 skrzynek Exchange do Microsoft 365. Migracja zakończyła się w piątek wieczór. W poniedziałek rano przychodzą pierwsze zgłoszenia: "Wszystkie moje emaile mają tę samą datę", "Nie mogę znaleźć maila z zeszłego roku", "Moja historia z tym klientem jest totalnie zepsuta". 80 użytkowników zablokowanych i przełożony czekający na odpowiedź.

W tym kontekście problem jest udokumentowany, możliwy do zidentyfikowania, a jego przyczyna jest jasna: narzędzie migracyjne dodało Received: datowany dniem migracji, a pewne klienty pocztowe używają tego nowego nagłówka jako daty wyświetlania. Oryginalny nagłówek Date: pozostaje nienaruszony w każdej wiadomości. Nigdy nie był modyfikowany. Nadal zawiera oryginalną, poprawną datę wysyłki.

Korekta nie jest więc fałszerstwem, lecz przywróceniem stanu pierwotnego. Wychodzi się od prawdziwych danych (oryginalny Date:), żeby odbudować spójne metadane. To fundamentalnie różni się od próby przedstawienia emaila z 2024 roku jako wiadomości z 2019.

Szczegółowe przypadki dla poszczególnych narzędzi opisują dedykowane przewodniki: naprawa dat BitTitan w Microsoft 365, naprawa dat CloudM w Outlooku lub naprawa dat imapsync w Google Workspace.

Dlaczego samodzielne pisanie skryptu to ryzyko

Podstawowa logika jest dostępna publicznie. Każdy administrator IT, który spędził trochę czasu na forach poświęconych IMAP, może odtworzyć ogólne podejście. To nie jest problem.

Problem leży w przepaści między skryptem działającym na 50 testowych emailach a skryptem uruchamianym na 40 000 wiadomościach produkcyjnych, bez utraty ani jednego emaila, bez uszkodzenia ani jednego załącznika i bez zerwania ani jednego wątku konwersacji.

Kilka konkretnych przypadków, z którymi skrypty domowe zazwyczaj sobie nie radzą:

• Emaile podpisane S/MIME: podpis obejmuje treść i nagłówki. Każda modyfikacja struktury wiadomości unieważnia podpis. Nieumiejętnie poprawiony podpisany email dociera do odbiorców z komunikatem "nieprawidłowy podpis".
• Wiadomości zaszyfrowane PGP: ta sama rodzina problemów, potencjalnie z gorszymi konsekwencjami w zależności od implementacji.
• Kodowania non-ASCII w nagłówkach: RFC 2047 opisuje kodowanie znaków specjalnych w nagłówkach. Skrypt manipulujący nagłówkami bez obsługi tych przypadków po cichu uszkodzi tematy emaili z polskimi znakami, znakami japońskimi czy arabskimi imionami.
• Limity wywołań API: Google Workspace i Microsoft 365 stosują agresywny throttling. O 3 w nocy batch 10 000 emaili, który napotka błąd 429 Too Many Requests bez obsługi wykładniczego backoff, zostawia połowę skrzynek w połowicznie poprawionym stanie.
• Uszkodzone granice MIME: wiadomości wieloczęściowe z załącznikami mają precyzyjne granice MIME. Niepoprawne ich zregenerowanie sprawia, że załączniki stają się nieczytelne.

I pytanie, którego żaden skrypt domowy nie rozwiązuje: jak zweryfikować, że każdy poprawiony email jest nienaruszony? Skrypt modyfikujący 40 000 wiadomości bez indywidualnej weryfikacji to zakład. Zakład na danych, które użytkownicy często uważają za nie do odzyskania.

Artykuł o dostępnych opcjach naprawy dat po migracji omawia różne podejścia, w tym ich ograniczenia.

Co robi Redate.io w tym kontekście

Redate.io jest zaprojektowane właśnie do tego przypadku: korekty dat uszkodzonych przez migrację IMAP, na dużą skalę, bez ryzyka dla integralności wiadomości.

Serwis łączy się bezpośrednio ze skrzynkami (Google Workspace przez delegację na poziomie domeny, Microsoft 365 przez Azure AD lub bezpośrednio przez IMAP), bezpłatnie skanuje wiadomości z błędnymi datami, a następnie stosuje autorski pipeline korekcji obsługujący opisane wyżej przypadki brzegowe. Każdy email jest weryfikowany indywidualnie po korekcie. Oryginały pozostają w widocznym folderze kopii zapasowej przez 30 dni.

Dopasowywanie wzorców obejmuje setki sygnatur znanych narzędzi migracyjnych: BitTitan MigrationWiz, CloudM, imapsync, GSMMO i ich warianty. Wykrywanie jest precyzyjne: Redate.io nie dotyka emaili, których data jest prawidłowa.

Model cenowy jest prosty: jednorazowa płatność za skrzynkę pocztową, bez subskrypcji. Skan diagnostyczny jest bezpłatny, co pozwala ocenić skalę problemu przed podjęciem jakichkolwiek decyzji.

Jeśli zarządzasz skrzynkami dotkniętymi tym problemem, artykuł o błędnych datach w Outlooku po migracji szczegółowo opisuje najczęstsze objawy i jak je odróżnić od innych przyczyn.

Chcesz sprawdzić skalę problemu w swoich skrzynkach? Uruchom bezpłatny skan na Redate.io i sprawdź dokładnie, ile emaili jest dotkniętych problemem, zanim cokolwiek zostanie poprawione.