HIN: espacio de confianza, Mail Gateway y Stargate

HIN no es un único programa de cifrado, sino un espacio de confianza sectorial compuesto por identidades verificadas, servicios centrales de plataforma y componentes de acceso o gateway. HIN Mail protege la comunicación por correo electrónico, HIN Access proporciona acceso a aplicaciones web protegidas y una HIN Identidad vincula a la persona u organización autorizada con material criptográfico de claves. En las instituciones, los componentes de Mail y Access se sitúan en el límite entre la infraestructura propia y la plataforma HIN (HIN Mail, Membresía colectiva de HIN con Gateway).

Para los administradores de mensajería, deben diferenciarse cuatro espacios de estado. El servidor de correo local dispone de buzones, conectores y colas. El gateway asume las decisiones de transporte, confianza y protección. La plataforma HIN proporciona servicios de directorio, identidad, claves, correo y acceso. Para destinatarios fuera de la comunidad HIN, se añade una ruta web y de autenticación. Una incidencia en un espacio no implica automáticamente una incidencia en todos los demás; por ejemplo, un puerto SMTP accesible no acredita ni una HIN Identidad válida ni una entrega correcta mediante el portal (HIN Gateway, HIN Mail a personas no miembros).

El nombre del producto también requiere una contextualización temporal. La generación clásica de gateway incluye un Mail Gateway, MGW, y, según el contrato, un Access Gateway, AGW. Como sucesor, HIN describe el nodo mesh compatible con correo desarrollado en el proyecto Stargate. Sigue siendo compatible con SMTP frente a los sistemas de correo locales, pero modifica la arquitectura, la distribución de claves, el despliegue y el transporte entre organizaciones. Por ello, las afirmaciones sobre la plataforma objetivo no deben trasladarse sin comprobación a un MGW existente, ni viceversa (HIN Gateway).

La explicación sigue un mensaje desde el remitente, pasando por la identidad HIN y el gateway, hasta el destinatario. A continuación se tratan los cambios de plataforma, las dependencias, el diagnóstico, el material de claves y la recuperación.

Enfoque arquitectónico: espacio de confianza con componentes edge

El modelo colectivo clásico proporciona HIN Mail y HIN Access como appliances virtuales. HIN documenta el cifrado y la firma S/MIME a nivel de dominio de correo, así como un rastro de auditoría; el Access Gateway actúa como proveedor local de identidad, asigna eIDs de HIN a solicitudes verificadas y puede integrar servicios existentes de directorio y autenticación (Membresía colectiva de HIN con Gateway).

Esta construcción es un modelo de confianza edge: la organización controla el servidor de correo, DNS, firewall, entrega interna y el recurso de gateway local; HIN opera los servicios superiores de confianza y plataforma. La finalización SMTP positiva transfiere la responsabilidad de un mensaje concreto al siguiente salto; no indica que la ruta posterior de HIN, portal o destinatario ya se haya completado. Para el nuevo stack de gateway, HIN asigna expresamente al cliente DNS y la reputación de correo (HIN Gateway Top-Level System Overview, RFC 5321).

Stargate desplaza este límite a un nodo mesh relacionado con la organización. HIN describe una arquitectura de microservicios nativa de la nube con API REST, identidades descentralizadas, gestión distribuida de claves y políticas programables. Está prevista una instancia propia por organización; HIN cita como modalidades de despliegue imágenes virtuales y contenedores, así como entornos OpenShift y Kubernetes en la descripción del producto. Se trata de una arquitectura objetivo publicada, no de una prueba de que todas las organizaciones HIN existentes ya operen de este modo (HIN Gateway: Arquitectura y despliegue, Descripción del producto HIN Gateway).

Stack tecnológico y responsabilidades

El stack documentado públicamente consta de varias generaciones y no debe mezclarse en un único monolito:

HIN documenta explícitamente el flujo de mensajes como External SMTP → Postfix → MXEngine → Postfix → External SMTP. La entrega forzada a MXEngine evita una elusión de políticas; Postfix sigue siendo responsable de la entrega y los reintentos. OPA/Rego mantiene las reglas de negocio fuera del código de la aplicación. PostgreSQL, Vault y MinIO almacenan clases de estado diferentes y no deben tratarse como un único sistema de archivos en el backup (HIN Gateway Top-Level System Overview, HIN Gateway Technical and Operational Overview).

