HIN: Tillitsområde, e-postgateway og Stargate

HIN er ikke et enkelt krypteringsprogram, men et bransjerelatert tillitsområde bestående av verifiserte identiteter, sentrale plattformtjenester og tilgangs- eller gatewaykomponenter. HIN Mail beskytter e-postkommunikasjon, HIN Access formidler tilgang til beskyttede webapplikasjoner, og en HIN-identitet kobler den autoriserte personen eller organisasjonen med kryptografisk nøkkelmateriale. Hos institusjoner ligger e-post- og Access-komponentene i grensen mellom egen infrastruktur og HIN-plattformen (HIN Mail, HIN kollektivmedlemskap med gateway).

For meldingsadministratorer må fire tilstandsrom holdes atskilt. Den lokale e-postserveren har postbokser, connectorer og køer. Gatewayen tar beslutninger om transport, tillit og beskyttelse. HIN-plattformen stiller katalog-, identitets-, nøkkel-, e-post- og Access-tjenester til rådighet. For mottakere utenfor HIN Community kommer det i tillegg en web- og autentiseringsvei. En feil i ett rom er ikke automatisk en feil i alle de andre; en tilgjengelig SMTP-port beviser for eksempel verken en gyldig HIN-identitet eller vellykket portallevering (HIN Gateway, HIN Mail til ikke-medlemmer).

Også produktnavnet trenger tidsmessig plassering. Den klassiske gatewaygenerasjonen omfatter en Mail Gateway, MGW, og avhengig av avtalen en Access Gateway, AGW. HIN beskriver som etterfølger den e-postkompatible mesh-noden som er utviklet i prosjektet Stargate. Den forblir SMTP-kompatibel overfor lokale e-postsystemer, men endrer arkitektur, nøkkeldistribusjon, utrulling og transporten mellom organisasjoner. Utsagn om målplattformen må derfor ikke uten videre overføres til en eksisterende MGW, og omvendt (HIN Gateway).

Forklaringen følger en melding fra avsenderen via HIN-identitet og gateway til mottakeren. Deretter behandles plattformbytte, avhengigheter, diagnose, nøkkelmateriale og gjenoppretting.

Arkitekturtilnærming: tillitsområde med edge-komponenter

Den klassiske kollektivmodellen leverer HIN Mail og HIN Access som virtuelle apparater. HIN dokumenterer S/MIME-kryptering og -signatur på e-postdomenenivå samt et revisjonsspor; Access Gateway fungerer som lokal identitetsleverandør, tilordner HIN-eID-er til verifiserte forespørsler og kan integrere eksisterende katalog- og autentiseringstjenester (HIN kollektivmedlemskap med gateway).

Denne konstruksjonen er en edge-tillitsmodell: Organisasjonen kontrollerer e-postservere, DNS, brannmur, intern levering og den lokale gatewayressursen; HIN driver de overordnede tillits- og plattformtjenestene. En positiv SMTP-avslutning overfører ansvaret for en konkret melding til neste hop; den sier ingenting om hvorvidt den etterfølgende HIN-, portal- eller mottakerveien allerede er fullført. For den nye gatewaystakken tilordner HIN uttrykkelig kunden DNS og e-postomdømme (HIN Gateway Top-Level System Overview, RFC 5321).

Stargate flytter denne grensen til en organisasjonsrelatert mesh-node. HIN beskriver en skyinnfødt mikrotjenestearkitektur med REST-API-er, desentraliserte identiteter, distribuert nøkkelhåndtering og programmerbare policyer. Det er planlagt en egen instans per organisasjon; HIN nevner virtuelle avbilder og containere som utrullingsformer, samt også OpenShift- og Kubernetes-miljøer i produktbeskrivelsen. Dette er en publisert målarkitektur, ikke bevis for at enhver eksisterende HIN-organisasjon allerede drives slik (HIN Gateway: arkitektur og utrulling, HIN Gateway-produktbeskrivelse).

Teknologistack og ansvarsområder

Den offentlig dokumenterte stacken består av flere generasjoner og må ikke blandes til én enkelt monolitt:

HIN dokumenterer meldingsflyten uttrykkelig som External SMTP → Postfix → MXEngine → Postfix → External SMTP. Den tvungne overleveringen til MXEngine forhindrer en policy-bypass; Postfix forblir ansvarlig for levering og retryer. OPA/Rego holder forretningsregler utenfor applikasjonskoden. PostgreSQL, Vault og MinIO lagrer ulike tilstandsklasser og må ikke behandles som ett enkelt filsystem i sikkerhetskopieringen (HIN Gateway Top-Level System Overview, HIN Gateway Technical and Operational Overview).

