Configurar Sophos Firewall Mail Protection en modo MTA

En MTA mode, Sophos Firewall acepta los correos, los inspecciona y los entrega al servidor de correo interno o al siguiente mail hop. El flujo solo funciona si el registro MX, la regla MTA automática, la SMTP route and scan Policy, el relay, TLS y la verificación de destinatarios encajan entre sí.

La configuración consta de seis pasos: definir el flujo y la ruta de reversión, activar MTA mode, añadir el dominio de correo, crear la route and scan Policy, proteger el relay y cambiar el registro MX. Después se validan los flujos entrante y saliente mediante comandos externos, cuarentena, spool y logs.

Cuándo conviene MTA mode

Mail Protection en el firewall resulta especialmente útil en entornos on-premises e híbridos diseñados de forma consciente, en los que se debe proteger un Exchange local u otro servidor de correo. Para Microsoft 365, Google Workspace y muchos entornos exclusivamente cloud, Sophos Email u otro gateway de correo cloud suele ofrecer una arquitectura más clara. Encadenar dos gateways complica la cuarentena, los headers, TLS, SPF/DKIM/DMARC y el troubleshooting.

Si Exchange Online debe utilizar de forma deliberada el MTA del firewall, Configurar Sophos Firewall MTA con Microsoft 365 explica la ruta completa de EOP, relay, conector, MX y SPF.

Se deben distinguir tres funciones de Sophos Firewall:

• MTA mode: el firewall acepta, inspecciona y enruta el correo.
• Legacy mode: procesamiento proxy transparente de una ruta SMTP existente. Configurar Mail Protection en Legacy mode explica NAT, reglas, políticas de análisis y validación.
• SMTP Relay en Device Access: controla desde qué zonas se puede alcanzar el MTA. El correo entrante desde Internet requiere WAN; el relay saliente se restringe además a servidores de correo internos concretos.

La recuperación de mensajes existentes del buzón mediante POP3 o IMAP es una tarea distinta. Analizar y probar POP3 e IMAP en Sophos Firewall explica la confianza TLS, la política opcional, la regla de firewall y la aceptación.

Se necesita una licencia válida de Email Protection, routing y DNS operativos, una IP pública conocida, el servidor de correo interno y su puerto de destino, además de estrategias definidas para TLS, cuarentena y reversión. Según la descripción actual de Sophos, MTA mode no está disponible en XGS 87/87w ni XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation y SXL2 Live Protection requieren acceso a Internet. El routing de correo, el análisis antimalware, el filtrado MIME y SPX pueden seguir funcionando con la licencia adecuada en un entorno airgap, pero un MTA activo no implica que allí estén disponibles todas las comprobaciones de protección.

Configurar MTA mode de principio a fin

1. Definir el flujo de correo y la ruta de reversión

Para el flujo entrante, el registro MX público apunta a la dirección en la que Sophos Firewall acepta TCP 25. El firewall inspecciona el mensaje y lo entrega al servidor interno. Una regla DNAT antigua no debe dejar dicho servidor accesible directamente desde Internet sin inspección, pues permitiría eludir el MTA. Publicar un servidor mediante DNAT explica la lógica general de DNAT.

Para el flujo saliente, solo el servidor previsto envía a través del firewall. La ruta de envío, el smarthost, PTR/rDNS, HELO, SPF, DKIM y DMARC deben corresponder a la identidad pública del remitente. Una regla general LAN to WAN es demasiado amplia; la base de reglas debe identificar claramente al remitente SMTP permitido. Entender las reglas de Sophos Firewall explica el orden de las reglas.

Antes de la migración se documentan:

• registro MX actual, prioridad y TTL;
• nueva dirección pública del firewall y servidor de destino interno;
• reglas DNAT y SMTP existentes y conectores del servidor de correo;
• remitentes de prueba entrante y saliente;
• registro MX o ruta de correo anteriores como reversión;
• monitorización de la cola del servidor, el spool del firewall y la cuarentena.

El TTL debe reducirse con antelación si puede ser necesaria una reversión rápida. Los cambios del MX productivo pertenecen a una ventana de mantenimiento.

2. Configurar MTA mode y los ajustes SMTP básicos

