HIN: Vertrauensraum, Mail Gateway und Stargate

HIN ist kein einzelnes Verschlüsselungsprogramm, sondern ein branchenbezogener Vertrauensraum aus geprüften Identitäten, zentralen Plattformdiensten und Zugangs- beziehungsweise Gatewaykomponenten. HIN Mail schützt E-Mail-Kommunikation, HIN Access vermittelt den Zugriff auf geschützte Webanwendungen, und eine HIN Identität verbindet die berechtigte Person oder Organisation mit kryptografischem Schlüsselmaterial. Bei Institutionen liegen Mail- und Access-Komponenten an der Grenze zwischen eigener Infrastruktur und HIN-Plattform (HIN Mail, HIN Kollektivmitgliedschaft mit Gateway).

Für Messaging-Admins sind vier Zustandsräume auseinanderzuhalten. Der lokale Mailserver besitzt Mailboxen, Connectoren und Queues. Das Gateway übernimmt Transport-, Vertrauens- und Schutzentscheidungen. Die HIN-Plattform stellt Verzeichnis-, Identitäts-, Schlüssel-, Mail- und Accessdienste bereit. Bei Empfängern ausserhalb der HIN Community kommt ein Web- und Authentisierungspfad hinzu. Eine Störung in einem Raum ist nicht automatisch eine Störung in allen anderen; ein erreichbarer SMTP-Port belegt beispielsweise weder eine gültige HIN Identität noch eine erfolgreiche Portalzustellung (HIN Gateway, HIN Mail an Nichtmitglieder).

Auch der Produktname braucht zeitliche Einordnung. Die klassische Gatewaygeneration umfasst ein Mail Gateway, MGW, und je nach Vertrag ein Access Gateway, AGW. HIN beschreibt als Nachfolger den im Projekt Stargate entwickelten, Mail-fähigen Mesh-Knoten. Er bleibt gegenüber lokalen Mailsystemen SMTP-kompatibel, verändert aber Architektur, Schlüsselverteilung, Bereitstellung und den Transport zwischen Organisationen. Aussagen zur Zielplattform dürfen deshalb nicht ungeprüft auf ein bestehendes MGW übertragen werden und umgekehrt (HIN Gateway).

Die Erklärung folgt einer Nachricht vom Absender über HIN-Identität und Gateway bis zum Empfänger. Anschliessend werden Plattformwechsel, Abhängigkeiten, Diagnose, Schlüsselmaterial und Wiederherstellung behandelt.

Architekturansatz: Vertrauensraum mit Edge-Komponenten

Das klassische Kollektivmodell liefert HIN Mail und HIN Access als virtuelle Appliances. HIN dokumentiert S/MIME-Verschlüsselung und Signatur auf Maildomänenebene sowie einen Audit-Trail; das Access Gateway arbeitet als lokaler Identitätsprovider, ordnet verifizierten Requests HIN-eIDs zu und kann vorhandene Verzeichnis- und Authentisierungsdienste einbinden (HIN Kollektivmitgliedschaft mit Gateway).

Diese Konstruktion ist ein Edge-Trust-Modell: Die Organisation kontrolliert Mailserver, DNS, Firewall, interne Zustellung und die lokale Gatewayressource; HIN betreibt die übergeordneten Vertrauens- und Plattformdienste. Der positive SMTP-Abschluss überträgt Verantwortung für eine konkrete Nachricht an den nächsten Hop; er sagt nichts darüber aus, ob der nachfolgende HIN-, Portal- oder Empfängerpfad bereits abgeschlossen ist. Für den neuen Gatewaystack weist HIN dem Kunden ausdrücklich DNS und Mailreputation zu (HIN Gateway Top-Level System Overview, RFC 5321).

Stargate verschiebt diese Grenze auf einen organisationsbezogenen Mesh-Knoten. HIN beschreibt eine cloud-native Microservice-Architektur mit REST-APIs, dezentralen Identitäten, verteiltem Schlüsselmanagement und programmierbaren Policies. Pro Organisation ist eine eigene Instanz vorgesehen; als Bereitstellungsformen nennt HIN virtuelle Images und Container sowie in der Produktbeschreibung auch OpenShift- und Kubernetes-Umgebungen. Das ist eine veröffentlichte Zielarchitektur, kein Beleg dafür, dass jede bestehende HIN-Organisation bereits so betrieben wird (HIN Gateway: Architektur und Bereitstellung, HIN Gateway Produktbeschreibung).

