Konfigurujemy VPS - część 4, poczta

Czwarty artykuł z cyklu Konfigurujemy VPS. Czas na obsługę poczty elektronicznej. Poniżej pokrótce przypominam podstawowe zasady jej działania, tłumaczę czemu jest na VPS potrzebna, wreszcie - omawiam przykładową prostą konfigurację.

Wprowadzenie

Przed przejściem do technikaliów, minimalne przypomnienie zasad działania poczty elektronicznej i uczestniczących w procesie jej dostarczania komponentów.

Email zostaje napisany przez człowieka przy pomocy programu pocztowego (tzw. MUA - Mail User Agent, czyli program obsługujący użytkownika, od Outlooka po Mutta, od Thunderbirda po Gmaila czy inny Webmail). Może też zostać wygenerowany automatycznie przez jakiś program. Proces przygotowania kończy się wysyłką, realizowaną na jeden z dwóch sposobów:

• połączenie TCP z odpowiednim (własnym) serwerem SMTP i przekazanie mu maila przy pomocy dedykowanego protokołu,

• (gdy serwer SMTP działa lokalnie na tej samej maszynie) wykorzystanie pomocniczego programu bezpośrednio wrzucającego email do serwera (standardowo /usr/bin/sendmail, wszystkie ważniejsze serwery poczty dostarczają tak nazwany program).

Serwer SMTP (bardziej formalnie MTA - Mail Transport Agent, czyli program transportujący pocztę) przyjmuje wiadomość (zwykle umieszcza ją w jakiejś formie kolejki), a następnie (zwykle asynchronicznie) przystępuje do właściwej wysyłki. W tym celu ustala dokąd ma być ona przekazana (nie zawsze jest to od razu serwer docelowy, może być wykorzystany jakiś pośrednik a nawet cała ich sekwencja), nawiązuje połączenie z docelowym serwerem SMTP i przekazuje wiadomość. Czasem po jednym, czasem po kilku takich krokach, wiadomość trafia na odpowiedni serwer docelowy. Ten proces jest odporny na błędy czy awarie, jeśli serwer docelowy jest niedostępny, serwer wysyłający będzie wielokrotnie próbował.

Serwer docelowy, po ustaleniu, że wiadomość jest kierowana do niego, uruchamia program dostarczający pocztę.

Program dostarczający pocztę (MDA - Mail Delivery Agent) odpowiada za jej zapisanie we właściwym miejscu. Mogą się tu dziać różne rzeczy, od prostego zmapowania adresu odbiorcy na lokalne konto i dopisania maila do pliku mailbox czy katalogu Maildir, po uruchamianie złożonych filtrów (programy antyspamowe i antywirusowe, filtry Sieve, skrypty rozrzucające pocztę po różnych kontach i folderach) i zapis poczty w bazach danych. Tak czy siak - MDA gdzieś zapisuje otrzymany email i na tym jego rola się kończy.

Ostatnim elementem obrazka jest czytanie poczty przez odbiorcę. MUA mogą bezpośrednio czytać wiadomości z plików mailbox czy katalogów Maildir, ale tylko, gdy działają na tej samej maszynie co MDA. Częściej pojawia się tu serwer POP3 lub IMAP (lub jeszcze inny, np. jakieś groupware), pozwalający na zdalny odczyt wiadomości przez klientów poczty. Dla opisanej wyżej mechaniki przesyłania poczty nie ma to znaczenia, trzeba jedynie, by taki serwer szukał listów tam, gdzie MDA je umieścił (no, jeszcze by oba respektowały jakiś protokół obrony przed konfliktami przy równoczesnym dostępie do tych samych zasobów).

Po co nam poczta na VPS? I czego potrzebujemy?

Po co nam poczta na VPS? Przede wszystkim po to, by efektywnie wysyłać maile. Jakąkolwiek aplikację będziemy uruchamiać, zapewne będzie potrzebowała wysyłać jakieś przypomnienia, powiadomienia, linki rejestracyjne, ... A nawet gdy nie, mailem będzie dostarczanych wiele ważnych informacji administracyjnych.

Dla większości z tych zastosowań dałoby się używać zdalnego serwera SMTP. Nie jest to jednak szczególnie dobry pomysł - zdalne połączenie SMTP potrafi zająć sporo czasu. Co lepsze - kazać użytkownikowi, który wypełnił formularz, czekać aż aplikacja dogada się z - powiedzmy - gmailem i wyśle przy jego pomocy email, czy też błyskawicznie wrzucić email do lokalnego MTA i pozostawić mu wysyłkę (do zrobienia asynchronicznie)? Oczywiście to drugie. Dlatego z wyjątkiem specyficznych przypadków (jak konfigurowanie farmy maszyn z których jedna zostaje wydzielona do obsługi poczty) warto zainstalować serwer SMTP.