En Email > General settings, seleccionar Switch to MTA mode si es necesario. Sophos Firewall crea entonces la regla Any-to-Any Auto added firewall policy for MTA para SMTP y SMTPS. No se debe editar y debe permanecer al principio de la lista de reglas. Al cambiar a Legacy mode se elimina y al volver a MTA mode se crea de nuevo.

Después se configuran los ajustes básicos:

1. En SMTP hostname, introducir el nombre de dominio, por ejemplo example.com, no el hostname del servidor interno. El valor aparece en HELO y en el banner SMTP de las notificaciones generadas por el sistema.

   Comprobar la respuesta de la API XML: La documentación de SFOS 23 incluye el estado 506 con Message.AVGeneralConfInvalidSmtpNtfyHostname para la operación Email Configuration de la API XML. Es un estado de la operación, no un código de estado HTTP. La clave no está resuelta ni constituye un mensaje de error en inglés; no permite deducir reglas concretas de validación. Si aparece esta respuesta, comprobar el valor de hostname enviado para las notificaciones, la respuesta real de la operación y la configuración guardada antes de dar por realizado el cambio. La fila adicional de la documentación no demuestra que este comportamiento en ejecución se introdujera por primera vez en SFOS 23.

2. Activar Reject based on IP reputation para rechazar conexiones de remitentes con mala reputación.

3. En SMTP TLS configuration, seleccionar un certificado de confianza pública y permitir Allow invalid certificate únicamente para excepciones documentadas.

4. Activar Disable legacy TLS protocols, salvo que haya sistemas antiguos documentados que lo impidan. Esta opción desactiva protocolos anteriores a TLS 1.1; no obliga automáticamente a usar solo versiones TLS actuales.

5. Activar Scan outgoing mails si también se deben inspeccionar los mensajes salientes.

Se debe usar Require TLS negotiation con precaución: si SFOS no puede establecer la conexión TLS exigida, descarta el correo al destino afectado o procedente del dominio remitente configurado. La ayuda de SFOS 22/23 advierte que la conexión y validación SMTP TLS utilizan la IP del dominio en lugar de su nombre; varios dominios en una misma IP pueden causar errores de certificado. Es una advertencia documental, no una prueba del algoritmo de comprobación de certificados del build desplegado.

Skip TLS negotiation selecciona hosts de correo remotos o redes para conexiones SMTP sin cifrar; el límite documentado es de 512 entradas de host. No es una solución para un certificado incorrecto. Allow invalid certificate es una excepción de validación del interlocutor TLS, no un cambio a texto en claro. No suponer precedencia si las listas Require y Skip se solapan, ni una alternativa en claro tras fallar el TLS obligatorio. Limitar y documentar las excepciones y verificar el resultado real de la conexión y del certificado en el build desplegado antes de modificarlas.

Definir los límites SMTP globales antes de las políticas

Los ajustes de Email > General settings se aplican a todos los correos y se procesan antes de las políticas SMTP y POP-IMAP. Por tanto, Reject based on IP reputation no es una acción de una política concreta: SFOS comprueba la IP del remitente antes de los controles de spam de la política SMTP. Blocked senders también es global, pero solo bloquea correos entrantes.

En SMTP settings, Don’t scan emails greater than define el tamaño máximo de mensaje para el análisis SMTP global. 0 significa 51,200 KB, no ilimitado. Para los mensajes mayores se dispone de Accept, Reject y Drop. Accept entrega sin analizar, Reject rechaza y notifica al remitente, y Drop descarta sin notificación. Esta elección se documenta como una brecha de análisis o una decisión de entrega consciente y se prueba con un mensaje justo por encima y por debajo del límite.

Los SMTP DoS settings limitan las conexiones simultáneas, los correos por conexión, los destinatarios por correo y las tasas de correo y de conexión. SFOS fija las conexiones máximas en función de la RAM y el procesador. Los valores predeterminados documentados son 1000 correos por conexión y 100 destinatarios por mensaje. Los valores propios se deducen del volumen real de correo; un límite demasiado bajo puede tratar como ataque a listas de distribución o escáneres legítimos.

En Advanced SMTP settings, SFOS puede rechazar un HELO no válido o la ausencia de RDNS y, con Do strict RDNS checks, un nombre de host que no resuelva de nuevo a la IP de origen. Estas comprobaciones no se introducen al mismo tiempo que una excepción amplia. Primero se registran en el log las rutas reales de socios, boletines y aplicaciones y después se prueban por separado.

