Powrót do strony głównej

Mailu w Kubernetes: konfiguracja serwera pocztowego dla deweloperów

Artykuł opisuje proces wdrażania serwera pocztowego Mailu w klastrze Kubernetes z użyciem Helm. Omówiono przygotowanie rekordów DNS, konfigurację polityk sieciowych, rozwiązywanie problemów z TLS oraz konfigurację DKIM, DMARC, SPF w celu zapewnienia dostarczania poczty.

Jak wdrożyć Mailu w Kubernetes: kompletny przewodnik
Advertisement 728x90

Wdrażanie serwera pocztowego Mailu w Kubernetes: praktyczny przewodnik

Mailu to skonteneryzowany serwer pocztowy, zoptymalizowany do pracy w środowiskach Docker i Kubernetes. W przeciwieństwie do tradycyjnych rozwiązań opartych na Postfix i Dovecot, jego wdrażanie wymaga minimalnego wysiłku w konfiguracji, co czyni go atrakcyjnym dla domowych laboratoriów i środowisk testowych. Niniejszy przewodnik opisuje proces instalacji Mailu w klastrze Kubernetes z użyciem Helm, konfiguracji polityk sieciowych, rekordów DNS i zapewnienia bezpieczeństwa.

Przygotowanie infrastruktury i DNS

Przed instalacją Mailu należy wykonać kilka obowiązkowych kroków przygotowawczych infrastruktury. Po pierwsze, wymagana jest domena z możliwością zarządzania rekordami DNS. Dla przykładu używa się domeny yourdomain.ru. Po drugie, potrzebny jest «biały» adres IP (np. 1.2.3.4), dla którego dostawca internetowy musi skonfigurować odwrotny (PTR) rekord. Bez PTR wiele usług pocztowych będzie odrzucać wiadomości jako spam.

Kluczowe rekordy DNS, które trzeba utworzyć:

Google AdInline article slot
  • Rekord typu A: mail.yourdomain.ru → 1.2.3.4
  • Rekord MX: @ → mail.yourdomain.ru

Po skonfigurowaniu DNS należy upewnić się, że polecenie nslookup 1.2.3.4 zwraca mail.yourdomain.ru. Potwierdzi to poprawność rekordu PTR.

Konfiguracja Kubernetes i wdrażanie Mailu

Dla izolacji serwera pocztowego i minimalizacji potencjalnych zagrożeń bezpieczeństwa zaleca się utworzenie osobnej przestrzeni nazw (namespace). W tym przykładzie używa się dmz-mailu. Natychmiast po utworzeniu przestrzeni nazw stosuje się politykę sieciową, która blokuje cały ruch przychodzący i wychodzący domyślnie, zezwalając tylko na niezbędne porty.

Przykład polityki sieciowej (network-policy-dmz-mail.yaml):

Google AdInline article slot
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-dmz-mailu-deny
  namespace: dmz-mailu
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-mailu-ports
  namespace: dmz-mailu
spec:
  podSelector: {}
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
      ports:
      - protocol: UDP
        port: 53
      - protocol: TCP
        port: 25
      - protocol: TCP
        port: 465

Następnie dodaje się repozytorium Mailu w Helm i przygotowuje plik values.yaml. Minimalna konfiguracja obejmuje ustawienia domeny, strefy czasowej, początkowego konta administratora, parametrów przechowywania i interfejsów sieciowych. Ważne jest prawidłowe określenie StorageClass, odpowiadającego Twojej infrastrukturze.

Główne parametry values.yaml:

  • hostnames: ["mail.yourdomain.ru"]
  • domain: yourdomain.ru
  • initialAccount dla stworzenia administratora
  • Ustawienia PostgreSQL lub MariaDB
  • Parametry persistence (np. size: 50Gi)
  • Konfiguracja Ingress z adnotacjami dla cert-manager
  • Ustawienia frontendu z typem LoadBalancer

Po skonfigurowaniu values.yaml wykonuje się instalację chartu:

Google AdInline article slot
helm install mailu mailu/mailu -n dmz-mailu --values mailu_values.yaml

