K-NET s.c.

Mailcow – instalacja i aktualizacja serwera poczty w Dockerze

Mailcow to jedno z ciekawszych rozwiązań dla osób, które chcą uruchomić własny serwer poczty bez ręcznego składania Postfixa, Dovecota, Rspamd, SOGo, antywirusa, webmaila i całej reszty usług. Wszystko działa w kontenerach Dockera, a administracja odbywa się z poziomu wygodnego panelu WWW.

W tym artykule pokażę praktyczną instalację Mailcow na serwerze Linux z Dockerem oraz bezpieczną procedurę aktualizacji. Nie będzie to opis „kliknij i zapomnij”, bo serwer poczty wymaga poprawnego DNS, portów, certyfikatów i kopii zapasowych. Będzie za to prosta checklista, która pozwala uniknąć typowych błędów.

W artykule pokażę:

• co sprawdzić przed instalacją Mailcow,
• jak przygotować system i Dockera,
• jak pobrać i uruchomić Mailcow,
• jakie rekordy DNS są potrzebne,
• jak zrobić backup,
• jak bezpiecznie wykonać aktualizację.

Uwaga: własny serwer poczty to nie tylko kontener Docker. Najważniejsze są: poprawny DNS, rekord PTR, otwarty port 25, reputacja adresu IP oraz regularne aktualizacje.

Dlaczego Mailcow?

Mailcow jest wygodny, bo zbiera w jednym projekcie większość elementów potrzebnych do uruchomienia pełnego serwera poczty. W praktyce dostajemy gotowy zestaw usług: SMTP, IMAP, webmail, filtrowanie spamu, obsługę domen, skrzynek, aliasów, certyfikatów oraz panel administracyjny.

Dla małej firmy, laboratorium, homelabu albo środowiska testowego jest to dużo prostsze niż ręczna konfiguracja każdego komponentu osobno. Nadal jednak trzeba pamiętać, że poczta elektroniczna jest wrażliwa na błędy konfiguracyjne. Źle ustawiony DNS albo zablokowany port 25 potrafi sprawić, że technicznie wszystko działa, ale poczta nie dochodzi albo trafia do spamu.

Zanim zaczniesz

Przed instalacją warto przygotować kilka rzeczy:

• serwer VPS lub maszynę wirtualną z publicznym adresem IP,
• pełną wirtualizację, np. KVM, ESXi, Hyper-V lub podobne rozwiązanie,
• system Debian albo Ubuntu,
• minimum 6 GB RAM oraz dodatkowy swap,
• wolne porty usług pocztowych i WWW,
• domenę, którą będziesz obsługiwać w Mailcow,
• możliwość ustawienia rekordu PTR/reverse DNS u operatora serwera.

Ważne: Mailcow nie powinien być uruchamiany w LXC/OpenVZ. To rozwiązanie najlepiej traktować jako usługę dla normalnej maszyny wirtualnej lub serwera fizycznego.

Porty, które muszą być wolne

Na początku sprawdź, czy na serwerze nie działa już inny serwer WWW albo inny MTA, np. Exim, Postfix z systemu albo stary kontener pocztowy.

ss -tlpn | grep -E -w '25|80|110|143|443|465|587|993|995|4190'

Najważniejsze porty dla Mailcow to:

• 25/tcp – SMTP, odbieranie poczty z Internetu,
• 465/tcp – SMTPS,
• 587/tcp – Submission, wysyłka poczty przez użytkowników,
• 143/tcp i 993/tcp – IMAP i IMAPS,
• 110/tcp i 995/tcp – POP3 i POP3S,
• 4190/tcp – ManageSieve,
• 80/tcp i 443/tcp – panel WWW, webmail i certyfikaty.

Jeżeli któryś z tych portów jest już zajęty, instalacja może się uruchomić częściowo albo zakończyć błędem. Warto rozwiązać ten problem przed startem kontenerów, a nie dopiero po fakcie.

DNS – najważniejszy element całej instalacji

Dla przykładu przyjmijmy, że serwer Mailcow będzie działał pod adresem:

mail.example.pl

Minimalnie warto przygotować:

• rekord A dla mail.example.pl wskazujący na publiczny adres IPv4 serwera,
• opcjonalnie rekord AAAA, jeśli używasz IPv6,
• rekord MX domeny wskazujący na mail.example.pl,
• rekord PTR dla adresu IP, również wskazujący na mail.example.pl,
• rekordy SPF, DKIM i DMARC – część z nich Mailcow podpowie po dodaniu domeny w panelu.

Praktyczna rada: bez poprawnego PTR poczta może działać technicznie, ale z dużym ryzykiem problemów z dostarczalnością. W przypadku VPS rekord PTR zwykle ustawia się w panelu operatora.

Instalacja Mailcow krok po kroku

Krok 1: Aktualizacja systemu

Na początku aktualizujemy system i instalujemy podstawowe narzędzia wymagane przez instalator.

apt update
apt upgrade -y
apt install -y git openssl curl gawk coreutils grep jq

Krok 2: Instalacja Dockera

Mailcow zaleca używanie aktualnego Dockera, a nie bardzo starej wersji z repozytorium dystrybucji. Najprostsza metoda instalacji na Debianie/Ubuntu wygląda tak:

curl -sSL https://get.docker.com/ | CHANNEL=stable sh
systemctl enable --now docker

Po instalacji sprawdź wersję:

docker version

Krok 3: Instalacja Docker Compose jako plugin

W nowych instalacjach najwygodniej używać składni docker compose, czyli bez myślnika.

apt update
apt install -y docker-compose-plugin

Sprawdzenie wersji:

docker compose version

Krok 4: Pobranie Mailcow

Przechodzimy do katalogu /opt, pobieramy oficjalne repozytorium i uruchamiamy generator konfiguracji.

cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
./generate_config.sh

Podczas generowania konfiguracji podaj pełną nazwę hosta, np.:

mail.example.pl

Po wygenerowaniu konfiguracji warto zajrzeć do pliku:

nano mailcow.conf

Na tym etapie można sprawdzić m.in. nazwę hosta, ustawienia IPv6, porty oraz ewentualne dodatkowe parametry.

Krok 5: Uruchomienie Mailcow

Gdy konfiguracja jest gotowa, pobieramy obrazy i uruchamiamy kontenery:

docker compose pull
docker compose up -d

Pierwsze pobieranie obrazów może potrwać dłuższą chwilę. Po starcie sprawdź stan kontenerów:

docker compose ps

Logi można podejrzeć poleceniem:

docker compose logs --tail=100

Pierwsze logowanie

Panel administracyjny powinien być dostępny pod adresem:

https://mail.example.pl/admin

Domyślne dane logowania to:

login: admin
hasło: moohoo

Uwaga: hasło administratora należy zmienić od razu po pierwszym logowaniu. Warto też włączyć dodatkowe zabezpieczenia konta administracyjnego.

Dodanie domeny i rekordów DNS

Po zalogowaniu dodaj domenę pocztową, np. example.pl. Mailcow podpowie rekordy DNS, które należy ustawić u operatora domeny. Szczególnie ważne są:

• MX – wskazanie serwera poczty,
• SPF – informacja, kto może wysyłać pocztę z domeny,
• DKIM – podpisywanie poczty kluczem domeny,
• DMARC – polityka obsługi wiadomości, które nie przejdą SPF/DKIM.

Po zmianach DNS trzeba odczekać na propagację rekordów. W praktyce część zmian działa po kilku minutach, ale pełna propagacja może potrwać dłużej.

Backup Mailcow

Przed każdą większą zmianą i przed aktualizacją warto wykonać backup. Mailcow dostarcza do tego gotowy skrypt:

cd /opt/mailcow-dockerized
./helper-scripts/backup_and_restore.sh backup all --delete-days 14

Można też wskazać katalog backupu przez zmienną środowiskową:

MAILCOW_BACKUP_LOCATION=/mnt/backup/mailcow \
./helper-scripts/backup_and_restore.sh backup all --delete-days 14

