Sendmail to najstarszy i najbardziej znany agent transferu poczty (MTA) w środowiskach uniksowych, odpowiedzialny za trasowanie i dostarczanie e-maili pomiędzy serwerami w sieci IP. Konfiguracja tego serwera opiera się na kompilacji czytelnych makr z języka m4 do wysoce skomplikowanego pliku sendmail.cf, co daje administratorom pełną kontrolę nad przepływem ruchu SMTP. Zrozumienie jego architektury pozwala zbudować infrastrukturę pocztową odporną na awarie.
Prawda jest zresztą absolutnie taka, że wielu młodych administratorów boi się tego oprogramowania. Zobaczysz w sieci dziesiątki opinii sugerujących szybką migrację na Postfixa lub Exima. Zmiana narzędzia nie naprawi jednak braku wiedzy o protokołach. Sendmail po prostu robi to, do czego został stworzony w latach osiemdziesiątych. Odbiera tekst. Sprawdza reguły. Wypycha tekst dalej w świat. Robi to z prędkością i stabilnością, której brakuje wielu nowszym aplikacjom obciążonym interfejsami graficznymi.
Pracowałem kiedyś przy migracji starego klastra pocztowego w lokalnej firmie hostingowej na poznańskich Ratajach. Sprzęt pamiętał początki lat dwutysięcznych. Mieliśmy tam Sendmaila obsługującego ruch z tysięcy domen bez zająknięcia. Kiedy próbowaliśmy wdrożyć nowocześniejsze rozwiązanie, serwer dusił się przy nagłych pikach spamu. Wróciliśmy do starych plików konfiguracyjnych m4 w ciągu jednego weekendu. To u nas w sumie chyba dowód na to, że czasami surowy kod C napisany dekady temu radzi sobie z ruchem sieciowym lepiej niż dzisiejsze wynalazki. Chociaż prawdę mówiąc brakuje nam twardych danych z tamtego okresu, więc wydaje się to tylko jedną z możliwych hipotez tłumaczących ówczesne problemy z wydajnością innych demonów.
Dlaczego administratorzy nadal wybierają serwer Sendmail w swoich sieciach?
To specyficzny kawałek kodu. Nie wybacza błędów konfiguracyjnych. Posiada jednak architekturę tak elastyczną, że pozwala na nadpisywanie niemal każdego nagłówka wiadomości w locie. Używa się go w korporacjach mających bardzo restrykcyjne zasady routingu wewnętrznego.
Agent transferu poczty działa w tle jako demon nasłuchujący na porcie 25. Kiedy inna maszyna nawiązuje połączenie TCP, Sendmail inicjuje sesję SMTP. Przyjmuje komendy EHLO, MAIL FROM oraz RCPT TO. Zarządza kolejką wiadomości. Jeśli serwer docelowy odrzuca połączenie z powodu chwilowej niedostępności, demon zapisuje plik w katalogu /var/spool/mqueue i ponawia próbę za jakiś czas.
- Potrafi integrować się z zewnętrznymi skanerami antywirusowymi przez protokół Milter.
- Pozwala na budowanie skomplikowanych map aliasów i wirtualnych tabel hostów.
- Zużywa śmiesznie mało pamięci RAM w porównaniu do serwerów napisanych w Javie.
- Natywnie obsługuje szyfrowanie TLS i autoryzację SASL.
Zanim zaczniesz cokolwiek instalować na serwerze produkcyjnym, musisz sprawdzić lokalne ustawienia DNS. Bez poprawnego rekordu MX i rozwiązywania nazw hostów demon pocztowy zgubi się przy pierwszej próbie wysłania wiadomości na zewnątrz. Skonfiguruj plik /etc/hosts tak, by maszyna znała swoją pełną nazwę domenową (FQDN). To absolutna podstawa.
Od czego zacząć instalację tego agenta transferu poczty na Linuksie?
Instalacja zależy od używanej dystrybucji. Repozytoria pakietów zazwyczaj zawierają gotowe i skompilowane wersje binarne. Wymaga to pobrania zaledwie kilku megabajtów danych.
W systemach z rodziny Debian lub Ubuntu wykonujesz proste polecenie w terminalu. Wpisujesz apt-get install sendmail sendmail-bin sendmail-cf. W środowiskach Red Hat, CentOS lub Rocky Linux używasz menedżera dnf. Pobierasz pakiety sendmail i sendmail-cf. Ten drugi pakiet zawiera zbiór makr m4. Bez niego nie wygenerujesz pliku konfiguracyjnego w ludzki sposób.
Zaraz po instalacji system uruchomi usługę. Domyślna konfiguracja pozwala tylko na wysyłanie poczty z poziomu konsoli lokalnej (localhost). Serwer nie przyjmie żadnej wiadomości z zewnątrz. To celowe zabezpieczenie przed stworzeniem tak zwanego open relay. Otwarty przekaźnik pocztowy to najszybsza droga do trafienia na wszystkie globalne czarne listy RBL. Spamerzy skanują sieć non stop. Znalezienie otwartego portu 25 bez autoryzacji zajmuje im bez mała prawie pięćdziesiąt minut od momentu podpięcia nowego adresu IP do sieci.
| Plik systemowy | Funkcja w architekturze poczty |
| /etc/mail/sendmail.mc | Główny plik z makrami edytowany przez człowieka. |
| /etc/mail/sendmail.cf | Wygenerowany kod zrozumiały wyłącznie dla demona. |
| /etc/mail/access | Baza danych określająca kto może wysyłać e-maile. |
| /etc/aliases | Tabela przekierowań adresów lokalnych na inne konta. |
Jak bezpiecznie edytować plik sendmail.mc i kompilować makra?
Nigdy nie dotykaj pliku sendmail.cf bezpośrednio. Zrobiłem to raz w 2011 roku na serwerze testowym. Składnia tego pliku przypomina ciąg przypadkowych znaków wyplutych przez uszkodzoną drukarkę igłową. Setki reguł przepisywania adresów opartych na niezrozumiałych operatorach matematycznych. Edytor tekstu pokazuje tam rzeczy w stylu „R$* < @ $* > $* $#esmtp $@ $2 $: $1 < @ $2 > $3″. Zrozumienie tego dialektu wymaga tygodni czytania oryginalnej dokumentacji z Uniwersytetu w Berkeley. Dlatego społeczność stworzyła abstrakcyjną warstwę opartą na procesorze m4.
Otwierasz plik /etc/mail/sendmail.mc w edytorze nano lub vim. Widzisz tam strukturę opartą na dyrektywach dnl. Słowo dnl oznacza „delete through newline” i pełni funkcję komentarza. Jeśli linijka zaczyna się od dnl, kompilator ją zignoruje. Aby włączyć jakąś funkcję, po prostu usuwasz to słowo z początku wiersza.
Chcesz wymusić nasłuchiwanie na wszystkich interfejsach sieciowych. Odszukujesz dyrektywę DAEMON_OPTIONS. Domyślnie wygląda tak: DAEMON_OPTIONS(`Family=inet, Name=MTA-v4, Port=smtp, Addr=127.0.0.1′). Zmieniasz adres IP na 0.0.0.0. Zapisujesz plik.
Zmiany w pliku .mc nie wpływają na działanie serwera. Musisz przetłumaczyć ten tekst na format .cf. W katalogu /etc/mail wykonujesz polecenie make. System uruchomi procesor m4, zaczyta twoje makra i wypluje gotowy plik konfiguracyjny. Następnie restartujesz demona komendą systemctl restart sendmail. Dopiero w tym momencie nowe reguły wchodzą w życie.
Co zrobić by serwer przekazywał pocztę przez zewnętrzny Smart Host?
Wielu dostawców internetu blokuje ruch wychodzący na porcie 25 dla domowych adresów IP. Jeśli masz serwer w biurze, nie wyślesz poczty bezpośrednio do serwerów Google czy Microsoftu. Twoje pakiety zginą na routerze operatora. Rozwiązaniem jest użycie Smart Hosta.
Smart Host to zewnętrzny serwer SMTP (np. Amazon SES, Mailgun lub serwer twojego ISP), który zgadza się przyjmować twoją pocztę i wysyłać ją w twoim imieniu. Aby go skonfigurować, dodajesz jedną linijkę w pliku sendmail.mc.
Wpisujesz: define(`SMART_HOST’, `smtp.twojdostawca.pl’)dnl.
Jeśli serwer nadrzędny wymaga autoryzacji loginem i hasłem, musisz skonfigurować plik authinfo. Tworzysz plik /etc/mail/authinfo i dodajesz w nim wiersz z danymi uwierzytelniającymi. AuthInfo:smtp.twojdostawca.pl „U:root” „I:twojlogin” „P:twojhaslo”. Potem kompilujesz tę bazę danych poleceniem makemap hash /etc/mail/authinfo.db < /etc/mail/authinfo. Wrzucasz to do pliku głównego przez FEATURE(`authinfo'). Przebudowujesz konfigurację. Restartujesz usługę. Od tej pory wszystkie e-maile wychodzące z twojej maszyny trafią najpierw do zewnętrznego dostawcy.
Jak skonfigurować autoryzację SASL i szyfrowanie TLS?
Poczta przesyłana jawnym tekstem to relikt przeszłości. Ktoś podpięty do sieci za pomocą analizatora pakietów odczyta treść każdej wiadomości. Serwer musi obsługiwać szyfrowanie połączeń. Wymaga to wygenerowania certyfikatów SSL/TLS. Możesz użyć darmowych certyfikatów od Let’s Encrypt.
Mając pliki certyfikatu i klucza prywatnego, wskazujesz ich ścieżki w pliku sendmail.mc.
- define(`confCACERT_PATH’, `/etc/ssl/certs’)dnl
- define(`confCACERT’, `/etc/letsencrypt/live/twojadomena.pl/chain.pem’)dnl
- define(`confSERVER_CERT’, `/etc/letsencrypt/live/twojadomena.pl/cert.pem’)dnl
- define(`confSERVER_KEY’, `/etc/letsencrypt/live/twojadomena.pl/privkey.pem’)dnl
Włączenie SASL pozwala użytkownikom na logowanie się do serwera w celu wysłania poczty z ich programów pocztowych (np. Thunderbird). Potrzebujesz pakietu cyrus-sasl. Po jego instalacji dodajesz do konfiguracji dyrektywy TRUST_AUTH_MECH i define(`confAUTH_MECHANISMS’). Ustawiasz mechanizmy na LOGIN PLAIN. Serwer zacznie weryfikować hasła klientów zanim pozwoli im na wysłanie e-maila poza lokalną domenę.
Gdzie definiuje się domeny, które serwer ma traktować jako własne?
MTA musi wiedzieć, dla jakich domen ma przyjmować pocztę ostatecznie, a jakie traktować jako ruch do przekazania dalej. Do tego służy plik /etc/mail/local-host-names. Wpisujesz tam po prostu listę swoich domen, każda w nowej linijce.
firma.pl
poczta.firma.pl
marketing.firma.pl
Kiedy serwer otrzyma wiadomość zaadresowaną do [email protected], sprawdzi ten plik. Zobaczy domenę na liście. Zamiast szukać serwerów MX w internecie, przekaże wiadomość do lokalnego agenta dostarczania (MDA), takiego jak procmail lub dovecot, który wrzuci maila do skrzynki użytkownika na dysku twardym.
W jaki sposób czytać logi systemowe i zarządzać kolejką mqueue?
Brak weryfikacji logów to proszenie się o kłopoty. Kiedy użytkownik dzwoni i mówi „mój e-mail nie dotarł”, twoim pierwszym krokiem jest sprawdzenie pliku /var/log/maillog. To tam demon zapisuje każdą transakcję.
Linijka logu zawiera identyfikator wiadomości, adres nadawcy, adres odbiorcy i status. Status „Sent” oznacza, że zdalny serwer przyjął dane i odpowiedział kodem 250 OK. Status „Deferred” informuje o tymczasowym błędzie. Może to być szara lista (greylisting) na serwerze docelowym lub problem z rozwiązaniem nazwy DNS. Wiadomość trafia wtedy do kolejki.
Zarządzanie kolejką odbywa się z poziomu terminala. Wpisujesz polecenie mailq. Widzisz listę wszystkich e-maili oczekujących na wysłanie. Jeśli kolejka puchnie i liczy tysiące wiadomości, prawdopodobnie z twojego serwera wysyłany jest spam. Ktoś złamał hasło użytkownika lub wykorzystał dziurę w skrypcie PHP na stronie WWW. W takiej sytuacji natychmiast zatrzymujesz demona. Czyścisz katalog /var/spool/mqueue. Zmieniasz hasła. Szukasz źródła wycieku w logach autoryzacji.
Wymuszenie natychmiastowego przetworzenia kolejki realizuje się poleceniem sendmail -q -v. Flaga -v (verbose) wypisuje na ekran całą konwersację SMTP z serwerami docelowymi. Widzisz dokładnie, w którym momencie połączenie jest zrywane.
Jakie rekordy DNS musisz wdrożyć by omijać foldery spam u odbiorców?
Sama konfiguracja serwera to ledwie połowa pracy na dzisiejszym rynku IT. Skonfigurowałeś demona. Wysyła wiadomości. Otwierasz skrzynkę na Gmailu i widzisz swojego maila w folderze Spam z wielkim czerwonym ostrzeżeniem. Zmieniliśmy te zasady na robocie już lata temu. Duży gracz nie ufa małym serwerom bez autoryzacji domenowej.
Musisz wdrożyć trzy mechanizmy w panelu u swojego rejestratora domen. Bez nich każda wiadomość zostanie odrzucona lub oflagowana.
SPF (Sender Policy Framework) to rekord tekstowy TXT. Informuje świat, które adresy IP mają prawo wysyłać pocztę w imieniu twojej domeny. Tworzysz rekord o treści: v=spf1 mx a ip4:twój_adres_ip ~all. Znak tyldy na końcu sugeruje miękkie odrzucenie wiadomości z innych źródeł.
DKIM (DomainKeys Identified Mail) dodaje kryptograficzny podpis do nagłówków każdego wychodzącego e-maila. Wymaga to instalacji dodatkowego oprogramowania, np. opendkim. Opendkim generuje klucze RSA. Klucz prywatny zostaje na serwerze i podpisuje maile. Klucz publiczny wrzucasz jako kolejny rekord TXT do strefy DNS. Serwer odbiorcy pobiera klucz publiczny i weryfikuje podpis. Zgadza się? Wiadomość nie została zmodyfikowana w drodze.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) spina SPF i DKIM w jedną politykę. Mówi serwerom docelowym, co mają zrobić z wiadomością, która nie przejdzie weryfikacji. Rekord TXT z wartością v=DMARC1; p=reject; rua=mailto:[email protected] nakazuje kategoryczne odrzucanie sfałszowanych e-maili i wysyłanie raportów o incydentach na podany adres.
Ostatnim elementem układanki jest rekord PTR (Reverse DNS). Adres IP twojego serwera musi rozwiązywać się z powrotem na nazwę domenową. Jeśli IP wskazuje na hosta „dynamic-ip-123.isp.com”, a ty wysyłasz pocztę jako „firma.pl”, serwery antyspamowe zablokują połączenie ze względu na brak wiarygodności. Rekord PTR ustawia dostawca infrastruktury, u którego wykupiłeś serwer VPS lub dedykowany.
Zaloguj się na swój serwer. Otwórz konsolę. Wpisz netstat -tulpn | grep 25. Sprawdź, co dokładnie nasłuchuje na twoich interfejsach i zacznij audyt od przeglądu starych plików konfiguracyjnych w katalogu pocztowym.
Pytania i odpowiedzi (FAQ)
- Czy Sendmail jest darmowy?
Tak. Jest to oprogramowanie open source, dostępne na licencji pozwalającej na darmowe wykorzystanie komercyjne i modyfikacje kodu. - Jak zrestartować serwer Sendmail po zmianie konfiguracji?
W nowoczesnych dystrybucjach używasz poleceniasystemctl restart sendmail. Zawsze pamiętaj o wcześniejszym skompilowaniu makr komendąmakew katalogu /etc/mail. - Gdzie serwer przechowuje wiadomości oczekujące na wysłanie?
Katalogiem buforowym jest domyślnie/var/spool/mqueue. Pliki rozpoczynające się od litery 'q’ zawierają nagłówki, a te od 'd’ treść wiadomości. - Czym różni się Sendmail od Postfixa?
Postfix powstał jako bezpieczniejsza i łatwiejsza w konfiguracji alternatywa. Ma modularną budowę (wiele małych procesów), podczas gdy starszy rywal działa jako jeden duży demon z uprawnieniami roota. - Jak wyczyścić kolejkę zablokowanych wiadomości?
Zatrzymujesz usługę. Usuwasz zawartość katalogu mqueue poleceniemrm -f /var/spool/mqueue/*. Uruchamiasz usługę ponownie. Robisz to tylko w ostateczności przy ataku spamerskim. - Dlaczego edytor pokazuje same krzaki w pliku sendmail.cf?
To nie krzaki. To surowy język reguł przepisywania adresów. Plik ten jest generowany automatycznie z czytelnych makr m4 i nie służy do ręcznej edycji przez człowieka.
Bibliografia
1. Sendmail Consortium – https://www.proofpoint.com
2. Internet Engineering Task Force (IETF) – https://www.ietf.org
3. Debian Project – https://www.debian.org
4. Red Hat – https://www.redhat.com
5. Let’s Encrypt – https://letsencrypt.org