Un banner saliente puede utilizar Inline, no conversion, la opción MIME part u Off. El análisis SMTP o SMTPS debe estar activo en la regla de firewall coincidente. Como un banner modifica el body y puede invalidar una firma DKIM existente, se firma después de ese cambio o se verifica expresamente en el destinatario que la firma prevista sigue siendo válida.

3. Añadir el dominio como Address Group

1. Abrir Email > Address group > Add.
2. Establecer Group type en Email address/domain y Type en Manual.
3. Añadir el dominio protegido, por ejemplo example.com.
4. Guardar el grupo.

Al crear el grupo, introducir también un Name claro antes de guardar. Para un grupo existente, usar Edit en Email > Address group; iniciar la importación de un archivo con Import. RBL (IPv4) admite direcciones IPv4 y RBL (IPv6) direcciones IPv6. Email address/domain permite entradas manuales o importación CSV/texto. La coincidencia RBL utiliza la IP de conexión y la acción definida en la policy SMTP; sigue aplicándose el comportamiento de rechazo SPF/RBL documentado por separado. Conservar los nombres predeterminados Premium RBL services y Standard RBL services, salvo un cambio planificado expresamente.

Las Address Groups no se limitan a dominios de correo. Group type puede ser Email address/domain, RBL IPv4 o RBL IPv6. Una misma dirección puede pertenecer a varios grupos, lo que permite crear objetivos de policy separados sin copiar ni renombrar la entrada.

Para listas extensas, SFOS puede importar un archivo CSV o de texto con hasta 400 direcciones o dominios. Las entradas no válidas y duplicadas se omiten. Después de la importación se comprueban el número de entradas y algunas muestras antes de asignar el grupo a una policy de producción.

Las nuevas SMTP route and scan Policies se diseñan con dominios, no con direcciones de destinatarios individuales. Las direcciones individuales migradas pueden seguir funcionando, pero no se pueden añadir ni editar en las policies actuales.

4. Crear una SMTP route and scan Policy

Abrir Email > Policies and exceptions > Add policy > SMTP route and scan:

1. Introducir un nombre claro, por ejemplo Inbound example.com to Exchange.
2. En Protected domain, seleccionar la Address Group.
3. Elegir Route by:
   • Static host: IP fija del servidor interno; si falla, el firewall prueba el siguiente host de la lista.
   • DNS host: nombre DNS como mailserver.example.com; se utilizan varios registros A entre entregas y se omiten los servidores que fallen.
   • MX: entrega basada en un registro MX.
4. Para Static host, seleccionar el servidor en Host list. Si es necesario, crear su IP host en Hosts and services > IP host.
5. Establecer Global action en Accept para los dominios que se protegen deliberadamente. Reject rechazaría todos los mensajes entrantes y salientes relacionados con esos dominios e informaría al remitente.
6. Activar Spam protection y Malware protection según la política operativa.
7. Activar File protection y Data protection solo después de entender su efecto sobre adjuntos, mensajes grandes, SPX y DKIM.
8. Guardar la policy.

Para modificar una política SMTP route and scan existente, abrir Email > Policies and exceptions, seleccionar Edit en la política correspondiente, cambiar los ajustes necesarios y guardar la política. Después, volver a comprobar la coincidencia de la política y la entrega con un mensaje controlado.

Con Route by MX, el MX resuelto por el firewall no debe apuntar de nuevo al propio firewall, pues se produciría un bucle de routing. El firewall debe resolver correctamente los destinos internos; para split DNS sirven las DNS Request Routes.

La opción Route inbound mail through gateway solo es necesaria para diseños especiales, por ejemplo servidores de destino en la zona WAN, aplicación de la regla original a destinos LAN/DMZ o selección de un gateway concreto con varias conexiones a Internet. No se debe activar sin un requisito real de routing.

5. Proteger el acceso entrante y el relay saliente

En Administration > Device access, permitir SMTP Relay desde todas las zonas que deban alcanzar el MTA. El correo entrante desde Internet requiere WAN; el saliente necesita además la zona del servidor interno, normalmente LAN o DMZ. Después, en Email > Relay settings > Host-based relay, restringir el acceso a servidores, escáneres o aplicaciones concretos.

Las autorizaciones amplias de hosts o redes crean un riesgo de open relay. Si impresoras o aplicaciones deben enviar correo, se documentan como objetos de host concretos. Proteger el acceso a Sophos Firewall explica los fundamentos de Device Access.

