RFC 5322

RFC 5322 to podstawowa specyfikacja opisująca format wiadomości internetowej, w tym strukturę nagłówków.

Zakres RFC 5322 i miejsce nagłówków wiadomości

RFC 5322 opisuje składnię wiadomości internetowych, czyli sposób zapisu ich nagłówków oraz treści. Dokument zastąpił wcześniejszy standard RFC 2822 i definiuje format używany przez programy pocztowe do przedstawiania informacji takich jak nadawca, odbiorca, temat, data utworzenia oraz identyfikator wiadomości. RFC 5322 nie jest jednak protokołem transportowym. Nie określa sposobu ustanawiania połączenia z serwerem ani mechanizmu przekazywania poczty między serwerami; te zadania należą między innymi do SMTP opisanego w RFC 5321.

Wiadomość zgodna z RFC 5322 składa się z nagłówka i opcjonalnego ciała, które są rozdzielone pustą linią. Nagłówek zawiera pola w postaci nazwa pola, dwukropek i wartość, na przykład Subject: Raport. Kolejne pola są zapisywane w osobnych wierszach. Standard używa zakończenia wiersza CRLF, czyli sekwencji znaków odpowiadającej powrotowi karetki i przejściu do nowej linii. Pusta linia po ostatnim polu nagłówka ma znaczenie składniowe, ponieważ wskazuje początek treści wiadomości.

Pola From, To, Date i Subject

RFC 5322 definiuje kilka pól obowiązkowych. Pole Date opisuje datę i czas utworzenia wiadomości, a pole From wskazuje autora lub autorów. W typowej wiadomości występuje także To, zawierające adresatów podstawowych, chociaż jego obecność nie zawsze jest konieczna w każdej poprawnej konstrukcji. Pole Subject jest opcjonalne i przechowuje temat wyświetlany przez klienta pocztowego. Jego brak nie oznacza automatycznie uszkodzenia wiadomości.

Adresy pocztowe w tych polach mogą być zapisane jako sama skrzynka, na przykład Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript., albo jako nazwa wyświetlana wraz z adresem, 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.>. RFC 5322 rozróżnia adresy skrzynek i adresy grupowe. Pole Sender może wskazywać rzeczywistego nadawcę technicznego, gdy wiadomość jest wysyłana w imieniu innej osoby lub procesu. Z kolei Reply-To podaje adres, na który klient powinien kierować odpowiedź, jeśli ma on być inny niż adres autora z pola From.

Warto odróżnić pole From od danych wykorzystywanych przez SMTP podczas dostarczania wiadomości. Adres autora zapisany w nagłówku nie musi być identyczny z adresem użytym w komendzie SMTP MAIL FROM. Dlatego sam wygląd pola From nie potwierdza, z jakiego serwera wiadomość została wysłana ani kto faktycznie ją dostarczył.

Składnia wierszy, kodowanie i śledzenie odpowiedzi

Standard ogranicza długość pojedynczego wiersza wiadomości do 998 znaków, a wiersze dłuższe niż 78 znaków uznaje za niezalecane. Limit 78 znaków nie jest twardym zakazem, lecz wskazówką ułatwiającą czytelne wyświetlanie tekstu. Gdy pole nagłówka jest długie, można zastosować składanie wiersza. Kontynuacja musi zaczynać się od białego znaku, na przykład spacji lub tabulatora. Taki sposób zapisu dotyczy logicznie jednego pola, mimo że jego wartość zajmuje kilka fizycznych wierszy.

RFC 5322 opisuje przede wszystkim znaki i strukturę składniową, ale nie rozwiązuje wszystkich problemów związanych z treścią binarną lub znakami spoza podstawowego zestawu ASCII. Kodowanie znaków w nagłówkach oraz sposób przenoszenia załączników i treści wieloczęściowych określa MIME, między innymi RFC 2045, RFC 2046 i RFC 2047. W praktyce wiadomość może więc zawierać nagłówki zgodne z RFC 5322 oraz dodatkowe pola MIME, takie jak MIME-Version i Content-Type.

Pola Message-ID, In-Reply-To i References służą do identyfikowania wiadomości oraz łączenia ich w wątki. Message-ID powinien być unikatowym identyfikatorem konkretnej wiadomości. Przy tworzeniu odpowiedzi klient może umieścić identyfikator wiadomości pierwotnej w In-Reply-To, a historię powiązanych identyfikatorów przechować w References. Brak tych pól może utrudniać grupowanie korespondencji, ale nie musi oznaczać błędu całego formatu.

RFC 5322 w praktyce serwisowej

Nieprawidłowa składnia RFC 5322 może powodować odrzucenie wiadomości, błędne wyświetlanie nadawcy lub tematu, rozdzielenie odpowiedzi na kilka wątków albo problemy z parserem używanym przez klienta pocztowego. Podczas diagnostyki warto sprawdzić, czy nagłówki mają poprawne dwukropki, czy pola kontynuowane zaczynają się od białego znaku, czy między nagłówkiem a treścią znajduje się pusta linia oraz czy wiadomość nie zawiera uszkodzonych znaków końca wiersza. Należy także rozdzielić błędy samej składni RFC 5322 od problemów SMTP, DNS, uwierzytelniania lub kodowania MIME.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy problemach z pocztą na komputerze można sprawdzić konfigurację klienta, integralność jego plików, działanie systemu oraz sposób wyświetlania i zapisywania wiadomości. Sama naprawa urządzenia nie zmienia jednak reguł RFC 5322. Jeżeli wiadomość jest odrzucana przez zewnętrzny serwer z powodu niepoprawnego nadawcy, błędnego SMTP albo polityki domeny, przyczyny trzeba szukać w odpowiednim elemencie infrastruktury, a nie w konstrukcji laptopa.

Do ręcznej kontroli struktury przydatny jest surowy widok wiadomości, a nie wyłącznie ekran z tematem i nazwą nadawcy. Analiza pełnych nagłówków pozwala zobaczyć pola Date, From, Message-ID, Received oraz informacje MIME. Pole Received nie jest podstawowym polem składni opisanym jako obowiązkowe przez RFC 5322; jest dodawane przez serwery obsługujące transport wiadomości. Dzięki temu można oddzielić problem prezentacji w programie pocztowym od problemu powstałego podczas przesyłania lub przetwarzania wiadomości.