Technologiestack und Zuständigkeiten

Der öffentlich belegte Stack besteht aus mehreren Generationen und darf nicht zu einem einzigen Monolithen vermischt werden:

HIN dokumentiert den Nachrichtenfluss ausdrücklich als External SMTP → Postfix → MXEngine → Postfix → External SMTP. Die erzwungene Übergabe an MXEngine verhindert einen Policy-Bypass; Postfix bleibt für Zustellung und Retries zuständig. OPA/Rego hält Geschäftsregeln ausserhalb des Anwendungscodes. PostgreSQL, Vault und MinIO speichern unterschiedliche Zustandsklassen und dürfen im Backup nicht wie ein einziges Dateisystem behandelt werden (HIN Gateway Top-Level System Overview, HIN Gateway Technical and Operational Overview).

Die technische Installationsdokumentation nennt Linux-Distributionen aus den RHEL-kompatiblen Familien sowie Ubuntu und Debian, einen Docker-Compose-Betrieb auf einem einzelnen Host und VM-Images für mehrere Plattformen. Diese Supportaussage ist versions- und rolloutbezogen; massgeblich bleibt die zum Installationszeitpunkt freigegebene HIN-Dokumentation, nicht eine statisch übernommene Distributionsliste (HIN Stargate Deployment).

Der Mailstore bleibt eine andere Grenze: Laut HIN wirkt Stargate als Mail Transport Agent, während IMAP auf der bestehenden Zimbra-Plattform abgebildet bleibt. HIN Access bildet zusätzlich einen eigenständigen Authentisierungs- und Autorisierungspfad über Client, AGW beziehungsweise Access Control Service (HIN Gateway, HIN Client 3 Handbuch).

Identität und PKI mit Autorisierung

Eine HIN Identität ist mehr als eine E-Mail-Adresse. Bei der Aktivierung erzeugt der HIN Client ein Schlüsselpaar; das Passwort entsperrt das lokale Schlüsselmaterial. Im neuen Gateway erzeugt der S/MIME Keys Client kryptografische Schlüssel und Certificate Signing Requests, während Vault private Schlüssel, Credentials und sensible Konfiguration aufnimmt. Ein Zertifikat bindet einen öffentlichen Schlüssel an eine benannte Identität, ersetzt aber keine anwendungsbezogene Autorisierung (HIN Client 3 Handbuch, HIN Gateway Top-Level System Overview, RFC 5280).

Der Lebenszyklus gehört in das IAM-Runbook: Registrierung, Aktivierung, Gerätewechsel, Rollen- oder Namensänderung, Sperre, erneute Registrierung bei Schlüsselverdacht und Austritt. HIN verlangt nach der Bestellung eine Identitätsprüfung und unterscheidet persönliche eIDs von der Organisations- beziehungsweise Device-ID im Kollektivmodell. Ein funktionierender Mailtransport darf nicht als Beleg gelten, dass eine ehemalige oder falsch zugeordnete Identität keinen Zugriff mehr besitzt (HIN Identität, HIN Kollektivmitgliedschaft mit Gateway).

HIN Access und HIN Mail teilen den Vertrauensraum, aber nicht denselben Protokollfluss. Der Access Control Service kann eine Authentisierungsstufe über den SAML RequestedAuthnContext anfordern; HIN dokumentiert Profile für Passwort und MFA. Für Integrationen stellt HIN zusätzlich OAuth-2.0-Flows für Authorization Code und Client Credentials bereit. Authentisierung, Tokenausgabe und die Autorisierung durch die Zielanwendung sind getrennt zu protokollieren (HIN Authentication Context, HIN OAuth2-Integration, SAML 2.0 Core, RFC 6749).

Erst wenn Identität und PKI geklärt sind, lässt sich der Mailpfad beurteilen. Gateway und Richtlinie entscheiden je nach Absender, Empfänger und Ziel, welches Schutzverfahren angewendet wird.

Mailpfade und Schutzentscheidungen