Las listas Allow y Block no siguen el principio de que Block siempre tenga prioridad. Si el mismo host o la misma red aparece en ambas listas de Host-based relay o Upstream host, SFOS permite el relay. Estas coincidencias se eliminan antes de activar la función y se realiza una prueba negativa desde una fuente no autorizada.

Un host permitido tampoco evita el análisis de correo. Si SFOS no puede analizar una IP de origen autorizada para host-based relay, la rechaza. Por tanto, una autorización de relay no demuestra ni un análisis correcto del contenido ni la entrega; ambos se comprueban con un mensaje real y los logs MTA.

La SMTP route and scan Policy no admite SMTP AUTH. Para dispositivos, Host-based relay es por tanto la opción fiable. Existen además Authenticated relay settings separadas para usuarios y grupos; Sophos advierte de que no implementan un estándar SMTP Authentication conforme a RFC, por lo que se debe probar la compatibilidad del cliente. Esto es distinto de la autenticación del firewall ante un smarthost upstream, para la que SFOS admite PLAIN y LOGIN. Nunca se debe usar como smarthost una IP de interfaz del propio firewall, ya que crearía un bucle de routing.

Varias interfaces WAN o direcciones IP alias

El MTA crea por sí mismo la conexión SMTP saliente. Cuando existen varias direcciones públicas posibles, una regla normal de cliente no es suficiente. Sophos distingue tres casos: con una interfaz WAN y varias direcciones IP alias se crea una regla SNAT con la Translated source pública deseada. Con varias interfaces WAN sin alias se crea una ruta SD-WAN para SMTP, SMTP(S) y SMTPS_465. Si hay varias interfaces WAN y direcciones alias, se combinan SNAT y la ruta SD-WAN.

La regla SNAT conserva destino y servicio, utiliza como interfaz de salida la línea WAN prevista y traduce a MASQ o a la IP alias deseada. La ruta SD-WAN utiliza como destino el grupo de Internet, los tres servicios SMTP y el gateway primario previsto, además de un backup opcional. El backup solo resulta útil si allí se permite realmente TCP 25 saliente y esa dirección pública también figura en el registro SPF del dominio de correo.

Para este procedimiento oficial con varias WAN, Sophos exige la precedencia static, vpn, sdwan_policyroute y activa SD-WAN para tráfico generado por el sistema. Ejecutar estos comandos en Device Console (opción 4 del menú CLI), no en Advanced Shell. Leer primero ambos valores iniciales, aplicar los cambios y volver a verificarlos:

system route_precedence show
show routing sd-wan-policy-route system-generate-traffic
set routing sd-wan-policy-route system-generate-traffic enable
system route_precedence set static vpn sdwan_policyroute
system route_precedence show
show routing sd-wan-policy-route system-generate-traffic

La precedencia de rutas es global y no un interruptor aislado de correo. Antes del cambio se documentan todas las rutas estáticas, VPN y SD-WAN solapadas y los dos valores leídos. Para revertir, restaurar el orden anterior completo con system route_precedence set ... y devolver system-generate-traffic a su estado inicial enable o disable. Después se comprueban no solo los contadores SMTP, sino también la IP de origen realmente utilizada, la entrega, el resultado SPF y el fallo del gateway primario. Comprobar el routing SD-WAN para tráfico generado por el sistema explica el procedimiento general de seguridad y reversión.

6. Cambiar el registro MX

El MX público solo se cambia a la dirección del firewall cuando la regla MTA, el dominio, la policy, el relay y la ruta de entrega interna están preparados. Inmediatamente después se envía un mensaje externo de prueba y se comprueba que aparece en Log Viewer o Mail logs, se entrega al servidor interno y llega al buzón.

Si los remitentes externos no pueden alcanzar el firewall o se rechazan de forma generalizada mensajes legítimos, se restaura la ruta anterior documentada. Las cachés DNS impiden que la reversión sea efectiva inmediatamente en todas partes. Por eso, las rutas anterior y nueva se mantienen operativas en paralelo y monitorizadas al menos hasta que caduque el TTL previo más largo. Si el firewall acepta mensajes pero no los entrega, se comprueban primero routing, DNS, TLS, recipient verification y los logs del servidor.

Elegir conscientemente las protecciones

