Raspberry Pi jako serwer poczty

Był już serwer wydruku, a teraz przyszedł czas na serwer poczty. Materiał ten jest podobny, do tego z wykorzystaniem BSD i bardzo starego serwera. Wykorzystałem go jako bazę, jednak nie wszystko zostało przeniesione 1:1 na Raspberry Pi.

Jak każdą pracę z wykorzystaniem RPI jako serwera czegoś, należy zacząć od przygotowania sobie czystego środowiska. Na kartę microSD nagrywamy obraz z systemem. Jeśli korzystamy z Linux-a to możemy użyć do tego polecenia dd.

$ sudo dd if=~/Downloads/2021-05-07-raspios-buster-armhf-lite.img bs=1M of=/dev/mmcblk0 status=progress

Instalowany system operacyjny to klasycznie RasPiOS. Po przegraniu systemu na kartę warto ustawić sobie możliwość zdalnego połączenia się przez SSH. Jeśli mamy już urządzenie gotowe do pracy to zaczynamy od:

Usunięcie domyślnego użytkownika i dodanie nowego, swojego
W systemach RasPiOS domyślnym użytkownikiem jest pi, a jego hasło raspberry do najtrudniejszych nie należy i najlepiej ze względów bezpieczeństwa pozbyć się tego użytkownika. Użytkownicy w przypadku przedstawionej tutaj konfiguracji serwera będą mapowani na użytkowników usług pocztowych, a pozostawienie niewykorzystanego konta z możliwością logowania, może stanowić potencjalną furtkę do systemu. Użytkownika pozbywamy się za pomocą polecenia deluser. Jednak przed jego usunięciem musimy stworzyć nowego użytkownika i nadać mu uprawnienia administracyjne, w przeciwnym wypadku zostalibyśmy bez zwykłego użytkownika, a co za tym idzie bez możliwości zdalnego logowania się na serwerze, chyba że pozwolimy na logowanie przez SSH użytkownika root, co jest jeszcze bardziej niebezpieczne niż pozostawienie użytkownika pi
```
pi@raspberrypi:~ $ sudo adduser xf0r3m
...
pi@raspberrypi: $ sudo usermod -aG sudo xf0r3m
# Przelogowanie się na nowego użytkownika.
xf0r3m@raspberrypi: $ sudo deluser pi
```
Aktualizacja systemu
Po pozbyciu się użytkownika pi, możemy przejeść do aktualizacji systemu.
```
$ sudo apt update
$ sudo apt upgrade
```
Opcjonalnie: zmiana nazwy hosta
Wypadałoby, aby host będący w domenie serwerem mailowym miał odpowienią nazwę, chociaż nie jest to wymagane.
```
$ sudo raspi-config
1 System Options -> S4 Hostname -> OK
```
Instalacja Postfix-a
Naszym serwerem protokołu SMTP będzie Postfix. Jest to chyba jedyny rzetelny, open sourcowy serwer SMTP, dostępny na UNIX-y, którego konfiguracja nie jest jakąś czarną magią.
```
$ sudo apt install postfix
```
Monit o konfiguracji Postfix-a w trakcie instalacji
Podczas instalacji Postfix-a, zostanie nam wyświetlone okno dialog-u na temat konfiguracji, wybieramy Strona internetowa/Internet site w polu do uzupełnienia wpisujemy nazwę swojej domeny.
Ustawienie opcji mydestination na nazwwę domeny
Niestety wybór opcji w oknie dialogowym i podanie odpowiedniej wartość nie załatwią poprawnej konfiguracji (takiej, która działa). Żeby serwer SMTP obsługiwał pocztę wewnątrz naszej organizacji, musimy ustawić w odpowiedniej opcji, że ten serwer jest jednym z serwerów obsługujących tą domenę.
```
$ sudo postconf -e "mydestination=example.com"
```
Sprawdzenie możliwości użycia Dovecot SASL
Przed wdrożeniem konkretnej implementacji mechanizmów uwierzytelniania musimy sprawdzić czy zainstalowana wersja Postfix-a jest z nią kompatybilna. Przedstawione tutaj czynności (całość materiału, konfiguracji) są tylko jednym ze sposobów. Możemy je dostosować do własnych potrzeb. Poniższe polecenie zwróci nam listę obsługiwanych implementacji uwierzytelniania.
```
$ sudo postconf -a
```
Polecenie na 99,9% zwróci dovecot, i to jest implementacja, która zostanie tutaj przedstawiona.
Instalacja dovecot
Instalacja dovecot, akurat w przypadku dystrybucji opartych na GNU/Linux Debian, nie jest wcale taka oczywista. Dovecot to kombajn, który zawiera masę usług, więc postanowiono go podzielić na pomniejsze pakiety zawierające tylko tą usługę, której nazwa jest zawarta w nazwie pakietu. Tak więc aby na RPI zainstalować dovecot mogący świadczyć usługi w organizacji potrzebujemy dwóch pakietów.
```
$ sudo apt dovecot-imapd dovecot-pop3d 
```
System uwierzytelniania SASL, zostanie zainstalowany wraz z pakietem dovecot-core, który jest zależnością dla powyższych pakietów, a te pakiety i tak będą nam potrzebne.
Uruchomienie uwierzytelniania dla Postfix-a
Tę czynność rozpoczniemy od konfiguracji dovecot-a, w pliku /etc/dovecot/conf.d/10-master.conf, w sekcji service auth włączamy - usuwając znaki komentarza, sekcję unix_listener /var/spool/postfix/private/auth wewnątrz tej sekcji zmieniamy wartość opcji mode na 0660 oraz dodajemy dwie opcje: user oraz group ustawione na wartość postfix. Już poza sekcją auth określamy rodzaje mechanizmów uwierzytelniania. Poniżej znajduje się listing przedstawiający poprawnie skonfigurowaną sekcję.
```
service auth {
...
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
...
}

auth_mechanisms = plain login
```
Po zapisaniu zmian, w kolejnym pliku /etc/postfix/main.cf dopisujemy poniższe opcje:
```
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_relay_restrictions = permit mynetworks, permit_sasl_authenticated, reject_unauth_destination
```
Te opcje wprowadzają restrykcje dla serwera SMTP nasłuchującego na porcie TCP/25. Tak, ten port musi być otwarty, w przeciwynym wypadku żaden mail z zewnątrz do nas nie dotrze. Użytkownicy poczty będą używać portu submission czyli TCP/587, ale maile przesyłane są między domenami (serwerami SMTP) przy użyciu portu TCP/25. Warto też dodać, że maile pomiędzy domenami przesyłane są zwykłym tekstem, dlatego też wiele osób stosuje szyfrowanie od końca do końca (ang. End-to-end encryption). Po zapisaniu tych ustawień możemy przejść do uruchomienia submission.