Musimy też pocztę odbierać - na choć jednej maszynie w ramach domeny. Absolutne minimum to obsługa adresów typu postmaster czy webmaster (także - abuse). Bardzo często przydadzą się także adresy aplikacyjne (choćby adres administratora naszej wspaniałej aplikacji, adres zwrotny wysyłanych emaili). Znowu - przyjmowanie maili zapewni nam ten sam serwer SMTP, który pomoże nam je wysyłać.

Co jeszce? Być może już nic. Zwłaszcza na małym VPS, najsensowniejszą metodą obsługi poczty jest po prostu przekierować ją (forward) na inny adres. Możemy np. skierować wszystkie maile do postmaster@supersajt.pl, webmaster@supersajt.pl i Jan.Kowalski@supersajt.pl na konto na gmailu, yahoo czy u dostawcy internetu.

Oczywiście zamiast supersajt.pl używamy właściwej nazwy domeny.

Jeśli powyższe nie wchodzi w rachubę, trzeba zainstalować i skonfigurować jakieś MDA i serwer umożliwiający czytanie maili.

Serwer SMTP

Żadnej egzotyki. Najlepszym serwerem SMTP jest obecnie Postfix, który także w konfiguracjach VPS sprawuje się bardzo dobrze.

Opisuję poniżej prostą, bazową konfigurację, nastawioną na wspomaganie wysyłania maili i przyjmowanie listów do jednego czy kilku odbiorców - czyli typowy scenariusz poczty wspomagającej aplikację webową. Na VPS można też zbudować poważniejsze serwery poczty, to jednak wykracza poza ramy tego cyklu.

Instalacja w ujęciu Debian/Ubuntu to

$ sudo apt-get install postfix

Może się też zdarzyć, że Postfix jest już zainstalowany, wtedy kluczowe parametry odświeżamy

$ sudo dpkg-reconfigure postfix

Prawidłowe odpowiedzi na kluczowe pytania:

1. General type of mail configuration - Internet Site (sami wysyłamy i odbieramy pocztę, inne możliwości to np. korzystanie z standardowego pośrednika).

2. System mail name - supersajt.pl (kanoniczna nazwa naszej domeny, używana w adresach na które przyjmujemy pocztę - tu będziemy używać kont typu Jan.Nowak@supersajt.pl).

3. Root and postmaster mail recipient - tadeusz (czyli nazwa naszego konta roboczego, na którym pracujemy).

4. Other destinations to accept mail for - supersajt.pl, www.supersajt.pl, localhost, ewentualnie jakaś inna nazwa subdomeny (są to adresy, które serwer będzie uznawał za nasze, tj. np. po dostaniu maila do Jan.Nowak@www.supersajt.pl przyjmie go zamiast próbować słać dalej).

5. Force synchronous updates on mail queue - No (chodzi o forsowanie mniej wydajnego ale bezpieczniejszego trybu dostępu do dysku, ryzyko utraty poczty jest bardzo nikłe, a narzut zauważalny).

6. Local networks - 127.0.0.0/8 111.112.113.114/32 (gdzie drugim z adresów jest IP naszej maszyny). Są to adresy maszyn, z których będzie dozwolone wysyłanie maili via nasz serwer, można to rozbudować np. o adres domowy, o ile także z niego będziemy chcieć słać pocztę via nasz VPS (tj. jeśli będziemy chcieli ustawić adres VPSa jako adres serwera SMTP w używanym w domu programie pocztowym). Trzeba tu być bardzo ostrożnym, by nie udostępnić serwera spamerom.

7. Use procmail for local delivery - Yes (ale patrz też niżej).

8. Mailbox size limit - 0.

9. Local address extension character - pusty napis (mechanizm raczej nie będzie nam potrzebny), ewentualnie domyślny +.

10. Internet protocols to use - ipv4 (ewentualna obsługa IP6 będzie wymagała większych zmian w konfiguracji maszyny).

Wszystkie te ustawienia (i parę innych) zostają zapisane w pliku /etc/postfix/main.cf. Jest to zwykły, czytelny plik konfiguracyjny, który można edytować ręcznie. Można też, jeśli ktoś woli, używać zamiast edytora polecenia postconf, np.:

$ sudo postconf -e 'inet_interfaces = all'

Po powyższych operacjach nasz system powinien już być w stanie wysyłać lokalnie nadaną pocztę. Możemy to przetestować np. tak:

$ sudo apt-get install mailx

$ mail Moj.Email@gdzies.indziej
Subject: Testowy mail