Rozwiązywanie problemów z TLS i dodatkowa konfiguracja

Z powodu specyfiki pracy Mailu z TLS może wystąpić błąd SSL przy użyciu Ingress. Jako obejście proponuje się utworzenie oddzielnego Service typu LoadBalancer dla frontendu. Pozwala to na przeniesienie interfejsu webowego na osobny adres IP, unikając konfliktów z terminacją TLS na Ingress.

Przykład manifestu svc-mailu-front-web.yaml:

apiVersion: v1
kind: Service
metadata:
  name: svc-mailu-front-web
  namespace: dmz-mailu
spec:
  externalTrafficPolicy: Local
  ports:
  - port: 443
    protocol: TCP
    targetPort: 443
  selector:
    app.kubernetes.io/component: front
    app.kubernetes.io/instance: mailu
    app.kubernetes.io/name: mailu
  type: LoadBalancer
  loadBalancerIP: 192.168.10.201

Po zastosowaniu tego Service należy powiązać rekord mail-local.yourdomain.ru z odpowiednim adresem IP w lokalnym DNS lub pliku hosts. Również wymagane jest przekierowanie portu 25 z bramy sieciowej do loadBalancerIP, określonego w values.yaml, aby zapewnić odbiór przychodzącej poczty.

Konfiguracja DKIM, DMARC i SPF

Dla zapewnienia dostarczania wiadomości na zewnętrzne usługi pocztowe (takie jak Gmail lub Yandex.Poczta) konieczne jest skonfigurowanie DKIM, DMARC i SPF. Te mechanizmy uwierzytelniania pomagają potwierdzić legalność nadawcy i zmniejszają prawdopodobieństwo trafienia wiadomości do spamu.

Proces konfiguracji:

  • W interfejsie webowym administratora Mailu przejdź do sekcji AdministrationMail Domains → wybierz Twoją domenę → Edytuj.
  • Kliknij Generate Keys w prawym górnym rogu.
  • Skopiuj wygenerowane rekordy TXT dla DKIM, DMARC i SPF do DNS Twojej domeny.
  • Poczekaj na propagację rekordów DNS (może to zająć do 48 godzin).

Sprawdzić poprawność konfiguracji można za pomocą narzędzi takich jak mxtoolbox.com. Po udanej weryfikacji można testować wysyłanie wiadomości na zewnętrzne adresy. Pierwsze wiadomości mogą trafiać do folderu «Spam», więc zaleca się sprawdzanie niechcianej poczty.

Optymalizacja wydajności i bezpieczeństwa

Mailu obejmuje kilka dodatkowych komponentów, które można wyłączyć dla oszczędności zasobów lub uproszczenia konfiguracji. Na przykład, ClamAV (antywirus), OleTools (analizator plików biurowych) i Tika (przetwarzacz metadanych) nie są obowiązkowe dla podstawowej pracy serwera pocztowego. Można je wyłączyć w values.yaml, ustawiając odpowiednie parametry na false.

Zalecane ustawienia dla użytku domowego:

  • clamav: false
  • oletools: false
  • tika: false

Przy tym Rspamd (system filtracji spamu) powinien pozostać włączony, ponieważ przetwarza przychodzącą i wychodzącą pocztę.

Co jest ważne

  • Obecność rekordu PTR dla «białego» adresu IP jest krytycznie ważna dla dostarczania poczty.
  • Użycie oddzielnej przestrzeni nazw i polityk sieciowych zwiększa bezpieczeństwo wdrożenia.
  • Problemy z TLS między Ingress a Mailu można rozwiązać poprzez oddzielny Service typu LoadBalancer.
  • Konfiguracja DKIM, DMARC i SPF jest obowiązkowa dla wysyłania wiadomości na zewnętrzne usługi pocztowe.
  • Wyłączenie nieobowiązkowych komponentów (ClamAV, OleTools, Tika) zmniejsza zużycie zasobów.

— Editorial Team

Advertisement 728x90

Czytaj dalej