Utilizar tipos de archivo propios y Data Control Lists

En MTA mode se crea un tipo de archivo propio en Email > Policies and exceptions > File type > Add a partir de una plantilla, extensiones o tipos MIME. Las extensiones se escriben sin punto inicial. Solo se pueden editar los tipos propios. Un tipo recién creado tampoco se incorpora automáticamente a las policies existentes: hay que abrir la SMTP route and scan Policy concreta, añadirlo en File protection y volver a guardarla. Una prueba positiva con un adjunto y otra negativa similar confirman la coincidencia mejor que el nombre del objeto por sí solo.

En File protection > Block file types, All bloquea mensajes con adjuntos; no significa analizar todos los adjuntos. None permite adjuntos en este filtro de archivos, pero no evita controles antimalware, antispam, Data Protection u otros. La ayuda de policies indica que los headers MIME seleccionados rellenan la MIME whitelist, permitiendo esos tipos y bloqueando los restantes. Los headers MIME y extensiones no demuestran que el contenido sea inocuo. Verificar adjuntos permitidos y bloqueados en el build desplegado antes de aplicar una receta precisa de whitelist.

Una Data Control List se compone de Content Control Lists, o CCLs, para tipos de contenido definidos, como datos financieros o personales. Al crearla en Email > Data control list > Add, se filtran las CCLs por Type y Region y se seleccionan solo las entradas realmente necesarias. La acción se define únicamente en la policy vinculada. Se prueba una coincidencia controlada y un contenido similar sin coincidencia para confirmar que match y acción funcionan juntos sin falsos positivos innecesarios.

Spam protection es más que la acción aplicada al spam. Los fallos SPF y RBL se rechazan directamente y no siguen las acciones normales para spam o probable spam. Greylisting rechaza temporalmente un mensaje de forma intencionada y exige que el servidor remitente vuelva a intentarlo.

Para Reject based on BATV, primero debe configurarse un BATV secret común en Email > General settings > Advanced SMTP settings. En varios sistemas MX propios se utiliza el mismo secreto. SFOS lo combina con la marca de tiempo y la dirección del remitente para crear la firma del Return-Path, que caduca a los siete días. Por tanto, un error BATV se contrasta con el secreto, la hora del sistema, la ruta del remitente y la antigüedad de la firma, en vez de ocultarlo con una excepción amplia sin caducidad.

Recipient verification impide mensajes a destinatarios desconocidos:

• With callout: consulta el servidor de destino. Si no está disponible temporalmente, SFOS acepta destinatarios tras un periodo definido en vez de bloquear permanentemente todo el flujo.
• In Active Directory: comprueba mediante Simple, SSL o STARTTLS y tiene un timeout de 30 segundos. Especificar el servidor AD, Bind DN y Base DN. Bind DN es el nombre distinguido completo, incluido el CN de la identidad de enlace configurada; Base DN es el punto de partida de las búsquedas en el directorio. Utilizar valores adecuados para el directorio propio. El ejemplo de administrador de la ayuda no establece la necesidad de privilegios Domain Admin. Elegir un transporte que cumpla la política de confianza y seguridad desplegada; la etiqueta SSL o STARTTLS por sí sola no demuestra una validación correcta del certificado.

Malware Protection puede usar análisis antivirus simple o doble. Para usar Zero-Day Protection con un solo antivirus, Sophos debe ser el motor principal. Sophos Firewall Zero-Day Protection explica los límites y las decisiones de liberación.

Según la ayuda de policies de SFOS 22/23, Single antivirus selecciona el motor principal solo para correo entrante; el saliente utiliza ambos motores. Dual antivirus analiza primero con el motor principal y después con el secundario. El motor principal, Sophos o Avira, se selecciona globalmente en Email > General settings. Elegir Avira desactiva Zero-day protection en policies SMTP con análisis antivirus único; Sophos debe ser principal para usar Zero-Day Protection con un solo análisis. La ayuda de ajustes generales describe el análisis único como uso exclusivo del motor principal, sin la distinción de dirección de la tabla de policies. Esta diferencia documental no demuestra qué motores se usan realmente: verificar build, policy, dirección del correo y estado de protección antes y después de un cambio. Registrar los ajustes anteriores; restaurar la elección de motor no demuestra que Zero-day protection se haya reactivado.

