serwer SMTP odrzuca połączenie

Odrzucenie połączenia przez serwer SMTP wskazuje zwykle na złą reputację nadawcy lub błędną konfigurację.

Co oznacza odrzucenie połączenia SMTP

Komunikat „serwer SMTP odrzuca połączenie” oznacza, że klient pocztowy, program lub urządzenie próbujące wysłać wiadomość nie uzyskało zgody na rozpoczęcie albo kontynuowanie sesji SMTP. Nie zawsze jest to równoznaczne z błędnym hasłem do skrzynki. Odrzucenie może nastąpić jeszcze przed uwierzytelnieniem, na podstawie adresu IP nadawcy, parametrów połączenia, nazwy hosta, użytego portu albo zasad ustalonych przez operatora poczty. Serwer może zwrócić kod odpowiedzi SMTP, na przykład 421, 450, 451, 550, 554 lub kod rozszerzony w formacie 5.7.x. Dokładna treść odpowiedzi jest ważniejsza niż ogólny komunikat wyświetlony przez aplikację.

W praktyce trzeba rozróżnić odrzucenie połączenia TCP od odrzucenia żądania SMTP. Jeżeli program zgłasza przekroczenie czasu oczekiwania, „connection refused” albo brak możliwości nawiązania połączenia, przyczyną może być zły adres serwera, nieprawidłowy port, blokada zapory sieciowej, niedostępność usługi lub problem z trasą do hosta. Jeżeli połączenie zostaje nawiązane, ale serwer odpowiada kodem 5xx po komendzie EHLO, podczas logowania albo po podaniu adresu nadawcy, problem dotyczy już reguł protokołu i polityki serwera. Te dwa przypadki wymagają innych czynności diagnostycznych.

Reputacja adresu IP i kontrola nadawcy

Serwery pocztowe często odrzucają połączenia z adresów IP sklasyfikowanych jako źródła spamu, złośliwego oprogramowania, otwartych serwerów proxy albo masowych, nieautoryzowanych wysyłek. Reputacja może pogorszyć się po wcześniejszym wysyłaniu dużej liczby wiadomości, po przejęciu konta pocztowego lub po użyciu współdzielonego adresu, z którego korzystają także inni klienci. Odrzucenie może być stałe albo czasowe. Kody z grupy 4xx zwykle wskazują na przejściową odmowę i mogą być obsługiwane przez ponowienie próby, natomiast kody 5xx oznaczają trwałe odrzucenie do czasu usunięcia przyczyny lub zmiany decyzji administratora.

Operator może sprawdzać również zgodność odwrotnego rekordu DNS, czyli rekordu PTR, z nazwą przedstawianą przez nadawcę w komunikacie powitalnym i podczas EHLO. Niektóre systemy oceniają także rekordy SPF, DKIM i DMARC domeny, choć ich brak częściej wpływa na przyjęcie konkretnej wiadomości niż na samo zestawienie sesji. Przy połączeniach z dynamicznego łącza konsumenckiego dostawca może całkowicie blokować wychodzący ruch SMTP na porcie 25, aby ograniczyć rozsyłanie spamu. W takim przypadku używa się portu submission udostępnionego przez operatora, najczęściej 587 z uwierzytelnieniem i szyfrowaniem STARTTLS, albo portu 465 dla połączenia szyfrowanego od początku sesji, jeżeli dana usługa go obsługuje.

Konfiguracja portu, TLS i uwierzytelniania

Błąd może wynikać z połączenia niewłaściwych ustawień. Port 25 służy przede wszystkim do transportu poczty między serwerami i nie musi pozwalać na wysyłanie wiadomości przez zwykłego użytkownika. Do konfiguracji klienta pocztowego właściwy jest zazwyczaj port 587, określany jako port submission. Program powinien używać nazwy serwera wskazanej przez operatora, poprawnego trybu szyfrowania oraz właściwej metody logowania. STARTTLS rozpoczyna połączenie nieszyfrowane, a następnie przełącza je na TLS po komendzie STARTTLS. W przypadku portu 465 szyfrowanie TLS jest negocjowane już podczas nawiązywania połączenia. Wybranie trybu STARTTLS dla portu, który oczekuje bezpośredniego TLS, albo odwrotnie, może zakończyć się błędem negocjacji lub natychmiastowym rozłączeniem.

Należy sprawdzić pełną nazwę hosta, ponieważ adres serwera poczty wychodzącej może być inny niż adres serwera IMAP lub POP3. Warto potwierdzić, czy konto wymaga pełnego adresu e-mail jako nazwy użytkownika, czy dopuszcza tylko jego część. Błędne dane logowania zwykle powodują odpowiedź 535, ale serwer może także odrzucić próbę po kilku nieudanych logowaniach, zablokować adres IP albo wymagać dodatkowej autoryzacji, na przykład hasła aplikacyjnego. Diagnostykę można rozpocząć od sprawdzenia rozwiązywania DNS i dostępności portu, a następnie przeanalizować kod odpowiedzi serwera. Samo wyłączenie szyfrowania lub obniżenie zabezpieczeń nie jest prawidłową naprawą, ponieważ może ujawnić dane logowania i treść transmisji.

Uporządkowana diagnostyka odmowy wysyłki

Najpierw trzeba zapisać dokładny komunikat błędu wraz z kodem SMTP, nazwą hosta, portem i godziną wystąpienia. Następnie można porównać działanie z innej sieci, na przykład przez inne łącze internetowe, o ile jest to bezpieczne i zgodne z zasadami operatora. Jeżeli problem występuje wyłącznie w jednej sieci, podejrzane są lokalna zapora, filtr antyspamowy routera, blokada portu 25 lub ograniczenie narzucone przez dostawcę internetu. Jeżeli odmowa pojawia się niezależnie od sieci, większe znaczenie mają dane konta, konfiguracja TLS, reputacja adresu IP, blokada po stronie operatora albo zasady domeny nadawcy.

Do weryfikacji połączenia można użyć narzędzi systemowych, takich jak nslookup lub Resolve-DnsName do sprawdzenia DNS oraz Test-NetConnection nazwa-serwera -Port 587 w systemie Windows do sprawdzenia osiągalności wskazanego portu. Wynik testu sieciowego nie potwierdza jeszcze poprawnej autoryzacji ani prawidłowej obsługi SMTP, ale pomaga oddzielić problem transportowy od problemu aplikacyjnego. Dalsze informacje znajdują się zwykle w logach klienta pocztowego, zaporze sieciowej i panelu operatora. Jeżeli kod wskazuje na blokadę reputacyjną, potrzebny jest kontakt z administratorem usługi oraz sprawdzenie, czy z konta nie wysyłano nieautoryzowanych wiadomości. Po zmianie ustawień należy wykonać pojedynczą próbę testową i potwierdzić zarówno nawiązanie sesji, jak i dostarczenie wiadomości do odbiorcy.