SEPPmail: Mail-Gateway, Schlüssel und GINA-Zustellung

SEPPmail ist ein spezialisiertes Mail-Gateway, das Nachrichten im SMTP-Pfad entgegennimmt, nach zentralen Regeln verarbeitet und an ein internes Mailsystem, einen Smarthost oder die nächste Internet-Gegenstelle weitergibt. Zu den dokumentierten Verarbeitungsarten gehören S/MIME- und OpenPGP-Signatur beziehungsweise -Verschlüsselung, S/MIME-basierte Domänenverschlüsselung, verbindungsbezogene TLS-Vorgaben und die GINA-Webzustellung für Empfänger ohne nutzbaren öffentlichen Schlüssel (SEPPmail: Products, SEPPmail: Mail System, SEPPmail: Encryption Policy).

Die zentrale Verarbeitung vereinfacht den Client: Benutzer können aus ihrem gewohnten Mailsystem senden, während das Gateway Schlüssel sucht, Richtlinien auswertet und kryptografische Operationen ausführt. Gleichzeitig wird die Appliance dadurch zu einer Vertrauens- und Verfügbarkeitsgrenze. Sie sieht den Nachrichteninhalt vor einer ausgehenden Verschlüsselung beziehungsweise nach einer eingehenden Entschlüsselung, hält privates Schlüsselmaterial und kann nach erfolgreicher SMTP-Annahme zum neuen Verantwortungspunkt für die Nachricht werden. Ein Administrator muss daher nicht nur «Verschlüsselung aktiv» nachweisen, sondern den gesamten Pfad aus Routing, Regel, Schlüsselwahl, Zustellverfahren, Queue, Logging und Recovery nachvollziehen können (RFC 5321: SMTP responsibility, RFC 8551: S/MIME, SEPPmail: Frontend/Backend Cluster).

Die Erklärung folgt einer Nachricht durch SMTP-Annahme, Ruleset und gewähltes Verschlüsselungsverfahren bis zur Zustellung oder zum GINA-Portal. Schlüssel, Cluster, Diagnose und Recovery werden anschliessend an diesem Pfad erklärt.

SEPPmail sitzt als zustandsbehaftetes Gateway im Nachrichtenweg. Es nimmt SMTP an, ermittelt Richtlinie und Empfängerfähigkeit, wählt S/MIME, OpenPGP, TLS oder GINA und stellt danach weiter zu. An diesem Ablauf orientieren sich Architektur, Betrieb und Recovery.

Architekturansatz: zustandsbehaftetes Inline-Gateway

Im einfachsten Aufbau sendet das interne Mailsystem ausgehende Nachrichten per SMTP an SEPPmail; für eingehende Nachrichten zeigt der öffentliche MX-Eintrag direkt oder über einen vorgeschalteten Smarthost auf das Gateway. Für jede verwaltete Domain ist ein interner Forwarding Server definiert. Ausgehend kann die Appliance selbst per DNS zustellen oder einen festgelegten SMTP-Smarthost verwenden. Die vom Hersteller dokumentierte Firewallmatrix bildet diese Richtungen getrennt ab und nennt TCP 25 jeweils zwischen Mailserver, Appliance, Internet oder Smarthost (SEPPmail: Setting Up The Firewall/Router, SEPPmail: Mail System).

Das Gateway ist kein transparentes Paketfiltergerät. Es beendet eine SMTP-Sitzung und eröffnet für die Weitergabe eine neue. Nach 250 auf das Ende der DATA-Phase liegt die Zustellverantwortung beim annehmenden SMTP-System; ein erfolgreicher Verbindungsaufbau oder STARTTLS allein belegt diese Übergabe nicht (RFC 5321, Abschnitt 4.1.1.4, RFC 3207: SMTP STARTTLS). Aus Sicht des Betriebs entstehen mindestens fünf getrennte Prüfobjekte: eingehende SMTP-Sitzung, lokale Verarbeitung, nächster SMTP-Hop, Schlüssel- und Policyzustand sowie gegebenenfalls der GINA-Webzustand.

