RFC 5322 header

Nagłówek zgodny z RFC 5322 musi spełniać ściśle określoną składnię pól i ich wartości.

RFC 5322 header — czym jest nagłówek wiadomości e-mail

RFC 5322 header to uporządkowana część wiadomości poczty elektronicznej, umieszczona przed właściwą treścią komunikatu. Zawiera pola opisujące wiadomość, jej nadawcę, odbiorców, temat, datę utworzenia oraz przebieg przekazywania pomiędzy kolejnymi systemami pocztowymi. Nagłówek nie jest zwykłym tekstem dopisanym nad treścią e-maila. Stanowi strukturę danych, którą programy pocztowe odczytują według określonych reguł składniowych.

Wiadomość zgodna z RFC 5322 składa się z nagłówka oraz ciała, a obie części oddziela pusta linia. Poszczególne pola nagłówkowe mają postać nazwy zakończonej dwukropkiem, po której znajduje się wartość, na przykład Subject: Zamówione materiały. Nazwa pola powinna być rozpoznawalna bez względu na wielkość użytych liter, dlatego Subject, subject i SUBJECT odnoszą się do tego samego pola. Wartość pola może zawierać tekst, adres pocztowy, datę, identyfikator albo listę kilku elementów.

Standard opisuje przede wszystkim format wiadomości, a nie sposób jej dostarczania. Za przesyłanie odpowiadają inne mechanizmy, między innymi protokoły używane przez pocztę wychodzącą i przychodzącą. Z tego powodu sam nagłówek RFC 5322 nie stanowi potwierdzenia, że wiadomość rzeczywiście pochodzi od wskazanego nadawcy. Pokazuje dane zapisane w komunikacie, lecz ich wiarygodność musi być oceniana dodatkowo.

RFC 5322 header — kontekst techniczny i porównanie pól

Najłatwiej wyobrazić sobie nagłówek jako metrykę przesyłki. Pole Date określa moment utworzenia wiadomości, From wskazuje autora deklarowanego przez nadawcę, To opisuje głównego adresata, a Subject zawiera temat. Pole Cc służy do jawnego wskazania dodatkowych odbiorców, natomiast Bcc jest obsługiwane w szczególny sposób: adres ukrytego odbiorcy może zostać wykorzystany przy wysyłaniu, ale nie musi pojawić się w kopii otrzymanej przez pozostałych adresatów.

Istotne jest rozróżnienie pomiędzy adresem widocznym dla użytkownika a techniczną drogą dostarczenia. From nie musi odpowiadać serwerowi, który przekazał wiadomość. Kolejne pola Received są dopisywane przez systemy obsługujące pocztę i zwykle tworzą zapis drogi komunikatu. Najnowszy wpis znajduje się zazwyczaj wyżej, a starsze wpisy niżej, choć interpretacja wymaga uwzględnienia konkretnego sposobu odbioru oraz możliwych modyfikacji przez programy pośredniczące.

W nagłówku mogą pojawić się także pola związane z identyfikacją wiadomości, takie jak Message-ID, oraz pola wskazujące odpowiedź lub wątek, na przykład In-Reply-To i References. Dzięki nim aplikacja pocztowa może połączyć wiadomości w rozmowę. Nie należy mylić ich z tematem. Dwie wiadomości z takim samym Subject nie muszą należeć do jednego wątku, a odpowiedź może zachować wspólną relację nawet po zmianie tematu.

RFC 5322 opisuje również obsługę długich wierszy. Jeżeli wartość pola jest rozbudowana, może zostać podzielona na kilka linii. Linie kontynuujące muszą zaczynać się od białego znaku, na przykład spacji lub tabulatora. Taki zabieg nazywa się składaniem pola. Przy odczycie logiczna wartość jest ponownie łączona, ale nieprawidłowe łamanie linii może prowadzić do błędów parsera, nieczytelnego wyświetlania albo odrzucenia wiadomości.

Warto odróżnić RFC 5322 od wcześniejszych i uzupełniających standardów pocztowych. RFC 5322 definiuje podstawowy format internetowej wiadomości tekstowej, natomiast kodowanie znaków spoza prostego zestawu znaków oraz załączniki są opisywane przez rozszerzenia MIME. Z kolei reguły dotyczące podpisów, uwierzytelniania nadawcy czy polityk domenowych wynikają z innych mechanizmów. Obecność poprawnego nagłówka nie oznacza więc automatycznie obecności załącznika, podpisu cyfrowego ani pomyślnego przejścia kontroli antyspamowej.

RFC 5322 header — typowe problemy w wiadomościach

Jednym z częstszych problemów jest brak pola Date albo jego zapis w formacie, którego program nie potrafi prawidłowo odczytać. Data w wiadomości nie musi być zapisana tak samo jak data prezentowana w interfejsie. Może zawierać dzień tygodnia, strefę czasową i przesunięcie względem czasu uniwersalnego. Błędne przesunięcie może sprawić, że wiadomość zostanie pokazana w niewłaściwej kolejności, mimo że sama treść nie została zmieniona.

Problemy pojawiają się także przy polu From. Może ono zawierać nazwę opisową oraz adres ujęty w nawiasach ostrych, na przykład Jan Kowalski <Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript.>. Błąd w cudzysłowie, nawiasie lub kodowaniu nazwy może zmienić sposób prezentacji nadawcy. Należy przy tym pamiętać, że poprawna składnia nie rozstrzyga, czy adres został użyty przez uprawnioną osobę.

