Resent-Date

Resent-Date to nagłówek wskazujący datę ponownego przesłania wiadomości.

Rodzina nagłówków Resent i idea ponownego wprowadzenia listu

Standard poczty internetowej przewiduje sytuację, w której odebrana wiadomość ma zostać wysłana dalej w niezmienionej postaci, tak jakby ktoś włożył gotowy list do nowej koperty. Ponieważ oryginalne pola nadawcy, odbiorcy i daty muszą pozostać nietknięte, dokłada się do nich komplet nagłówków z przedrostkiem Resent: Resent-From, Resent-To, Resent-Message-ID i właśnie Resent-Date, opisujący moment powtórnego nadania. Dzięki temu odbiorca widzi zarówno pierwotny obieg wiadomości, jak i to, kto i kiedy podał ją dalej. Nagłówki te mają charakter informacyjny i nie zmieniają treści ani identyfikatora oryginału.

Przekazanie dalej to nie to samo co ponowne nadanie

Klasyczne przekazywanie tworzy nową wiadomość, w której stary list zostaje wklejony do treści albo dołączony jako załącznik. Nadawcą jest osoba przekazująca, temat zyskuje przedrostek, a data jest bieżąca. Ponowne nadanie, zwane redistribution, zachowuje oryginalny nagłówek From, więc odpowiedź trafia do pierwotnego autora, a nie do pośrednika. Ten mechanizm leży u podstaw działania list dyskusyjnych i aliasów przekierowujących pocztę. Różnica jest nie tylko kosmetyczna: wpływa na to, komu trafi odpowiedź, jak wiadomość policzą filtry antyspamowe i co zobaczy dział zgodności przy odtwarzaniu korespondencji.

Co potrafi się przy tym popsuć

Największym źródłem problemów jest dziś uwierzytelnianie nadawcy. Serwer, który podaje list dalej z zachowaniem oryginalnego pola From, wysyła go z własnego adresu IP, przez co kontrola SPF nie zgadza się z domeną nadawcy, a przy restrykcyjnej polityce DMARC wiadomość ląduje w spamie lub jest odrzucana. Drugi kłopot to programy pocztowe, które sortują skrzynkę po dacie i pokazują list w miejscu odpowiadającym oryginałowi sprzed miesięcy, choć dotarł przed chwilą; różnica między Date a Resent-Date bywa wtedy jedynym wyjaśnieniem. Trzeci to niespójne implementacje: część klientów w ogóle nie wyświetla tych pól, więc trzeba sięgnąć do podglądu źródła wiadomości.

Kiedy trzeba odtworzyć drogę wiadomości

Analiza pełnych nagłówków przydaje się przy sporach o to, czy oferta dotarła na czas, przy podejrzeniu podszywania się pod kontrahenta i przy fakturach z podmienionym numerem konta. Czyta się wtedy łańcuch pól Received od dołu ku górze, porównuje znaczniki czasu i sprawdza wyniki weryfikacji SPF, DKIM oraz DMARC. Warszawskie Pogotowie Komputerowe pomaga wyciągnąć takie nagłówki z programu pocztowego lub serwera, zinterpretować je i zabezpieczyć dowody, a przy okazji sprawdza, czy komputer odbiorcy nie został zainfekowany oprogramowaniem podmieniającym treść wiadomości. Sprzęt odbieramy i odwozimy sami, bez kurierów i bez dodatkowych opłat.