Configurar el cifrado de correo SPX en Sophos Firewall

Con Secure PDF Exchange, o SPX, Sophos Firewall convierte un correo saliente y sus archivos adjuntos en un PDF protegido con contraseña. El destinatario no necesita un cliente de cifrado propio. Según el modelo de contraseña seleccionado, recibe una contraseña de un solo uso, utiliza una contraseña almacenada o registra una personalmente.

Para un funcionamiento fiable deben coordinarse cuatro elementos: una plantilla SPX, un activador inequívoco, un canal seguro para la contraseña y, si se necesita, el SPX Reply Portal. Después se prueban un flujo positivo y otro negativo. La mera entrega de un PDF no demuestra que se haya activado la política correcta ni que funcionen el registro de contraseña y la respuesta segura.

SPX en ocho pasos

1. Comprobar la licencia Email Protection, el flujo de correo MTA, la compatibilidad del modelo, el certificado del portal y la ruta SMTP TLS independiente.
2. Decidir si el cifrado se activa por un dominio protegido, una coincidencia de Data Control o el remitente.
3. Crear una plantilla propia en Email > Encryption > SPX templates > Add.
4. Elegir de forma consciente el tipo de contraseña, el cifrado del PDF, la notificación y el Reply Portal.
5. Proteger el FQDN, las redes permitidas y el puerto en Email > Encryption > SPX portal settings.
6. En MTA mode, configurar la política SMTP route and scan y asignar la plantilla; un Default SPX template no sustituye esta política.
7. Probar el PDF, el canal de contraseña, el registro y la respuesta con un destinatario externo.
8. Realizar una prueba negativa sin activador SPX y documentar Mail logs, los registros MTA y la reversión.

⚠️ Un campo Allowed networks vacío en el SPX Portal no significa «sin acceso», sino que vuelve a Any. Sophos también recomienda un puerto dedicado para el Reply Portal. Por eso, el FQDN del portal, el certificado, los orígenes permitidos y el canal de contraseña deben estar definidos antes de la prueba en producción.

Cuándo encaja SPX

SPX es útil cuando los destinatarios externos deben recibir contenido confidencial como PDF protegido sin instalar un cliente de cifrado. Puede utilizarse tanto en MTA mode como en Legacy mode. Este procedimiento usa MTA mode porque permite relacionar de forma clara el dominio, Data Control y el enrutamiento dentro de la política SMTP. Configurar Mail Protection en Legacy mode explica la alternativa transparente.

SPX no es cifrado de transporte entre servidores de correo ni cifrado de extremo a extremo entre dos clientes de correo. La firewall procesa el texto sin cifrar, genera el PDF y controla la contraseña o el registro. Después, el PDF puede seguir existiendo fuera de la firewall en buzones, archivos o descargas. El alcance de destinatarios, la retención y la entrega de contraseñas forman por tanto parte del diseño de seguridad.

El cifrado de transporte SMTP se controla por separado en Email > General settings > SMTP TLS configuration. Require TLS negotiation obliga a usar TLS con los hosts remotos o redes seleccionados; si SFOS no puede establecer la conexión TLS, descarta el correo destinado a ese destino. Por el contrario, Skip TLS negotiation fuerza una conexión SMTP sin cifrar. El TLS certificate seleccionado allí protege la ruta SMTP y no es el certificado de los portales SPX. Por tanto, SPX y SMTP TLS se planifican por separado y después se validan conjuntamente en el flujo externo.

Los requisitos son:

• una licencia Email Protection válida;
• un flujo de correo saliente ya probado a través de Sophos Firewall;
• un destinatario externo de prueba documentado;
• un FQDN de confianza y un certificado adecuado para los portales SPX utilizados;
• un canal seguro independiente para las contraseñas cuando no las registra el destinatario;
• una vía de recuperación que permita retirar las asignaciones de plantilla y política.

Según la ayuda actual de Sophos, SPX no está disponible en XGS 87/87w. Además, MTA mode completo no está disponible en XGS 88/88w. Configurar Mail Protection en MTA mode explica el flujo de correo, la licencia, el relay y los límites de modelo.