W środowisku produkcyjnym warto dodatkowo wykonywać snapshot maszyny wirtualnej albo kopię katalogów na zewnętrzny system backupu. Sam fakt, że usługa działa w Dockerze, nie zastępuje kopii zapasowej.

Moja zasada: najpierw backup, potem aktualizacja. Nigdy odwrotnie.

Aktualizacja Mailcow

Aktualizacja Mailcow jest bardzo prosta, ale nie należy jej wykonywać „w ciemno”. Najpierw warto sprawdzić, czy aktualizacja jest dostępna:

cd /opt/mailcow-dockerized
./update.sh --check

Jeżeli wszystko wygląda poprawnie, wykonujemy backup:

./helper-scripts/backup_and_restore.sh backup all --delete-days 14

Dopiero po backupie uruchamiamy właściwą aktualizację:

./update.sh

Skrypt sam pobierze zmiany, obrazy kontenerów i w razie potrzeby zada dodatkowe pytania. Po aktualizacji sprawdzamy stan usług:

docker compose ps
docker compose logs --tail=100

Jeżeli chcesz tylko posprzątać stare obrazy po aktualizacjach, można użyć:

./update.sh --gc

Co sprawdzić po aktualizacji?

Po aktualizacji warto wykonać krótką checklistę:

• czy wszystkie kontenery są uruchomione,
• czy panel administracyjny działa,
• czy webmail SOGo działa,
• czy można wysłać wiadomość na zewnątrz,
• czy można odebrać wiadomość z zewnątrz,
• czy certyfikat TLS jest poprawny,
• czy w logach nie ma powtarzających się błędów.

Przydatne polecenia:

docker compose ps
docker compose logs --tail=200 -f
ss -tlpn | grep -E -w '25|80|110|143|443|465|587|993|995|4190'

Najczęstsze problemy

Port 25 jest zablokowany

To jeden z najczęstszych problemów. Wielu operatorów VPS blokuje port 25 wychodzący lub przychodzący, szczególnie na nowych kontach. Bez portu 25 serwer poczty nie będzie poprawnie wymieniał wiadomości z Internetem.

Brak rekordu PTR

Jeżeli adres IP nie ma poprawnego reverse DNS, część serwerów może odrzucać pocztę albo traktować ją jako podejrzaną. PTR powinien wskazywać na nazwę hosta Mailcow, np. mail.example.pl.

Inna usługa zajmuje port 80 lub 443

Jeżeli na serwerze działa już Apache, Nginx albo inny reverse proxy, Mailcow może nie wystartować poprawnie. Wtedy trzeba zdecydować, czy Mailcow ma używać tych portów bezpośrednio, czy ma działać za istniejącym reverse proxy.

Instalacja w LXC

Mailcow nie jest dobrym kandydatem do LXC. Jeżeli używasz Proxmoxa, najbezpieczniej przygotować normalną maszynę wirtualną, a nie kontener LXC.

Brak backupu przed aktualizacją

Aktualizacja zwykle przebiega bezproblemowo, ale serwer poczty przechowuje ważne dane: skrzynki, konfigurację domen, klucze DKIM, bazę SQL, Redis, ustawienia Rspamd. Backup przed aktualizacją powinien być standardem.

Podsumowanie

Mailcow bardzo ułatwia uruchomienie własnego serwera poczty, bo większość trudnych elementów jest gotowa w jednym projekcie. Nie zwalnia to jednak administratora z myślenia o DNS, portach, certyfikatach, backupach i aktualizacjach.

Najbezpieczniejsza procedura wygląda tak:

1. przygotuj poprawny DNS i PTR,
2. sprawdź porty,
3. zainstaluj aktualnego Dockera i Docker Compose,
4. wygeneruj konfigurację Mailcow,
5. uruchom kontenery,
6. dodaj domenę i rekordy SPF/DKIM/DMARC,
7. regularnie wykonuj backup,
8. aktualizuj przez ./update.sh.