Für Exchange Online beschreibt SEPPmail ein explizites Connector- und Mailflow-Regelmodell. In mandantenfähigen Umgebungen empfiehlt die Herstelleranleitung zertifikatbasierte Connectoren; mehrere Gateway-Hosts müssen zusätzlich in den Microsoft-Connectoren und gegebenenfalls der Anti-Spam-Konfiguration berücksichtigt werden. Microsoft dokumentiert Connectoren ebenfalls als definierte Vertrauens- und Routingbeziehung, nicht als generelle Abschaltung aller übrigen Zustellpfade (SEPPmail: Setup with Exchange Online, Microsoft: Configure mail flow using connectors).

Technologiestack und dauerhafte Zustände

Die öffentlich zugängliche Revisionshistorie dokumentiert einen Appliance-Stack auf OpenBSD-Basis mit Postfix als MTA sowie unter anderem Apache HTTP Server, OpenSSL beziehungsweise LibreSSL, GnuPG, OpenLDAP, Dovecot, Fetchmail, ClamAV, OpenSSH und Perl. Diese Komponenten erfüllen verschiedene Rollen; ihre in einer bestimmten Release Note genannten Versionsstände sind keine zeitlosen Produkteigenschaften. Für den Betrieb ist entscheidend, welche Schnittstelle der Hersteller unterstützt: SMTP- und TLS-Parameter werden beispielsweise über «Mail System» verwaltet, während «Extended Postfix MTA settings» ausdrücklich als risikobehaftet und nicht cluster-synchronisiert beschrieben sind (SEPPmail: Revision History, SEPPmail: Mail System – Extended Postfix settings).

Der sichtbare Mailfluss ist nur ein Teil des Zustands. Für eine belastbare Bestandsaufnahme sind mindestens folgende Objekte getrennt zu inventarisieren:

Die Zuordnung folgt der dokumentierten Menü- und Komponentenstruktur, der GINA-Kontenverwaltung, der Clusterbeschreibung und dem Quick Setup Guide. Sie ist ein Inventarmodell für Administratoren, keine Behauptung über eine undokumentierte interne Datenbankstruktur (SEPPmail: Mail System, SEPPmail: GINA User Details, SEPPmail: Frontend/Backend Cluster, SEPPmail: Quick Setup Guide).

SMTP-Annahme, Routing und Relaygrenze

Eine Managed Domain verbindet einen angenommenen SMTP-Namensraum mit dem internen Forwarding Server und weiteren domänenspezifischen Einstellungen. Optional kann das Gateway die Empfängeradresse per SMTP-Lookup gegen diesen Server prüfen. Der ausgehende Pfad wird entweder vom eingebauten MTA per DNS oder über einen konfigurierten SMTP-Server bestimmt; domänenspezifische TLS- und Sender-Based-Routing-Einstellungen können diesen Standardpfad übersteuern (SEPPmail: Mail System – Managed Domains and Outgoing Server).

«Relaying allowed» definiert, aus welchen IP-Adressen oder Netzen die Appliance Nachrichten an externe Empfänger annimmt. Die Herstellerdokumentation warnt ausdrücklich davor, den ausgehenden Server pauschal einzutragen, weil daraus ein Open Relay entstehen kann. Portfreigabe, Relayberechtigung, verwaltete Absenderdomain und gegebenenfalls SMTP-Authentisierung sind deshalb verschiedene Kontrollen. Ein positiver TCP-Test sagt nichts über die Relayentscheidung nach MAIL FROM und RCPT TO aus (SEPPmail: Mail System – Relaying, RFC 5321: SMTP commands).

Bei mehreren Gateways muss der davorliegende Load Balancer oder der sendende Dienst jeden produktiven Host erreichen können. Gleichzeitig müssen nachgelagerte Systeme alle erwarteten Gateway-Identitäten akzeptieren. In Exchange Online betrifft dies Connectorzertifikate oder IP-Bereiche; in einer Clusterumgebung zusätzlich virtuelle IPs und die dokumentierte Eigenheit, dass mit IP-Alias empfangen, aber über die physische Adresse des sendenden Systems gesendet wird (SEPPmail: Firewall and IP aliases, SEPPmail: Exchange Online clustering and multi-host).

Nach der SMTP-Annahme entscheidet das Ruleset, welcher Schutz- und Zustellweg gilt. Diese Entscheidung muss aus Nachricht, Identität, Verzeichnisdaten und Regelversion später nachvollziehbar bleiben.