La documentación técnica de instalación cita distribuciones Linux de familias compatibles con RHEL, así como Ubuntu y Debian, funcionamiento con Docker Compose en un único host e imágenes de VM para varias plataformas. Esta declaración de soporte depende de la versión y del despliegue; prevalece la documentación HIN aprobada en el momento de la instalación, no una lista de distribuciones copiada estáticamente (HIN Stargate Deployment).

El almacén de correo sigue siendo otro límite: según HIN, Stargate actúa como Mail Transport Agent, mientras que IMAP permanece implementado en la plataforma Zimbra existente. Además, HIN Access constituye una ruta independiente de autenticación y autorización mediante el cliente, AGW o Access Control Service (HIN Gateway, Manual de HIN Client 3).

Identidad y PKI con autorización

Una HIN Identidad es más que una dirección de correo electrónico. Durante la activación, HIN Client genera un par de claves; la contraseña desbloquea el material de claves local. En el nuevo gateway, S/MIME Keys Client genera claves criptográficas y Certificate Signing Requests, mientras que Vault alberga claves privadas, credenciales y configuración sensible. Un certificado vincula una clave pública a una identidad nombrada, pero no sustituye la autorización específica de una aplicación (Manual de HIN Client 3, HIN Gateway Top-Level System Overview, RFC 5280).

El ciclo de vida debe formar parte del runbook de IAM: registro, activación, cambio de dispositivo, cambio de función o nombre, bloqueo, nuevo registro ante sospecha sobre una clave y salida. Tras el pedido, HIN exige una verificación de identidad y distingue entre eIDs personales y la ID de organización o dispositivo en el modelo colectivo. Un transporte de correo funcional no debe considerarse prueba de que una identidad anterior o asignada incorrectamente ya no tenga acceso (HIN Identidad, Membresía colectiva de HIN con Gateway).

HIN Access y HIN Mail comparten el espacio de confianza, pero no el mismo flujo de protocolo. Access Control Service puede solicitar un nivel de autenticación mediante la RequestedAuthnContext SAML; HIN documenta perfiles para contraseña y MFA. Para integraciones, HIN proporciona además flujos OAuth 2.0 para Authorization Code y Client Credentials. La autenticación, la emisión de tokens y la autorización por la aplicación de destino deben registrarse por separado (HIN Authentication Context, Integración OAuth2 de HIN, SAML 2.0 Core, RFC 6749).

Solo cuando se han aclarado la identidad y la PKI puede evaluarse la ruta de correo. El gateway y la política deciden qué procedimiento de protección se aplica según el remitente, el destinatario y el destino.

Rutas de correo y decisiones de protección

Con los componentes HIN implicados en mente, ya puede explicarse la ruta concreta del mensaje. Los siguientes casos se distinguen según dónde se encuentren remitente y destinatario y qué servicio toma la decisión de protección.

Entre participantes de HIN

HIN describe los mensajes entre direcciones HIN como transmitidos automáticamente de forma compatible con la protección de datos. La plataforma indica el estado de integridad en el asunto con [HIN secured] o [Not secured by HIN]. Esta marca es una señal para el usuario, pero no una correlación técnica suficiente: para un incidente se requieren además el remitente y destinatario del sobre, Internet Message-ID, la cadena Received, el evento del gateway y la ventana temporal (HIN Mail, HIN Mail y Mobile, RFC 5322).

Una ruta organizativa clásica puede describirse como Mailserver → SMTP → MGW → HIN → MGW → SMTP → Mailserver. Cada estación termina una sesión y puede tener su propia cola. HIN describe el modelo colectivo como cifrado y firma S/MIME a nivel de dominio de correo; la entrega local antes y después de este límite de gateway sigue siendo un ámbito propio de protección y operación (Membresía colectiva de HIN con Gateway, RFC 5321).

A personas sin membresía HIN

Para destinatarios sin dirección HIN, el remitente debe marcar expresamente el mensaje como confidencial según la documentación de HIN, por ejemplo con (Vertraulich) en el asunto. El destinatario abre el contenido protegido mediante una ruta web y se autentica con número de móvil y código SMS; es posible una respuesta segura. Esto crea estados adicionales: correo de notificación, objeto del portal, registro del destinatario, segundo factor, conservación y canal de respuesta (HIN Mail a personas no miembros, HIN Mail).

