tłumaczenia logów błędów po stronie SMTP

Tłumaczenia logów błędów po stronie SMTP ułatwiają zrozumienie przyczyny odrzucenia wiadomości przez zagraniczny serwer.

Jak czytać odpowiedź zwrotną serwera SMTP

Tłumaczenie logów błędów po stronie SMTP polega na przełożeniu technicznej odpowiedzi serwera pocztowego na informację o przebiegu dostarczania wiadomości. Wpis w logu może zawierać kod odpowiedzi, tekst opisowy, nazwę hosta, adres IP, użyte polecenie SMTP oraz moment wystąpienia problemu. Najważniejszy jest trzycyfrowy kod zgodny z logiką opisaną w RFC 5321. Pierwsza cyfra określa ogólny rezultat: odpowiedź rozpoczynająca się od 2 oznacza pomyślne wykonanie operacji, 3 wskazuje na oczekiwanie na dalsze dane, 4 oznacza przejściową odmowę, a 5 — trwałe odrzucenie.

Przykładowo odpowiedź 250 po poleceniu MAIL FROM, RCPT TO albo DATA informuje, że serwer zaakceptował daną fazę rozmowy. Kod 354 po poleceniu DATA nie jest błędem, lecz sygnałem, że można rozpocząć przesyłanie nagłówków i treści wiadomości, zakończonych sekwencją końca danych SMTP. Z kolei odpowiedź 421 zwykle oznacza zakończenie połączenia z powodu chwilowego problemu, a 450, 451 lub 452 wskazuje na czasową niedostępność, odrzucenie odbiorcy albo ograniczenie zasobów. Takich odpowiedzi nie należy automatycznie traktować jako ostatecznej utraty wiadomości, ponieważ system wysyłający może ponawiać próbę.

Kody trwałego odrzucenia i rozszerzone statusy

Odpowiedzi zaczynające się od 5 wskazują na problem, którego samo ponowienie połączenia zwykle nie rozwiązuje. Kod 550 może oznaczać odrzucenie odbiorcy, niedozwoloną operację albo blokadę wynikającą z polityki serwera. Kod 551 informuje, że skrzynka odbiorcy nie znajduje się na danym serwerze, natomiast 552 może odnosić się do przekroczenia przydzielonego miejsca lub limitu rozmiaru wiadomości. Kod 553 bywa używany przy nieprawidłowym adresie nadawcy albo odbiorcy, a 554 ma charakter ogólny i często towarzyszy odmowie przyjęcia wiadomości z powodów polityki antyspamowej lub błędu transakcji.

Sam kod trzycyfrowy nie zawsze wystarcza do jednoznacznej diagnozy. W logu może pojawić się również rozszerzony kod statusu, na przykład 5.1.1, 5.7.1 albo 4.2.2. Taki format opisano w RFC 3463 i późniejszych aktualizacjach. Pierwsza część wskazuje klasę statusu, druga obszar odpowiedzialności, a trzecia bardziej szczegółowy przypadek. Status 5.1.1 często wiąże się z nieistniejącym adresem odbiorcy, 5.2.2 z przepełnieniem skrzynki, a 5.7.1 z odmową wynikającą z reguł bezpieczeństwa lub polityki odbiorcy. Interpretację trzeba jednak połączyć z pełnym komunikatem, ponieważ konkretne serwery mogą stosować dodatkowe kody i własne opisy.

Rozróżnienie błędu adresu, uwierzytelniania i TLS

W praktyce pierwszy etap analizy polega na ustaleniu, w którym miejscu rozmowy SMTP wystąpiła odmowa. Błąd po EHLO lub HELO może wskazywać na problem z ustanowieniem sesji, nieprawidłową nazwę hosta albo wymagania dotyczące sposobu połączenia. Odpowiedź po AUTH dotyczy uwierzytelniania, a więc danych logowania, wybranej metody autoryzacji lub braku zgody serwera na dany mechanizm. Odmowa po MAIL FROM może być związana z adresem nadawcy, natomiast błąd po RCPT TO częściej dotyczy adresu odbiorcy, jego istnienia albo zasad przyjmowania wiadomości.

Osobną grupę stanowią problemy z szyfrowaniem transportu. Jeżeli klient korzysta z polecenia STARTTLS, log może zawierać informację o nieudanej negocjacji TLS, niezgodności wersji protokołu, odrzuconym certyfikacie lub braku wspólnego zestawu szyfrów. Nie wolno utożsamiać tego automatycznie z błędnym hasłem. W przypadku połączeń szyfrowanych od początku sesji klient i serwer muszą również korzystać z właściwego trybu pracy oraz portu przewidzianego przez konfigurację danego dostawcy. Tłumaczenie logu powinno więc obejmować kolejność zdarzeń, nazwę hosta, port, moment rozpoczęcia TLS oraz dokładną treść odpowiedzi, bez usuwania istotnych fragmentów komunikatu.

Praktyczne wykorzystanie przetłumaczonego logu w serwisie

Przy analizie problemu warto zachować cały wpis błędu, a nie tylko pojedyncze słowo, takie jak „rejected” albo „failed”. Istotne są również informacje o tym, czy wiadomość została odrzucona przed przekazaniem treści, po wskazaniu odbiorcy, czy dopiero po zakończeniu transmisji danych. Należy sprawdzić poprawność adresu odbiorcy, ustawienia serwera SMTP, port, tryb szyfrowania, metodę uwierzytelniania oraz lokalny czas wystąpienia błędu. Jeżeli komunikat ma klasę 4xx, pomocne jest ustalenie, czy kolejne próby kończą się taką samą odpowiedzią. Przy klasie 5xx ważniejsze jest znalezienie przyczyny odmowy niż wielokrotne ponawianie wysyłki.

Tłumaczenie logu nie polega na mechanicznym przekładzie angielskich słów. Trzeba powiązać komunikat z konkretną fazą protokołu i ocenić, czy dotyczy konfiguracji programu pocztowego, adresu, uwierzytelniania, połączenia szyfrowanego, limitu wiadomości czy polityki serwera odbiorcy. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, w tym diagnostyką problemów z oprogramowaniem pocztowym działającym na tych urządzeniach. Do oceny przydatne są zanonimizowane logi, pełny tekst komunikatu oraz informacja, czy błąd występuje przy każdym odbiorcy, czy tylko przy jednej domenie.