Ruleset, Policies und Entscheidungsnachweis

SEPPmail erzeugt aus den Einstellungen des Ruleset Generators ausführbare Verarbeitungsregeln. Zusätzliche Encryption Policies können für ausgewählte Managed Domains und optionale Flags Verfahren wie S/MIME-only, OpenPGP-only, GINA-only oder eine hierarchische Auswahl erzwingen. Nach einer Policyänderung muss das Ruleset laut Hersteller neu generiert werden, bevor die Änderung aktiv ist. «In der GUI gespeichert» und «im aktiven Nachrichtenpfad wirksam» sind damit zwei unterschiedliche Zustände (SEPPmail: Add/Edit Encryption Policy).

Custom Commands erweitern diese Pipeline um Bedingungen und Aktionen. Der Hersteller dokumentiert unter anderem LDAP-Abfragen, Flags, Benutzer- und Schlüsselerzeugung, Headeroperationen, Signatur, Verschlüsselung, Zustellung und Ablehnung. Makros werden beim Generieren des Rulesets expandiert; ein Syntaxfehler kann die Generierung verhindern (SEPPmail: Macros, SEPPmail: LDAP-based user creation).

Header- oder Betrefftrigger sind Eingaben in eine Sicherheitsentscheidung. Sie dürfen nur aus einer vertrauenswürdigen Richtung ausgewertet oder vor der Auswertung bereinigt werden. Die SEPPmail-Beispiele für mandantenübergreifende Signatur warnen ausdrücklich davor, die Absenderidentität ungeprüft vorauszusetzen. Für jeden Trigger gehören daher Quelle, zulässiger Connector, Authentisierung, Normalisierung, Priorität und Fail-Closed-Verhalten in die Dokumentation (SEPPmail: Signing emails between clients, SEPPmail: Internal X-header processing).

Ein reproduzierbarer Entscheidungsnachweis enthält mindestens: Envelope-Absender und -Empfänger, sichtbaren From:- und gegebenenfalls Sender:-Header, Richtung und Managed Domain, auslösende Policy beziehungsweise Regel, gefundene Schlüssel, gewähltes Verfahren, finale Aktion und Queue-ID. Das ist besonders wichtig, weil S/MIME-Signaturidentität üblicherweise gegen den sichtbaren Absender geprüft wird, während SMTP-Routing zunächst mit dem Envelope arbeitet (SEPPmail: Sender identity selection, RFC 5322: Originator fields).

S/MIME, OpenPGP und TLS als getrennte Schutzebenen

S/MIME kapselt signierte oder verschlüsselte MIME-Inhalte mit Cryptographic Message Syntax. Identitäten und öffentliche Schlüssel werden typischerweise durch X.509-Zertifikate gebunden; Pfadprüfung, Gültigkeitszeit, Schlüsselverwendung und Sperrinformationen gehören deshalb zur Entscheidung (RFC 5652: CMS, RFC 5280: PKIX certificate validation, RFC 6960: OCSP). SEPPmail kann Benutzer- und Domänenzertifikate verwalten und über MPKI-Schnittstellen beziehen; die Firewalldokumentation weist dafür HTTPS sowie für OCSP/CRL HTTP oder HTTPS aus (SEPPmail: Firewall – MPKI and revocation).

OpenPGP verwendet ein anderes Paket-, Schlüssel- und Vertrauensmodell. Ein vorhandener öffentlicher Schlüssel belegt nicht automatisch, dass er zum beabsichtigten Empfänger gehört oder noch verwendet werden soll. Fingerprint, Herkunft, User ID, Ablauf, Widerruf, Algorithmus und private Entschlüsselbarkeit müssen als Lebenszyklus behandelt werden. Die Encryption Policy unterscheidet PGP/MIME und Inline PGP und kann Signatur beziehungsweise Verschlüsselung getrennt konfigurieren (SEPPmail: Encryption Policy – OpenPGP options, RFC 9580: Key structures).