Definir el activador y la prioridad

SPX puede activarse de tres maneras. Si se configuran varios métodos, Sophos Firewall aplica este orden en MTA mode:

1. Dominio protegido: La plantilla SPX seleccionada en Domains and routing target se aplica a los mensajes salientes del dominio protegido coincidente.
2. Data control list: Solo si no hay una plantilla SPX a nivel de dominio, una coincidencia de Data Control puede aplicar la plantilla seleccionada para la lista.
3. Activador del remitente: Solo cuando ni el dominio ni Data Control proporcionan una plantilla se aplica el método del remitente configurado en Default SPX template.

La asignación por dominio es amplia y solo resulta adecuada cuando realmente deben cifrarse todos los mensajes salientes coincidentes. Data Control es apropiado para tipos de contenido definidos, pero debe probarse con ejemplos positivos y negativos reales para detectar falsos positivos. El activador del remitente deja la decisión en sus manos, pero exige un proceso de cliente de correo bien documentado.

Antes de configurar se define un único activador principal para cada flujo de correo. Un segundo método no debe imponerse silenciosamente a otro.

Crear la plantilla SPX

El ejemplo utiliza la plantilla Finance-SPX-Recipient. El nombre es un valor de documentación y debe adaptarse al propósito y a la organización.

Se pueden utilizar plantillas separadas con textos adecuados y logotipos de empresa para distintos dominios de clientes. No es solo una cuestión de imagen: las instrucciones del destinatario deben corresponder al modelo de contraseña y al dominio realmente asignado.

1. Abrir Email > Encryption > SPX templates.
2. Seleccionar Add.
3. Introducir un nombre como Finance-SPX-Recipient. SFOS no permite apóstrofos, barras, comas, barras invertidas ni comillas en el nombre.
4. Establecer el nombre de la organización para las notificaciones.
5. Elegir Encryption standard y PDF page size según los requisitos propios.
6. En Password type, seleccionar el modelo de contraseña previsto.
7. Revisar el asunto, el cuerpo del mensaje y las instrucciones para el destinatario, y adaptarlos si es necesario.
8. Para este procedimiento MTA, activar Enable SPX reply portal, tal como exige la ayuda de la plantilla. Proteger el acceso al portal como se describe más abajo antes de probarlo.
9. Activar Include original body into reply solo si se permite incluir el mensaje original en la respuesta.
10. Guardar la plantilla.

Elegir conscientemente el modelo de contraseña

Sophos Firewall ofrece cuatro modelos:

• Specified by sender: El remitente establece la contraseña. La firewall la elimina antes del envío y no la almacena. Debe llegar al destinatario por un canal seguro independiente.
• Generate one-time password for every email: La firewall genera una contraseña nueva para cada mensaje y la envía al remitente. Este la entrega por separado al destinatario. La contraseña no se almacena.
• Generated and stored for recipient: La firewall genera una contraseña específica para el destinatario, la envía al remitente y la reutiliza hasta que caduca.
• Specified by recipient: Un destinatario aún no registrado recibe un enlace de registro, define su contraseña y la utiliza hasta que caduque para otros mensajes SPX de la organización.

Con Specified by recipient, el primer mensaje cifrado se envía únicamente después del registro de la contraseña; recibir el enlace de registro no significa que se haya entregado el PDF SPX.

Para una relación continuada con un partner, Specified by recipient suele ser el proceso más fácil de entender. Una contraseña de un solo uso puede resultar más adecuada para un envío único especialmente sensible. No conviene mezclar sin planificación distintos modelos de contraseña almacenada para el mismo destinatario, porque este tendría que identificar la contraseña correspondiente a cada mensaje.

Con Specified by sender, la contraseña se introduce en el asunto con el patrón [secure:<password>]<subject text>. Después, el remitente debe entregar la contraseña por separado. Para Microsoft Outlook, Sophos ofrece un Outlook Add-in en Authentication > Client downloads.

Tras comprobar la instalación, seleccionar Encrypt en Outlook para el mensaje que se quiere cifrar. Instalar el complemento por sí solo no activa el cifrado.

