↓ Zum Hauptinhalt springen
Zyria
  1. Beiträge/
  2. Kleines Homelab/
  3. k3s-prod: Kubernetes Cluster Konfiguration und Anwendungsbereitstellung/

Mailstack

··3036 Wörter· ·
K3s-Prod Kubernetes Mail Postfix Dovecot
Inhaltsverzeichnis

Mailstack
#

Quelle
#

Kein eigenes Chart, sondern ein Verbund aus zwei Quellen:

Chart Herkunft Zweck
app-template BJW-S Labs Alle Mail-Komponenten als Container eines Verbunds
redis oci://registry-1.docker.io/bitnamicharts Ablage für Rspamd

Die Container-Images stammen aus den eigenen Repositories (postfix-docker, dovecot-docker, rspamd-docker, unbound-docker) und werden über Docker Hub beziehungsweise die Registry der Forgejo-Instanz bezogen.

Dokumentation
#

Die Konfiguration basiert auf dem Mailu Projekt, wurde aber stark angepasst. Die Dokumentation der einzelnen Komponenten (Postfix, Dovecot, etc.) ist auf deren jeweiligen Projekt-Webseiten zu finden.

Funktion
#

Der Mailstack ist für den gesamten E-Mail-Verkehr der gehosteten Domains zuständig. Er besteht aus mehreren ineinandergreifenden Diensten:

  • Postfix: Der Mail Transfer Agent (MTA), der E-Mails über SMTP empfängt und versendet.
  • Dovecot: Der Mail Delivery Agent (MDA), der E-Mails in den Postfächern der Benutzer ablegt und den Zugriff über IMAP ermöglicht. Dient auch zur SASL-Authentifizierung für Postfix.
  • Rspamd: Ein fortschrittliches Spam-Filtersystem. Es prüft eingehende E-Mails auf Spam-Merkmale, signiert ausgehende E-Mails mit DKIM und stellt eine Weboberfläche zur Verwaltung bereit.
  • ClamAV: Ein Virenscanner, der E-Mail-Anhänge auf Malware überprüft.
  • Unbound: Ein lokaler DNS-Resolver, der für DNS-Abfragen (z.B. für RBLs) verwendet wird.
  • Redis: Dient als schneller Cache und Speicher für Rspamd.

Lokale Anpassungen
#

Die Konfiguration ist sehr umfangreich und erfolgt über die values.yaml-Datei, sowie diverse ConfigMaps und Secrets.

Wichtige Einstellungen
#

  • LoadBalancer: Die Mail-Ports (SMTP, IMAP) werden über einen LoadBalancer-Service mit einer dedizierten externen IP-Adresse bereitgestellt.
  • Ingress: Die Weboberflächen von Rspamd und dem Autodiscover-Dienst sind über Ingresses erreichbar. Der Zugriff auf Rspamd ist durch Authentik geschützt.
  • LDAP-Integration: Postfix und Dovecot sind mit einem LDAP-Server integriert, um Benutzer, Aliase und Weiterleitungen zu verwalten.
  • Speicher: Alle persistenten Daten (Mail-Speicher, Konfigurationen, Rspamd-Daten) liegen auf Longhorn-Volumes. Die PVs tragen persistentVolumeReclaimPolicy: Retain — ein gelöschtes PVC nimmt den Mail-Speicher also nicht mit.
  • Sicherheit: Ausgehende E-Mails werden mit DKIM signiert und es wird MTA-STS für eine sichere E-Mail-Zustellung verwendet.

Installation
#

Die Anwendung wird mittels Kustomize und Helm durch ArgoCD im Kubernetes-Cluster bereitgestellt. Die Konfiguration befindet sich im apps/mailstack-Verzeichnis. Eine manuelle Installation kann mit folgendem Befehl durchgeführt werden:

1kubectl kustomize --enable-helm apps/mailstack | kubectl apply -n mailstack -f -

Abhängigkeiten
#

  • LDAP-Server: Ein externer LDAP-Server wird für die Benutzerverwaltung benötigt.
  • Traefik: Wird als Ingress-Controller für den externen Zugriff auf die Web-UIs benötigt.
  • Metallb: Wird benötigt, um dem Mail-Service eine externe IP-Adresse zuzuweisen.
  • Longhorn: Storage-Provider für alle persistenten Volumes.
  • Authentik: Wird zur Absicherung der Rspamd-Weboberfläche verwendet.