SMTP-TLS schützt eine Verbindung zwischen zwei Hops. Ohne verbindliche Policy ist STARTTLS opportunistisch: Ist es nicht verfügbar, kann der sendende MTA je nach Konfiguration unverschlüsselt zustellen. SEPPmail kann TLS pro Ziel mit Stufen, festem Server, Zertifikatsfingerprint oder anderen Vorgaben konfigurieren. Das ist weder S/MIME noch OpenPGP und schützt die Nachricht nicht vor den beteiligten MTAs (RFC 3207, RFC 7672: SMTP DANE, SEPPmail: Mail System – TLS Settings).

Für eine Gatewayverschlüsselung liegen Klartext und private Absenderschlüssel innerhalb der SEPPmail-Vertrauensgrenze. Das ermöglicht zentrale Policies, bedeutet aber auch: Administratorrollen, Backups, Clusterverbindungen, Debugexporte, Logs und nachgelagerte Inhaltsverarbeitung müssen so geschützt werden, als könnten sie vertrauliche Kommunikationsdaten oder Schlüssel berühren. Ob ein konkreter Export tatsächlich Inhalte enthält, ist anhand der Herstellerdokumentation und eines kontrollierten Tests zu verifizieren.

Wenn kein geeigneter Empfängerschlüssel oder direkter Schutzweg verfügbar ist, verlagert GINA den Zugriff in ein Webportal. Damit kommen Webidentität, Sitzung, Speicher und Benachrichtigungsmail zum SMTP-Pfad hinzu.

GINA als Webdienst mit Identität und Speicher

GINA ist der dokumentierte Ausweichpfad, wenn eine Nachricht nicht mit einem geeigneten Empfängerschlüssel zugestellt wird oder eine Policy ausdrücklich GINA erzwingt. Die Kommunikation zum Portal läuft über HTTPS auf TCP 443. GINA Domains steuern unter anderem Portalname, Layout, Konto- und Passwortverhalten, initiale Passwortübermittlung sowie Aufbewahrungsparameter (SEPPmail: GINA Domains, SEPPmail: Firewall – GINA).

Für Administratoren ist GINA kein blosses Darstellungsformat, sondern ein eigener Dienstzustand. Ein GINA-Konto besitzt Status, Passwort- und gegebenenfalls externe Authentisierungseinstellungen, Benutzerlogs, Mailhistorie und einen Schlüssel. Die Herstellerdokumentation warnt, dass das Löschen des Kontos auch dessen Schlüssel unwiderruflich löscht und verbleibende GINA-Nachrichten damit unlesbar werden können (SEPPmail: GINA User Details).

Zum GINA-Betrieb gehören daher mindestens:

• ein stabiler, zertifikatskonformer öffentlicher Hostname und dessen DNS-Lebenszyklus;
• HTTPS-Zertifikat, vollständige Kette, Erneuerung und externe Erreichbarkeit;
• getrennte Übermittlung oder Herleitung des initialen Geheimnisses;
• Kontosperre, Reset, externe Identität und Supportprozess;
• Aufbewahrungs- und Löschregeln für Nachricht, Metadaten, Logs und Schlüssel;
• ein Recoverytest, der eine vor dem Backup erzeugte GINA-Nachricht nach der Wiederherstellung tatsächlich öffnet.

Der Quick Setup Guide weist darauf hin, dass eine Änderung des Hostnamens dazu führen kann, dass frühere GINA-Nachrichten nicht mehr erreichbar sind. Er dokumentiert ausserdem, dass ein Restore auf ein neues System das beim Backup gesetzte Passwort benötigt (SEPPmail: Quick Setup Guide). Hostname, Zertifikat, GINA-Domain, Konto und Schlüssel müssen deshalb gemeinsam betrachtet werden.

Verzeichnis und Lebenszyklus für Schlüssel und Zertifikate

LDAP/LDAPS kann öffentliche Schlüssel bereitstellen, Benutzer- oder Gruppenbedingungen auswerten und die automatische Konto- beziehungsweise Schlüsselerzeugung begrenzen. Die Appliance kann ausserdem eigene LDAP-Endpunkte zur Verteilung gesammelter oder interner öffentlicher Schlüssel anbieten. Die benötigten Richtungen und Ports unterscheiden sich je nach Rolle; die offizielle Firewallmatrix nennt 389/636 für externe oder interne Verzeichnisabfragen sowie separate Ports für die integrierten Keyserver-Endpunkte (SEPPmail: Firewall – LDAP and Key server, SEPPmail: LDAP-based user creation).

