Sendmail

Sendmail to jeden z najstarszych serwerów MTA, wciąż wykorzystywany w niektórych środowiskach uniksowych.

Sendmail jako agent transportu poczty

Sendmail jest serwerem MTA (Mail Transfer Agent), czyli oprogramowaniem odpowiedzialnym za przyjmowanie, przekazywanie i dostarczanie wiadomości e-mail pomiędzy systemami. Jego zadaniem nie jest wyświetlanie poczty użytkownikowi, jak w przypadku klienta pocztowego, ani udostępnianie skrzynki przez IMAP lub POP3. Sendmail obsługuje przede wszystkim transport wiadomości zgodnie z protokołem SMTP, a lokalne dostarczenie może przekazywać do odpowiednich mechanizmów systemu Unix.

Projekt Sendmail wywodzi się z systemów Unix i przez wiele lat był standardowym komponentem wielu dystrybucji oraz instalacji serwerowych. W praktyce jego działanie obejmuje analizę adresu nadawcy i odbiorcy, wybór trasy dostarczenia, nawiązywanie połączeń z innymi serwerami SMTP, obsługę kolejek oraz zapisywanie informacji diagnostycznych w logach. Sendmail może działać jako demon nasłuchujący na porcie SMTP, ale może być także uruchamiany przez lokalne programy jako interfejs do przekazywania wiadomości.

Ważną cechą Sendmaila jest rozdzielenie konfiguracji od samego procesu wykonawczego. Program korzysta z pliku konfiguracyjnego sendmail.cf, którego składnia jest szczegółowa i ma charakter niskopoziomowy. Z tego powodu administracja często wykorzystuje pliki wejściowe dla procesora makr m4, na przykład sendmail.mc, z których następnie generowany jest plik sendmail.cf. Zmiana konfiguracji wymaga więc sprawdzenia zarówno źródła w m4, jak i wynikowego pliku używanego przez uruchomiony proces.

Adresowanie, reguły i kolejka wiadomości

Sendmail przetwarza adresy za pomocą reguł przepisywania. Reguły te mogą zmieniać lokalną część adresu, domenę, format adresu lub sposób wyboru tak zwanego mailera, czyli mechanizmu dostarczającego wiadomość do określonego celu. Błąd w tych regułach może spowodować odrzucanie prawidłowych adresów, dostarczanie poczty do niewłaściwego miejsca albo zapętlenie przekazywania między hostami.

Do lokalnego mapowania adresów często wykorzystywany jest plik aliases, w typowej instalacji umieszczany w /etc/aliases. Może on kierować pocztę na przykład do lokalnej skrzynki, wielu odbiorców albo programu. Po zmianie tekstowej wersji tego pliku należy zbudować bazę aliasów poleceniem newaliases; samo zapisanie pliku nie musi wystarczyć, jeżeli Sendmail korzysta z wygenerowanej bazy. Konkretne położenie plików zależy od systemu i ustawień kompilacji, dlatego podczas diagnostyki trzeba potwierdzić aktywną konfigurację.

Jeżeli wiadomości nie można dostarczyć natychmiast, Sendmail umieszcza ją w kolejce. W wielu instalacjach katalog kolejki znajduje się pod ścieżką /var/spool/mqueue, lecz lokalizacja może być zmieniona w konfiguracji. Polecenie sendmail -bp służy do wyświetlenia zawartości kolejki, a uruchomienie procesu z opcją -q pozwala zlecić próbę jej obsługi zgodnie z ustawionym harmonogramem. W kolejce mogą pozostawać wiadomości z powodu niedostępności hosta docelowego, błędu DNS, odrzucenia przez serwer odbiorcy albo problemu z lokalnym mechanizmem dostarczania.

SMTP, TLS i kontrola dostępu

Sendmail może przyjmować połączenia SMTP od innych hostów oraz przekazywać wiadomości do zewnętrznych serwerów. W konfiguracji określa się między innymi domeny uznawane za lokalne, dozwolone relaye, interfejsy nasłuchujące oraz reguły akceptowania nadawców i odbiorców. Szczególnej uwagi wymaga ustawienie relaya. Serwer, który bez ograniczeń przekazuje wiadomości dla dowolnych domen, może zostać wykorzystany jako otwarty przekaźnik przez osoby wysyłające spam.

Sendmail obsługuje rozszerzenie SMTP STARTTLS, jeżeli został odpowiednio skonfigurowany i zbudowany z obsługą wymaganych bibliotek kryptograficznych. TLS szyfruje połączenie po rozpoczęciu negocjacji, ale nie gwarantuje sam w sobie, że zdalny nadawca jest uprawniony do wysyłania poczty. Uwierzytelnianie SMTP może być skonfigurowane z wykorzystaniem mechanizmów AUTH, często współpracujących z biblioteką SASL. Należy osobno sprawdzić wymaganie szyfrowania, dostępne mechanizmy uwierzytelniania oraz to, czy reguły dostępu nie pozwalają na wysyłkę bez autoryzacji.

Logi Sendmaila są zwykle przekazywane do systemowego mechanizmu syslog. Wpisy zawierają identyfikator wiadomości, adresy, wynik połączenia oraz komunikaty serwera zdalnego. Przydatne jest porównanie czasu przyjęcia wiadomości z czasem kolejnych prób dostarczenia. Sam komunikat o przyjęciu przez lokalny MTA nie oznacza jeszcze dostarczenia do skrzynki odbiorcy. Ostatecznym potwierdzeniem jest dopiero poprawna odpowiedź zdalnego serwera albo lokalne zakończenie procesu dostarczania.

Metody sprawdzania działania Sendmaila

Podstawową kontrolę można rozpocząć od ustalenia, czy proces Sendmaila działa jako demon oraz na jakim adresie i porcie nasłuchuje. Następnie należy sprawdzić, czy plik sendmail.cf jest tym, który wskazuje uruchomiona usługa, oraz czy został wygenerowany z aktualnego pliku m4. Przydatne są także uprawnienia do plików konfiguracyjnych, katalogów kolejki i lokalnych skrzynek, ponieważ Sendmail wykonuje część operacji z ograniczonymi uprawnieniami.

Tryb testowy reguł adresowania można uruchomić poleceniem sendmail -bt. Pozwala on prześledzić sposób, w jaki Sendmail interpretuje wskazany adres i do jakiego mailera oraz hosta próbuje go skierować. To narzędzie jest szczególnie użyteczne przy błędach przepisywania domen, nieoczekiwanym routingu i problemach z adresami lokalnymi. Do obserwacji samej sesji dostarczania można użyć opcji -v, która wyświetla przebieg komunikacji, jednak jej użycie powinno być ograniczone do kontrolowanych testów.

Jeżeli wiadomość pozostaje w kolejce, diagnostyka powinna obejmować identyfikator kolejki, treść błędu z logu, rozwiązywanie nazwy DNS, połączenie TCP z hostem docelowym oraz odpowiedź SMTP. Warto rozdzielić awarię Sendmaila od problemu z infrastrukturą: brak rekordu MX, blokada portu 25, odrzucenie adresu przez serwer odbiorcy i przekroczony limit czasu nie oznaczają tego samego. Dopiero zestawienie konfiguracji, stanu kolejki i logów pozwala ustalić, czy przyczyną jest lokalna reguła, niedostępność zewnętrzna, błędna autoryzacja czy nieprawidłowe dostarczanie lokalne.