Mailcow jest świetnym narzędziem, ale wymaga porządku administracyjnego. Jeśli potraktujesz go jak normalną usługę produkcyjną, z backupem i checklistą aktualizacji, potrafi odwdzięczyć się stabilną pracą.

Twoja kolej

Masz własne doświadczenia z Mailcow? Udało Ci się uruchomić go w homelabie, firmie albo na VPS? A może największym problemem okazał się DNS, port 25 albo reputacja adresu IP?

Daj znać w komentarzu. Takie praktyczne uwagi są często bardziej wartościowe niż sama dokumentacja.

G

Tagi: Docker, e-mail, Linux, serwer, webmail

Microsoft Exchange – kopia zapasowa skrzynki w formacie MSG

Wykonywanie kopii zapasowych serwera Microsoft Exchange 2010 jest zagadnieniem dobrze znanym, szeroko opisywanym i wydawać by się mogło, że nie można już nic więcej zaproponować w tej dziedzinie. Jeśli jednak nie mamy uprawnień administratora serwera, dysponujemy tylko klientem Outlook a chielibyśmy robić regularnie kopie swojej skrzynki to, jak się okazuje, oferta aplikacji jest dość skromna. Mowa tu, rzecz jasna, o sytuacji gdy nie dysponujemy lokalna kopią PST a korzystamy wyłącznie zdalnie z zasobów sieciowych (de facto oznacza to korzystanie z pliku OST – kopii offline). Można zawsze robić ręcznie kopie korzystając z funkcji eksport do pliku PST lub nieco zautmatyzować proces korzystając np. z AutoIt. Jest to jednak trudne ze względu na niestandardowy interfejs Outlooka.

Stojąc przed opisywanym problemem założyłem, że chciałbym wykorzystać harmonogram zadań systemowych oraz tekstowy skrypt wsadowy BAT lub CMD (do tego niekoniecznie wykorzystujący np. PowerShell). Czyli coś co wydawać by się mogło nierealne. A jednak nie do końca.

Poszukując aplikacji, która spełniałaby założenia trafiłem na ReliefJet Essentials for Outlook. Czemu jest ona wyjątkowa? Ponieważ oprócz interfejsu graficznego posiada tryb pracy wsadowej. Co więcej, najpierw można przygotować np. kopie zapasowe korzystając z okienek konfiguracyjnych a potem skorzystać z ikonki Show command line, żeby zobaczyć jak będzie wyglądać odpowiednia komenda systemowa.

ExecutorCli.exe /u OutlookFolderBackup ↵
Profile=nazwa_konta For="\\nazwa_skrzynki*" ↵ 
IgnoreErrors=True TargetDir=C:\TEMP\ ↵
StartDate="2015-01-01 00:00:00.000" ↵
Report=C:\TEMP\raport.csv

Powyższa komenda umożliwia przygotowanie kopii skrzynki współdzielonej przy użyciu wybranego profilu Outlooka. Możemy ponadto określić od jakiej daty zostanie ona wykonana oraz przygotować raport końcowy.

Możliwości aplikacji są dużo większe i myślę, że naprawde warto zapoznać się z tym produktem.

MG

Tagi: e-mail, MS Exchange, poczta elektroniczna, Windows

Konfiguracja pakietu vacation dla konta z aliasami pocztowymi

Włączanie autoodpowiedzi w czasie urlopu stało się obecnie praktyką powszechną. Większość największych systemów pocztowych oferuje taką funkcję. Co mają jednak zrobić administratorzy dedykowanych serwerów pocztowych, przygotowanych na potrzeby własne lub firmy? Jeśli korzystają z Linuksa, który jest bardzo wygodnym i elastycznym systemem operacyjnym dla serwera poczty, na pewno prędzej czy później trafią na pakiet vacation. Nie chcę się w tym momencie skupiać na jego konfiguracji, gdyż jest ona dosyć prosta, dobrze opisana oraz podparta szczegółowymi przykładami dostępnymi w sieci. Chciałbym natomiast omówić jeden z przypadków konfiguracji, z którym ostatnio się zetknąłem.