Blah blah

po czym naciskamy Ctrl-D i Enter. I sprawdzamy czy mail przyszedł na podane konto. Jeśli nie, interesujemy się plikami /var/log/mail.err, /var/log/mail.info i /var/log/mail.log.

Rekonfiguracja firewalla

O ile konfigurowaliśmy firewall według opisu z części pierwszej, musimy zrobić dziurkę umożliwiającą przyjmowanie poczty. Chodzi o linijkę:

SMTP/ACCEPT    all     fw

w /etc/shorewall/rules. Oraz uruchomienie

$ sudo /etc/init.d/shorewall restart

po jego dodaniu. Reguła musi pozwalać na połączenia zewsząd, bo zewsząd możemy dostawać maile.

Przyjmowanie poczty w najprostszym ujęciu - przekaż dalej

Jak już pisałem wyżej, najprostszym sposobem przyjmowania poczty na VPS jest przekazywanie jej dalej, na inny adres mailowy (konto na gmailu czy inne standardowo używane konto pocztowe). Ma to parę zalet:

• mamy mniej kont do sprawdzania,
• nie musimy instalować na VPS dość zasobożernych filtrów antyspamowych i antywirusowych (a także serwera POP3 czy IMAP),
• maile z powiadomieniami administracyjnymi lądują poza maszyną (ewentualny włamywacz ich nie skasuje, ewentualna awaria nie umożliwi odczytania).

Konfiguracja jest trywialna. Otwieramy plik /etc/aliases, który po konfiguracji zawiera coś w stylu:

postmaster:   root
root:         tadeusz

i zmieniamy go następująco:

postmaster:   root
root:         tadeusz
tadeusz:      TeddyBeddy@gmail.com

Po zakończeniu edycji robimy:

$ sudo newaliases
$ sudo /etc/init.d/postfix reload

Postfix nie czyta pliku /etc/aliases ale binarny plik /etc/aliases.db, polecenie newaliases tworzy ten drugi na bazie tego pierwszego. Jeśli zmodyfikujemy /etc/aliases ale zapomnimy o newaliases, Postfix nie dowie się o zmianach.

Ustawienia DNS

Do przyjmowania poczty potrzebujemy jeszcze poprawnego wpisu MX w konfiguracji dns. Przykład jest w części drugiej. Wpis ten ma następujące znaczenie: gdy jakiś serwer SMTP ma wysłać email do Jan.Kowalski@supersajt.pl, sprawdza jaki jest MX dla domeny supersajt.pl - po czym właśnie z tą maszyną się łączy i przekazuje jej maila.

W naszej sytuacji mamy tylko jedną maszynę, w większych konfiguracjach możemy wydelegować odbiór poczty do wydzielonego osobnego systemu, a nawet skonfigurować kilka MX-ów. Tak czy siak, nawet przy jednej maszynie doradzam stworzenie aliasu DNS typu mail.supersajt.pl albo poczta.supersajt.pl i ustawienie jego jako MX, ewentualna przyszła migracja będzie łatwiejsza.

Skoro już jesteśmy przy DNS - możemy rozważyć dopisanie dla naszej domeny rekordu SPF. Jest to jedna z form utrudniania życia spamerom, pozwala zadeklarować listę maszyn, które mogą legalnie wysyłać pocztę z adresem nadawcy ktoś@supersajt.pl, w ten sposób pozwalając wykryć przypadki, gdy ktoś fałszywie podaje nasz adres jako autora spamu.

Nie będę tu szczegółowo opisywał zasad działania SPF ani związanych z nim kontrowersji (patrz np. artykuł na wikipedii). Główne pytanie jakie musimy sobie zadać: z jakich maszyn możemy wysyłać pocztę ustawiając From na cokolwiek@supersajt.pl.

Oprócz samego VPS, możemy chcieć wysyłać takie maile także np. z domu, via serwer SMTP dostawcy internetu. Informację jakich serwerów użyaw można czasem zdobyć ... przy pomocy SPF. Na przykład:

$ dig -t TXT aster.pl

znajduje wpis

aster.pl.     86400   IN  TXT "v=spf1 ip4:212.76.33.23 ip4:212.76.33.39 ip4:212.76.33.47 ip4:212.76.33.55 ip4:212.76.33.58  ip4:212.76.39.221 ip4:212.76.32.12 ?all"

skąd wiemy, którędy poczta wychodzi z serwerów Astera.

Aby ustawić rekord SPF, wpisujemy do /etc/mararc/db.supersajt.pl linijkę podobną do:

supersajt.pl.  SPF 'v=spf1 a mx -all'