Nutzerteil
#

Einleitung und Geltungsbereich
#

Dieses Dokument beschreibt die technische Konfiguration, die administrativen Prozesse und die Nutzungsrichtlinien für das E-Mail-System. Es richtet sich an IT-Administratoren, den IT-Support sowie an alle Mitarbeiter als Leitfaden für die ordnungsgemäße Nutzung des E-Mail-Dienstes.

Ziel ist es, einen stabilen, sicheren und effizienten E-Mail-Verkehr zu gewährleisten und klare Anweisungen für Standardprozeduren bereitzustellen.

Systemübersicht
#

Die E-Mail-Infrastruktur ist vollständig lokal (“on-premises”) und basiert auf den folgenden Open-Source-Komponenten:

  • Mail Transfer Agent (MTA): Postfix. Zuständig für den Empfang und Versand von E-Mails über das SMTP-Protokoll.

  • Mail Delivery & Access (MDA/IMAP): Dovecot. Speichert die E-Mails im Maildir-Format auf unseren Servern und stellt sie den Benutzern über die Protokolle IMAP (zum Empfangen) und POP3 (optional) zur Verfügung.

  • E-Mail-Security: rspamd. Ein fortschrittliches Filtersystem, das eingehende E-Mails in Echtzeit auf Spam, Viren und andere Bedrohungen prüft, bevor sie in die Postfächer zugestellt werden.

  • Webmail-Client: Roundcube. Ermöglicht den Zugriff auf E-Mails über jeden modernen Webbrowser.

  • Unterstützte E-Mail-Clients:

    • Desktop: Jeder E-Mail-Client, der IMAP und SMTP unterstützt (z.B. Mozilla Thunderbird, Microsoft Outlook, Apple Mail).

    • Web: Roundcube Webmail.

    • Mobil: Jede mobile E-Mail-App, die IMAP und SMTP unterstützt.

Benutzer- und Postfachverwaltung
#

Die Verwaltung von Postfächern erfolgt durch die IT-Administration über Systemskripte, die mit der zentralen Benutzerdatenbank interagieren.

Anlage eines neuen Postfach
#

  1. Ein neuer Benutzer wird in der zentralen Benutzerdatenbank angelegt.

  2. Ein dazugehöriges Postfach im Maildir-Format wird auf dem Mailserver erstellt. (Welcome Mail lässt Dovecot das Postfach anlegen)

  3. Die primäre E-Mail-Adresse wird konfiguriert. Notwendige Aliase werden in der zentralen Benutzerdatenbank gespeichert.

  4. Der Benutzer erhält sein initiales Passwort und die Server-Konfigurationsdaten von der IT-Abteilung.

Deaktivierung eines Postfachs (Offboarding)
#

  1. Der Benutzer-Account wird am letzten Arbeitstag gesperrt. Der Login ist damit sofort unterbunden.

  2. Nach Rücksprache mit der Fachabteilung wird entschieden, wie mit den bestehenden E-Mails verfahren wird:

    • Archivierung: Das Maildir-Verzeichnis des Benutzers wird als komprimiertes Archiv (.tar.gz) gesichert und für die gesetzliche Aufbewahrungsfrist aufbewahrt.

    • Weiterleitung: Optional wird eine serverseitige Weiterleitung an den Vorgesetzten oder Nachfolger eingerichtet.

  3. Das aktive Postfach und der Benutzer werden nach einer Frist von 30 Tagen endgültig vom System gelöscht.

Konfigurationsanleitungen
#

Für die Einrichtung Ihres E-Mail-Kontos benötigen Sie die folgenden Server-Einstellungen:

  • Benutzername: Ihre volle E-Mail-Adresse
  • Passwort: Das Ihnen zugewiesene Passwort

Server für eintreffende E-Mails (IMAP):

  • Server: mail.example.com (Beispiel anpassen)

  • Port: 993

  • Verbindungssicherheit: SSL/TLS oder STARTTLS

  • Authentifizierungsmethode: Passwort, normal

Server für ausgehende E-Mails (SMTP):

  • Server: mail.example.com (Beispiel anpassen)

  • Port: 587

  • Verbindungssicherheit: STARTTLS

  • Authentifizierungsmethode: Passwort, normal