El límite de política Drop message greater than de File protection no es lo mismo que el comportamiento global ante mensajes demasiado grandes: en este punto se descartan los mensajes mayores. SFOS también examina el contenido visible y el contenido de formatos empaquetados como docx, xlsx, pptx, odt, ods, odp y odg. Por tanto, una prueba positiva solo con un archivo de texto sin empaquetar no demuestra cómo se trata la misma información dentro de un documento de Office.

Con la opción DKIM verification activada, SFOS distingue un hash que no coincide, una firma no válida o una clave pública no disponible y la ausencia de firma DKIM. Para cada resultado pueden seleccionarse Accept, Quarantine o Reject. Según Sophos, los mensajes firmados con DKIM que usan RSA-SHA1 o una clave fuera de 1024 a 4096 bits se ponen en cuarentena. Esta verificación entrante se prueba por separado de la firma saliente.

En mensajes salientes importa el orden del procesamiento. El cifrado SPX, los prefijos de asunto, File o Data Protection y los banners salientes pueden modificar el header o el body después de aplicar una firma DKIM. La validación DKIM falla entonces en el destinatario. Se debe decidir si firma el servidor interno, Sophos Firewall o un gateway posterior.

Firmar los mensajes salientes con DKIM en el firewall

Si Sophos Firewall debe firmar los mensajes, se añade una firma para cada dominio remitente en Email > General settings > DKIM signing > Add. Domain es el FQDN del dominio de correo; Key selector es exactamente el selector que después se publica en el DNS público. Un nombre como fw01 o zurich facilita comprender futuras rotaciones de claves, pero no es una función de seguridad.

SFOS espera una clave RSA privada de 1024 a 2048 bits entre -----BEGIN RSA PRIVATE KEY----- y -----END RSA PRIVATE KEY-----. Para configuraciones nuevas, 2048 bits es la opción adecuada. No se debe usar RSA-SHA1. Según Sophos, el firewall no acepta una clave de 1024 bits generada con PuTTYgen, por lo que allí también se seleccionan 2048 bits. La clave privada pertenece exclusivamente al firewall y nunca debe aparecer en DNS, tickets ni documentación pública.

Después de guardar, se publica en el proveedor DNS autoritativo el registro TXT DKIM del selector con la clave pública. Solo cuando el registro se resuelva externamente se envía un mensaje nuevo por la ruta MTA saliente prevista. La cabecera recibida debe mostrar el selector y el dominio esperados, y la verificación DKIM del destinatario debe ser correcta. Si falta la firma, se comprueban el dominio remitente, la coincidencia de la policy y Scan outgoing mails. Si falla la verificación, primero se comparan el registro DNS, el selector, la clave utilizada y los cambios posteriores realizados por SPX, banners, File Protection o Data Protection.

Configurar y probar el cifrado de correo SPX explica cómo se relacionan la plantilla, la prioridad de los activadores, el modelo de contraseña y el Reply Portal.

Validar el flujo de correo

Los siguientes comandos se ejecutan desde un sistema fuera de la red propia:

dig MX example.com
dig A mail.example.com
dig AAAA mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Sustituir example.com y mail.example.com por los valores reales. Los comandos prueban DNS, TCP 25 y STARTTLS, pero no la autorización de relay ni la entrega completa. openssl s_client permanece interactivo después del handshake; se detiene con Ctrl+C.

Probar al menos estos casos:

• mensaje externo a un destinatario válido;
• con Recipient verification activado, mensaje externo a un destinatario no válido;
• mensaje saliente a través del servidor previsto;
• prueba de spam o malware adecuada para la policy;
• STARTTLS y la cadena de certificados presentada;
• acción de cuarentena y entrega tras la liberación;
• intento de relay bloqueado desde una fuente no autorizada;
• ausencia de entrega directa que eluda el MTA mediante una regla DNAT antigua.

Registrar únicamente resultados de aceptación observados: el mensaje de prueba válido debe figurar como Delivered en Mail logs y poder seguirse mediante su Message-ID hasta el buzón de destino. Con recipient verification activado, el destinatario no válido debe rechazarse; si la verificación está desactivada, el rechazo no es el resultado esperado de esta prueba negativa. El intento de relay no autorizado no debe generar ningún mensaje y la liberación de cuarentena debe mostrar la entrega posterior del mismo Message-ID.