Instalar el Outlook Add-in de forma controlada

Los usuarios sin acceso a WebAdmin abren Download client en el User Portal y seleccionan Download Sophos Outlook Add-in. El archivo comprimido descargado se extrae en una carpeta temporal; para la instalación interactiva se ejecuta allí setup.exe. La descarga administrativa en Authentication > Client downloads constituye una vía de acceso distinta.

Comprobar el nombre del archivo MSI antes de la distribución: La ayuda del User Portal para SFOS 22 y 23 indica SophosOutlookAddInSetup.msi; en cambio, la descripción de instalación de SPX indica SophosOutlookAddInSetupUTM.msi, como en el ejemplo existente que figura a continuación. No se ha confirmado que estos nombres sean intercambiables. Debe comprobarse el nombre real del archivo MSI en el paquete extraído. El siguiente ejemplo solo es válido si el archivo se llama realmente SophosOutlookAddInSetupUTM.msi. Si el paquete contiene SophosOutlookAddInSetup.msi, se utiliza exactamente ese nombre existente como argumento de /i; los modificadores documentados /qr /i y T=1 EC=3 C=1 I=1 permanecen sin cambios. Si falta el MSI esperado o no puede identificarse inequívocamente el paquete, se detiene la distribución y se aclara qué paquete corresponde, en lugar de renombrar un archivo o dar por supuesta la compatibilidad con plataformas modernas.

Para una instalación interactiva, ejecutar setup.exe desde el paquete descargado del firewall activo. Sophos documenta este comando para una implementación desatendida:

msiexec /qr /i SophosOutlookAddInSetupUTM.msi T=1 EC=3 C=1 I=1

La lista pública de compatibilidad es llamativamente antigua: La ayuda de SFOS documenta los siguientes requisitos históricos para la instalación desatendida del SPX Outlook Add-in: Windows XP, Windows Vista, Windows 7 o Windows 8, cada uno en versiones de 32 bits y de 64 bits; Microsoft Outlook 2007 SP3, 2010 o 2013, también cada uno en versiones de 32 bits y de 64 bits; Microsoft .NET Framework 4 Client Profile y Microsoft Visual Studio 2010 Tools for Office Runtime 4.0. De ello no puede deducirse compatibilidad con las aplicaciones actuales de Microsoft 365 ni con versiones modernas de Windows. Por tanto, antes de una distribución generalizada, se comprueban en un dispositivo piloto el paquete realmente descargado, las versiones de Windows y Outlook y sus respectivas arquitecturas de bits, un activador SPX positivo y otro negativo, así como la desinstalación. Los parámetros MSI no explicados no se modifican por suposición.

La ayuda actual de Sophos utiliza dos grafías distintas del encabezado para otros clientes de correo: X-Sophos-SPXEncrypt: yes en la página de la plantilla y X-Sophos-SPX-Encrypt: yes en la página general Encryption. Esta discrepancia no se trata como una receta para copiar y pegar. Antes de desplegarlo en producción, hay que verificar qué grafía funciona en el build de SFOS utilizado. Siempre que sea posible, una política, Data Control o el Sophos Outlook Add-in ofrece un activador más trazable.

Diseñar la notificación sin crear otra fuga de datos

Las variables disponibles para las notificaciones incluyen:

• %ENVELOPE_TO%: destinatario de la contraseña.
• %PASSWORD%: contraseña para abrir el PDF SPX.
• %ORGANIZATION_NAME%: nombre de la organización introducido en la plantilla.
• %SENDER%: remitente del correo.
• %REG_LINK%: enlace para registrar la contraseña.

Se admiten formato HTML sencillo y enlaces. El texto debe explicar quién envía el mensaje, cómo se obtiene la contraseña de forma segura y durante cuánto tiempo son posibles el registro o la respuesta. Las credenciales o el contenido confidencial del correo no deben copiarse además en una notificación sin protección.

Reset restaura la notificación predeterminada. Guardar antes los textos personalizados; después del restablecimiento, comprobar de nuevo el asunto, el cuerpo del mensaje y las instrucciones del destinatario.

