Nagłówki serwerów pośrednich to wpisy dodawane przez kolejne systemy przekazujące wiadomość, dokumentujące jej trasę.
Jak powstają nagłówki serwerów pośrednich
Nagłówki serwerów pośrednich to pola dodawane przez systemy, które przekazują wiadomość lub żądanie dalej do następnego serwera. Każdy taki wpis opisuje fragment trasy, a niekoniecznie całą drogę od nadawcy do odbiorcy. System pośredniczący może dopisać informację o urządzeniu, z którego otrzymał dane, protokole użytym podczas połączenia, nazwie własnego hosta oraz czasie odebrania komunikatu. Kolejny serwer zwykle nie modyfikuje wcześniejszych wpisów, lecz dodaje własny, dzięki czemu powstaje uporządkowany zapis kolejnych etapów przekazywania.
Znaczenie konkretnego nagłówka zależy od protokołu. W poczcie elektronicznej podstawowym polem śledzącym trasę jest Received:. W komunikacji HTTP podobną funkcję opisuje nagłówek Via:, natomiast informacje o pośrednikach przekazujących żądanie mogą być również przekazywane za pomocą nagłówka Forwarded:. Nie są to zamienne mechanizmy: mają inne składnie, inne zastosowania i różne zasady wiarygodności.
Pole Received w poczcie elektronicznej
Serwery SMTP dodają pole Received: w momencie przyjęcia wiadomości od innego systemu SMTP lub od klienta przekazującego pocztę. Zgodnie z mechanizmem opisanym w RFC 5321 każdy serwer powinien umieścić własny wpis przed dotychczasowymi polami tego rodzaju. W efekcie najnowszy etap trasy znajduje się zazwyczaj najwyżej w nagłówkach wiadomości, a wcześniejsze etapy są położone niżej. Analizę trzeba prowadzić od dołu ku górze, porównując kolejne połączenia z kierunkiem dostarczania wiadomości.
Wpis Received: może zawierać między innymi słowa from i by, nazwy domenowe lub identyfikatory hostów, adres w nawiasach kwadratowych, użyty mechanizm transportu oraz znacznik czasu. Przykładowo zapis from mail.example (mail.example [192.0.2.10]) by mx.example with ESMTP id ABC123; Tue, 25 Aug 2026 10:15:00 +0200 wskazuje, że serwer odbierający otrzymał połączenie od hosta przedstawionego jako mail.example, z adresem 192.0.2.10, przy użyciu ESMTP. Sam wpis nie dowodzi jednak, że wszystkie wymienione nazwy są prawdziwe. Nazwa przekazana przez nadawcę może być błędna, a nieuczciwy nadawca może próbować wstawić własne, fałszywe pola przed dostarczeniem wiadomości.
Via, Forwarded i granice wiarygodności
W protokole HTTP nagłówek Via: służy do informowania o pośrednikach, takich jak proxy lub brama. Jego wartość może wskazywać wersję protokołu oraz identyfikator pośrednika, na przykład Via: 1.1 proxy.example. Nagłówek opisuje udział pośrednika w obsłudze komunikatu, ale nie jest pełnym dziennikiem sieciowym i nie musi ujawniać wszystkich urządzeń znajdujących się pomiędzy klientem a serwerem końcowym.
Nagłówek Forwarded:, zdefiniowany w RFC 7239, może przenosić parametry for, by, host i proto. Pozwalają one przekazać informację o wcześniejszym kliencie, pośredniku, żądanym hoście oraz użytym schemacie, takim jak HTTP lub HTTPS. Wartości mogą być umieszczone w cudzysłowie, a adres IPv6 powinien być zapisany w nawiasach kwadratowych. W praktyce część wdrożeń stosuje również niestandardowy nagłówek X-Forwarded-For, lecz jego interpretacja zależy od konfiguracji konkretnego łańcucha proxy. Adres odczytany z tego pola można uznać za wiarygodny tylko wtedy, gdy wiadomo, które zaufane systemy miały prawo go dopisać.
Odczyt trasy i rozpoznawanie nieprawidłowości
Podczas analizy nagłówków należy sprawdzić kolejność wpisów, zgodność znaczników czasu, nazwy hostów, adresy IP, identyfikatory wiadomości oraz deklarowany protokół. Nienaturalny układ może wskazywać na błędną konfigurację, zapętlenie przekazywania, brak synchronizacji czasu albo ręczne dopisanie części nagłówków. Nie każda różnica oznacza atak. Serwer może celowo ukrywać nazwę wewnętrznego hosta, zastępować adres publicznym identyfikatorem albo usuwać informacje podczas przekazywania komunikatu.
W poczcie elektronicznej warto porównać pola Received: z Message-ID:, Date:, Return-Path: oraz wynikami mechanizmów SPF, DKIM i DMARC. Nagłówki serwerów pośrednich pokazują trasę transportową, ale nie potwierdzają same przez się tożsamości autora treści. W HTTP podobną ostrożność należy zachować przy interpretacji Forwarded i X-Forwarded-For, szczególnie gdy żądanie mogło pochodzić bezpośrednio od klienta, a nie od zaufanego proxy. Wiarygodna diagnostyka wymaga zestawienia nagłówków z logami serwerów, konfiguracją pośredników i rzeczywistym przebiegiem połączeń.