Para la primera revisión se utilizan Email > Mail logs, Email > Mail spool, Email > SMTP quarantine y Log Viewer. Para un análisis más profundo se anotan la hora de prueba, remitente, destinatario, asunto, IP de origen y Message-ID, y se correlacionan con estos archivos:

• MTA: smtpd_main.log
• rechazos: smtpd_reject.log
• errores de análisis: smtpd_error.log
• errores internos del MTA: smtpd_panic.log
• anti-spam: sasi.log
• proxy SMTP legacy: awarrensmtp.log
• proxy POP/IMAP: warren.log

Servicios y logs de Sophos Firewall explica la asignación y el acceso mediante Advanced Shell.

En Mail logs, Result identifica el estado de entrega y Reason describe el motivo de análisis o de policy. Rejected significa que SFOS descartó el mensaje e informó al remitente. Dropped lo descarta sin notificación; Bounced aparece tras varios intentos de entrega fallidos. Estos estados no se tratan como equivalentes porque generan respuestas y rutas de diagnóstico diferentes. Otros resultados son Delivered, Quarantined y Deleted manualmente; entre los motivos pueden filtrarse Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM y BATV.

Operar la cuarentena y el Mail spool

En Email > SMTP quarantine, filtrar por periodo, remitente, destinatario, asunto y motivo de cuarentena:

• Release: entregar el mensaje.
• Delete: eliminar el mensaje.
• Release and report: liberar y notificar a SophosLabs solo falsos positivos clasificados como Spam o Probable spam.

Los mensajes infectados por virus o clasificados como maliciosos por Zero-Day Protection no se pueden liberar. Para eliminar entradas de Zero-Day Protection, el perfil de administrador necesita permisos de escritura para esa función. Cuando la cuarentena está llena, se purgan los mensajes más antiguos.

Solo reciben resúmenes de cuarentena los usuarios que se han autenticado al menos una vez en el firewall. De forma predeterminada, SFOS no aplica los ajustes del resumen a las direcciones alias; asignarlas junto con la dirección principal en Email > Quarantine settings > Change user’s quarantine digest settings o en el objeto de usuario. El resumen puede incluir entonces spam enviado a las direcciones principal y alias. Los mensajes dirigidos a alias siguen sin aparecer en el propio User Portal.

Configurar y probar el resumen de cuarentena de Sophos Firewall explica la configuración, la asignación de usuarios, el enlace de liberación y la prueba funcional completa.

Email > Mail spool contiene mensajes aún no entregados o fallidos. SFOS reintenta la entrega durante tres días y descarta los mensajes después de otros cuatro; los mensajes descartados siguen visibles en Mail logs. Un spool creciente es, por tanto, una alerta de problemas de routing, DNS, TLS, policy o servidor, no un motivo para pulsar Retry repetidamente sin diagnóstico.

El filtro de estado distingue Queued, Failed, SPX blocked, Zero-day protection y Error. SPX blocked espera a que el destinatario genere una contraseña; Zero-day protection espera el análisis. Solo los mensajes de la error queue pueden descargarse o eliminarse. Para eliminar o volver a enviar mensajes de Zero-Day Protection, el perfil de administrador necesita permisos de lectura y escritura para Zero-Day Protection Activity. Si falta un botón, primero se comprueban el estado y el perfil, en vez de intentar evitar la limitación reiniciando un servicio.

La cuarentena y el spool consumen almacenamiento local. Se deben monitorizar el espacio libre, el estado de la SSD y System Health; véanse Limpiar almacenamiento y reports y Comprobar SSD Health. En HA, los logs y reports son independientes por node y no se sincronizan, por lo que se deben comprobar ambos. Clústeres HA de Sophos Firewall explica los fundamentos.

Troubleshooting

No llega correo externo

Comprobar MX, A/AAAA, IP pública, TCP 25 y SMTP Relay desde WAN. Después verificar que MTA mode esté activo, que el dominio protegido coincida con la policy y que ninguna regla DNAT antigua o regla de mayor prioridad cambie la ruta esperada. Si smtpd_main.log no muestra ninguna conexión, el problema probablemente se encuentra antes de Mail Protection.

El firewall acepta el correo, pero no lo entrega

Comprobar el servidor interno, la ruta, DNS, puerto de destino, TLS y recipient verification. Static host, DNS host y MX usan rutas de resolución y failover distintas. Correlacionar los logs de rechazo y error del firewall con los del servidor.