Establecer los periodos de validez y las notificaciones de error

Los periodos y los destinatarios de errores se establecen en Email > Encryption > SPX configuration, no en SPX portal settings:

• Keep unused password for: Validez de una contraseña almacenada cuando no se envía ningún mensaje SPX a ese destinatario. Por ejemplo, con tres días, la ayuda indica que caduca a medianoche al final del tercer día. Es un periodo de inactividad, no una duración universal de cada PDF.
• Allow secure reply for: Número de días durante los que el destinatario puede responder mediante el SPX Reply Portal; esta opción pertenece al procedimiento MTA.
• Allow password registration for: Periodo tras el cual caduca el enlace de registro. Es independiente del periodo de las contraseñas almacenadas.
• Send error notification to: Destinatarios responsables de las notificaciones de error SPX. Los errores también aparecen en el registro SMTP.

Elegir los periodos según las necesidades de respuesta y las normas de seguridad de la organización. En el piloto, probar por separado el registro, la inactividad de la contraseña y el plazo de respuesta. La caducidad en el firewall no demuestra que un PDF ya entregado se haya eliminado o haya dejado de poder abrirse.

Proteger los portales SPX

El registro de contraseñas y el acceso al portal se definen en Email > Encryption > SPX portal settings:

1. En Hostname, introducir el FQDN mediante el que los destinatarios externos acceden realmente al portal.
2. En Allowed networks, definir solo las redes de origen necesarias. Any solo es apropiado cuando cualquier destinatario externo debe acceder al portal y se acepta conscientemente el riesgo.
3. Documentar el puerto. El Password Registration Portal utiliza de forma predeterminada TCP 8094.
4. Utilizar un puerto dedicado para el SPX Reply Portal.

Si Allowed networks queda vacío, SFOS utiliza Any, porque el SPX Reply Portal está activado de forma predeterminada en la zona WAN. Si no se necesita el Reply Portal, Sophos documenta como método de desactivación el uso de una dirección privada de confianza sin utilizar, por ejemplo 169.254.0.1, como única red permitida. Este valor de documentación no debe coincidir con una dirección utilizada en producción.

CAPTCHA está siempre activo en el SPX Portal y no puede desactivarse. Controlar conscientemente CAPTCHA en Sophos Firewall explica los límites de la configuración CAPTCHA de otros portales.

WebAdmin, User Portal, VPN Portal, Captive Portal y los dos portales SPX utilizan la misma selección central de certificado. Por tanto, un cambio puede afectar a varios servicios al mismo tiempo. El certificado, los SAN, la vía de recuperación y la URL real del portal deben planificarse con Gestionar certificados en Sophos Firewall. Para un nombre público puede encajar un certificado Let’s Encrypt en Sophos Firewall.

La selección se encuentra en Administration > Admin and user settings > Admin console and end-user interaction > Certificate. La identidad del certificado en el SAN o CN debe coincidir con el FQDN del portal introducido en Hostname, y la cadena de CA completa debe estar presente en el firewall. Por eso, un cambio de certificado no se considera exclusivo de SPX: después también se comprueban WebAdmin y los demás portales.

Conectar la plantilla con la política SMTP

Para MTA mode, la plantilla SPX se selecciona en la política SMTP route and scan correspondiente bajo Email > Policies and exceptions.

Usar un dominio como activador

En Domains and routing target, se asigna la plantilla al dominio protegido. A partir de entonces se aplica a los mensajes salientes coincidentes. Una asignación amplia por dominio se prueba primero con un remitente piloto y un destinatario externo de prueba.

Usar Data Control como activador

Una Data Control List no es una regla de contenido redactada libremente. Se construye con Sophos Content Control Lists, o CCLs, para patrones de datos definidos. Al crearla, se filtran las CCLs por Type y Region. En el piloto solo se incluyen los patrones realmente necesarios, para que una selección demasiado amplia no active innecesariamente el envío SPX.