Nieprawidłowości dotyczą często znaków diakrytycznych. Starsze pola tekstowe mogły zakładać ograniczony zestaw znaków, dlatego temat lub nazwa nadawcy zawierająca polskie litery może zostać zakodowana w specjalnej postaci. Program pocztowy powinien ją odtworzyć podczas wyświetlania. Jeżeli dekodowanie zawiedzie, pojawiają się ciągi znaków przypominające losowy zapis, a nie czytelny temat.

Osobną kategorię stanowią uszkodzone wpisy Received. Ich liczba może być duża, a kolejność bywa trudna do analizy. Nie powinno się wyciągać wniosków na podstawie jednego wiersza. Istotne są spójność adresów, nazwy hostów, znaczniki czasu oraz zgodność z informacjami widocznymi w innych częściach komunikatu. Wartość z nagłówka może również zostać zmieniona po odebraniu wiadomości przez lokalne oprogramowanie, dlatego analiza powinna obejmować cały plik źródłowy.

Błędem jest także traktowanie pól technicznych jako poleceń do wykonania. Tekst zawarty w Subject, From lub polach dodatkowych pozostaje danymi wiadomości. Nie powinien być uruchamiany jako skrypt ani kopiowany do powłoki bez sprawdzenia. Dotyczy to zwłaszcza wiadomości z nietypowymi znakami, zagnieżdżonymi odwołaniami oraz pozornie pilnymi instrukcjami.

RFC 5322 header — praktyczne wskazówki odczytu i diagnostyki

Przy sprawdzaniu wiadomości najlepiej otworzyć widok źródła, a nie ograniczać się do tego, co pokazuje zwykły ekran programu pocztowego. Widok uproszczony może ukrywać część pól, skracać adresy albo zmieniać sposób prezentacji daty. W źródle należy odszukać pustą linię oddzielającą nagłówek od treści, a następnie sprawdzić, czy wcześniejsze wiersze tworzą poprawne pola.

W pierwszej kolejności można zweryfikować obecność Date, From oraz identyfikatora wiadomości. Następnie warto porównać To, Cc i adres użyty podczas faktycznego wysłania. Przy wiadomościach będących odpowiedzią należy sprawdzić In-Reply-To i References. Jeżeli temat wygląda na ten sam, lecz relacje identyfikatorów są niespójne, program może utworzyć osobny wątek albo połączyć komunikaty w sposób nieoczekiwany.

Do analizy dobrze użyć kopii pliku źródłowego, aby nie zmieniać oryginalnej wiadomości. Nie powinno się ręcznie poprawiać nagłówka w celu uzyskania innego czasu, adresu lub nadawcy, ponieważ taka zmiana utrudnia późniejsze ustalenie pochodzenia pliku. Jeżeli potrzebne jest przekazanie wiadomości do analizy, należy uważać na adresy, identyfikatory i inne dane osobowe. Można je zamaskować w kopii, zachowując strukturę pól oraz informację o tym, które fragmenty zostały ukryte.

W przypadku błędu wyświetlania warto porównać wiadomość w kilku programach, sprawdzić kodowanie i zwrócić uwagę na linie zaczynające się od białego znaku. Przy podejrzeniu fałszerstwa należy analizować cały nagłówek, a nie tylko nazwę wyświetlaną obok wiadomości. Sam zapis zgodny ze składnią RFC 5322 nie przesądza o autentyczności, ale może pomóc wskazać miejsce powstania problemu.

RFC 5322 header — kiedy zgłosić się do serwisu

Do serwisu warto zgłosić się wtedy, gdy wiadomości znikają z programu, pojawiają się w złej kolejności, wyświetlają niezrozumiałe znaki albo nie otwierają się mimo poprawnego odbioru przez inne urządzenie. Pomoc może być potrzebna także wtedy, gdy problem dotyczy tylko jednego konta, kopie wiadomości mają uszkodzone nagłówki, a ustawienia programu pocztowego były zmieniane bez wyraźnej przyczyny. Przed przekazaniem urządzenia dobrze zachować przykładową wiadomość w oryginalnym formacie oraz zanotować, czy problem występuje przy odbiorze, wysyłaniu, wyszukiwaniu czy wyświetlaniu.

W Warszawie takie przypadki może przyjąć Warszawskie Pogotowie Komputerowe 24/7, gdzie można skonsultować problemy z działaniem programu pocztowego, odczytem źródła wiadomości oraz konfiguracją systemu. Przy analizie należy jasno opisać objawy i wskazać, czy błąd pojawia się na jednym urządzeniu, czy na kilku. Ułatwia to odróżnienie uszkodzenia lokalnej aplikacji od problemu z kontem albo z samą wiadomością.

Najważniejsze jest zachowanie ostrożności. Nie należy odpowiadać na podejrzaną wiadomość tylko po to, aby sprawdzić adres, otwierać nieoczekiwanych załączników ani przekazywać pełnego źródła bez usunięcia danych, które nie są potrzebne do diagnozy. Prawidłowo odczytany RFC 5322 header dostarcza wielu wskazówek, lecz jego interpretacja wymaga uwzględnienia sposobu odebrania wiadomości, użytego programu oraz pozostałych zabezpieczeń poczty.