Uruchomienie submission dla połączeń klient-serwer SMTP

W pliku /etc/postfix/master.cf odnajdujemy wiersz tabeli zawierający napis submission, usuwamy poprzedzający go znak komentarza, następnie pod tym wierszem zapisujemy opcje z jakimi ma zostać uruchomiony.

submission  inet  n - y - - smtpd
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_sasl_type=dovecot
 -o smtpd_sasl_path=private/auth
 -o smtpd_sasl_security_options=noanonymous
 -o smtpd_sasl_local_domain=example.com
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 -o smtpd_sender_login_maps=hash:/etc/postfix/virtual
 -o smtpd_sender_restrictions=reject_sender_login_mismatch
 -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject

Restart Postfix-a
Teraz przyszedł czas na sprawdzenie poprawności wprowadzonych ustawień. Na początek uruchomimy ponownie Postfix-a.
```
$ sudo postfix reload
```
Jeśli teraz daemon nie zwróci żadnych komunikatów, to wszystko jest na dobrej drodze. Warto jeszcze zajrzeć do pliku /var/log/syslog.
Instalacja certyfikatów SSL organizacji dla SMTP
W pliku /etc/postfix/main.cf, odnajdujemy dwie opcje smtpd_tls_cert_file oraz smtpd_tls_cert_key. Tej pierwszej, jako wartość ustawiamy ścieżkę do pliku certyfikatu, a drugiej ścieżkę do pliku klucza certyfikatu.
```
smtpd_tls_cert_file=/etc/openssl/certs/fullchain1.pem
smtpd_tls_cert_key=/etc/openssl/private/privkey1.pem
```
Utworzenie bazy użytkowników usług pocztowych
Baza użytkowników jest zwykłym plikem tekstowym, w którym występują mapowania adresów e-mail organizacji na nazwy użytkowników systemu. W pliku każda linia to jedno mapowanie, a bazą użytkowników dla Postfix-a jest /etc/postfix/virtual. Po zapisaniu zmian plik ten należy dostosować za pomocą polecnia dostarczanego wraz z Postfix-em, aby był dla niego czytelny. Za każdym dodanie mapowania baza będzie wymagała konwersji.
```
/etc/postfix/virtual:
root@example.com  root
xf0r3m@example.com  xf0r3m

$ sudo postmap /etc/postfix/virtual
```
Po skonwertowaniu bazy, należy zrestartować Postfix-a.
```
$ sudo postfix reload
```
Włączenie SSL w Dovecot
Za pomocą protokołów IMAP oraz POP3 użytkownicy będą pobierać maile z serwera, aby zabezpieczyć komunikację pomiędzy klientem a serwerem tak jak zrobiliśmy to z protkołem SMTP tu również użyjemy certyfikatów SSL. W /etc/dovecot/ssl/10-ssl.conf ustawiamy ścieżki do plików certyfikatu.

