EHLO extensions to dodatkowe funkcje protokołu SMTP zgłaszane przez serwer w odpowiedzi na polecenie EHLO.
Jak serwer SMTP ogłasza EHLO extensions
EHLO extensions to rozszerzenia protokołu SMTP, które serwer przedstawia klientowi po otrzymaniu polecenia EHLO. Klient wysyła zwykle nazwę swojej domeny lub identyfikator hosta, a serwer odpowiada kodem 250 i listą dostępnych możliwości. Każda pozycja listy zaczyna się od słowa kluczowego rozszerzenia, na przykład SIZE, 8BITMIME, STARTTLS, AUTH, PIPELINING albo SMTPUTF8. Odpowiedź wielowierszowa wykorzystuje zapis 250- dla kolejnych wierszy oraz 250 dla ostatniego wiersza.
Mechanizm rozszerzeń pozwala klientowi dopasować przebieg sesji do faktycznych możliwości danego serwera. Sam fakt, że określona funkcja istnieje w standardzie SMTP, nie oznacza, że konkretny serwer ją obsługuje. Klient powinien korzystać z rozszerzenia tylko wtedy, gdy zostało ono zgłoszone w odpowiedzi na bieżące EHLO. Jeżeli serwer nie rozpoznaje EHLO, może odpowiedzieć kodem błędu, a klient może przejść do starszego polecenia HELO. W takim trybie rozszerzenia nie są negocjowane, dlatego klient powinien używać podstawowego zestawu poleceń SMTP.
Najczęściej spotykane rozszerzenia i ich parametry
Rozszerzenie SIZE, opisane w RFC 1870, pozwala serwerowi ogłosić maksymalny rozmiar wiadomości, zwykle jako liczbę bajtów umieszczoną po słowie kluczowym. Klient może następnie przekazać przewidywany rozmiar wiadomości w komendzie MAIL FROM, używając parametru SIZE=. 8BITMIME, zdefiniowane w RFC 6152, sygnalizuje możliwość przyjmowania treści MIME zawierającej oktety o wartościach spoza siedmiobitowego zakresu ASCII. Nie oznacza to automatycznie obsługi dowolnego kodowania znaków w nagłówkach; sposób reprezentacji treści nadal wynika z reguł MIME.
PIPELINING z RFC 2920 pozwala klientowi wysłać kilka komend SMTP bez oczekiwania na odpowiedź po każdej z nich, co zmniejsza liczbę opóźnień sieciowych. AUTH, opisane w RFC 4954, informuje o dostępnych mechanizmach uwierzytelniania, na przykład przez listę mechanizmów umieszczoną po słowie kluczowym. DSN z RFC 3461 dotyczy żądania rozszerzonych powiadomień o statusie dostarczenia, natomiast ENHANCEDSTATUSCODES z RFC 2034 wskazuje możliwość używania trzyczęściowych kodów diagnostycznych, takich jak 5.1.1. Każde z tych rozszerzeń ma własne reguły składni i nie można zastępować ich ogólnymi założeniami o działaniu SMTP.
STARTTLS, SMTPUTF8 i negocjowanie możliwości sesji
Jeżeli odpowiedź EHLO zawiera STARTTLS, klient może użyć komendy STARTTLS w celu rozpoczęcia negocjacji TLS, o ile polityka połączenia na to pozwala. Po pomyślnym zakończeniu negocjacji szyfrowania stan sesji SMTP jest resetowany i klient powinien ponownie wysłać EHLO. Dopiero druga odpowiedź określa rozszerzenia dostępne po ustanowieniu kanału TLS; serwer może na przykład dopiero wtedy ogłosić AUTH. Samo pojawienie się słowa STARTTLS nie oznacza, że szyfrowanie zostało już włączone ani że klient ma obowiązek użyć tej komendy w każdej konfiguracji.
SMTPUTF8 z RFC 6531 pozwala negocjować obsługę adresów i elementów wiadomości wykorzystujących znaki Unicode zgodnie z rozszerzeniami międzynarodowego pocztowego formatu MIME. Klient nie powinien wysyłać parametru SMTPUTF8 w komendzie MAIL FROM, jeżeli serwer nie ogłosił tego rozszerzenia. Z kolei CHUNKING z RFC 3030 zastępuje klasyczne przesyłanie treści przez DATA mechanizmem BDAT, który przekazuje dane w określonych porcjach. Rozszerzenie to jest powiązane z innymi możliwościami, takimi jak BINARYMIME, dlatego klient musi sprawdzać wszystkie wymagane deklaracje, a nie tylko pojedyncze słowo z listy EHLO.
Rola EHLO extensions w diagnozowaniu połączenia pocztowego
Analiza odpowiedzi na EHLO pomaga ustalić, dlaczego klient pocztowy lub aplikacja nie może wysłać wiadomości. Należy sprawdzić kod odpowiedzi, kompletność listy rozszerzeń oraz moment, w którym poszczególne funkcje się pojawiają. Brak STARTTLS oznacza, że klient nie może rozpocząć negocjacji TLS za pomocą tej sesji. Brak AUTH wskazuje, że serwer nie zadeklarował uwierzytelniania w aktualnym stanie połączenia, choć po zmianie portu, trybu TLS lub ponownym EHLO wynik może być inny. Komunikat o zbyt dużej wiadomości należy zestawić z wartością ogłoszoną przy SIZE oraz z odpowiedzią na MAIL FROM.
Podczas diagnostyki warto zachować dokładną kolejność komend i odpowiedzi, ponieważ rozszerzenia są negocjowane w ramach konkretnej sesji SMTP. Inny zestaw może wystąpić przed i po STARTTLS, a także na różnych portach lub w różnych punktach infrastruktury pocztowej. Nieprawidłowo działający klient może próbować użyć AUTH, SMTPUTF8 albo parametru SIZE mimo braku odpowiedniej deklaracji, co prowadzi do odpowiedzi takich jak 500, 502 lub 504. Porównanie logu klienta z surową odpowiedzią serwera pozwala rozdzielić błąd negocjacji rozszerzeń od problemu z nazwą hosta, certyfikatem TLS, uwierzytelnieniem lub samą treścią wiadomości.