Den tekniske installasjonsdokumentasjonen nevner Linux-distribusjoner fra RHEL-kompatible familier samt Ubuntu og Debian, Docker Compose-drift på én enkelt vert og VM-avbilder for flere plattformer. Denne støtteerklæringen er versjons- og utrullingsrelatert; det avgjørende er HIN-dokumentasjonen som er godkjent på installasjonstidspunktet, ikke en statisk overført distribusjonsliste (HIN Stargate Deployment).

E-postlageret forblir en annen grense: Ifølge HIN fungerer Stargate som Mail Transport Agent, mens IMAP fortsatt er lagt til den eksisterende Zimbra-plattformen. HIN Access utgjør i tillegg en selvstendig autentiserings- og autoriseringsvei via klient, AGW eller Access Control Service (HIN Gateway, HIN Client 3-håndbok).

Identitet og PKI med autorisering

En HIN-identitet er mer enn en e-postadresse. Ved aktivering oppretter HIN Client et nøkkelpar; passordet låser opp det lokale nøkkelmaterialet. I den nye gatewayen genererer S/MIME Keys Client kryptografiske nøkler og Certificate Signing Requests, mens Vault lagrer private nøkler, legitimasjon og sensitiv konfigurasjon. Et sertifikat knytter en offentlig nøkkel til en navngitt identitet, men erstatter ikke applikasjonsrelatert autorisering (HIN Client 3-håndbok, HIN Gateway Top-Level System Overview, RFC 5280).

Livssyklusen hører hjemme i IAM-runbooken: registrering, aktivering, enhetsbytte, rolle- eller navneendring, sperring, ny registrering ved mistanke om nøkkelkompromittering og uttreden. HIN krever en identitetskontroll etter bestilling og skiller mellom personlige eID-er og organisasjons- eller Device-ID i kollektivmodellen. En fungerende e-posttransport må ikke anses som bevis på at en tidligere eller feiltilordnet identitet ikke lenger har tilgang (HIN-identitet, HIN kollektivmedlemskap med gateway).

HIN Access og HIN Mail deler tillitsområdet, men ikke den samme protokollflyten. Access Control Service kan be om et autentiseringsnivå via SAML RequestedAuthnContext; HIN dokumenterer profiler for passord og MFA. For integrasjoner tilbyr HIN også OAuth 2.0-flyter for Authorization Code og Client Credentials. Autentisering, tokenutstedelse og autorisering gjennom målapplikasjonen skal loggføres separat (HIN Authentication Context, HIN OAuth2-integrasjon, SAML 2.0 Core, RFC 6749).

Først når identitet og PKI er avklart, kan e-postveien vurderes. Gateway og policy avgjør, avhengig av avsender, mottaker og mål, hvilken beskyttelsesmetode som brukes.

E-postveier og beskyttelsesbeslutninger

Med de involverte HIN-komponentene i mente kan den konkrete meldingsveien nå forklares. Følgende tilfeller skiller seg etter hvor avsender og mottaker befinner seg, og hvilken tjeneste som treffer beskyttelsesbeslutningen.

Mellom HIN-deltakere

HIN beskriver meldinger mellom HIN-adresser som automatisk overført i samsvar med personvernet. Plattformen markerer integritetsstatusen i emnefeltet med [HIN secured] eller [Not secured by HIN]. Denne markeringen er et brukersignal, men ikke tilstrekkelig teknisk korrelasjon: For en hendelse trengs i tillegg envelope-avsender og -mottaker, Internet Message-ID, Received-kjeden, gatewayhendelsen og tidsvinduet (HIN Mail, HIN Mail og Mobile, RFC 5322).

En klassisk organisasjonsvei kan beskrives som Mailserver → SMTP → MGW → HIN → MGW → SMTP → Mailserver. Hver stasjon avslutter en økt og kan ha sin egen kø. HIN beskriver kollektivmodellen som S/MIME-kryptering og -signatur på e-postdomenenivå; den lokale leveringen før og etter denne gatewaygrensen forblir et eget beskyttelses- og driftsområde (HIN kollektivmedlemskap med gateway, RFC 5321).

Til personer uten HIN-medlemskap

