RFC 5322 – format wiadomości

RFC 5322 definiuje dozwolone pola nagłówka i składnię adresów w wiadomości e-mail.

Co dokładnie normuje ten dokument

RFC 5322 opisuje wewnętrzną budowę wiadomości internetowej: zestaw dozwolonych pól nagłówka, ich składnię oraz zapis adresów. Zastąpił RFC 2822, który wcześniej zastąpił historyczny RFC 822 z 1982 roku - stąd wciąż spotykane określenie format 822. Wiadomość składa się z sekcji nagłówków i opcjonalnego ciała oddzielonego pustą linią. Wymagane są tylko dwa pola: From oraz Date, wszystkie pozostałe, łącznie z Subject i To, są opcjonalne z punktu widzenia samego standardu.

Koperta SMTP a nagłówki wiadomości

Najczęstsze nieporozumienie polega na myleniu tego dokumentu z RFC 5321, który opisuje protokół SMTP. Adresy podawane w poleceniach MAIL FROM i RCPT TO tworzą kopertę i to one decydują, dokąd fizycznie trafi list. Adresy w polach From, To i Cc są jedynie treścią wiadomości i mogą się od koperty różnić - na tym opiera się zarówno legalna wysyłka przez listy dyskusyjne, jak i podszywanie się. Standard dopuszcza też pole Sender, gdy nadawca faktyczny różni się od autora, oraz nagłówki Resent-, opisujące ponowne wysłanie. Limit długości linii wynosi 998 znaków plus zakończenie CRLF, przy zaleceniu 78, a dłuższe pola zwija się przez folding. Data ma sztywną postać w rodzaju Tue, 1 Jul 2003 10:52:37 +0200, a Message-ID musi być globalnie unikatowy, bo na nim opierają się pola In-Reply-To i References budujące wątek.

Gdzie ten format pęka w codziennej praktyce

Sam standard zna wyłącznie znaki US-ASCII, więc polskie ogonki w temacie muszą być zakodowane mechanizmem z RFC 2047 - to stąd biorą się nagłówki wyglądające jak ciąg równa się, znak zapytania, UTF-8. Źle zakodowany temat pokazuje odbiorcy krzaki albo surowy ciąg kodowania. Adresy z krajowymi znakami wymagają rozszerzenia SMTPUTF8, którego nie wspiera każdy przekaźnik. Załączniki i wiadomości wieloczęściowe opisują osobne dokumenty MIME, a nie ten standard. Systemy handlowe generujące faktury mailem potrafią wstawiać w Message-ID nazwę hosta bez domeny, co u części odbiorców kończy się odrzuceniem listu przez filtr antyspamowy.

Analiza nagłówków przy sporach o niedoręczone listy

Gdy klient twierdzi, że wysłał, a kontrahent, że nie dostał, rozstrzygnięcie leży w nagłówkach - w kolejności pól Received czytanych od dołu, w wynikach Authentication-Results i w identyfikatorach wiadomości. Odczytujemy je z konta nadawcy i odbiorcy, ustalamy, na którym przekaźniku list zniknął albo został zakwalifikowany jako niechciany, i poprawiamy konfigurację po stronie serwera lub programu pocztowego. Robimy to również dla wysyłek generowanych przez systemy sprzedażowe oparte o SQL Server, gdzie temat i nadawca składane są w kodzie aplikacji.