Eine LDAP-Abfrage ist Teil des Nachrichtenpfads, sobald eine Regel ohne ihr Ergebnis nicht entscheiden kann. Search Base, Filter, Objektklasse, Bind-Identität, TLS-Vertrauen, Timeout, Cacheverhalten und Verhalten bei Nichterreichbarkeit gehören deshalb in das Betriebsmodell. Ein leerer Suchtreffer, ein Timeout und ein nicht vertrauenswürdiges Zertifikat dürfen nicht als dasselbe Ergebnis behandelt werden. Die allgemeinen Protokoll- und TLS-Anforderungen sind im LDAP-Artikel beschrieben.

Für Schlüssel und Zertifikate braucht es mindestens folgende, getrennt messbare Lebenszyklen:

Die Prüfmerkmale folgen den jeweiligen Standards und den dokumentierten Import-, Policy- und Signaturprüfungen. SEPPmail nennt bei einer ungültigen S/MIME-Signatur insbesondere CA-Vertrauen, vollständige Kette, Absenderbindung und nachträgliche Inhaltsänderung als Ursachen (SEPPmail: Reasons for an invalid signature, RFC 5280, RFC 9580).

Da Gateway, Schlüssel, Verzeichnis, GINA und Queue gemeinsam wirken, muss Hochverfügbarkeit mehr als einen virtuellen Listener abdecken. Die Frontend-/Backend-Aufteilung bestimmt, welche Zustände gemeinsam verfügbar sein müssen.

Cluster, Frontend/Backend-Trennung und Ausfallbereiche

Die allgemeine Clusterkommunikation verwendet laut Firewallmatrix SSH zwischen Appliances; Zeitsynchronisation per NTP ist im Cluster verpflichtend. Die Matrix nennt ausserdem virtuelle IPs und weist darauf hin, dass bei IP-Alias das Senden über die physische Adresse des aktiven Systems erfolgt. Firewall-, Smarthost- und Connector-Allowlisten müssen deshalb den tatsächlichen Absenderpfad abbilden, nicht nur die virtuelle Empfangsadresse (SEPPmail: Firewall – Cluster and NTP).

Ein spezielles Frontend/Backend-Cluster trennt Mailverarbeitung und dauerhafte Konfigurationsdaten. Nach Herstellerbeschreibung liegt auf dem Frontend keine Konfigurationsdatenbank; benötigte Konfiguration und Schlüsselmaterial werden vom Backend für eine Aktion bereitgestellt und danach auf dem Frontend verworfen. Bei aktiviertem Large File Transfer bleibt dennoch zusätzlicher Dateizustand auf dem Frontend erforderlich (SEPPmail: Frontend/Backend Cluster).

Diese Architektur reduziert die dauerhafte Schlüsselhaltung in der DMZ, beseitigt aber nicht alle Abhängigkeiten. Backend, SSH-Pfad, Namensauflösung, Zeit, Zertifikate und gegebenenfalls LFT-Speicher bleiben Ausfallbereiche. «Frontend nimmt SMTP an» beweist weder erreichbares Backend noch eine ausführbare Kryptoaktion. Umgekehrt beweist ein funktionsfähiges Backend nicht, dass virtuelle IP, externe Route und nächster SMTP-Hop funktionieren.

Nicht alle Einstellungen sind clusterweit. Die Mail-System-Dokumentation bezeichnet mehrere maschinenbezogene Parameter und insbesondere Extended-Postfix-Einstellungen sowie bestimmte TLS-Ziele als lokal zu pflegen. Vor Failovertests ist deshalb eine Soll-Ist-Matrix pro Knoten sinnvoll: Systemname, IP, Zertifikat, Outgoing Identity, TLS-Routen, Extended Settings, lokale Dienste, Monitoringziel und erwartete Clusterreplikation (SEPPmail: Mail System – cluster notes).

Monitoring, Logging, Backup und Recovery