1. Crear una lista con un nombre claro en Email > Data control list o revisar la lista existente.
2. Activar Data protection en la política SMTP route and scan y seleccionar exactamente esa lista en Data control list.
3. Establecer Data control list action en Accept with SPX y seleccionar el SPX template previsto. Accept entrega sin SPX; Drop descarta el mensaje sin avisar al remitente.
4. Realizar una prueba positiva de contenido y otra negativa similar.

Si ya existe una plantilla SPX en Domains and routing target, esta tiene prioridad sobre la plantilla de Data Control. Además, una coincidencia de la Data Control List solo demuestra la coincidencia de contenido configurada. El flujo de correo real debe confirmar si se cifró el mensaje correcto.

Utilizar un activador del remitente

En Email > Encryption > SPX configuration, se selecciona un Default SPX template. Solo se aplica al cifrado SPX activado por el remitente si la política SMTP no proporciona ya una plantilla a nivel de dominio o Data Control. None desactiva esta vía predeterminada.

Para MTA mode, la ayuda exige expresamente una política SMTP route and scan configurada y la selección de la plantilla en Domains and routing target o Data control list. Cita example.com como dominio ficticio si no se quiere especificar un dominio protegido. Es un ejemplo de documentación, no un dominio de correo de producción ni una autorización general de relay o enrutamiento. La asignación de la política y ambos casos de prueba también deben ser correctos en este caso especial. La descripción general de la plantilla predeterminada no demuestra que MTA pueda funcionar sin política SMTP. None desactiva solo la vía predeterminada, no una asignación SPX en una política.

Automatizar SPX mediante la API XML

Para los cambios recurrentes, primero se registran el modo de correo, las plantillas existentes y sus asignaciones a políticas o como predeterminadas. Las referencias XML para SFOS 22 y 23 distinguen entre objetos Legacy y MTA; que los campos tengan los mismos nombres no hace que sus payloads sean intercambiables. La información siguiente explica el contrato documentado, pero no constituye una solicitud de escritura ejecutable ni demuestra que se haya realizado una prueba de laboratorio. La autorización de orígenes, la cuenta de servicio con privilegios mínimos, la verificación TLS, la operación explícita, el backup y la evaluación del estado XML en lugar del estado HTTP se describen en Limitar de forma segura el acceso a la API XML y comprobar las respuestas. Antes de escribir, confirmar el contrato completo del objeto en API help del build instalado; las contradicciones sin resolver no se subsanan con un payload basado en conjeturas.

Configuración global: separar Legacy y MTA

Legacy: El ejemplo documentado anida SPXConfiguration dos veces: un SPXConfiguration externo que contiene otro SPXConfiguration. En el elemento interno se encuentra SPXGlobalTemplate con DefaultSPXTemplate; junto a él aparecen HostName, AllowedNetworks con entradas Network repetibles, Port, KeepUnusedPassFor, AllowPassRegistrationFor y SendNotifcationErrorTo. No eliminar el doble nivel por considerarlo un supuesto error tipográfico ni utilizar el ejemplo como esquema general para MTA.

MTA: El objeto independiente se llama MTASPXConfiguration. Su ejemplo contiene directamente SPXGlobalTemplate con DefaultSPXTemplate, además del nombre de host, el puerto, los plazos de contraseña y la notificación de errores, sin el doble anidamiento de Legacy. Para ambos contratos, la tabla de parámetros indica que Network, DefaultSPXTemplate y HostName son arrays opcionales de cadenas; esto no confirma la validez de una estructura de array construida arbitrariamente. El FQDN del portal y los orígenes permitidos se contrastan con los controles de portal y certificado descritos anteriormente. El valor de ejemplo MTA None para HostName no demuestra un estado de desactivación seguro.

Los parámetros obligatorios son KeepUnusedPassFor (número de días documentado como cadena, valor predeterminado 30), AllowPassRegistrationFor (número entero de días, valor predeterminado 10), Port (entero, valor predeterminado 8094, intervalo de 1025 a 65535) y SendNotifcationErrorTo. La grafía SendNotifcationErrorTo se mantiene sin cambios pese a la letra que falta. Los tokens permitidos son SenderOnly y Nobody; sin embargo, el ejemplo Legacy y la indicación del valor predeterminado muestran Sender Only. No normalizar silenciosamente esta discrepancia ni deducir, solo a partir de lo mostrado, que alguno de los dos valores sea un valor XML probado. Si no se ha aclarado el contrato para el build utilizado, detener la tarea de escritura.