Una notificación entregada aún no es un mensaje leído. Por ello, las pruebas sintéticas deberían cubrir toda la ruta hasta el inicio de sesión, la apertura, el adjunto y la respuesta. Los reenvíos desde el portal pueden abandonar la ruta de protección; HIN señala expresamente que determinados tipos de reenvío se envían sin cifrar. Estas acciones de usuario deben incluirse en la formación, el modelo DLP y el análisis de incidentes (HIN Mail a personas no miembros).

Dispositivos, aplicaciones y envíos masivos

El Mail Gateway clásico puede servir como interfaz SMTP para dispositivos internos; HIN también documenta esta capacidad para Stargate. La página de servicios HIN Mail indica que el envío desde sistemas a través del gateway requiere una licencia independiente. Por tanto, escáneres, HIS, aplicaciones de laboratorio y procesos por lotes necesitan una ruta propia y documentada de remitente, relay, volumen y errores, en lugar de usar silenciosamente el flujo de correo de los usuarios (HIN Gateway, HIN Mail).

Enrutamiento SMTP y límites de aceptación

El gateway debe saber con precisión para cada dirección qué dominios son locales, autoritativos, deben reenviarse o deben rechazarse. Una responsabilidad poco clara entre Exchange, conector de nube, Secure Mail Gateway y edge de HIN genera elusiones o bucles. SMTP prescribe líneas de trazado y describe la detección de bucles; la transferencia real de responsabilidad solo ocurre con una respuesta positiva tras el contenido completo del mensaje (RFC 5321, información de trazado, RFC 5321, DATA).

Para cada ruta, la documentación operativa debe incluir como mínimo estos valores:

• listener local, puerto y redes de origen o identidades de par esperadas;
• nombre EHLO, dominios de sobre y ámbitos de relay autorizados;
• orden de filtro antispam/antimalware, gateway HIN y sistema de correo interno;
• siguiente salto, resolución DNS o de smarthost y requisito de TLS;
• comportamiento cuando la plataforma HIN, el componente de identidad o de claves no es accesible;
• antigüedad de la cola, plan de reintentos, número máximo de saltos y responsabilidad de los rebotes;
• rutas de excepción para dispositivos, envío de sistemas y coexistencia durante la migración.

Para Exchange Online, se trata de una cuestión de conectores y no solo de DNS. Microsoft documenta el enrutamiento hacia gateways de terceros y las condiciones de conectores basadas en certificado o IP. Las preguntas frecuentes de HIN confirman la compatibilidad básica con arquitecturas híbridas y cercanas a Microsoft 365, pero remiten a documentación de migración específica del cliente para la configuración concreta (Microsoft: flujo de correo con conectores, Microsoft: flujo de correo de terceros en la nube, HIN Gateway).

Almacén de correo y acceso de clientes con token

El acceso al buzón y el transporte de gateway son modelos operativos diferentes. HIN publica para cuentas personales HIN Mail IMAP en el puerto 993 con TLS y Message Submission en el puerto 587 con STARTTLS; como contraseña se utiliza un token de correo generado. POP en el puerto 995 también está documentado, pero normalmente descarga los mensajes localmente y puede eliminarlos del servidor. Las funciones de protocolo corresponden a IMAP, POP3 y Message Submission, no al transporte de gateway a gateway (HIN Mail Token Service, Configuración POP de HIN, RFC 9051, RFC 1939, RFC 6409).

El manual de HIN Client documenta la sustitución del proxy de correo local histórico por acceso basado en tokens. HIN señala expresamente para servidores de terminal que, con el proxy desactivado, el envío y la recepción se realizan mediante tokens de correo. Esto es relevante para la historia técnica: originalmente, el cliente era un intermediario de comunicación para HTTP, SMTP, POP e IMAP; los modelos operativos posteriores separan más el acceso del cliente de correo y el cliente de identidad HIN (Manual de HIN Client 3, HIN Client en servidores de terminal).