Die Postmasteradresse erhält laut Hersteller wichtige Watchdog- und Daily-Report-Meldungen; ohne konfigurierte und tatsächlich erreichbare Adresse fehlt dieser Alarmweg. Ergänzend dokumentiert SEPPmail SNMP über UDP 161, NRPE über TCP 5666 sowie Syslog über UDP 514 oder TLS-geschütztes TCP 6514. Welche Werte und Ereignisse überwacht werden, muss pro Installation festgelegt werden; eine offene Monitoring-Schnittstelle allein ist kein Healthcheck (SEPPmail: Mail System – Postmaster, SEPPmail: Firewall – Monitoring and Syslog).

Ein aussagekräftiges Dashboard trennt mindestens SMTP-Annahme und -Ablehnungen, Queuealter pro Next Hop, Ruleset-Fehler, Kryptoerfolg und -fehler, Zertifikatsablauf, OCSP/CRL- und MPKI-Erreichbarkeit, LDAP-Latenz, GINA-Login- und Zustellfehler, Plattenzustand, Clusterkommunikation und Backupalter. Schwellwerte brauchen Bezug zu normalem Durchsatz und vereinbartem RPO/RTO. Eine hohe Queue kann eine langsame Gegenstelle anzeigen; eine leere Queue kann ebenso bedeuten, dass keine Nachricht mehr angenommen wird.

Der Quick Setup Guide beschreibt ein passwortgeschütztes Backup, das Appliance-Daten einschliesslich registrierter Benutzer und Zertifikate sichert, Logs jedoch ausnimmt. Das Passwort wird für den Restore auf ein neues System benötigt. Der Guide beschreibt zudem eine nächtliche Zustellung an den «Backup Operator» (SEPPmail: Quick Setup Guide). Daraus folgen drei getrennte Kontrollen:

1. Die Backupdatei muss ausserhalb der Appliance ankommen und ihr Alter überwacht werden.
2. Das Backup-Passwort muss getrennt, zugriffsgeschützt und im Notfall verfügbar sein.
3. Logs brauchen einen eigenen Export- und Aufbewahrungspfad, wenn sie für Forensik oder Nachweis erhalten bleiben sollen.

Ein Restore ist erst getestet, wenn das Zielsystem startet, Netzwerk und Lizenzen passen, Regeln aktiv sind, SMTP in beide Richtungen funktioniert, historische S/MIME-/OpenPGP- und GINA-Inhalte entschlüsselt werden können und ein dokumentierter Testfall die erwartete Policy ausführt. Clusterreplikation ersetzt diesen Test nicht: Sie adressiert Verfügbarkeit, nicht eine unabhängige Kopie gegen Fehlkonfiguration, Löschung oder kompromittierte Schlüssel.

Die Diagnose folgt einer Nachricht von SMTP-Annahme über Rulematch und Schlüsselentscheidung bis zum gewählten Ausgang oder GINA-Portal.

Diagnosewerkzeuge

Die Fehlersuche folgt der Nachricht vom öffentlichen Namen über SMTP und TLS bis zum Ruleset und gewählten Verschlüsselungsweg. So wird zuerst der Transport belegt, bevor Schlüssel- oder Portalfunktionen verändert werden.

DNS, MX und öffentliche Namen

Resolve-DnsName -Type MX example.ch
Resolve-DnsName securemail.example.ch -Type A,AAAA
Resolve-DnsName _25._tcp.securemail.example.ch -Type TLSA

dig +short MX example.ch
dig +short A securemail.example.ch
dig +short AAAA securemail.example.ch
dig +short TLSA _25._tcp.securemail.example.ch

Resolve-DnsName und dig prüfen MX, Gatewayadresse und gegebenenfalls DANE-TLSA. Dabei sind externe und interne Resolveransicht getrennt zu testen. Der GINA-Hostname muss zusätzlich zum Zertifikat passen; der MX allein sagt nichts über den nachgelagerten Forwarding Server oder Exchange-Online-Connector aus (RFC 5321: Address resolution and mail routing, RFC 7672).

TCP-, SMTP- und STARTTLS-Erreichbarkeit

Test-NetConnection securemail.example.ch -Port 25 -InformationLevel Detailed
Test-NetConnection securemail.example.ch -Port 443 -InformationLevel Detailed
curl.exe --verbose --ssl-reqd smtp://securemail.example.ch:25