Solo la tabla MTA incluye además AllowSecureReplyfor como campo obligatorio para el plazo de respuesta (número de días como cadena, valor predeterminado 30). Precisamente este campo falta en el ejemplo MTA. Por tanto, el ejemplo no demuestra de forma completa que la solicitud esté lista para producción; no omitir el plazo de respuesta sin verificarlo ni inventar una grafía con mayúsculas o minúsculas distintas. La plantilla global, la inactividad de la contraseña, el registro y el plazo de respuesta siguen siendo decisiones independientes; ninguna sustituye la asignación en la política SMTP.

Para Update SPX Configuration, el contrato Legacy documenta las siguientes correspondencias de estado XML:

En cambio, el contrato MTA de la misma operación indica 200 con Operation Successful. y 500 con Operation Fail.. No presentar el código Legacy 541 como una respuesta MTA documentada en ese contrato. Para la correspondencia Legacy 541, comprobar primero el uso real del puerto y el puerto del portal almacenado, en lugar de repetir la tarea sin cambios o modificar SMTP TLS.

Plantillas: proteger la identidad, los valores y la notificación

Para Legacy se documenta SPXTemplates y para MTA, MTASPXTemplates. Name es la identidad única obligatoria de la plantilla, con un máximo de 255 caracteres, y se compara exactamente con el objeto existente antes de actualizarlo o eliminarlo. Description y OrganizationName son cadenas opcionales; para OrganizationName también se aplica un máximo de 255. Un nuevo texto de descripción no justifica volver a crear a ciegas un objeto con el mismo nombre.

Ambos contratos exigen PDFEncryption, PageSize y PasswordType. Los valores de selección exactos son:

• PDFEncryption: AES/128 o AES/256.
• PageSize: A/4, Letter o Legal. El valor predeterminado mostrado, A4, no es el token de selección documentado A/4.
• PasswordType: SpecifiedBySender, GeneratedOneTimePasswordForEveryEmail, GeneratedAndStoredForRecipient o SpecifiedByRecipient. El valor predeterminado mostrado, Specified by sender, no constituye una recomendación de token XML.

NotificationSubject, NotificationBody y InstructionsForRecipient son cadenas opcionales. Según el contrato, los dos campos de notificación solo son aplicables a los modelos de contraseña generada o registrada por el destinatario, no a SpecifiedBySender. Solo la plantilla MTA añade SPXReplyPortal e IncludeOriginalBodyIntoReply: ambos son opcionales, con valor predeterminado Disabled y valores permitidos Disabled o Enable. El ejemplo Enable/Disabled es una notación de selección, no un único valor que deba enviarse. No confundir la obligatoriedad del Reply Portal en el procedimiento de la interfaz gráfica MTA descrito anteriormente con el campo opcional de la API y su valor predeterminado.

Los textos de notificación se localizan, pero los marcadores de posición técnicos se conservan sin cambios. Los ejemplos de la API muestran además %CURRENT_RECIPIENT% y, en el asunto, %%ENVELOPE_TO%% o %%ORGANIZATION_NAME%%; no convertirlos automáticamente en las variables delimitadas por un solo signo de porcentaje a cada lado que se enumeran más arriba. Antes de un cambio, guardar una copia de la plantilla realmente almacenada y comprobar la resolución de variables con un nuevo mensaje de prueba. El HTML de fábrica, las indicaciones históricas sobre lectores de PDF y las contraseñas de ejemplo de la referencia no constituyen una plantilla obligatoria para las notificaciones propias. El HTML, las comillas y los saltos de línea deben serializarse de forma controlada y comprobarse después de guardar. Tampoco adoptar el |n visible en el ejemplo MTA como mecanismo de escape universal sin confirmación específica para el build.

Las correspondencias documentadas coinciden para las plantillas Legacy y MTA:

Los identificadores Message.* siguen siendo claves de mensaje sin resolver de la referencia, no textos verificados en tiempo de ejecución. Ante 502, comprobar la identidad exacta y el contenido existente; no cambiar automáticamente de Add a Update. Ante 541 en Update, investigar las asignaciones reales de Spam, Data Control y SPX, sin deducir del identificador un mecanismo de conflicto universal. Ante 504 en Delete, aclarar primero las referencias en las políticas y en la configuración global; el orden de reversión descrito más abajo sigue siendo obligatorio. Antes de cada reintento, contrastar la respuesta con el estado realmente almacenado; comprobar el objeto de destino también después de 200. Solo un nuevo correo de prueba positivo y otro negativo, junto con las pruebas de contraseña y respuesta, permiten validar el efecto operativo.

Validar el flujo de correo cifrado

Se anotan la hora de la prueba, el remitente, el destinatario, el asunto y el activador esperado. Después se prueban como mínimo estos casos:

1. Prueba positiva: Un mensaje saliente activa exactamente la plantilla SPX prevista.
2. Prueba de contraseña: El destinatario recibe la contraseña o el enlace de registro por el canal previsto y puede abrir el PDF.
3. Prueba de contenido: El asunto, el cuerpo y los archivos adjuntos aparecen en el PDF como se espera y son legibles.
4. Prueba de respuesta: Si está activado, el enlace de respuesta conduce al FQDN esperado y una respuesta de prueba llega al remitente original.
5. Prueba negativa: Un mensaje similar sin activador no se envía como PDF SPX.
6. Prueba de caducidad: El registro, la contraseña almacenada y el periodo de respuesta se comportan de forma previsible después de la validez definida.
7. Prueba de certificado: El navegador y el destinatario externo reciben una cadena de certificados completa y de confianza para el FQDN del portal utilizado.

La correlación comienza en Email > Mail logs. En Reason, SPX encryption identifica los mensajes cifrados mediante SPX y SPX failure los mensajes SPX no entregados; en Result se puede filtrar además, por ejemplo, por Delivered, Dropped o Quarantined. Se comparan remitente, destinatario, asunto e intervalo horario con la nota de prueba. Para errores detallados se continúa con Log Viewer y los archivos MTA smtpd_main.log, smtpd_error.log y smtpd_panic.log. Servicios y registros de Sophos Firewall explica el acceso y otros archivos de registro.

SPX failure no es otro nombre para la cuarentena SMTP. Un mensaje solo aparece en Email > SMTP quarantine si una acción de Spam, Malware, Unscannable, DKIM u otra acción de política lo pone realmente en cuarentena. Durante la prueba no se libera sin haber documentado antes el motivo y la política activadora; de lo contrario se puede confundir un fallo de análisis o política con un fallo SPX.

En HA, los registros se encuentran en el nodo que ha procesado el tráfico. Después de un failover controlado se prueban por separado un nuevo correo SPX, el registro de contraseña y la respuesta. No se presupone que una sesión de portal existente o un proceso de registro en curso continúen sin interrupción. Los fundamentos se explican en Clústeres HA de Sophos Firewall.

Acotar los errores de forma sistemática

El mensaje no se cifra

Comprobar la dirección, el dominio protegido, la política SMTP route and scan real y la prioridad de los activadores. Para Data Control, revisar también Data protection, la Data control list seleccionada, Data control list action: Accept with SPX y su SPX template. Para un activador del remitente debe existir una plantilla predeterminada y no debe estar sobreescrita por una plantilla de dominio o Data Control. Las dos grafías documentadas del encabezado no justifican desplegar ambas sin probarlas en producción.

Mail logs muestra SPX failure

En Email > Mail logs, acotar la fila afectada por hora, remitente, destinatario y asunto, y confirmar Reason: SPX failure. Correlacionar el error visible con smtpd_main.log, smtpd_error.log y, para errores graves de proceso, smtpd_panic.log a la misma hora. Solo entonces cambiar el modelo de contraseña, la plantilla, la entrega o la ruta del portal. Si Result es Quarantined, investigar en Email > SMTP quarantine el análisis o la acción de política que lo activó.

