Inhaltsverzeichnis
OmniMail™ · Dokumentationsentwurf V2
Stand: 2026-11-03. Geltung: ausschließlich OmniMail für omnisrv.de auf OMNISRV. Diese eigenständige Entwurfsseite ergänzt die technische V1-Systemübersicht und verändert sie nicht.
Teil 1 · Die Postreise einfach erklärt
Was ist OmniMail™?
OmniMail ist die Mailstraße für omnisrv.de. Vorne nimmt ein Postfix-Dienst E-Mails aus dem Internet entgegen. Er fragt nach, ob der Empfänger existiert, und lässt die Nachricht prüfen. Ein zweiter Postfix-Dienst transportiert angenommene Mail zum Stalwart-Postfach. Für ausgehende Mail läuft der Weg kontrolliert in die andere Richtung.
Wie liest man das Bild?
Das Schema zeigt Arbeitsschritte, keine zusätzliche Netzwerkfreigabe. Eine E-Mail für einen unbekannten Empfänger wird schon im SMTP-Gespräch abgewiesen. Spam- und Virenprüfungen können ebenfalls zur Ablehnung führen. Erst eine angenommene Nachricht gelangt in die Postfix-Queue und danach zur Mailbox.
Teil 2 · Die beteiligten Dienste
SMTP-Eingang und Empfängerprüfung
Postfix (Codename: Alois) im Container ext-qipu ist das öffentliche SMTP-Tor. Vor der Annahme fragt es den Prüfdienst von Postfix (Codename: Hildegard) im Container int-mailgateway. Dieser prüft die Empfängerexistenz bei Stalwart. Die Entscheidung kommt zum ersten SMTP-Dialog zurück.
Warum dieser Umweg?
Stalwart kennt die lokalen Konten. Alois benötigt nur die Antwort, ob die Adresse zulässig ist. Der direkte Mailweg von Alois zu Stalwart bleibt gesperrt.
Spam- und Virenschutz
Rspamd (Codename: Illapa) bewertet die eingehende Nachricht als Milter. Für die Malwareprüfung fragt Rspamd ClamAV (historischer Name: Ix Chel, im Betrieb auch „Ixcel“) ab. Redis (Codename: Itzamná) dient Rspamd als Datenspeicher. Eine Ablehnung erfolgt nach den wirksamen Regeln vor der dauerhaften Queue-Annahme.
Prüfergebnis"| R["int-spamcheck: Rspamd"] R -->|"ClamAV 3310"| V["int-viruscheck: ClamAV"] R -->|"Cache"| C["int-mailmemcache: Redis"]
Zustellung und Ausgangspost
Für omnisrv.de führt die aktive Postfix-Transporttabelle von Alois über Hildegard zu Stalwart. Stalwart verwaltet die Postfächer. Authentifizierte, autorisierte Ausgangspost geht von Stalwart über Hildegard und Alois zum externen MX. Postfix ist dabei kein offenes Relay.
ext-qipu"] -->|"TCP 25"| E2["Hildegard
int-mailgateway"] E2 -->|"lokale Zustellung"| E3["Stalwart
cdf-stalwart"] end subgraph A["Ausgangspost"] direction LR A1["Stalwart
cdf-stalwart"] -->|"autorisierter Ausgang"| A2["Hildegard
int-mailgateway"] A2 -->|"Relay"| A3["Alois
ext-qipu"] A3 -->|"SMTP TCP 25"| A4["externer MX"] end
DNS und Zertifikats-Kurier
Alois verwendet für seine DNS-Abfragen den externen BIND-Dienst; Hildegard nutzt den internen BIND-Dienst. Der Zertifikats-Kurier übernimmt geprüfte Zertifikatspakete aus der Caddy-Welt in geschützte Zielverzeichnisse. Kontrollierte Watcher laden die Zertifikate bei den Maildiensten nach. Private Schlüssel gehören weder in das Wiki noch in Git.
Monitoring und Backup
Ein Host-Monitor prüft die Mailstraße und löst bei relevanten Zustandswechseln Alarm aus. Der Alarmdienst nutzt authentifizierte Stalwart-Submission. Borg archiviert die vorgesehenen Daten- und Konfigurationsquellen; ein isolierter Restore wurde geprüft. Eine SMTP-Annahme bestätigt nur die Übergabe an den nächsten Dienst, nicht den tatsächlichen Eingang in einem externen Postfach.
Teil 3 · Technische Referenz
Live-Container, Netze und Adressen
| Technischer Dienst | Container / Hostdienst | Netz und IPv4 | Protokoll / Port |
|---|---|---|---|
| Postfix-Eingang und Internet-Relay | ext-qipu | ext-net 10.0.0.10; inbound-mail-checks 10.0.70.10; int-mailforward 10.0.71.10 | SMTP 25; Policy 10.0.71.20:10031; Milter 10.0.70.20:11332 |
| Postfix-Transport und Empfänger-Policy | int-mailgateway | int-mailforward 10.0.71.20; int-net 10.0.50.10 | SMTP 25; Policy 10031; Stalwart-RCPT 10.0.40.10:25 |
| Rspamd | int-spamcheck | inbound-mail-checks 10.0.70.20 | Milter 11332 |
| ClamAV | int-viruscheck | inbound-mail-checks 10.0.70.21 | ClamAV 3310 |
| Redis | int-mailmemcache | inbound-mail-checks 10.0.70.22 | Nur freigegebener Rspamd-Datenpfad |
| Stalwart | cdf-stalwart | cdf-mail-net 10.0.40.10 | SMTP 25; IMAPS 993; TLS-Submission 465; internes HTTPS 443; interner Listener 8080 |
| BIND intern | int-bind-internal | int-net 10.0.50.2 | DNS 53 |
| BIND extern | ext-bind-public | ext-net 10.0.0.2 | DNS 53 |
| Caddy intern | int-caddy | cdf-web-net 10.0.30.10 | HTTPS-Routing gemäß Caddy-Labels |
| Private Autokonfiguration | omnimail-m01-private-autoconfig | int-net 10.0.50.20 | internes HTTPS für Clientkonfiguration |
Diese Adressen stammen aus Docker-Inspect vom 03.11.2026. Die fünf Stalwart-Listener wurden zusätzlich im Container als TCP-Listener geprüft; ein Listener allein ist keine öffentliche Freigabe. Das HTTP-/API-Interface auf 8080 ist kein öffentlicher Admin-Zugang. HOME0 und autorisierte WireGuard-Clients erreichen die ausdrücklich freigegebenen Stalwart-Dienste; die Administration auf 443 bleibt intern.
Konfiguration und Schutzgrenzen
Mailverarbeitung und Postfächer
Postfix-Build und Compose: /opt/omnisrv/omnimail-m01-deploy-001/; aktive Hauptdateien alois-main-m01d008a.cf, hildegard-main-m01d002.cf und Transport-/Empfänger-Maps. Die laufenden Container-Mounts sind für den IST-Stand maßgeblich.
Rspamd: aktive local.d-/override.d-Bindungen aus demselben Deploy-Verzeichnis; DKIM- und Redis-Geheimnisse liegen getrennt unter /opt/omnisrv/secrets.
Stalwart: /mnt/docker-container/cdf-stalwart/config/config.json und persistente Daten; Zertifikate aus geschütztem Kurierziel. Die dynamische Konfiguration wird nicht als Klartext in Git abgebildet.
DNS und Betriebssteuerung
DNS: getrennte int-bind- und ext-bind-Konfigurationen unter /mnt/docker-container/; TSIG und dynamische Journale nicht im Quellrepo.
Start, Netzgrenzen und Überwachung: installierte omnimail-*.service und omnimail-*.timer unter /etc/systemd/system, Skripte im genannten Deploy-Verzeichnis.
Sicherheitsgrenzen
Verbotene direkte Mailwege laut M01-Netzvertrag: Alois → Stalwart, Rspamd → Stalwart und Stalwart → Alois. Hildegard darf DNS nicht über ext-bind beziehen; fremde Clients erhalten keinen offenen Relayzugang.
Betrieb und Wiederherstellung
Bei Zustellproblemen zuerst Monitorstatus, Postfix-Queues, Stalwart-Health und DNS-Antworten aus den jeweils berechtigten Netzen prüfen. Zertifikatswechsel über den vorhandenen Kurier/Watcher und dessen Fingerprint-Readback bewerten. Die isolierte Borg-Recovery aus M01-DEPLOY-015C-B ist ein Teilnachweis, keine vollständige Ersatzhost-Abnahme. Änderungen an laufenden Maildiensten, DNS, Firewall oder Backup sind nicht Teil dieses Wiki-Entwurfs.
VOE und Quellenstand
Die VOE (Vereinigung der OmniMail-Elektriker) verlangt für jede produktive Leitung eine geprüfte Nummer und Verbindungsmatrix. Für die obigen Mailkanten ist keine vollständige autoritative OM-LINK-Liste belegt; deshalb tragen die neuen Diagramme keine erfundenen Leitungsnummern. Verifiziert ist der gesonderte Vertrag OM-LINK-ETPW-001 für die technische QaD-Maestro-Alarmierung, der hier keine zusätzliche allgemeine Mailroute begründet.
Quellstand: Live-Docker-Inspect und Listener-Readback vom 03.11.2026; M01-DEPLOY-010, 012D, 014 und 015C-B; OmniMail-ROM PANTHEON-GRUNDORDNUNG.md; V1-Systemübersicht; geprüftes Quellmanifest. Offen bleiben die vollständige dynamische Konfigurationsabbildung, lückenlose VOE-Leitungsnummern und die visuelle Browserabnahme durch den Benutzer.
Pantheon-Legende™
Die erste Grundordnung ist ein historischer Scaffold-Stand. Sie bestimmt Namen und Rollen, beweist aber für sich keine heutige Containerbelegung. Live-Zuordnungen sind unten ausdrücklich gekennzeichnet.
| Codename | Herkunft | Technische Funktion / Stand | Tatsächliches Ziel |
|---|---|---|---|
| Alois | Ein Urgestein als Postbote … | Aktiver äußerer Postfix-Eingang und Internet-Relay | ext-qipu, 10.0.0.10 |
| Hildegard | Eine nette Mitarbeiterin aus der Postverteilstelle … | Aktiver interner Postfix-Transport und Empfänger-Policy | int-mailgateway, 10.0.71.20 / 10.0.50.10 |
| Kukulkan | Aus dem Maya-Pantheon Die gefiederte Schlange, verehrt als Gottheit des Wissens. | Historische Rollenbezeichnung für Postfix-Transport/Queues; heute auf Alois und Hildegard verteilt | Kein eigener Container; siehe ext-qipu und int-mailgateway |
| Illapa | Aus dem Inka-Pantheon Gott des Blitzes und Donners. | Aktive Rspamd-Spamprüfung | int-spamcheck, 10.0.70.20 |
| Ix Chel / Ixcel | Aus dem Maya-Pantheon Göttin der Schwangerschaft und Heilkunst; „Ixcel“ ist der Betriebsname. | Aktive ClamAV-Malwareprüfung | int-viruscheck, 10.0.70.21 |
| Itzamná | Aus dem Maya-Pantheon Schöpfergott, dem auch die Schrift zugeschrieben wurde. | Aktiver Redis-Datenspeicher für Rspamd | int-mailmemcache, 10.0.70.22 |
| Hermes | Aus dem griechischen Pantheon Götterbote und Schutzherr der Reisenden. | Symbolischer Bote der Ausgangspost; keine zusätzliche Containerpflicht | Kein eigener Container; Transport durch Stalwart, Hildegard und Alois |
| Inti | Aus dem Inka-Pantheon Als Sonnengott verehrt. | Symbolische oberste Prüfungsinstanz im historischen Scaffold | Kein eigener Container oder IP-Ziel |
| QIPU | Aus der Inka-Kultur Knotenschnüre für Aufzeichnungen und Nachrichten; keine Gottheit. | Bezeichnung der Mailgateway-Welt, nicht zusätzlicher Dienst | Unter anderem ext-qipu; kein separates QIPU-Backend |
| Stalli-Maus | Projektinterner Stalwart-Spitzname aus M01-Arbeitsaufträgen | Stalwart-Postfach- und Verwaltungsdienst | cdf-stalwart, 10.0.40.10 |
| Brunhilde, Kunigunde, Jolanthe | Projektinterne Namen synthetischer Testpostfächer | Konten, keine technischen Transportdienste | Stalwart; keine eigenen Container-IPs |
| Julius | Projektinterner Name des externen Testabsenders | Testrolle, kein lokales Mailkonto | Kein OmniMail-Container |
Zeus und weitere Figuren bleiben nach der Grundordnung künstlerische Figuren ohne technische Zuständigkeit.