analiza logów SMTP

Analiza logów SMTP to badanie zapisów aktywności serwera pocztowego w celu diagnostyki problemów z wysyłką.

Jakie dane zawiera log SMTP

Analiza logów SMTP polega na odczytywaniu zapisów tworzonych podczas obsługi wiadomości przez serwer pocztowy lub program pełniący funkcję klienta SMTP. Wpisy mogą obejmować czas rozpoczęcia połączenia, adres IP drugiej strony, nazwę hosta, identyfikator sesji, wynik uwierzytelnienia, użyte polecenia SMTP, adres nadawcy z komendy MAIL FROM, adres odbiorcy z komendy RCPT TO, wynik przekazania treści oraz kod odpowiedzi serwera. Konkretna zawartość logu zależy od użytego oprogramowania i jego konfiguracji, dlatego przed interpretacją trzeba ustalić, który komponent zapisał dany wpis.

W standardowym przebiegu sesji SMTP klient najpierw nawiązuje połączenie TCP, zwykle z portem 25 dla przekazywania poczty między serwerami albo z portem 587 dla przesyłania wiadomości przez klienta pocztowego do serwera submission. Po połączeniu serwer wysyła powitanie z kodem 220. Klient przedstawia się poleceniem EHLO lub starszym HELO, a serwer zwraca listę obsługiwanych rozszerzeń. Następnie mogą wystąpić uwierzytelnienie, negocjacja TLS przez STARTTLS, polecenia adresowe oraz transmisja danych po komendzie DATA. Log pozwala sprawdzić, na którym etapie przepływ został przerwany.

Interpretacja kodów odpowiedzi i etapów transmisji

Podstawowe odpowiedzi SMTP mają trzycyfrowy kod. Kody rozpoczynające się od 2 oznaczają powodzenie, kody z grupy 3 wskazują na oczekiwanie na dalsze dane, a kody z grup 4 i 5 oznaczają odpowiednio błąd tymczasowy lub trwałe odrzucenie. Przykładowo 220 oznacza gotowość usługi, 221 zakończenie połączenia, 250 pozytywne wykonanie polecenia, 354 gotowość do przyjęcia treści po DATA, 421 zamknięcie usługi z powodu problemu tymczasowego, 450 czasową niedostępność skrzynki lub zasobu, 451 błąd lokalny podczas przetwarzania oraz 550 trwałe odrzucenie adresata lub żądania. Sam numer nie zawsze wystarcza; trzeba czytać również tekst odpowiedzi i sprawdzać, czy wpis pochodzi od serwera nadawcy, serwera odbiorcy czy pośredniego systemu filtrującego.

W wielu logach pojawiają się także rozszerzone kody statusu, na przykład wartości z klas 2, 4 lub 5 oraz podklasami określającymi typ problemu. Kod 4.x.x zwykle oznacza sytuację, w której ponowienie próby może zakończyć się powodzeniem, natomiast 5.x.x wskazuje na błąd wymagający zmiany adresata, uwierzytelnienia, konfiguracji albo treści wiadomości. Analiza powinna rozróżniać odrzucenie podczas MAIL FROM, odrzucenie konkretnego RCPT TO i błąd po przesłaniu treści. Jeżeli serwer przyjmuje nadawcę, ale odrzuca odbiorcę, problem dotyczy innego etapu niż sytuacja, w której połączenie zostaje zamknięte przed rozpoczęciem sesji.

Śledzenie opóźnień, ponowień i odrzuceń

Logi SMTP są szczególnie przydatne przy rozróżnianiu opóźnienia od całkowitego niepowodzenia wysyłki. Przy błędzie tymczasowym serwer może pozostawić wiadomość w kolejce i ponawiać dostarczenie według własnego harmonogramu. W takim przypadku trzeba zestawić czas utworzenia wiadomości, moment kolejnych prób, odpowiedzi zdalnego serwera oraz czas ostatecznego dostarczenia albo usunięcia z kolejki. Pojedynczy wpis o kodzie 4xx nie dowodzi jeszcze utraty wiadomości. Ważne jest ustalenie, czy później pojawiła się próba zakończona kodem 2xx, czy też wygasł limit przechowywania wiadomości w kolejce.

Podczas korelacji wpisów warto używać identyfikatora wiadomości, identyfikatora kolejki, adresu odbiorcy i dokładnego znacznika czasu. Nagłówek Message-ID może pomóc powiązać wiadomość na poziomie aplikacji, ale nie musi być tym samym identyfikatorem, którym serwer posługuje się w kolejce. Należy też uwzględnić różnice stref czasowych i formatów dat. Jeżeli wiadomość przechodzi przez kilka serwerów, każdy z nich może zapisać własną sesję i własny rezultat. Powtarzające się próby połączenia z tym samym hostem, poprzedzone przekroczeniem limitu czasu, wskazują na problem z dostępnością, trasą sieciową, zaporą lub usługą zdalną, natomiast szybkie odpowiedzi 5xx wskazują na świadome odrzucenie żądania.

Postępowanie po wykryciu problemu w logach

Diagnostykę należy rozpocząć od zebrania pełnego fragmentu obejmującego całą sesję, a nie tylko ostatni komunikat o błędzie. Trzeba sprawdzić, czy połączenie zostało nawiązane, czy serwer odpowiedział na EHLO, czy wymagane uwierzytelnienie zakończyło się powodzeniem, czy negocjacja TLS doszła do skutku oraz czy odbiorca został zaakceptowany. Błędy uwierzytelnienia często są oznaczane kodami 535 albo 534, ale dokładna treść zależy od serwera. Jeżeli problem występuje przed odpowiedzią powitalną, analiza powinna objąć DNS, routing, zaporę i dostępność portu. Jeżeli pojawia się po STARTTLS, należy sprawdzić zgodność obsługiwanych mechanizmów TLS i poprawność certyfikatu po stronie serwera.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy problemach z analizą logów SMTP można najpierw zweryfikować stan systemu, klienta pocztowego, połączenia sieciowego oraz lokalnego oprogramowania używanego do wysyłki. W praktyce warto zachować datę i godzinę nieudanej próby, adres odbiorcy, pełny kod odpowiedzi, nazwę hosta oraz identyfikator sesji, o ile występuje. Takie dane pozwalają odtworzyć kolejność zdarzeń bez zgadywania, czy wiadomość została odrzucona przez aplikację, lokalny serwer, system pośredni czy serwer odbiorcy. Nie należy utożsamiać komunikatu klienta „wysyłanie nie powiodło się” z konkretną przyczyną, dopóki nie zostanie on powiązany z odpowiednim wpisem SMTP i kodem odpowiedzi.