En las preguntas frecuentes de Stargate, HIN describe el Mail Storage Agent existente como basado en Zimbra y, por el momento, no afectado por el nuevo transporte de gateway. Por tanto, un flujo de correo Stargate satisfactorio no demuestra ni la disponibilidad de IMAP ni la consistencia del buzón. A la inversa, Webmail puede funcionar mientras el conector de la organización o el transporte mesh están afectados (HIN Gateway).

La ruta clásica de almacén de correo no es la única modalidad operativa. Stargate desplaza funciones y responsabilidades y, por tanto, debe entenderse como una ruta independiente de mensajería y administración.

Stargate como arquitectura objetivo

Stargate pretende conservar la compatibilidad del correo en el borde y, al mismo tiempo, permitir un intercambio de datos descentralizado más general. HIN menciona Self-Sovereign Identity, Data Mesh, microservicios, API RESTful, componentes de código abierto y un nodo mesh compatible con correo. Para el canal entre instancias Stargate se anuncia un transporte aplicación a aplicación basado en WireGuard; HIN lo diferencia expresamente de un túnel VPN general (HIN Gateway).

Para los administradores, de ello se deriva un trazado tripartito:

1. A nivel local, SMTP con respuesta de aceptación, cola y conector sigue siendo el límite verificable.
2. Entre los nodos mesh se añaden estados de identidad, descubrimiento, claves y canal WireGuard.
3. En el destino vuelve a surgir una ruta SMTP local hacia el sistema de correo receptor.

Las vistas generales del sistema publicadas acreditan Postfix, MXEngine, OPA/Rego, PostgreSQL, Vault, MinIO, IDAgent, Promtail/Loki y métricas compatibles con Prometheus. No se especifica allí un lenguaje de programación ni un árbol fuente completo de los servicios de producto; por ello, esta información no se deduce de imágenes de contenedores ni de proyectos ajenos con el mismo nombre (HIN Gateway Top-Level System Overview, HIN Gateway Technical and Operational Overview).

Los límites de red del nuevo gateway están documentados públicamente con un nivel de detalle inusual:

Los puertos de diagnóstico y servicio expuestos localmente, incluidos PostgreSQL, Vault, MinIO y los endpoints de métricas, no deberían ser accesibles desde Internet público según HIN. Los accesos administrativos a 22, 443, 8180 o 8190 deben pertenecer a una red de gestión definida y no a una autorización genérica de Internet (HIN Gateway Technical and Operational Overview, HIN Stargate Deployment).

HIN describe la migración como una implantación paralela del nuevo gateway. Solo tras la configuración, las pruebas y la confirmación de la disponibilidad operativa, el cliente decide la conmutación. En principio, las direcciones IP existentes pueden reutilizarse, pero la configuración debe traducirse. Por tanto, un runbook de cutover seguro incluye al menos inventario, exportación, ruta paralela, matriz de pruebas, criterio de conmutación, ruta de retorno, tratamiento de colas y rollback claro (HIN Gateway: Migración).

Alta disponibilidad con backup y recuperación

HIN documenta un clúster OpenShift redundante para su propia parte de Stargate, pero no planifica automáticamente dos máquinas virtuales redundantes del lado del cliente. Estas afirmaciones no deben combinarse para inferir una alta disponibilidad general de extremo a extremo. Un servicio de plataforma redundante no protege frente a un único hipervisor local, una regla de conector errónea, una clave vencida o un firewall bloqueado (HIN Gateway).

En el nuevo gateway, los servicios persisten mediante volúmenes Docker. Vault se sella automáticamente después de reiniciar un contenedor y requiere un proceso de unseal controlado. La vista técnica indica por defecto backups diarios de bases de datos, claves y secretos de Vault, archivos de configuración y certificados; la responsabilidad y la conservación deben acordarse con el cliente (HIN Gateway Technical and Operational Overview).

Un inventario de recuperación debería contener al menos, por generación:

La lista pública de backups menciona base de datos, Vault, configuración y certificados, pero no menciona explícitamente mensajes y adjuntos MinIO. De ello no puede deducirse ni que se aseguren ni que se excluyan intencionadamente; precisamente este punto debe constar por escrito en el acuerdo de retención, backup y restauración antes de la puesta en producción. Además, una instantánea de VM genérica no acredita ni un estado PostgreSQL consistente ni un Vault recuperable (HIN Gateway Technical and Operational Overview, HIN Gateway Top-Level System Overview).