Muchos mensajes permanecen en el spool

Revisar primero Email > Mail spool y los logs del MTA. Una causa frecuente es una regla situada por encima de la regla MTA automática que ya coincide con SMTP. En Rules and policies > Firewall rules, comprobar nuevas reglas con posición Top, reglas IPsec o hotspot generadas automáticamente y otros solapamientos. No mover ninguna regla a ciegas; lo decisivo es su match SMTP real.

Solo después de confirmar que la nueva regla solapada es la causa, moverla hacia abajo en Rules and policies > Firewall rules lo suficiente para que la regla SMTP prevista vuelva a evaluarse. Después, volver a comprobar la entrega y el spool con un mensaje controlado; las demás conexiones necesarias deben seguir utilizando las reglas previstas.

NC-177930 se corrigió en SFOS 22.0 MR2: los mensajes permanecían en el spool tras un crash de mailpoller. Si el problema aparece en una versión anterior, el firmware debe formar parte del diagnóstico. Usar la comprobación de actualización a SFOS 22 para elegir la build de destino, preparar el cambio y volver a probar después el flujo de correo.

Sophos Fusion muestra Invalid API request

En SFOS 22.0 MR1, Release y Delete podían fallar cuando el firewall se abría mediante Sophos Fusion (antes Sophos Central). El síntoma Invalid API request se registra como NC-182056; NC-181904 identifica la corrección del fallo de liberación desde Sophos Fusion. El workaround seguro es iniciar sesión directamente en el WebAdmin local y ejecutar la acción en Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 corrige el problema. Si sigue fallando, comprobar por separado el perfil de administrador, el acceso a Sophos Fusion y los permisos locales. Para una actualización, seguir el proceso completo de aprobación, preparación, validación y troubleshooting de Actualización del firmware de Sophos Firewall: preparación y prácticas recomendadas.

No se puede activar Reject based on RBL

NC-144563 es un caso asociado específicamente a SFOS 20.0.2 MR2 Build 378: Si se han cambiado los nombres de los grupos RBL predeterminados en Email > Address group, no se puede activar Reject based on RBL al crear una política SMTP route and scan. En una política existente, la opción no se puede volver a activar después de deshabilitarla. No hay una versión corregida documentada.

Los grupos predeterminados se llaman Premium RBL services y Standard RBL services. Primero documentar el build exacto y los nombres actuales de los grupos. Si se cumplen ambas condiciones, restablecer los nombres originales de las RBL predeterminadas, volver a abrir la política y comprobar la opción. No confundir las RBL personalizadas con estos dos grupos del sistema.

En otros builds, o si los nombres predeterminados no han cambiado, una opción atenuada no demuestra NC-144563. Comprobar por separado el tipo de política, Spam protection, la licencia de Email Protection y el resto de la configuración.

Un remitente legítimo se clasifica como spam

Comprobar el dominio remitente, SPF/DKIM/DMARC, headers, reputación, policy match y destinatarios afectados. Solo entonces crear una excepción limitada y con fecha de revisión. Crear y probar excepciones de correo de forma segura describe el proceso completo de alcance, pruebas y reversión.

Los sistemas internos no pueden usar relay

Comprobar la zona de origen en Administration > Device access, el objeto de host en Email > Relay settings > Host-based relay y los logs del MTA. Si un escáner espera SMTP AUTH estándar, Host-based relay suele ser más fiable. El Authenticated relay separado, que no cumple RFC, debe probarse con el cliente concreto.

Lista de comprobación operativa

• Se han verificado licencia, compatibilidad del modelo, DNS y servicios de Internet necesarios.
• Se han documentado MX, TTL, rutas pública e interna y reversión.
• La regla MTA automática permanece sin cambios y al principio.
• Ninguna regla DNAT antigua elude Mail Protection.
• Address Group, destino de routing y policy match están probados.
• SMTP Relay entrante desde WAN y permisos de host salientes están correctamente separados.
• Se entienden los efectos de SPF/RBL, recipient verification, TLS, DKIM, SPX y banners.
• Se han realizado pruebas externas positivas y negativas.
• Se monitorizan cuarentena, spool, almacenamiento y logs.
• El flujo se vuelve a probar después de actualizaciones de firmware.

Para una retención y correlación más largas, utilizar Central Firewall Reporting o enviar logs de Sophos Firewall a un SIEM.

FAQ