Mit den beteiligten HIN-Komponenten im Blick kann nun der konkrete Nachrichtenweg erklärt werden. Die folgenden Fälle unterscheiden sich danach, wo Absender und Empfänger liegen und welcher Dienst die Schutzentscheidung trifft.

Zwischen HIN-Teilnehmenden

HIN beschreibt Nachrichten zwischen HIN-Adressen als automatisch datenschutzkonform übermittelt. Die Plattform kennzeichnet den Integritätsstatus im Betreff mit [HIN secured] beziehungsweise [Not secured by HIN]. Diese Markierung ist ein Benutzersignal, aber keine ausreichende technische Korrelation: Für einen Incident werden zusätzlich Envelope-Absender und -Empfänger, Internet Message-ID, Received-Kette, Gatewayereignis und Zeitfenster benötigt (HIN Mail, HIN Mail und Mobile, RFC 5322).

Ein klassischer Organisationspfad lässt sich als Mailserver → SMTP → MGW → HIN → MGW → SMTP → Mailserver beschreiben. Jede Station beendet eine Sitzung und kann eine eigene Queue besitzen. HIN beschreibt das Kollektivmodell als S/MIME-Verschlüsselung und Signatur auf Maildomänenebene; die lokale Zustellung vor und nach dieser Gatewaygrenze bleibt ein eigener Schutz- und Betriebsbereich (HIN Kollektivmitgliedschaft mit Gateway, RFC 5321).

An Personen ohne HIN-Mitgliedschaft

Bei Empfängern ohne HIN-Adresse muss der Sender die Nachricht nach HIN-Dokumentation ausdrücklich als vertraulich markieren, etwa mit (Vertraulich) im Betreff. Der Empfänger öffnet den geschützten Inhalt über einen Webpfad und authentisiert sich mit Mobilnummer und SMS-Code; eine sichere Antwort ist möglich. Damit entstehen zusätzliche Zustände: Benachrichtigungsmail, Portalobjekt, Empfängerregistrierung, zweiter Faktor, Aufbewahrung und Antwortkanal (HIN Mail an Nichtmitglieder, HIN Mail).

Eine zugestellte Benachrichtigung ist noch keine gelesene Nachricht. Synthetische Tests sollten deshalb den gesamten Pfad bis Anmeldung, Öffnen, Anhang und Antwort abdecken. Weiterleitungen aus dem Portal können den Schutzpfad verlassen; HIN weist ausdrücklich darauf hin, dass bestimmte Weiterleitungsarten unverschlüsselt versendet werden. Solche Benutzeraktionen gehören in Schulung, DLP-Modell und Incidentanalyse (HIN Mail an Nichtmitglieder).

Geräte, Applikationen und Massenversand

Das klassische Mail Gateway kann als SMTP-Schnittstelle für interne Geräte dienen; HIN dokumentiert diese Fähigkeit auch für Stargate. Die HIN-Mail-Leistungsseite weist darauf hin, dass Systemversand über das Gateway eine separate Lizenzierung erfordert. Scanner, KIS, Laboranwendungen und Batchprozesse brauchen daher einen eigenen, dokumentierten Absender-, Relay-, Mengen- und Fehlerpfad statt einer stillen Mitbenutzung des Benutzer-Mailflows (HIN Gateway, HIN Mail).

SMTP-Routing und Annahmegrenzen

Das Gateway muss für jede Richtung genau wissen, welche Domains lokal, autoritativ, weiterzuleiten oder abzulehnen sind. Unklare Zuständigkeit zwischen Exchange, Cloudconnector, Secure-Mail-Gateway und HIN-Edge erzeugt entweder Bypässe oder Schleifen. SMTP schreibt Tracezeilen vor und beschreibt Schleifenerkennung; die tatsächliche Verantwortungsübergabe erfolgt erst mit einer positiven Antwort nach dem vollständigen Nachrichteninhalt (RFC 5321, Trace Information, RFC 5321, DATA).

Für jede Route gehören mindestens diese Werte in die Betriebsdokumentation:

• lokaler Listener, Port und erwartete Quellnetze beziehungsweise Peeridentitäten;
• EHLO-Name, Envelope-Domains und autorisierte Relaybereiche;
• Reihenfolge von Spam-/Malwarefilter, HIN-Gateway und internem Mailsystem;
• nächster Hop, DNS- oder Smarthostauflösung und TLS-Anforderung;
• Verhalten bei nicht erreichbarer HIN-Plattform, Identitäts- oder Schlüsselkomponente;
• Queuealter, Retryplan, maximaler Hopcount und Bouncezuständigkeit;
• Ausnahmepfade für Geräte, Systemversand und Migrationskoexistenz.

Für Exchange Online ist das eine Connector- und nicht nur eine DNS-Frage. Microsoft dokumentiert die Routenführung zu Drittgateways sowie zertifikat- oder IP-basierte Connectorbedingungen. Die HIN-FAQ bestätigt die grundsätzliche Unterstützung hybrider und Microsoft-365-naher Architekturen, verweist für die konkrete Konfiguration aber auf kundenspezifische Migrationsdokumentation (Microsoft: Mail flow using connectors, Microsoft: Third-party cloud mail flow, HIN Gateway).

Mailstore und Clientzugriff mit Token

Mailboxzugriff und Gatewaytransport sind verschiedene Betriebsmodelle. HIN veröffentlicht für persönliche HIN-Mailkonten IMAP auf Port 993 mit TLS und Message Submission auf Port 587 mit STARTTLS; als Passwort dient ein erzeugtes Mail-Token. POP auf Port 995 ist ebenfalls dokumentiert, lädt Nachrichten aber typischerweise lokal herunter und kann sie serverseitig entfernen. Die Protokollrollen entsprechen IMAP, POP3 und Message Submission, nicht dem Gateway-zu-Gateway-Transport (HIN Mail Token Service, HIN POP-Konfiguration, RFC 9051, RFC 1939, RFC 6409).

Das HIN-Client-Handbuch dokumentiert die Ablösung des historischen lokalen Mail-Proxys durch tokenbasierten Zugriff. HIN weist für Terminalserver ausdrücklich darauf hin, dass Versand und Empfang bei deaktiviertem Proxy über Mail-Token erfolgen. Für die technische Geschichte ist das relevant: Der Client war ursprünglich Kommunikationsvermittler für HTTP, SMTP, POP und IMAP; spätere Betriebsmodelle entkoppeln Mailclient-Zugang und HIN-Identitätsclient stärker (HIN Client 3 Handbuch, HIN Client auf Terminalservern).

HIN beschreibt den bestehenden Mail Storage Agent in der Stargate-FAQ als Zimbra-basiert und vom neuen Gatewaytransport zunächst unberührt. Ein erfolgreicher Stargate-Mailflow beweist daher weder IMAP-Verfügbarkeit noch Mailboxkonsistenz. Umgekehrt kann Webmail funktionieren, während der Organisationsconnector oder Mesh-Transport gestört ist (HIN Gateway).

Der klassische Mailstore-Pfad ist nicht die einzige Betriebsform. Stargate verschiebt Funktionen und Zuständigkeiten und muss deshalb als eigener Nachrichten- und Administrationsweg verstanden werden.

Stargate als Zielarchitektur

Stargate soll die E-Mail-Kompatibilität am Rand erhalten und zugleich einen allgemeineren, dezentralen Datenaustausch ermöglichen. HIN nennt Self-Sovereign Identity, Data Mesh, Microservices, RESTful APIs, Open-Source-Komponenten und einen Mail-fähigen Mesh-Knoten. Für den Kanal zwischen Stargate-Instanzen ist ein WireGuard-basierter Anwendung-zu-Anwendung-Transport angekündigt; HIN grenzt ihn ausdrücklich von einem allgemeinen VPN-Tunnel ab (HIN Gateway).

Für Admins folgt daraus ein dreigeteilter Trace:

1. Lokal bleibt SMTP mit Annahmeantwort, Queue und Connector die überprüfbare Grenze.
2. Zwischen den Mesh-Knoten kommen Identitäts-, Discovery-, Schlüssel- und WireGuard-Kanalzustände hinzu.
3. Am Ziel entsteht wieder ein lokaler SMTP-Pfad zum empfangenden Mailsystem.