En caso de incidencia, el mensaje se sigue desde la aceptación, pasando por la decisión de identidad y política, hasta la ruta de entrega elegida; solo después se reinician o evitan componentes individuales.

Monitorización y triaje de incidentes

Una visión operativa útil combina señales locales y centrales:

• disponibilidad y antigüedad de cola por siguiente salto SMTP;
• tasas de aceptación, transferencia y rebote con Message-ID correlacionable;
• errores de HIN, portal, identidad, claves y políticas por separado;
• vencimiento de certificados, estado de registro y token;
• acceso al buzón mediante Webmail e IMAP independientemente del gateway;
• resolución DNS y de firewall mediante nombres en lugar de direcciones IP de HIN codificadas de forma fija;
• avisos de plataforma en HIN Status y telemetría local.

El nuevo stack proporciona métricas de servicio compatibles con Prometheus, métricas de host mediante Node Exporter, envío central de logs mediante Promtail a Loki y un Version Collector que consulta endpoints de liveness. Para las alertas, deben tratarse por separado como mínimo la ausencia de scrape, la falta de entrada de logs, la antigüedad de cola de Postfix, los errores de MXEngine, el estado sellado de Vault, la capacidad de PostgreSQL y MinIO, el estado de pares WireGuard y el vencimiento de certificados (HIN Gateway Top-Level System Overview, HIN Gateway Technical and Operational Overview).

La documentación de firewall de HIN recomienda nombres DNS, ya que las direcciones IP pueden cambiar, y cita rutas HTTPS y SMTP, entre otras, para servicios de cliente. Una página de estado global no puede detectar una incidencia local de DNS, NAT, MTU, conector o claves. Por ello, el triaje comienza por el alcance: un usuario, una identidad, un dominio, una dirección, un gateway o la plataforma (Ajustes de firewall de HIN, HIN Status).

La oferta colectiva clásica cita un rastro de auditoría para el flujo de correo; el nuevo gateway añade logs centrales estructurados. Para un análisis integral de correo, estas evidencias deben correlacionarse con logs SMTP locales y del sistema de correo. La sincronización horaria y las zonas horarias uniformes son requisitos operativos, no ajustes estéticos (Membresía colectiva de HIN con Gateway, HIN Gateway Top-Level System Overview).

Herramientas de diagnóstico

El diagnóstico comienza por el nombre público o interno y después sigue la ruta real del correo. Solo cuando DNS, conexión y certificado son correctos se evalúan el estado del gateway, la cola y los eventos específicos de HIN.

DNS y endpoints de HIN

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 y dig muestran si los nombres documentados pueden resolverse desde la perspectiva del resolver realmente utilizada. Esto es más importante que un valor IP copiado, especialmente con Split-DNS y proxies; HIN recomienda expresamente nombres DNS en lugar de direcciones fijadas a largo plazo (Ajustes de firewall de HIN).

Accesibilidad TCP y TLS

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 y nc acreditan la ruta TCP. La llamada UDP de nc puede, como mucho, indicar accesibilidad; dado que WireGuard descarta paquetes no autorizados sin responder, solo el handshake autenticado del par constituye una prueba sólida para el puerto 19818. curl.exe de Windows y openssl s_client comprueban el borde SMTP/STARTTLS. Un handshake correcto aún no demuestra el procesamiento de políticas ni la entrega del mensaje (HIN Gateway Technical and Operational Overview, RFC 8446).

Transacción SMTP controlada

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 y swaks solo deben utilizarse contra un listener y destinatario de prueba expresamente autorizados. Se registran la respuesta final tras DATA, el ID de cola local, el evento del gateway, la ruta de protección elegida, el siguiente salto y la llegada real. Un 250 en RCPT TO aún no supone aceptación del contenido del mensaje (RFC 5321).

Estados de sockets locales

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 y ss muestran listeners locales y sesiones TCP establecidas. Solo tienen sentido donde el administrador dispone de acceso al host correspondiente; un producto gestionado de appliance o contenedor no debe modificarse mediante accesos de shell no documentados.

