RFC 6532 – Unicode w nagłówkach

RFC 6532 pozwala zapisywać w nagłówkach wiadomości znaki spoza podstawowego zestawu ASCII bezpośrednio.

RFC 6532 i miejsce znaków Unicode w wiadomości e-mail

RFC 6532, opublikowany jako standard techniczny dla internetowej poczty elektronicznej, opisuje sposób umieszczania znaków Unicode zapisanych w UTF-8 bezpośrednio w polach nagłówka wiadomości. Dokument aktualizuje składnię zdefiniowaną wcześniej w RFC 5322, które opierało się na ograniczeniach zestawu znaków ASCII. Dzięki temu w odpowiednich polach nagłówka mogą występować między innymi litery używane w języku polskim, cyrylica, alfabet grecki, znaki azjatyckie oraz inne znaki reprezentowane przez UTF-8.

Zmiana dotyczy nagłówka wiadomości, czyli części zawierającej pola takie jak Subject, From, To, Cc, Reply-To i inne elementy metadanych. RFC 6532 nie definiuje nowego kodowania znaków konkurencyjnego wobec Unicode. Określa natomiast, w jaki sposób istniejąca składnia nagłówków pocztowych ma zostać rozszerzona, aby mogła przenosić tekst UTF-8. Treść właściwa wiadomości jest opisywana odrębnymi zasadami, między innymi przez MIME oraz RFC 6531 dotyczące rozszerzenia SMTPUTF8.

Jak rozszerzono składnię pól nagłówka

W klasycznym formacie wiadomości wiele fragmentów nagłówka należało zapisać znakami ASCII. Dla tekstu spoza tego zakresu stosowano mechanizm encoded-word zdefiniowany w RFC 2047, na przykład ciągi rozpoczynające się od =? i zawierające informację o użytym kodowaniu. RFC 6532 pozwala w określonych miejscach używać znaków UTF-8 bezpośrednio, bez wcześniejszego zamieniania całego tekstu na encoded-word. Dotyczy to przede wszystkim pól tekstowych, w których składnia RFC 5322 dopuszczała wcześniej elementy typu unstructured.

Rozszerzenie nie oznacza jednak, że każdy bajt UTF-8 można wstawić w dowolne miejsce nagłówka. Nadal obowiązują reguły dotyczące nazw pól, separatora dwukropka, składni adresów, nawiasów, cudzysłowów, komentarzy, białych znaków oraz łamania długich wierszy. RFC 6532 wprowadza także odpowiednie warianty składni, między innymi uAtom, uQuoted-String i uComment, aby opisać użycie znaków UTF-8 w elementach, które wcześniej miały ograniczenia ASCII. Znaki kontrolne pozostają niedozwolone, a poprawność bajtów UTF-8 musi być zachowana.

SMTPUTF8, kompatybilność i zachowanie starszych programów

Samo zapisanie nagłówka w UTF-8 nie gwarantuje, że wiadomość zostanie poprawnie dostarczona przez całą trasę pocztową. RFC 6532 należy rozpatrywać razem z RFC 6531, które definiuje rozszerzenie SMTP o nazwie SMTPUTF8. Nadawca przekazujący wiadomość zawierającą międzynarodowe elementy poczty powinien użyć odpowiedniego mechanizmu negocjowanego podczas sesji SMTP. Serwer ogłaszający obsługę SMTPUTF8 informuje o tym w odpowiedzi na komendę EHLO. Jeżeli wymaganej obsługi nie ma, wiadomość może nie być możliwa do przekazania w swojej pierwotnej postaci.

Problem zgodności dotyczy zwłaszcza starszych serwerów, filtrów antyspamowych, bibliotek pocztowych i programów, które zakładają, że nagłówki składają się wyłącznie z ASCII. Taki program może wyświetlić znaki zastępcze, błędnie odczytać temat, nieprawidłowo przetworzyć adres albo odrzucić wiadomość. Z tego powodu implementacja musi rozróżniać zwykłe kodowanie tekstu od pełnej obsługi międzynarodowej poczty. RFC 6532 nie nakazuje serwerowi automatycznej transliteracji znaków ani zamiany nazw na zapis bez znaków diakrytycznych. Konwersja może zmienić znaczenie adresu lub treści, więc zależy od możliwości całego łańcucha dostarczania.

Co sprawdzić, gdy polskie znaki w nagłówku są nieczytelne

Przy diagnozowaniu problemu należy najpierw ustalić, czy błąd występuje w temacie, nazwie nadawcy, adresie odbiorcy, komentarzu, identyfikatorze wiadomości czy w innym polu. Warto obejrzeć surową wiadomość, a nie tylko jej widok w programie pocztowym. Obecność bezpośrednich bajtów UTF-8 w nagłówku wskazuje na format zgodny z założeniami RFC 6532, natomiast zapis =?UTF-8?B? lub =?UTF-8?Q? oznacza użycie starszego mechanizmu encoded-word z RFC 2047. Oba sposoby mogą być poprawne, lecz wymagają właściwego parsera po stronie odbiorczej.

Jeżeli temat jest prawidłowy w surowym źródle, a nieczytelny tylko w interfejsie, przyczyną może być błąd dekodowania lub niepełna obsługa UTF-8 w aplikacji. Jeżeli nagłówek został uszkodzony już podczas przekazywania, trzeba sprawdzić negocjację SMTPUTF8, komunikaty z sesji SMTP oraz zachowanie pośrednich bram pocztowych. Należy także zweryfikować, czy nagłówek nie został nieprawidłowo złamany na kilka wierszy i czy kontynuowane wiersze zaczynają się od białego znaku, zgodnie z regułami RFC 5322. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego w przypadku lokalnych problemów z programem pocztowym można rozpocząć diagnostykę od systemu, konfiguracji aplikacji oraz poprawności zainstalowanych składników obsługujących UTF-8.