Die veröffentlichten Systemübersichten belegen Postfix, MXEngine, OPA/Rego, PostgreSQL, Vault, MinIO, IDAgent, Promtail/Loki und Prometheus-kompatible Metriken. Eine Programmiersprache oder ein vollständiger Quellbaum der Produktservices ist dort nicht ausgewiesen; diese Information wird deshalb nicht aus Containerbildern oder gleichnamigen Fremdprojekten geraten (HIN Gateway Top-Level System Overview, HIN Gateway Technical and Operational Overview).

Die Netzgrenzen des neuen Gateways sind öffentlich ungewöhnlich konkret dokumentiert:

Die lokal exponierten Diagnose- und Dienstports, darunter PostgreSQL, Vault, MinIO und Metrikendpunkte, sollen nach HIN nicht aus dem öffentlichen Internet erreichbar sein. Administrationszugriffe auf 22, 443, 8180 oder 8190 gehören auf ein definiertes Managementnetz und nicht in eine pauschale Internetfreigabe (HIN Gateway Technical and Operational Overview, HIN Stargate Deployment).

HIN beschreibt die Migration als parallelen Aufbau des neuen Gateways. Erst nach Konfiguration, Tests und bestätigter Betriebsbereitschaft entscheidet der Kunde über die Umschaltung. Bestehende IP-Adressen können grundsätzlich weiterverwendet werden, die Konfiguration muss jedoch übersetzt werden. Ein sicheres Cutover-Runbook enthält deshalb mindestens Inventar, Export, Parallelroute, Testmatrix, Umschaltkriterium, Rückweg, Queuebehandlung und klaren Rollback (HIN Gateway: Migration).

Hochverfügbarkeit mit Backup und Recovery

HIN dokumentiert für die eigene Stargate-Seite einen redundanten OpenShift-Cluster, plant aber auf Kundenseite nicht automatisch zwei redundante virtuelle Maschinen. Diese Aussagen dürfen nicht zu einer allgemeinen Ende-zu-Ende-Hochverfügbarkeit zusammengezogen werden. Ein redundanter Plattformdienst schützt nicht vor einem einzelnen lokalen Hypervisor, einer falschen Connectorregel, abgelaufenem Schlüssel oder einer blockierten Firewall (HIN Gateway).

Beim neuen Gateway persistieren die Dienste über Docker-Volumes. Vault versiegelt sich nach einem Containerneustart automatisch und verlangt einen kontrollierten Unseal-Prozess. Die technische Übersicht nennt standardmässig tägliche Backups von Datenbanken, Vault-Schlüsseln und -Secrets, Konfigurationsdateien sowie Zertifikaten; Verantwortung und Aufbewahrung sollen mit dem Kunden vereinbart werden (HIN Gateway Technical and Operational Overview).

Ein Recovery-Inventar sollte pro Generation mindestens enthalten:

Die öffentliche Backup-Liste nennt Datenbank, Vault, Konfiguration und Zertifikate, aber MinIO-Nachrichten und -Anhänge nicht ausdrücklich. Daraus darf weder deren Sicherung noch deren absichtlicher Ausschluss abgeleitet werden; genau dieser Punkt gehört vor Produktivsetzung schriftlich in Retention-, Backup- und Restorevereinbarung. Ein generischer VM-Snapshot belegt zudem weder einen konsistenten PostgreSQL-Stand noch ein wiederherstellbares Vault (HIN Gateway Technical and Operational Overview, HIN Gateway Top-Level System Overview).

Bei einer Störung wird die Nachricht von der Annahme über Identitäts- und Policyentscheidung bis zum gewählten Zustellweg verfolgt; erst danach werden einzelne Komponenten neu gestartet oder umgangen.

Monitoring und Incident-Triage

Ein brauchbares Betriebsbild kombiniert lokale und zentrale Signale:

• Verfügbarkeit und Queuealter je SMTP-Next-Hop;
• Annahme-, Weitergabe- und Bouncequoten mit korrelierbarer Message-ID;
• HIN-, Portal-, Identitäts-, Schlüssel- und Policyfehler getrennt;
• Zertifikatsablauf, Registrierungs- und Tokenstatus;
• Mailboxzugriff über Webmail und IMAP unabhängig vom Gateway;
• DNS- und Firewallauflösung über Namen statt fest verdrahteter HIN-IP-Adressen;
• Plattformmeldungen auf HIN Status plus lokale Telemetrie.