Ruta de paquetes en el punto de medición adecuado

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 y tcpdump solo ven el tráfico en el punto de medición elegido. Para Stargate, un trazado SMTP local no puede explicar por completo el canal mesh; para ello se requieren adicionalmente eventos de gateway y plataforma. Las capturas pueden contener direcciones, líneas de asunto o partes de protocolo sin cifrar y deben tratarse como datos operativos sensibles.

Historia técnica

La FMH y la Ärztekasse fundaron Health Info Net AG en 1996, cuando surgió el correo electrónico en el sector sanitario y se reconoció que el envío de datos sensibles mediante correo de Internet convencional estaba insuficientemente protegido. HIN comenzó así como proveedor de comunicación segura por correo electrónico para el colectivo médico y evolucionó hacia un espacio más amplio de confianza y acceso (Historia de la empresa HIN).

La arquitectura del cliente muestra el cambio técnico. HIN Client 1 y 2 fueron sustituidos por HIN Client 3. Por motivos de compatibilidad, el cliente siguió funcionando como proxy local para navegadores y programas de correo; para el acceso web, HIN documentó posteriormente Challenge/Response y, para las cuentas de correo, la transición a tokens independientes mediante puertos estándar. La historia explica por qué las guías de instalación antiguas indican puertos proxy locales, mientras que los documentos más recientes utilizan endpoints directos de IMAP, POP y Submission (Manual de HIN Client 3, HIN Mail Token Service).

El modelo colectivo clásico de HIN agrupaba appliances de Mail y Access en la red del cliente. La página de servicios actual documenta para esta generación S/MIME a nivel de dominio de correo, rastro de auditoría, un proveedor de identidad local y la conexión de servicios existentes de autenticación y directorio. Estas funciones explican la separación histórica entre transporte de correo y acceso web (Membresía colectiva de HIN con Gateway).

A partir de 2025, HIN introdujo una nueva entrega a personas no miembros; al mismo tiempo, se renovaron la infraestructura de plataforma y Access. La documentación de Gateway publicada en 2026 describe Stargate como el siguiente cambio generacional: de un gateway exclusivamente de cifrado de correo a un nodo descentralizado y nativo de la nube para correo e intercambio estructurado de datos sanitarios. La documentación técnica concreta este cambio con Postfix, MXEngine, OPA/Rego, PostgreSQL, Vault, MinIO y operación en contenedores. Por tanto, para un plan de migración no basta con sustituir una VM, sino que se requiere una nueva evaluación de identidad, claves, transporte, observability y recuperación (HIN Mail, HIN Access, HIN Gateway, HIN Gateway Top-Level System Overview).

Fuentes

• HIN – HIN Mail
• HIN – Membresía colectiva con Gateway
• Soporte HIN – HIN Gateway y Stargate
• Soporte HIN – HIN Mail a personas no miembros
• HIN – Gateway Top-Level System Overview
• RFC 5321 – Simple Mail Transfer Protocol
• HIN – Descripción del producto HIN Gateway
• HIN – Gateway Technical and Operational Overview
• HIN – Stargate Deployment
• HIN – Manual de HIN Client 3
• RFC 5280 – Internet X.509 PKI
• Soporte HIN – HIN Identidad
• Soporte HIN – SAML Authentication Context
• HIN – Integración OAuth2
• OASIS – SAML 2.0 Core
• RFC 6749 – OAuth 2.0
• Soporte HIN – HIN Mail y Mobile
• RFC 5322 – Internet Message Format
• Microsoft – Flujo de correo con conectores
• Microsoft – Flujo de correo mediante un servicio cloud de terceros
• Soporte HIN – HIN Mail Token Service
• Soporte HIN – Configuración POP
• RFC 9051 – IMAP4rev2
• RFC 1939 – POP3
• RFC 6409 – Message Submission
• Soporte HIN – HIN Client en servidores de terminal
• WireGuard – Protocol and Cryptography
• HIN Status
• Soporte HIN – Ajustes de firewall para HIN Client
• Microsoft – Resolve-DnsName
• ISC BIND – Manual de dig
• Microsoft – Test-NetConnection
• OpenBSD – Manual de nc
• curl – Manual de línea de comandos
• 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 – Historia de la empresa
• Soporte HIN – HIN Access