Sicherheitsrichtlinien und Best Practices
#

  • Passwörter: Passwörter müssen den Richtlinien entsprechen. Geben Sie Ihr Passwort niemals an Dritte weiter. Sollte das Passwort einmal in die Hände Dritter gelangen ist sofort die IT zu informieren.

  • Phishing und verdächtige E-Mails:

    • Klicken Sie niemals auf Links oder öffnen Sie Anhänge in E-Mails von unbekannten Absendern oder bei unerwarteten Nachrichten.

    • Melden von Phishing: Legen Sie verdächtige E-Mails bitte in das Postfach Junk oder je nach Sprache auch Spam. Dies hilft uns, die Filterregeln in rspamd zu verbessern.

  • mgang mit Anhängen:*

    • Nutzen Sie für größere Anhänge einen Dateidienst.

    • Gefährliche Dateitypen (z.B. .exe, .bat, .js) werden von rspamd automatisch blockiert.

  • Vertrauliche Informationen: Für den Versand streng vertraulicher Daten wird eine clientseitige Ende-zu-Ende-Verschlüsselung mittels S/MIME oder PGP/GPG empfohlen. Die Einrichtung liegt in der Verantwortung des Benutzers.

Backup und Wiederherstellung
#

  • Backup-Strategie: Die IT-Administration führt nächtliche Backups der E-Mail-Infrastruktur durch. Dies umfasst:

    • Die Maildir-Verzeichnisse aller Benutzer.

    • Die Konfigurationsdateien von Postfix, Dovecot und rspamd.

    • Die Benutzerdatenbank.

Wiederherstellung von E-Mails: Gelöschte E-Mails können nicht vom Benutzer selbst wiederhergestellt werden. Bitte kontaktieren Sie den IT-Support mit einer genauen Angabe der E-Mail (Absender, Betreff, ungefähres Datum), damit diese aus dem Backup wiederhergestellt werden kann.

IT Teil
#

Architektur
#

Der Mailstack wird auf mehreren virtuellen Maschinen als Kubernetes (k3s) Cluster aufgebaut. Es werden unabhängige Deployments bevorzugt und je Pod nur die nötigsten Dienste betrieben. Der Ein-Dienst-Ein-Container-Ansatz wird nicht empfohlen, da so unnötig viele Container erstellt werden. Da Dovecot und Postfix die gleiche IP Adressen haben sollen und beide Container die echte IP des Endnutzers sehen müssen, ist es notwendig beide Container in einem Pod zu betreiben. Siehe dazu die Metallb Dokumentation.

Hier ist ein Diagramm, das den Fluss einer eingehenden E-Mail visualisiert:

 1sequenceDiagram
 2    participant Externer MTA
 3    participant Postfix (MTA)
 4    participant Rspamd (Filter)
 5    participant Dovecot (MDA)
 6    participant Maildir (Speicher)
 7
 8    Externer MTA->>+Postfix (MTA): E-Mail via SMTP
 9    Postfix (MTA)->>+Rspamd (Filter): Prüfung via Milter
10    Rspamd (Filter)-->>-Postfix (MTA): Ergebnis (Clean/Spam)
11    Postfix (MTA)->>+Dovecot (MDA): Zustellung via LMTP
12    Dovecot (MDA)->>+Maildir (Speicher): Speichert E-Mail

Vorhandene Infrastruktur (Out of scope für dieses Dokument)
#

Zeitsynchronisation (NTP - Network Time Protocol)
#

Eine exakte und synchronisierte Systemzeit ist entscheidend für korrekte Zeitstempel in E-Mail-Headern, die Analyse von Logdateien und die Gültigkeit von Authentifizierungstickets

Transportverschlüsselung (TLS/SSL)
#

Verschlüsselt die Kommunikation zwischen E-Mail-Clients und dem Server sowie zwischen den Mailservern untereinander (via STARTTLS). Dies schützt Anmeldedaten und E-Mail-Inhalte vor dem Mitlesen.