Der neue Stack liefert Prometheus-kompatible Servicemetriken, Hostmetriken über Node Exporter, zentralen Logversand über Promtail nach Loki und einen Version Collector, der Liveness-Endpunkte abfragt. Für die Alarmierung sind mindestens fehlender Scrape, ausbleibender Logeingang, Postfix-Queuealter, MXEngine-Fehler, Vault-Seal-Zustand, PostgreSQL- und MinIO-Kapazität, WireGuard-Peerzustand sowie Zertifikatsablauf getrennt zu behandeln (HIN Gateway Top-Level System Overview, HIN Gateway Technical and Operational Overview).

Die HIN-Firewalldokumentation empfiehlt DNS-Namen, weil sich IP-Adressen ändern können, und nennt für Clientdienste unter anderem HTTPS- und SMTP-Pfade. Eine globale Statusseite kann eine lokale DNS-, NAT-, MTU-, Connector- oder Schlüsselstörung nicht erkennen. Triage beginnt deshalb mit Scope: ein Benutzer, eine Identität, eine Domäne, eine Richtung, ein Gateway oder die Plattform (HIN Firewall-Anpassungen, HIN Status).

Das klassische Kollektivangebot nennt einen Audit-Trail für den Mailfluss; das neue Gateway ergänzt strukturierte zentrale Logs. Für eine durchgängige Mailanalyse müssen diese Nachweise mit lokalen SMTP- und Mailsystemlogs korreliert werden. Zeitsynchronisation und einheitliche Zeitzonen sind dabei Betriebsanforderungen, keine kosmetischen Einstellungen (HIN Kollektivmitgliedschaft mit Gateway, HIN Gateway Top-Level System Overview).

Diagnosewerkzeuge

Die Diagnose beginnt beim öffentlichen beziehungsweise internen Namen und folgt danach dem tatsächlichen Mailpfad. Erst wenn DNS, Verbindung und Zertifikat stimmen, werden Gatewayzustand, Queue und HIN-spezifische Ereignisse ausgewertet.

DNS und HIN-Endpunkte

Resolve-DnsName gateway.hin.ch -Type A
Resolve-DnsName gateway.hin.ch -Type AAAA
Resolve-DnsName smtp.mail.hin.ch -Type A

dig +short A gateway.hin.ch
dig +short AAAA gateway.hin.ch
dig +short A smtp.mail.hin.ch

Resolve-DnsName und dig zeigen, ob die dokumentierten Namen aus der tatsächlich verwendeten Resolverperspektive auflösbar sind. Das ist gerade bei Split-DNS und Proxys wichtiger als ein kopierter IP-Wert; HIN empfiehlt ausdrücklich DNS-Namen statt langfristig festgelegter Adressen (HIN Firewall-Anpassungen).

TCP- und TLS-Erreichbarkeit

Test-NetConnection hin-gateway.example.ch -Port 25 -InformationLevel Detailed
Test-NetConnection hin-gateway.example.ch -Port 19818 -InformationLevel Detailed
curl.exe --verbose --ssl-reqd smtp://hin-gateway.example.ch:25

nc -vz hin-gateway.example.ch 25
nc -vz hin-gateway.example.ch 19818
nc -vzu hin-gateway.example.ch 19818
openssl s_client -starttls smtp -connect hin-gateway.example.ch:25 \
  -servername hin-gateway.example.ch -showcerts

Test-NetConnection und nc belegen den TCP-Pfad. Der UDP-Aufruf von nc kann allenfalls Erreichbarkeit andeuten; weil WireGuard unautorisierte Pakete ohne Antwort verwirft, ist erst der authentisierte Peer-Handshake ein belastbarer Nachweis für Port 19818. Windows-curl.exe und openssl s_client prüfen den SMTP-/STARTTLS-Rand. Ein erfolgreicher Handshake beweist noch keine Policyverarbeitung oder Nachrichtenzustellung (HIN Gateway Technical and Operational Overview, RFC 8446).

Kontrollierte SMTP-Transaktion

curl.exe --verbose --url smtp://hin-gateway.intern.example:25 `
  --mail-from hin-test@example.ch `
  --mail-rcpt test-recipient@example.net `
  --upload-file .\hin-test.eml