For mottakere uten HIN-adresse må avsenderen ifølge HIN-dokumentasjonen uttrykkelig merke meldingen som konfidensiell, for eksempel med (Vertraulich) i emnefeltet. Mottakeren åpner det beskyttede innholdet via en webvei og autentiserer seg med mobilnummer og SMS-kode; et sikkert svar er mulig. Dermed oppstår ytterligere tilstander: varslings-e-post, portalobjekt, mottakerregistrering, andre faktor, oppbevaring og svarkanal (HIN Mail til ikke-medlemmer, HIN Mail).

Et levert varsel er ennå ikke en lest melding. Syntetiske tester bør derfor dekke hele veien frem til pålogging, åpning, vedlegg og svar. Videresendinger fra portalen kan forlate beskyttelsesveien; HIN påpeker uttrykkelig at visse videresendingstyper sendes ukryptert. Slike brukerhandlinger hører hjemme i opplæring, DLP-modell og hendelsesanalyse (HIN Mail til ikke-medlemmer).

Enheter, applikasjoner og masseutsendelse

Den klassiske Mail Gateway kan fungere som SMTP-grensesnitt for interne enheter; HIN dokumenterer denne muligheten også for Stargate. HIN Mail-tjenestesiden påpeker at systemutsendelse via gatewayen krever separat lisensiering. Skannere, KIS, laboratorieapplikasjoner og batchprosesser trenger derfor en egen, dokumentert avsender-, relay-, mengde- og feilvei i stedet for skjult medbruk av brukerens e-postflyt (HIN Gateway, HIN Mail).

SMTP-ruting og mottaksgrenser

Gatewayen må for hver retning vite nøyaktig hvilke domener som er lokale, autoritative, skal videresendes eller avvises. Uklar ansvarsfordeling mellom Exchange, cloud connector, Secure Mail Gateway og HIN-edge fører enten til bypasser eller løkker. SMTP krever sporlinjer og beskriver løkkedeteksjon; den faktiske ansvarsoverføringen skjer først med et positivt svar etter hele meldingsinnholdet (RFC 5321, Trace Information, RFC 5321, DATA).

For hver rute må minst disse verdiene inngå i driftsdokumentasjonen:

• lokal listener, port og forventede kildenettverk eller peeridentiteter;
• EHLO-navn, envelope-domener og autoriserte relayområder;
• rekkefølge på spam-/skadevarefilter, HIN-gateway og internt e-postsystem;
• neste hop, DNS- eller smarthost-oppløsning og TLS-krav;
• atferd når HIN-plattformen, identitets- eller nøkkelkomponenten ikke er tilgjengelig;
• køalder, retryplan, maksimalt hopptall og bounce-ansvar;
• unntaksveier for enheter, systemutsendelse og migreringssameksistens.

For Exchange Online er dette et spørsmål om connectorer og ikke bare DNS. Microsoft dokumenterer ruting til tredjepartsgatewayer samt sertifikat- eller IP-baserte connectorbetingelser. HIN-FAQ-en bekrefter grunnleggende støtte for hybride og Microsoft 365-nære arkitekturer, men viser for konkret konfigurasjon til kundespesifikk migreringsdokumentasjon (Microsoft: Mail flow using connectors, Microsoft: Third-party cloud mail flow, HIN Gateway).

E-postlager og klienttilgang med token

Postbokstilgang og gatewaytransport er forskjellige driftsmodeller. HIN publiserer IMAP på port 993 med TLS og Message Submission på port 587 med STARTTLS for personlige HIN-e-postkontoer; et generert e-posttoken brukes som passord. POP på port 995 er også dokumentert, men laster vanligvis ned meldinger lokalt og kan fjerne dem på serversiden. Protokollrollene samsvarer med IMAP, POP3 og Message Submission, ikke gateway-til-gateway-transport (HIN Mail Token Service, HIN POP-konfigurasjon, RFC 9051, RFC 1939, RFC 6409).

HIN Client-håndboken dokumenterer at den historiske lokale e-postproxyen erstattes av tokenbasert tilgang. HIN påpeker uttrykkelig for terminalservere at sending og mottak skjer via e-posttoken når proxyen er deaktivert. Dette er relevant for den tekniske historien: Klienten var opprinnelig kommunikasjonsformidler for HTTP, SMTP, POP og IMAP; senere driftsmodeller kobler tilgang til e-postklient og HIN-identitetsklient sterkere fra hverandre (HIN Client 3-håndbok, HIN Client på terminalservere).