Zentrale Benutzerauthentifizierung (LDAP / Active Directory
#

Anstatt Benutzerkonten und Passwörter lokal auf dem Mailserver zu verwalten, kann der Server an einen zentralen Verzeichnisdienst angebunden werden.

Monitoring und Logging
#

Eine lückenlose Protokollierung aller Vorgänge ist für die Fehleranalyse (z.B. bei Zustellproblemen) und die Erkennung von Sicherheitsvorfällen (z.B. kompromittierte Konten) unerlässlich.

DNS Konfiguration
#

Folgende DNS Einträge müssen gesetzt werden
#

Alle Einträge müssen in den entsprechenden Zonen gesetzt werden, für welche der Mailserver zuständig sein soll.

Basis:

  • A
  • AAAA (wenn wir das aktuell nicht nutzen bitte NICHT setzen)
  • MX
  • PTR

Sicherheit:

Optional:

Bei Delegierung der ACME Challenge auch einen CNAME Eintrag.

Dienste welche mit dem Mailstack interagieren
#

Wer hat eigentlich auf welche Mailbox Zugriff?
#

Nutzer können ihre Mailboxen mit anderen Nutzern teilen. Die IT hat einige Freigaben eingerichtet; gepflegt werden sie über AD-Gruppen — siehe Zugriff auf fremde Postfächer per AD-Gruppe. Wer auf ein Postfach zugreifen darf, steht damit in der Gruppe Mailbox-<adresse>-ADM|-RW|-RO und nirgends sonst.

Den aktuellen Stand eines Postfachs zeigt:

1kubectl exec -n mailstack deploy/mailstack-main -c dovecot -- \
2  doveadm acl get -u info@example.com INBOX

Einzelne Rechte lassen sich weiterhin von Hand setzen — für Postfächer ohne Mailbox-*-Gruppe, denn sonst überschreibt der ACL-Sync sie beim nächsten Lauf:

1kubectl exec -n mailstack deploy/mailstack-main -c dovecot -- \
2  doveadm acl set -u info@example.com INBOX user=m.mustermann@example.com \
3  lookup read write write-seen write-deleted insert post expunge create delete

Früher lagen diese Befehle gesammelt in sharedfolders.sh. Die Datei ist entfallen — der Bestand steckt jetzt in den AD-Gruppen, die Übernahme beschreibt Bestand übernehmen.

Senden im Namen eines anderen Postfachs (Send-As)
#

Für Funktionspostfächer (info@, support@, …) kann geregelt werden, wer im Namen dieser Adresse senden darf. Gesteuert wird das ausschließlich über eine AD-Gruppenmitgliedschaft — es ist kein Attribut am Benutzerkonto zu pflegen.

Wie es funktioniert
#

Postfix prüft beim Versand mit reject_sender_login_mismatch, ob der angemeldete SASL-Login (= die Mailadresse des Nutzers) zur Absenderadresse passt. Die Zuordnung liefert smtpd_sender_login_maps über postfix/ldap/ldap_sender_login_match.cf. Deren Query hat zwei Zweige:

  1. das Konto selbst (Treffer über mail / otherMailbox)
  2. die Gruppe SendAs-<volle Absenderadresse> — Postfix folgt deren member-Einträgen und lässt die Mailadressen der Mitglieder als Absender zu

Beides muss in einem LDAP-Query stehen: smtpd_sender_login_maps durchsucht mehrere Tabellen nur bis zum ersten Treffer, eine separate Gruppen-Map würde nie erreicht.

Die Berechtigung wirkt nur auf den Versand. Die Zustellmaps (ldap_mailbox.cf, ldap_alias.cf, ldap_forward.cf) lesen weder cn noch member — eingehende Mail landet weiterhin ausschließlich im Postfach des Funktionskontos.

Namenskonvention
#

Der Gruppen-CN enthält die vollständige Adresse inklusive Domain, da mehrere Maildomains betrieben werden:

1info@example.com    →  CN=SendAs-info@example.com
2support@example.com →  CN=SendAs-support@example.com

Gematcht wird auf cn. samba-tool setzt sAMAccountName gleich dem Gruppennamen — das passt zur bestehenden Praxis (eine bestehende catchall-Adresse ist genauso angelegt). Die 20-Zeichen-Grenze für den Pre-Windows-2000-Namen ist eine Konvention der Windows-Werkzeuge; das Schema erlaubt 256 Zeichen und Samba erzwingt die Grenze nicht. @ ist im sAMAccountName zulässig, unzulässig sind nur " / \ [ ] : ; | = , + * ? < >.

Berechtigung einrichten
#

Auf dem Samba-DC als root:

1samba-tool group add "SendAs-info@example.com" \
2  --groupou="OU=Gruppen" --group-scope=Global --group-type=Security \
3  --description="Darf im Namen von info@example.com senden"
4
5samba-tool group addmembers "SendAs-info@example.com" mmustermann

Erteilen und Entziehen der Berechtigung ist danach reine Gruppenmitgliedschaft. Verschachtelte Gruppen werden mit aufgelöst — soll ein Delegierter auch unter einem Alias des Postfachs senden, genügt es, die bestehende Gruppe in die Gruppe des Alias aufzunehmen:

1samba-tool group addmembers "SendAs-kontakt@example.com" "SendAs-info@example.com"

Im Mailclient muss zusätzlich eine Identität mit der Funktionsadresse angelegt werden; Postfix prüft den Envelope-Sender, den der Client aus der gewählten Identität setzt.

Fallstricke
#

  • Den SendAs-Gruppen kein mail-Attribut geben. Sonst greift ldap_group.cf in virtual_alias_maps und die Gruppe wird als Verteiler behandelt — Mail an die Adresse ginge dann an alle Mitglieder.
  • Die Auflösung über member filtert nicht: gesperrte Konten und Mitglieder der Gruppe noOutgoingMail werden nicht ausgeschlossen. Gesperrte Konten können sich zwar ohnehin nicht anmelden, noOutgoingMail-Nutzer gehören aber nicht in eine SendAs-Gruppe.
  • Die Konvention hängt am CN — beim Umbenennen der Gruppe bricht die Berechtigung still.
  • Das Secret postfix-ldap wird mit disableNameSuffixHash: true erzeugt: nach einer Änderung an den .cf-Dateien startet der Pod nicht automatisch neu.

Prüfen
# 

1kubectl exec -n mailstack deploy/mailstack-main -c postfix -- \
2  postmap -q info@example.com ldap:/etc/postfix/ldap/ldap_sender_login_match.cf

Erwartete Ausgabe: die Adressen des Funktionskontos plus die Mailadressen aller Gruppenmitglieder.

Zugriff auf fremde Postfächer per AD-Gruppe (ACL-Sync)
#

Ergänzend zu den manuell gesetzten Freigaben pflegt der CronJob aclsync die Dovecot-ACLs aus dem AD. Damit ist auch der Postfach-Zugriff reine Gruppenmitgliedschaft — analog zu Send-As, nur dass hier die Zustellseite betroffen ist.

Namenskonvention
#

Wie bei Send-As trägt der Gruppen-CN die vollständige Adresse:

1CN=Mailbox-info@example.com-ADM  →  Vollzugriff inkl. admin (darf ACLs per IMAP setzen)
2CN=Mailbox-info@example.com-RW   →  Vollzugriff auf info@example.com
3CN=Mailbox-info@example.com-RO   →  nur lesender Zugriff
4CN=Mailbox-info@example.org-RW   →  anderes Postfach, andere Domain

Ist jemand in mehreren Gruppen desselben Postfachs, gewinnt die höchste Stufe (ADM > RW > RO). Verschachtelte Gruppen werden transitiv aufgelöst (LDAP_MATCHING_RULE_IN_CHAIN), gesperrte Konten werden übersprungen.

1samba-tool group add "Mailbox-info@example.com-RW" \
2  --groupou="OU=Gruppen" --group-scope=Global --group-type=Security \
3  --description="Vollzugriff auf das Postfach info@example.com"
4
5samba-tool group addmembers "Mailbox-info@example.com-RW" mmustermann

Ablauf
#

aclsync läuft alle 15 Minuten und ruft per kubectl exec acl-sync.sh im Dovecot-Container auf. Der Umweg ist nötig, weil doveadm für die userdb-Auflösung den auth-Socket der laufenden Dovecot-Instanz braucht — ein eigener Pod mit gemountetem Mail-Volume könnte das nicht. Der CronJob-Pod hält deshalb weder Mail-Storage noch Konfiguration, nur ein kubectl-Binary.

Das Skript

  1. liest die LDAP-Zugangsdaten aus /etc/dovecot/dovecot-ldap.conf.ext (keine zweite Kopie der Credentials im Repository),
  2. sucht alle Gruppen Mailbox-* und löst deren Mitglieder auf,
  3. gleicht je Postfach den Soll- gegen den Ist-Zustand aus doveadm acl get ab und setzt bzw. entfernt user=-Einträge auf der INBOX (acl_defaults_from_inbox = yes vererbt das an die Unterordner),
  4. abonniert den Delegierten den Ordner shared/<adresse>/INBOX, damit er im Client auftaucht (abschaltbar über ACL_AUTOSUBSCRIBE=0).

Zu beachten
#

  • Das AD ist die Quelle der Wahrheit. Auf einem Postfach, für das eine Mailbox-*-Gruppe existiert, verwaltet der Job alle user=-ACL-Einträge — von Hand gesetzte Rechte auf diesen Postfächern verschwinden beim nächsten Lauf. Postfächer ohne solche Gruppe fasst der Job nicht an.
  • Rechte entziehen: Gruppe leeren, nicht löschen. Eine gelöschte Gruppe sieht der Job nicht mehr, die ACLs blieben bestehen.
  • Schlägt eine LDAP-Abfrage fehl, bricht der Lauf vor jeder Änderung ab — ein LDAP-Ausfall entzieht also keine Rechte.
  • pods/exec ist ein weitreichendes Recht (faktisch Vollzugriff auf alle Postfächer). Der Job hat deshalb einen eigenen ServiceAccount mailstack-aclsync und hängt nicht am mailstack-main-Account.
  • Trockenlauf zum Prüfen, ohne etwas zu ändern:
1kubectl exec -n mailstack deploy/mailstack-main -c dovecot -- \
2  env ACL_DRY_RUN=1 /etc/dovecot/acl-sync.sh
  • Logs des letzten Laufs:
1kubectl logs -n mailstack -l app.kubernetes.io/controller=aclsync --tail=100

Bestand übernehmen (einmalig)
#

acl-migrate.sh überführt die bereits von Hand gesetzten Freigaben in das Gruppenmodell. Das Skript ist rein lesend — es wertet die dovecot-acl-Dateien im Mail-Storage aus und erzeugt daraus ein Shell-Skript für den Samba-DC (stdout) sowie einen Bericht (stderr). Es muss nicht im Image liegen, sondern wird über stdin hineingereicht.

1. CronJob anhalten, damit kein Lauf Rechte abräumt, für die es noch keine Gruppe gibt:

1kubectl patch cronjob mailstack-aclsync -n mailstack -p '{"spec":{"suspend":true}}'

2. Bestand auswerten:

1kubectl exec -i -n mailstack deploy/mailstack-main -c dovecot -- bash -s \
2  < apps/mailstack/dovecot/acl-migrate.sh > mailbox-groups.sh

Der Bericht auf stderr listet, was übernommen wird, und was Handarbeit braucht: group=-, anyone- und authenticated-Einträge, relative Rechte (+r/-w) und ACLs auf Unterordnern — letztere, weil der Sync nur die INBOX verwaltet. Die Rechte werden in beiden Schreibweisen erkannt (ausgeschrieben wie lookup read write … und als Buchstaben wie lrwstipekxa): mit admin bzw. a wird daraus -ADM, alles andere mit Schreib-, Einfüge- oder Löschrecht -RW, reiner Lookup/Read-Zugriff -RO.

3. mailbox-groups.sh prüfen und auf dem Samba-DC als root ausführen. Das erzeugte Skript nutzt samba-tool group add/addmembers und löst die Mailadressen der Berechtigten über ldbsearch gegen /var/lib/samba/private/sam.ldb in sAMAccountName auf. Es ist wiederholbar: vorhandene Gruppen und Mitgliedschaften werden nicht doppelt angelegt, fehlende oder mehrfach vergebene Adressen werden gemeldet und übersprungen (Exit-Code 1). Die Ziel-OU steckt in GROUP_OU am Kopf des Skripts (Vorgabe OU=Gruppen, relativ zur Domain-DN — so erwartet es samba-tool).

4. Trockenlauf und CronJob wieder aktivieren:

1kubectl exec -n mailstack deploy/mailstack-main -c dovecot -- \
2  env ACL_DRY_RUN=1 /etc/dovecot/acl-sync.sh
3kubectl patch cronjob mailstack-aclsync -n mailstack -p '{"spec":{"suspend":false}}'

Betrieb und Wartung
#

Wichtige Komponenten (Spam/Virus-Schutz)
#

Anti-Spam, Anti-Virus Rspamd
#
Quelle
#

Docker Hub

Repository
#

Repo

Funktion
#

Spam/Malware Filter

MDA, IMAP, Sieve Dovecot
#
Quelle
#

Docker Hub

Repository
#

Repo

Funktion
#

Dovecot fungiert in diesem Setup als MDA, Sieve und IMAP Server.

MTA Postfix
#
Quelle
#

Docker Hub

Repository
#

Repo

Funktion
#

Postfix ist der Mail Transfer Agent (MTA). Er nimmt E-Mails von externen Servern entgegen, leitet sie zur Prüfung an Rspamd weiter und übergibt sie anschließend zur lokalen Zustellung an Dovecot. Er ist ebenfalls für den Versand ausgehender E-Mails zuständig.

Backup & Wiederherstellung
#

Was wird gesichert
#

Gesichert werden sollen lediglich Nutzerdaten. Die Konfiguration sowie das Deployment selbst sind in Git Repositories und werden extern gesichert.

Wie wird gesichert
#

Backup erfolgt durch VEEAM auf Fileserver Ebene. Eine Sicherung der Nodes oder PV Daten ist nicht notwendig.

Wie sieht der Restore-Prozess aus
#

  1. Kommunikation: Informieren Sie die Nutzer über die geplante Downtime.

  2. Dienste stoppen: Skalieren Sie die betroffenen Deployments im mailstack-Namespace auf 0 Replicas, um Schreibzugriffe zu verhindern.

    1kubectl scale deployment -n mailstack --replicas=0 <deployment-name>

  3. Daten wiederherstellen: Stellen Sie das Backup des Mail-Datenverzeichnisses über VEEAM auf dem Fileserver wieder her.

  4. Berechtigungen prüfen: Stellen Sie sicher, dass die Dateiberechtigungen (owner, group, permissions) im wiederhergestellten Verzeichnis korrekt sind.

  5. Dienste starten: Skalieren Sie die Deployments wieder auf die ursprüngliche Anzahl an Replicas hoch.

  6. Funktionstest: Überprüfen Sie die Logs auf Fehler und führen Sie einen Sende- und Empfangstest durch.

Troubleshooting
#

Dieser Abschnitt beschreibt die ersten Schritte zur Analyse von häufigen Problemen.

Logs prüfen
#

Der erste Schritt bei Problemen ist immer die Analyse der Log-Dateien der jeweiligen Container. Annahme ist, dass die Pods im Namespace mailstack laufen.

1# Logs von Postfix/Dovecot live verfolgen
2kubectl logs -f -n mailstack <postfix-dovecot-pod-name>
3
4# Logs von Rspamd prüfen
5kubectl logs -f -n mailstack <rspamd-pod-name>

Mail-Warteschlange (Queue) prüfen
#

Wenn E-Mails nicht versendet werden oder sich verzögern, gibt die Postfix-Warteschlange Aufschluss über die Ursache.

1# In den Postfix-Container wechseln
2kubectl exec -it -n mailstack <postfix-pod-name> -- /bin/bash
3
4# Warteschlange anzeigen (entspricht `postqueue -p`)
5mailq
6
7# Eine bestimmte Nachricht in der Queue genauer ansehen
8postcat -q <QUEUE_ID>

Troubleshooting
#

Dieser Abschnitt beschreibt die ersten Schritte zur Analyse von häufigen Problemen.

Logs prüfen
#

Der erste Schritt bei Problemen ist immer die Analyse der Log-Dateien der jeweiligen Container. Annahme ist, dass die Pods im Namespace mailstack laufen.

1# Logs von Postfix/Dovecot live verfolgen
2kubectl logs -f -n mailstack <postfix-dovecot-pod-name>
3
4# Logs von Rspamd prüfen
5kubectl logs -f -n mailstack <rspamd-pod-name>

Mail-Warteschlange (Queue) prüfen
#

Wenn E-Mails nicht versendet werden oder sich verzögern, gibt die Postfix-Warteschlange Aufschluss über die Ursache.

1# In den Postfix-Container wechseln
2kubectl exec -it -n mailstack <postfix-pod-name> -- /bin/bash
3
4# Warteschlange anzeigen (entspricht `postqueue -p`)
5mailq
6
7# Eine bestimmte Nachricht in der Queue genauer ansehen
8postcat -q <QUEUE_ID>
Fabrice Kirchner
Autor
Fabrice Kirchner
stolzer Vater, Nerd, Admin
Xing