Jeśli przed opcją ssl znajduje się znak komentarza, to należy go usunąć.

A pliki certyfikatu ustawiane są w opcjach ssl_cert - dla pliku certyfikatu i ssl_key - dla pliku klucza prywatnego certyfikatu.
```
ssl_cert=</etc/openssl/certs/fullchain1.pem
ssl_key=</etc/openssl/private/privkey1.pem
```
Uwaga! Ostre nawiasy są cześcią składni wartości opcji.
Uruchomienie IMAPS i POP3S
Po ustawieniu SSL dla usług dovecot, przyszedł czas aby je włączyć. W pliku /etc/dovecot/conf.d/10-master.conf musimy odnaleźć dwie sekcje: inet_listener imaps oraz inet_listener pop3s, w tych sekcjach dopisujemy dwie opcje: port wskazującą na numer portu usługi oraz opcje ssl uruchamiającą szyfrowaną transmisję dla połączeń z tym serwerem. Te opcje oczywiście o innych portach ustawiamy w obu wymienionych sekcjach.
```
...
inet_listener imaps {
  port = 993
  ssl = yes
}

...
inet_listener pop3s {
  port = 995
  ssl = yes
}
```
Restart dovecot
Po wdrożeniu ostatnich zmian, trzeba zrestartować usługę aby zmiany zostały uzwględnione przez działającego daemona.
```
$ sudo dovecot reload
```
Sprawdzenie poprawności działania serwera za pomocą Thunderbirda
W internecie jest bardzo dużo dostępnych klientów pocztowych różnej maści. Jednak tutaj będzie zależało nam na prostocie konfiguracji, dlatego do celów testowych wybierzemy Thunderbirda.

Tworząc nowe konto pocztowe, w początkowych polach podajemy nazwę, adres e-mail oraz hasło. Na dole okna klikamy przycisk ręcznej konfiguracji. Następnie uzupełniamy pola, tak jak opisano to poniżej

Konfiguracja serwera poczty wychodzącej:
- Protokół: SMTP
- Serwer: mail.example.com
- Port: 587
- SSL: STARTTLS
- Uwierzytelnianie: Normalne hasło
- Nazwa użytkownika: Nazwa użytkownika (systemowa z serwera mailowego)
Konfiguracja serwera poczty przychodzącej:
- Protokół: IMAP/POP3
- Serwer: mail.example.com
- Port: 993/995
- SSL: SSL/TLS
- Uwierzytelnianie: Normalne hasło
- Nazwa użytkownika: Nazwa użytkownika (systemowa z serwera mailowego)
Po zatwierdzeniu będziemy mieć już gotową skrzynkę. W celach testowych wyślijmy maila z załącznikiem (serwer nie przepuści wiadomości większej niż 10MB) do siebie. Powinna wysłać się bez problemu i od razu pojawić się w skrzynce.

Jeśli chodzi o pracę tego typu rozwiązania w jakieś konkretnej organizacji, to zostało jeszcze wiele pracy. Większość skrzynek pocztowych będzie traktować maile wysłane z tego serwera jako SPAM. Jeśli odpowiemy na maila, to trafi on automatycznie do skrzynki odbiorczej jako kontynuacja wątku. To rozwiązanie w takiej postaci może sprawdzić się w korespondencji wewnętrznej.

Jeśli ktoś jest spragniony testowania tego rozwiązania, to w materiale na podbny temat w sekcji "bsd" znajduje się więcej informacji. W tym materiale znajduje się konfiguracja programu MUTT dla usług pocztowych tego typu. Link poniżej:

https://morketsmerke.net/site/articles/bsd/20_letni_Sun_Netra_T1_jako_serwer_mailowy_z_wykorzystaniem_NetBSD.html

~xf0r3m