HIN beskriver den eksisterende Mail Storage Agent i Stargate-FAQ-en som Zimbra-basert og foreløpig uberørt av den nye gatewaytransporten. En vellykket Stargate-e-postflyt beviser derfor verken IMAP-tilgjengelighet eller postbokkonsistens. Omvendt kan webmail fungere mens organisasjonsconnectoren eller mesh-transporten er forstyrret (HIN Gateway).

Den klassiske e-postlagerveien er ikke den eneste driftsformen. Stargate forskyver funksjoner og ansvar, og må derfor forstås som en egen meldings- og administrasjonsvei.

Stargate som målarkitektur

Stargate skal bevare e-postkompatibiliteten ved kanten og samtidig muliggjøre mer generell, desentralisert datautveksling. HIN nevner Self-Sovereign Identity, Data Mesh, mikrotjenester, RESTful API-er, open source-komponenter og en e-postkompatibel mesh-node. For kanalen mellom Stargate-instanser er en WireGuard-basert applikasjon-til-applikasjon-transport annonsert; HIN avgrenser den uttrykkelig fra en generell VPN-tunnel (HIN Gateway).

For administratorer følger dette tredelte sporet:

1. Lokalt forblir SMTP med mottakssvar, kø og connector den kontrollerbare grensen.
2. Mellom mesh-nodene kommer identitets-, discovery-, nøkkel- og WireGuard-kanaltilstander i tillegg.
3. Ved målet oppstår igjen en lokal SMTP-vei til det mottakende e-postsystemet.

De publiserte systemoversiktene dokumenterer Postfix, MXEngine, OPA/Rego, PostgreSQL, Vault, MinIO, IDAgent, Promtail/Loki og Prometheus-kompatible måledata. Et programmeringsspråk eller et komplett kildekodetre for produkttjenestene er ikke oppgitt der; denne informasjonen skal derfor ikke gjettes fra containeravbilder eller fremmedprosjekter med samme navn (HIN Gateway Top-Level System Overview, HIN Gateway Technical and Operational Overview).

Nettverksgrensene for den nye gatewayen er offentlig dokumentert på en uvanlig konkret måte:

De lokalt eksponerte diagnose- og tjenesteportene, herunder PostgreSQL, Vault, MinIO og metrikkendepunkter, skal ifølge HIN ikke være tilgjengelige fra det offentlige internettet. Administrasjonstilgang på 22, 443, 8180 eller 8190 hører til et definert administrasjonsnettverk og ikke en generell internettåpning (HIN Gateway Technical and Operational Overview, HIN Stargate Deployment).

HIN beskriver migreringen som en parallell oppbygging av den nye gatewayen. Først etter konfigurasjon, tester og bekreftet driftsberedskap bestemmer kunden om omkoblingen. Eksisterende IP-adresser kan i utgangspunktet gjenbrukes, men konfigurasjonen må oversettes. En sikker cutover-runbook inneholder derfor minst inventar, eksport, parallellrute, testmatrise, omkoblingskriterium, returrute, køhåndtering og tydelig rollback (HIN Gateway: migrering).

Høy tilgjengelighet med backup og gjenoppretting

HIN dokumenterer en redundant OpenShift-klynge for sin egen Stargate-side, men planlegger ikke automatisk to redundante virtuelle maskiner på kundesiden. Disse utsagnene må ikke trekkes sammen til en generell ende-til-ende-høytilgjengelighet. En redundant plattformtjeneste beskytter ikke mot én enkelt lokal hypervisor, en feil connectorregel, utløpt nøkkel eller blokkert brannmur (HIN Gateway).

I den nye gatewayen persisterer tjenestene via Docker-volumer. Vault forsegler seg automatisk etter en containeromstart og krever en kontrollert unseal-prosess. Den tekniske oversikten nevner som standard daglige sikkerhetskopier av databaser, Vault-nøkler og -hemmeligheter, konfigurasjonsfiler samt sertifikater; ansvar og oppbevaring skal avtales med kunden (HIN Gateway Technical and Operational Overview).

Et gjenopprettingsinventar bør per generasjon minst inneholde:

Den offentlige backuplisten nevner database, Vault, konfigurasjon og sertifikater, men ikke uttrykkelig MinIO-meldinger og -vedlegg. Derav kan verken sikkerhetskopiering eller bevisst utelatelse avledes; nettopp dette punktet hører skriftlig hjemme i en avtale om retention, backup og restore før produksjonssetting. Et generisk VM-snapshot beviser dessuten verken en konsistent PostgreSQL-tilstand eller en gjenopprettbar Vault (HIN Gateway Technical and Operational Overview, HIN Gateway Top-Level System Overview).

