RFC 5321

RFC 5321 to podstawowa specyfikacja protokołu SMTP, opisująca zasady wymiany poczty między serwerami.

RFC 5321 i rola protokołu SMTP

RFC 5321 to dokument opublikowany w październiku 2008 roku, opisujący podstawowy protokół Simple Mail Transfer Protocol używany do transportu poczty elektronicznej w Internecie. Specyfikacja zastąpiła RFC 2821 oraz wcześniejszy RFC 821, a jednocześnie aktualizowała wymagania dotyczące transportu poczty zawarte w RFC 1123. Dokument ma status Draft Standard w ścieżce standaryzacyjnej IETF. RFC 5321 opisuje transport wiadomości i komunikację pomiędzy procesami SMTP, natomiast format nagłówków i treści wiadomości określa przede wszystkim osobny RFC 5322.

SMTP działa w modelu klient–serwer. Klient nawiązuje połączenie z serwerem odbierającym, przekazuje informacje o nadawcy i odbiorcach, a następnie przesyła treść wiadomości. Serwer może dostarczyć pocztę lokalnie albo przekazać ją do kolejnego serwera pośredniczącego. Do ustalenia docelowego hosta pocztowego wykorzystywane są rekordy MX w systemie DNS. Protokół nie jest tym samym co POP3 lub IMAP, ponieważ SMTP służy do wysyłania i przekazywania poczty, a nie do jej pobierania ze skrzynki przez użytkownika.

Przebieg sesji i podstawowe komendy

Typowa sesja SMTP rozpoczyna się od połączenia klienta z serwerem i odpowiedzi powitalnej zawierającej kod 220. Klient powinien przedstawić się komendą EHLO, która pozwala serwerowi ogłosić obsługiwane rozszerzenia SMTP. Starsza komenda HELO pełni funkcję zgodnościową, ale nie przekazuje listy rozszerzeń. Po ustanowieniu sesji klient rozpoczyna transakcję pocztową komendą MAIL FROM, podaje kolejnych odbiorców za pomocą RCPT TO, a następnie wysyła dane po komendzie DATA. Zakończenie treści sygnalizuje sekwencja pustej linii zawierającej pojedynczą kropkę, czyli <CRLF>.<CRLF>.

Serwer odpowiada na komendy trzycyfrowymi kodami SMTP. Kody rozpoczynające się od 2 oznaczają pomyślne wykonanie operacji, kody 3 wymagają dalszych danych, a kody 4 i 5 wskazują odpowiednio błąd przejściowy lub trwałe odrzucenie żądania. Po poprawnym przyjęciu treści wiadomości serwer zwykle zwraca kod 250. Do przerwania bieżącej transakcji służy RSET, do sprawdzenia aktywności połączenia NOOP, a do jego prawidłowego zamknięcia QUIT. Sekwencja komend ma znaczenie: MAIL FROM musi poprzedzać RCPT TO, a DATA jest dozwolona dopiero po zaakceptowaniu co najmniej jednego odbiorcy.

Adresowanie, przekazywanie i ograniczenia formatu

RFC 5321 rozróżnia adres koperty SMTP od pól nagłówka widocznych w wiadomości. Adres przekazany w MAIL FROM określa ścieżkę zwrotną używaną przy generowaniu komunikatu o niedostarczeniu, natomiast adresy z RCPT TO wskazują odbiorców dla danej transakcji. Wartość podana w MAIL FROM może być pusta, zapisana jako <>, na przykład w przypadku automatycznej wiadomości zwrotnej. Serwer może zaakceptować jednego lub wielu odbiorców w ramach tej samej transakcji, a dla każdego z nich powinien zwrócić osobną odpowiedź.

Podstawowa składnia SMTP używa linii zakończonych parą znaków CRLF. RFC 5321 określa między innymi limit 512 oktetów dla linii komendy wraz z zakończeniem CRLF oraz limit 1000 oktetów dla pojedynczej linii danych wiadomości wraz z CRLF. Jeżeli właściwa treść wiadomości zawiera linię zaczynającą się od kropki, klient stosuje mechanizm transparency, potocznie nazywany dot-stuffingiem: dodaje dodatkową kropkę, aby nie została pomylona ze znacznikiem końca danych. Rozszerzenia takie jak STARTTLS, AUTH czy SMTPUTF8 są opisane w odrębnych dokumentach i nie należy przypisywać ich szczegółowych zasad wyłącznie RFC 5321.

Znaczenie RFC 5321 w diagnostyce poczty

Podczas diagnozowania problemów z wysyłaniem wiadomości RFC 5321 pomaga rozdzielić awarię połączenia od błędu samej transakcji SMTP. Brak odpowiedzi 220 może wskazywać na problem z dostępnością hosta, portem, zaporą sieciową albo usługą serwera. Odpowiedź 530 może oznaczać konieczność uwierzytelnienia, kod 550 często wiąże się z odrzuceniem odbiorcy lub brakiem uprawnień do przekazywania, a kod 421 wskazuje na czasowe zamknięcie usługi. Interpretacja zawsze wymaga odczytania pełnego komunikatu tekstowego oraz sprawdzenia, na którą komendę serwer odpowiedział błędem.

Na komputerze użytkownika praktyczna diagnostyka obejmuje sprawdzenie nazwy serwera SMTP, portu, sposobu uwierzytelniania i zgodności ustawień szyfrowania z wymaganiami dostawcy poczty. Warto także przeanalizować log aplikacji pocztowej, ponieważ program może zgłaszać ogólny komunikat, mimo że serwer zwrócił precyzyjny kod SMTP. Jeżeli połączenie jest zrywane po długim oczekiwaniu, należy uwzględnić limity czasu oraz działanie zapory lub programu antywirusowego pośredniczącego w obsłudze poczty. RFC 5321 opisuje zachowanie protokołu, ale nie gwarantuje dostarczenia wiadomości, jeśli serwer docelowy odrzuci ją z przyczyn lokalnych lub polityki antyspamowej.