Powyższe pozwala wysyłać pocztę z maszyn posiadających nazwy - czyli rekordy A - w naszej domenie, oraz z maszyny ustawionej jako jej MX (nawet gdyby do niej nie należała). Bardziej rozbudowany przykład:

supersajt.pl.  SPF 'v=spf1 a mx ip4:111.112.113.114 ip4:201.112.113.0/24 -all'

jeszcze inny (wysyłka z naszego serwera i z gmaila):

supersajt.pl.  SPF 'v=spf1 a mx include:aspmx.googlemail.com -all'

Uwaga co do znaczków przed all. Minus to twarda odmowa (powoduje odrzucenie maili z niewłaściwych źródeł, oczywiście tylko przez serwery które SPF używają), tylda to miękka odmowa (często maile są przepuszczane ale otagowane jako potencjalny spam), a znak zapytania to brak informacji (maile przechodzą i są traktowane podobnie jak maile z domen bez SPF - co ma znaczenie głównie w scoringach antyspamowych).

Testować regułki SPF można programikiem spfquery, np.

$ spfquery --ip=10.11.12.13 \
           --sender=Jan.Kowalski@supersajt.pl \
           --helo=supersajt.pl

podając jako parametry adres IP maszyny wysyłającej mail, adres From i nazwę pocztową (/etc/mailname) wysyłającej maszyny. Trzeba to powtórzyć dla różnych miejsc, z których wysyłamy legalnie pocztę.

Testy

Możemy teraz spróbować wysłać pocztę z zewnątrz na VPS. Ze zwykłego konta pocztowego wysyłamy mail do tadeusz@supersajt.pl (albo może do postmaster@supersajt.pl). Po pewnym czasie powinien pojawić się na koncie, na które forwardujemy.

Uwagi użytkowe

Forwardowane maile mają zachowany oryginalny adres docelowy, co można wykorzystać przy filtrowaniu poczty na docelowym koncie (np. przy rozrzucaniu jej do folderów).

Przy odpisywaniu warto pamiętać o wyborze odpowiedniego From, a przynajmniej Reply-To. Przykładowo, gmail pozwala się skonfigurować tak, by przy odpowiadaniu zachowywać adres, na który przyszedł list.

Jeszcze raz uwaga na SPF! Jeśli wysyłamy jako jan@supersajt.pl pocztę z gmaila, nasza regułka SPF (o ile istnieje) powinna obejmować gmaila.

Czytelne adresy, standardowe aliasy

Plik /etc/aliases pozwala także definiować eleganckie adresy, jak Tadeusz.Kowalski@supersajt.pl czy Administrator@supersajt.pl. Dopisujemy je następująco:

Tadeusz.Kowalski:     tadeusz
Administrator:        tadeusz

Jest to rozwikływane na zasadzie łańcuszka. Gdy przychodzi mail do Administrator@supersajt.pl, serwer znajduje powyższe mapowanie na tadeusz i ... uruchamia proces dostarczania poczty do tadeusza od początku. Skoro tadeusz ma ustawiony forward, mail zostanie sforwardowany.

Przy okazji dopiszmy parę standardowych aliasów (adresów, które bywają przy takich czy innych okazjach przez ludzi bądź programy używane):

mailer-daemon: postmaster
hostmaster:    root
webmaster:     root
www:           root
abuse:         root
security:      root
logcheck:      root

Może się też przydać coś takiego:

AutoSender:    noreply
noreply:       /dev/null

Maile przysłane do noreply@supersajt.pl i AutoSender@supersajt.pl zostaną wyrzucone do kosza.

Na koniec jak zwykle:

$ sudo newaliases
$ sudo /etc/init.d/postfix reload

Są osoby, które - mając możliwość taką jak powyższa - dodają nowe aliasy dla niemal każdej sytuacji, gdy podają gdzieś w sieci swój email. Na przykład rejestrując się na - powiedzmy - Fotosiku dodają alias typu mikefoto, forwardowany na prawdziwy email i podają jako swój email mikefoto@supersajt.pl.

Główne zastosowanie do tropienie źródeł spamu, jeśli reklama nowych farmaceutyków porzyjdzie do mikefoto@supersajt.pl, wiadomo skąd wyciekł.

Podsumowanie

Przygotowaliśmy minimalną konfigurację poczty. Programy działające na naszym VPS będą mogły wysyłać maile, będziemy też mogli używać adresów z naszej domeny do przyjmowania poczty.

Nie wyczerpuje to jeszcze wszystkich zagadnień związanych z pocztą, do tematu wrócę w którymś z dalszych odcinków - ale do podstawowych zastosowań tyle wystarczy.

Ciąg dalszy nastąpił.