El enlace de registro o el portal no es accesible

Comprobar el FQDN, la resolución DNS pública, el puerto, el certificado, Allowed networks y la validez del enlace. Un valor vacío de Allowed Networks se trata como Any y, por tanto, no es un estado de desactivación seguro. Si el cliente llega a otro host o portal, la URL, NAT o la asignación de certificado no coinciden con la ruta prevista.

El PDF no se puede abrir

Primero hay que asociar el tipo de contraseña con el mensaje concreto. Una contraseña de un solo uso solo es válida para ese correo. En contraseñas almacenadas o registradas, la causa puede ser la caducidad o la mezcla de varios modelos. Después de un SPX Password Reset, el remitente debe volver a entregar la nueva contraseña al destinatario de forma segura.

Para un restablecimiento específico, introducir en Email > Encryption > SPX password reset la dirección de correo del destinatario afectado y comprobarla antes de ejecutarlo. Coordinar el restablecimiento y la entrega segura de la nueva contraseña con remitente y destinatario; después, abrir un nuevo mensaje SPX de prueba. Esto no garantiza que los PDF antiguos puedan abrirse con la nueva contraseña.

La respuesta segura no llega

Comprobar Enable SPX reply portal en la plantilla, el periodo de respuesta, el FQDN del portal, el puerto, el certificado y los orígenes permitidos. Después, revisar Mail logs y los registros MTA para la respuesta concreta. Abrir correctamente el PDF no demuestra que funcione el canal de retorno.

La validación DKIM falla después de SPX

SPX modifica el cuerpo y los archivos adjuntos. Si un mensaje se firma antes de ese cambio, la firma puede resultar inválida en el destinatario. Debe definirse si el servidor de correo interno, Sophos Firewall o un gateway posterior firma después de todas las modificaciones previstas. La cadena de procesamiento y una prueba externa deben validarse conjuntamente.

Revertir de forma segura

1. Retirar primero la asignación SPX concreta de Domains and routing target. Para un activador de Data Control, restaurar Data control list action en la política SMTP desde Accept with SPX hasta la acción anterior documentada.
2. Si se utiliza, establecer Default SPX template en None.
3. Realizar una prueba negativa saliente y confirmar que no se genera ningún PDF SPX nuevo.
4. Retirar el Reply y Registration Portal solo si ninguna otra política SPX activa depende de ellos.
5. Restaurar los accesos temporales públicos de puerto, DNS o portal al estado anterior documentado. Revertir los requisitos SMTP TLS modificados por separado únicamente según su propio estado anterior registrado.
6. Eliminar la plantilla solo cuando ninguna política ni proceso operativo activo haga referencia a ella.
7. Conservar Mail logs y los registros MTA de la última prueba cifrada y la primera sin cifrar.

Antes de modificar rutas de correo y portales en producción se crea un backup actual de Sophos Firewall. SPX puede seguir funcionando en entornos air gap, pero las dependencias externas de DNS, certificados y portal deben seguir siendo accesibles por separado. Los límites del producto se explican en Funciones de SFOS sin acceso a internet.

Lista de comprobación operativa

• Se han comprobado la licencia, el modelo, el flujo de correo MTA y el destinatario externo.
• El activador y su prioridad están documentados.
• El tipo de contraseña y el canal seguro de entrega encajan con el caso de uso.
• El FQDN del portal, el certificado central de los portales, el puerto y Allowed Networks tienen un alcance estricto; SMTP TLS se documenta por separado.
• La asignación de dominio, Data Control o predeterminada es inequívoca.
• Se han superado las pruebas positiva, negativa, de contraseña, PDF y respuesta.
• Los filtros SPX encryption y SPX failure de Mail logs y los registros MTA se pueden correlacionar con el mensaje de prueba; las acciones de cuarentena se distinguen de ellos.
• El failover HA y los registros locales de cada nodo forman parte del procedimiento operativo.
• El responsable, las caducidades, la fecha de revisión y la reversión están documentados.

Preguntas frecuentes