Zawyczaj użytkownicy serwera pocztowego korzystają z jednej nazwy konta pocztowego. Jednak czasami trzeba administrować w środowisku, nazwijmy to hmm… mocno eksperymentalnym, gdzie użytkownicy potrafią zażądać 2, 3 i więcej aliasów. Pakiet vacation standardowy obsłuży tylko jeden. Co zrobić aby można było ustawić automatyczną odpowiedź dla kilku aliasów przypisanych do jednego użykownika? W przypadku konfiguracji w wykorzystaniem pliku .forward trzeba skorzystać z opcji – a, która oznacza nie mniej, nie więcej jak odpowiadaj także na wiadomości dla aliasów konta pocztowego. Przykładowy wpis dla dwóch dodatkowych aliasów w pliku .forward będzie miał postać:

\nazwa_konta, "|/usr/bin/vacation -a alias1 alias2 nazwa_konta"

Rzecz jasna nie odkryłem tutaj Ameryki, wszystko jest opisane na stronach man, ale z drugiej strony kto czyta manuale…

MG

 

Tagi: Debian, e-mail, Linux, poczta elektroniczna, polecenia

Odnowienie certyfikatu SSL w serwerze MS Exchange 2010

Każdy kto instalował i konfigurował serwer MS Exchange wie, że jednym z jego komponentów jest dostęp do skrzynek pocztowych przez przeglądarkę (tzw. OWA – Outlook Web Access). Jak każda tego typu komunikacja OWA powinno być zabezpieczone, najczęściej za pomocą protokołu HTTPS. Żeby zrealizować takie rozwiązanie trzeba zainstalować certyfikat SSL. Standardowa procedura zakłada wygenerowanie żądania, przesłanie go do wystawcy certyfikatu, w efekcie zaś otrzymanie samego pliku z certyfikatem. Co jednak zrobić jeśli tylko odnawiamy certyfikat? Czy standardowa procedura jest konieczna?

W przypadku odnowienia certyfikatu, który podpisany został przez tego samego, zaufanego wydawcę, możemy spokojnie pominąć typową, szeroko opisywaną w Internecie, procedurę. Ponieważ podczas instalacji OWA wymagany jest serwer IIS (Internet Information Server), tak naprawdę wystarczy dokonać zmian w konfiguracji tego ostatniego.