Ved en feil følges meldingen fra mottak via identitets- og policybeslutning til valgt leveringsvei; først deretter startes eller omgås enkeltkomponenter på nytt.

Overvåking og hendelsestriage

Et brukbart driftsbilde kombinerer lokale og sentrale signaler:

• tilgjengelighet og køalder per SMTP-neste-hop;
• mottaks-, overleverings- og bouncekvoter med korrelerbar Message-ID;
• HIN-, portal-, identitets-, nøkkel- og policyfeil separat;
• sertifikatutløp, registrerings- og tokenstatus;
• postbokstilgang via webmail og IMAP uavhengig av gatewayen;
• DNS- og brannmuroppløsning via navn i stedet for fastkodede HIN-IP-adresser;
• plattformmeldinger på HIN Status pluss lokal telemetri.

Den nye stacken leverer Prometheus-kompatible tjenestemåledata, vertsmetrikk via Node Exporter, sentral loggvideresending via Promtail til Loki og en Version Collector som spør liveness-endepunkter. For varsling må minst manglende scrape, uteblivende loggmottak, Postfix-køalder, MXEngine-feil, Vault-seal-tilstand, PostgreSQL- og MinIO-kapasitet, WireGuard-peer-tilstand samt sertifikatutløp behandles separat (HIN Gateway Top-Level System Overview, HIN Gateway Technical and Operational Overview).

HINs brannmurdokumentasjon anbefaler DNS-navn fordi IP-adresser kan endres, og nevner blant annet HTTPS- og SMTP-veier for klienttjenester. En global statusside kan ikke oppdage en lokal DNS-, NAT-, MTU-, connector- eller nøkkelfeil. Triage begynner derfor med omfang: én bruker, én identitet, ett domene, én retning, én gateway eller plattformen (HIN brannmurtilpasninger, HIN Status).

Det klassiske kollektivtilbudet nevner et revisjonsspor for e-postflyten; den nye gatewayen supplerer dette med strukturerte sentrale logger. For en sammenhengende e-postanalyse må disse bevisene korreleres med lokale SMTP- og e-postsystemlogger. Tidssynkronisering og ensartede tidssoner er driftskrav, ikke kosmetiske innstillinger (HIN kollektivmedlemskap med gateway, HIN Gateway Top-Level System Overview).

Diagnoseverktøy

Diagnosen starter med det offentlige eller interne navnet og følger deretter den faktiske e-postveien. Først når DNS, forbindelse og sertifikat er riktige, evalueres gatewaytilstand, kø og HIN-spesifikke hendelser.

DNS og HIN-endepunkter

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 og dig viser om de dokumenterte navnene kan løses opp fra perspektivet til resolveren som faktisk brukes. Dette er viktigere enn en kopiert IP-verdi, særlig ved split-DNS og proxyer; HIN anbefaler uttrykkelig DNS-navn i stedet for langsiktig fastlagte adresser (HIN brannmurtilpasninger).

TCP- og TLS-tilgjengelighet

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 og nc dokumenterer TCP-veien. UDP-kallet fra nc kan høyst indikere tilgjengelighet; fordi WireGuard forkaster uautoriserte pakker uten svar, er det først det autentiserte peer-håndtrykket som er et pålitelig bevis for port 19818. Windows-curl.exe og openssl s_client kontrollerer SMTP-/STARTTLS-randen. Et vellykket håndtrykk beviser ennå ikke policybehandling eller meldingslevering (HIN Gateway Technical and Operational Overview, RFC 8446).

Kontrollert SMTP-transaksjon

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 og swaks må bare brukes mot en uttrykkelig autorisert listener og testmottaker. Det registreres sluttrespons etter DATA, lokal kø-ID, gatewayhendelse, valgt beskyttelsesvei, neste hop og faktisk ankomst. En 250 på RCPT TO er ennå ikke et mottak av meldingsinnholdet (RFC 5321).

Lokale sockettilstander

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 og ss viser lokale listenere og etablerte TCP-økter. De er bare nyttige der administratoren har tilgang til den aktuelle verten; et administrert apparat- eller containerprodukt må ikke endres gjennom udokumentert shell-tilgang.