swaks --server hin-gateway.intern.example --port 25 \
  --from hin-test@example.ch --to test-recipient@example.net \
  --data hin-test.eml

curl und swaks dürfen nur gegen einen ausdrücklich autorisierten Listener und Testempfänger eingesetzt werden. Erfasst werden Endantwort nach DATA, lokale Queue-ID, Gatewayereignis, gewählter Schutzpfad, nächster Hop und tatsächliche Ankunft. Ein 250 auf RCPT TO ist noch keine Annahme des Nachrichteninhalts (RFC 5321).

Lokale Socketzustände

Get-NetTCPConnection -State Listen,Established |
  Where-Object LocalPort -In 25,443,587,993

ss -tanp '( sport = :25 or sport = :443 or sport = :587 or sport = :993 )'

Get-NetTCPConnection und ss zeigen lokale Listener und etablierte TCP-Sitzungen. Sie sind nur dort sinnvoll, wo der Administrator Zugriff auf den betreffenden Host hat; ein verwaltetes Appliance- oder Containerprodukt darf nicht durch undokumentierte Shellzugriffe verändert werden.

Paketpfad an der richtigen Messstelle

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

tcpdump -ni any -s 0 -w hin.pcap \
  'tcp port 25 or tcp port 443 or tcp port 587 or tcp port 993'

pktmon und tcpdump sehen nur den Verkehr an der gewählten Messstelle. Für Stargate kann ein lokaler SMTP-Trace den Mesh-Kanal nicht vollständig erklären; dafür werden zusätzlich Gateway- und Plattformereignisse benötigt. Mitschnitte können Adressen, Betreffzeilen oder unverschlüsselte Protokollteile enthalten und müssen wie sensible Betriebsdaten behandelt werden.

Technische Geschichte

Die FMH und die Ärztekasse gründeten die Health Info Net AG 1996, als E-Mail im Gesundheitswesen aufkam und der Versand sensibler Daten über reguläre Internetmail als unzureichend geschützt erkannt wurde. HIN begann damit als Anbieter geschützter E-Mail-Kommunikation für die Ärzteschaft und entwickelte sich zu einem breiteren Vertrauens- und Zugangsraum (HIN Unternehmensgeschichte).

Die Clientarchitektur zeigt den technischen Wandel. HIN Client 1 und 2 wurden durch HIN Client 3 abgelöst. Aus Kompatibilitätsgründen arbeitete der Client weiterhin als lokaler Proxy für Browser und Mailprogramme; für Webzugriff dokumentiert HIN später Challenge/Response, für Mailkonten den Übergang zu unabhängigen Tokens über Standardports. Die Historie erklärt, warum ältere Installationsanleitungen lokale Proxyports nennen, während neuere Unterlagen direkte IMAP-, POP- und Submission-Endpunkte verwenden (HIN Client 3 Handbuch, HIN Mail Token Service).

Das klassische HIN-Kollektivmodell bündelte Mail- und Access-Appliances im Kundennetz. Die heutige Leistungsseite dokumentiert für diese Generation S/MIME auf Maildomänenebene, Audit-Trail, einen lokalen Identitätsprovider sowie die Anbindung vorhandener Authentisierungs- und Verzeichnisdienste. Diese Funktionen erklären die gewachsene Trennung zwischen Mailtransport und Webzugriff (HIN Kollektivmitgliedschaft mit Gateway).

Ab 2025 führte HIN eine neue Nichtmitglieder-Zustellung ein; zugleich wurde die Plattform- und Access-Infrastruktur erneuert. Die 2026 veröffentlichte Gateway-Dokumentation beschreibt Stargate als nächsten Generationswechsel: weg von einem ausschliesslichen Mail-Verschlüsselungsgateway, hin zu einem dezentralen, cloud-nativen Knoten für Mail und strukturierten Gesundheitsdatenaustausch. Die technischen Unterlagen machen diesen Wechsel mit Postfix, MXEngine, OPA/Rego, PostgreSQL, Vault, MinIO und containerisiertem Betrieb konkret. Für einen Migrationsplan zählt deshalb nicht nur das Ersetzen einer VM, sondern die Neuvermessung von Identität, Schlüssel, Transport, Observability und Recovery (HIN Mail, HIN Access, HIN Gateway, HIN Gateway Top-Level System Overview).