Na początek uruchamiamy menadżera IIS (’IIS Manager’). W lewym okienku aplikacji wybieramy definicje swojego serwera (poniżej opcji 'Start Page’) i w środkowej sekcji wybieramy certyfikaty serwera (’Server Certificates’). Po prawej stronie, z dostępnych opcji wybieramy Complete Certificate Request…. Po uruchomieniu okna Wizard, wskazujemy plik z certyfikatem (uwaga – domyślne rozszerzenie nie jest wymagane). Wybieramy również przyjazną nazwę, inaczej alias. Po zakończeniu czynności, program wyświetli monit Complete Certificate Request. W tym momencie potwierdzamy (OK) komunikat i przechodzimy dalej.

Tym razem rozwijamy drzewko po lewej stronie i wśród dostępnych serwerów wybieramy właściwy, podświetlając jego nazwe. Najczęściej będzie to Default Web Site. W tym momencie konieczne jest zatrzymanie usługi IIS (serwera). Po prawej stronie w sekcji Edit Site wybieramy opcje Bindings…. W okienku konfiguracyjnym, które pojawi się na środku ekranu, wybieramy https, następnie zaś, w kolejnym okienku, z rozwijanej listy wybieramy nowy certyfikat (zainstalowany w poprzednim kroku). Uruchamiamy usługę IIS. W tym momencie zakończyliśmy instalację certyfikatu SSL dla naszego OWA.

MG

Tagi: e-mail, MS Exchange, poczta elektroniczna, Windows

Listy dystrybucyjne i procmail

Powszechne narzekanie na ilość zalewającego nas spamu stało się banałem. Automaty rozsyłające niechciane wiadomości działają nieustannie, dość skutecznie zalewając skrzynki pocztowe. Istnieje wiele metod walki z opisywanym zjawiskiem. Ja jednak chciałem skupić się na wybranym przypadku. W większości firm istnieją adresy zbiorowe, za pomocą których tworzy się proste listy dystrybucyjne,  np.  wysłanie wiadomości na adres „biuro@firma.com” powoduje automatyczne rozesłanie jej do kilku adresatów. Nie trzeba długo się zastanawiać aby dojść do wniosku, że taki adres może również ułatwiać rozsyłanie spamu! Co zrobić aby zabezpieczyć się przed tym zjawiskiem? Poniżej zamieściłem opis dość prostej i skutecznej metody.

Przede wszystkim zakładam, że na serwerze zainstalowany jest pakiet procmail, który umożliwi przetwarzanie przychodzących wiadomości. Na temat pisania reguł dla procmaila można znaleźć dużo materiałów w sieci  np. tutaj. Nadaje się do wielu zadań i pozwola naprawdę dodać nowe funkcje do serwera poczty sam nie będąc jego integralną częścią. Ale do rzeczy. Żeby zabezpieczyć adres zbiorowy tworzymy w katalogu domowym dla konta „biuro” (kontynuując przykład z pierwszego akapitu) plik „.procmailrc”

touch .procmailrc

Następnie umieszczamy w nim mniej więcej taką zawartość:

LOGFILE=$HOME/.procmail_log
:0
# Przepuszczaj wiadomosci jesli pole nadawca zawiera ciąg @firma.com.
* ^From:.*@firma\.com
# Odfiltruj wiadomosci od daemona.
* ! ^FROM_DAEMON
# Odfiltruj wiadomosci zapetlone.
* ! ^X-Loop: EFa1bie2reifiuXeiveizae2
{
  :0fwh
  # Stempluj naglowek kazdej przetwarzanej wiadomosci.
  | formail -A"X-Loop: EFa1bie2reifiuXeiveizae2"
  :0
  # Wyslij wiadomosc na adresy pobrane z pliku ".lista".
  !`cat .lista`
}
:0
# Cala reszte przekieruj w kosmos!
/dev/null

A teraz po kolei. Przede wszystkim ograniczamy zbiór nadawców do tych, którzy mają w polu „Nadawca” ustawione „@firma.com„. Oczywiście spamerzy również mogą podszyć się pod ten adres  (zmiana wartości pola „Nadawca” jest łatwa). Jednak z mojego doświadczenia wynika, że to proste ograniczenie pozwala znacznie ograniczyć ruch. Pozostałe wiadomości odrzucamy przekierowując  je na „/dev/null”.

Wiadomość, która spełnia podstawowy warunek zostanie przetworzona. Zanim jednak tak się stanie dobrze jest sprawdzić 2 warunki:

• Czy nie jest to przypadkiem wiadomość od daemona systemowego. Bardzo pożyteczny warunek w sytuacji gdy dystrybuujemy wiadomość na konto, które nie istnieje (np. administrator usunał je bez poinformowania nas o tym). Zabezpiecza przed zapętleniem wiadomości.

• Czy nie jest to wiadomość zapętlona. Np. użytkownik docelowy ustawił sobie autoodpowiedź, wówczas będzie automatycznie odpowiadał na wiadomość z listy dystrybucyjnej (rozsyłając tym samym autoodpowiedź do wszystkich jej odbiorców). Lista z kolei będzie odsyłać ją z powrotem i tak w kółko. Warto zwrócić uwagę, że aby sprawdzić czy wiadomość nie była już raz przetwarzana (czyt. jest zapętlona) trzeba ją oznaczyć stemplem w nagłówku.

Jeżeli wymienione warunki zostały spełnione, możemy z czystym sumieniem rozesłać wiadomość do użytkowników wymienionych w pliku „.lista”, która przykładowo ma postać:

user1@firma.com
user2@firma2.com
user3@firma3.com

MAG

Tagi: e-mail, Linux, poczta elektroniczna, Procmail