Pakkebane ved riktig målepunkt

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 og tcpdump ser bare trafikken ved det valgte målepunktet. For Stargate kan et lokalt SMTP-spor ikke fullt ut forklare mesh-kanalen; det trengs i tillegg gateway- og plattformhendelser. Opptak kan inneholde adresser, emnelinjer eller ukrypterte protokolldeler og må behandles som sensitive driftsdata.

Teknisk historie

FMH og Ärztekasse grunnla Health Info Net AG i 1996, da e-post i helsevesenet vokste frem og sending av sensitive data via vanlig internett-e-post ble ansett som utilstrekkelig beskyttet. HIN startet dermed som leverandør av beskyttet e-postkommunikasjon for leger og utviklet seg til et bredere tillits- og tilgangsområde (HIN selskapshistorie).

Klientarkitekturen viser den tekniske endringen. HIN Client 1 og 2 ble erstattet av HIN Client 3. Av kompatibilitetshensyn fortsatte klienten å fungere som lokal proxy for nettlesere og e-postprogrammer; for webtilgang dokumenterte HIN senere Challenge/Response, og for e-postkontoer overgangen til uavhengige token via standardporter. Historikken forklarer hvorfor eldre installasjonsveiledninger nevner lokale proxyporter, mens nyere dokumentasjon bruker direkte IMAP-, POP- og Submission-endepunkter (HIN Client 3-håndbok, HIN Mail Token Service).

Den klassiske HIN-kollektivmodellen samlet Mail- og Access-apparater i kundenettverket. Den nåværende tjenestesiden dokumenterer S/MIME på e-postdomenenivå, revisjonsspor, en lokal identitetsleverandør og tilkobling av eksisterende autentiserings- og katalogtjenester for denne generasjonen. Disse funksjonene forklarer det utviklede skillet mellom e-posttransport og webtilgang (HIN kollektivmedlemskap med gateway).

Fra 2025 innførte HIN en ny levering til ikke-medlemmer; samtidig ble plattform- og Access-infrastrukturen fornyet. Gateway-dokumentasjonen som ble publisert i 2026, beskriver Stargate som neste generasjonsskifte: fra en utelukkende e-postkrypteringsgateway til en desentralisert, skyinnfødt node for e-post og strukturert utveksling av helsedata. Den tekniske dokumentasjonen konkretiserer denne endringen med Postfix, MXEngine, OPA/Rego, PostgreSQL, Vault, MinIO og containerisert drift. For en migreringsplan er det derfor ikke nok å bytte ut en VM, men identitet, nøkler, transport, observability og recovery må måles på nytt (HIN Mail, HIN Access, HIN Gateway, HIN Gateway Top-Level System Overview).

Kilder

• HIN – HIN Mail
• HIN – Kollektivmedlemskap med gateway
• HIN Support – HIN Gateway og Stargate
• HIN Support – HIN Mail til ikke-medlemmer
• HIN – Gateway Top-Level System Overview
• RFC 5321 – Simple Mail Transfer Protocol
• HIN – HIN Gateway-produktbeskrivelse
• HIN – Gateway Technical and Operational Overview
• HIN – Stargate Deployment
• HIN – HIN Client 3-håndbok
• RFC 5280 – Internet X.509 PKI
• HIN Support – HIN-identitet
• HIN Support – SAML Authentication Context
• HIN – OAuth2-integrasjon
• OASIS – SAML 2.0 Core
• RFC 6749 – OAuth 2.0
• HIN Support – HIN Mail og Mobile
• RFC 5322 – Internet Message Format
• Microsoft – Mail flow using connectors
• Microsoft – Mail flow using a third-party cloud service
• HIN Support – HIN Mail Token Service
• HIN Support – POP-konfigurasjon
• RFC 9051 – IMAP4rev2
• RFC 1939 – POP3
• RFC 6409 – Message Submission
• HIN Support – HIN Client på terminalservere
• WireGuard – Protocol and Cryptography
• HIN Status
• HIN Support – Brannmurtilpasninger for HIN Client
• Microsoft – Resolve-DnsName
• ISC BIND – dig-manual
• Microsoft – Test-NetConnection
• OpenBSD – nc-manual
• curl – kommandolinjemanual
• OpenSSL – s_client
• RFC 8446 – TLS 1.3
• swaks – Swiss Army Knife for SMTP
• Microsoft – Get-NetTCPConnection
• Linux man-pages – ss
• Microsoft – Packet Monitor
• tcpdump – tcpdump(1)
• HIN – Selskapshistorie
• HIN Support – HIN Access