nc -vz securemail.example.ch 25
nc -vz securemail.example.ch 443
openssl s_client -starttls smtp -connect securemail.example.ch:25 \
  -servername securemail.example.ch -showcerts

Test-NetConnection und nc belegen nur TCP-Erreichbarkeit. Windows-curl.exe kann STARTTLS anfordern; openssl s_client zeigt auf Unix-Systemen SMTP-Fähigkeiten, Handshake und Zertifikatskette. Für eine kontrollierte SMTP-Transaktion mit Envelope und DATA eignet sich swaks; sie darf nur gegen autorisierte Testempfänger erfolgen. Ein Zustelltest ist erst mit Queue-ID, Logereignis und Ankunft am nächsten Hop vollständig.

GINA-HTTPS und Zertifikatsname

Invoke-WebRequest -Method Head -Uri https://securemail.example.ch/

curl --head --verbose https://securemail.example.ch/
openssl s_client -connect securemail.example.ch:443 \
  -servername securemail.example.ch -showcerts

Invoke-WebRequest und curl prüfen HTTP-Erreichbarkeit und Antwortverhalten; openssl s_client macht die ausgehandelte TLS-Sitzung und präsentierte Kette sichtbar. Ein 200, 301 oder 302 belegt noch weder erfolgreiche GINA-Anmeldung noch Zugriff auf eine historische Nachricht. Dafür braucht es einen synthetischen Benutzerfluss mit Registrierung, Login, Lesen, Antworten und Reset gemäss der konfigurierten GINA-Domain.

Paketpfad an einer autorisierten Messstelle

pktmon filter remove
pktmon filter add SEPPmail-SMTP -p 25
pktmon start --capture --pkt-size 0 --file-name seppmail.etl
pktmon stop
pktmon pcapng seppmail.etl -o seppmail.pcapng

tcpdump -ni any -s 0 -w seppmail.pcap 'tcp port 25 or tcp port 443'

pktmon und tcpdump erfassen nur Verkehr, der die gewählte Messstelle passiert. Auf einem Administrationsclient ist das nicht automatisch der Mailverkehr zwischen Mailsystem und Gateway; nötig sind ein autorisierter Host, Port Mirror oder anderer geeigneter Beobachtungspunkt. SMTP vor STARTTLS kann personenbezogene Inhalte enthalten, HTTPS und STARTTLS liefern zumindest Metadaten. Erfassung, Zugriff, Aufbewahrung und Löschung gehören deshalb in das Incident-Runbook.

Technische Geschichte

SEPPmail beschreibt den Ursprung des Unternehmens im Jahr 2001: Gründer Stefan Klein entwickelte zunächst eine Lösung für verschlüsselte Kommunikation zwischen einer Zürcher Anwaltskanzlei und ihren Mandanten. Aus dieser Anforderung entstand das spätere Produktunternehmen (SEPPmail: Die SEPPmail-Story).

Die öffentlich dokumentierte Produktgeschichte zeigt den Ausbau von einem zentralen Verschlüsselungsgateway zu einer modularen Appliance: historische Release Notes nennen bereits 2007 eine interne CA/RA, S/MIME-Domänenverschlüsselung, Webmail-Funktionen, Anti-Spam/Antivirus und einen eingeschränkten Backupbenutzer. Spätere Generationen ergänzten unter anderem mandantenfähige Policies, REST-Schnittstellen, MPKI-Connectoren, Large File Transfer, DKIM/ARC, moderne S/MIME-Verfahren und spezialisierte Clusterrollen (SEPPmail: Revision History).

Auch der Unterbau entwickelte sich weiter. Die Revisionshistorie nennt über die Jahre OpenBSD, Postfix, Apache, Perl, GnuPG, OpenLDAP, OpenSSL/LibreSSL, Dovecot, Fetchmail und ClamAV. Für Administratoren ist diese Herkunft relevant, weil Logbegriffe, MTA-Parameter, Zertifikatsformate und Netzwerkverhalten aus diesen Komponenten stammen. Direkte Eingriffe unterhalb der Herstelleroberfläche sind daraus jedoch nicht automatisch unterstützt; insbesondere warnt die Dokumentation vor Extended-Postfix-Änderungen und deren fehlender Clustersynchronisierung (SEPPmail: Mail System).