Crear y probar excepciones de correo en Sophos Firewall
Una excepción de correo en Sophos Firewall no se limita a permitir un remitente. Omite comprobaciones de seguridad seleccionadas para una ruta SMTP definida. Por eso puede resolver de forma precisa un falso positivo confirmado, pero también puede desactivar silenciosamente SPF, el análisis de malware, Zero-Day Protection o las comprobaciones DKIM.
⚠️ Una excepción solo se crea después de reproducir un falso positivo. Se omite únicamente la comprobación afectada y el alcance contiene la combinación fiable más pequeña de IP de origen, remitente y destinatario. All checks y los comodines amplios no son una solución rápida estándar.
Crear la excepción en siete pasos
- Registrar la hora de la prueba, la IP de origen SMTP, el remitente del sobre, el destinatario, el asunto, el Message-ID y el motivo exacto del rechazo.
- Comprobar si el problema se debe a DNS, enrutamiento, relay, TLS o a la propia política de correo en lugar de a una comprobación de seguridad.
- En Email > Policies and exceptions > Add an exception, seleccionar solo la comprobación afectada que se haya demostrado.
- Definir Sources or hosts, Sender addresses y Recipient addresses de la forma más restringida posible.
- Probar positivamente un mensaje equivalente y negativamente al menos dos variantes fuera del alcance.
- Confirmar en Mail logs y en los logs de MTA que solo se ha omitido la comprobación prevista y que las demás funciones de protección siguen actuando.
- Documentar el responsable, la justificación y la fecha de revisión; eliminar la excepción después de corregir la causa.
Qué omite realmente una excepción
SFOS agrupa las comprobaciones que se pueden omitir según su efecto. En Spam protection figuran RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF y BATV. Malware protection incluye Malware y Zero-day protection. En Other se encuentran Data protection, File protection, Encryption, Banner addition, DKIM signing y DKIM verification.
Esta selección no es una lista de comodidad. Una excepción para SPF, por ejemplo, mantiene el resto de la ruta antispam y antimalware. En cambio, una excepción para Malware o Zero-day protection elimina una comprobación de contenido central para todos los mensajes que coincidan con el alcance. Encryption, DKIM signing o DKIM verification también cambian la confidencialidad y la validación de integridad del flujo de correo saliente o entrante.
La ruta general de MTA se documenta en Configurar Mail Protection de Sophos Firewall en modo MTA. Para el proxy transparente, se aplica Configurar Mail Protection en modo heredado. En ninguno de los dos modos una excepción sustituye el enrutamiento, el relay, una regla de firewall o una política de análisis adecuada.
Comprender el alcance antes de guardar
Sources or hosts
SFOS acepta como origen direcciones IP, rangos IP, listas IP, redes o FQDN. Los FQDN con comodín no se admiten para las excepciones de hosts de correo. Por tanto, *.example.net no es un sustituto válido de la dirección de origen SMTP observada. Para localhost no se necesita una excepción, ya que SFOS no analiza los correos locales de forma predeterminada.
En servicios de correo en la nube o gateways distribuidos, una sola IP puede ser demasiado restrictiva, mientras que toda una red del proveedor puede resultar demasiado amplia. Se utiliza únicamente el objeto de origen publicado y realmente observado en el flujo de correo propio. Si el proveedor cambia sus redes, la excepción no se amplía ciegamente a Any, sino que se vuelve a contrastar con los logs y la información del fabricante.
Remitente y destinatario
En Sender addresses y Recipient addresses se admite una dirección individual como sender@example.net o un comodín de dominio como *@example.net. Un comodín de dominio abarca todos los remitentes o destinatarios de ese dominio y, por tanto, necesita un punto de anclaje más restrictivo, como una IP de origen confirmada y un destinatario piloto.
BATV tiene una regla especial poco habitual: para omitir la comprobación BATV de los correos de un remitente, su dirección debe introducirse tanto en Sender addresses como en Recipient addresses. Si falta uno de los dos campos, la excepción no está completa para ese caso BATV.
Crear una excepción restringida
El ejemplo trata un falso positivo SPF confirmado de un socio. 203.0.113.25 es una dirección de documentación y debe sustituirse por la IP pública de origen realmente observada en el log SMTP. partner.example y pilot@example.com también son valores de ejemplo.
- Abrir Email > Policies and exceptions > Add an exception.
- Introducir un nombre trazable como
FP-SPF-partner-example-review-2026-09-30. - Seleccionar únicamente SPF entre las comprobaciones que se omitirán.
- En Sources or hosts, introducir el host
203.0.113.25. - En Sender addresses, introducir
*@partner.exampley, en Recipient addresses, inicialmente solopilot@example.com. - Guardar la excepción y no ampliarla todavía a otros destinatarios.
El nombre incluye deliberadamente la causa y la fecha de revisión. Sin embargo, no sustituye la documentación del cambio o del ticket. El nombre no impone técnicamente una fecha de caducidad; el responsable debe realizar realmente la revisión.
Realizar pruebas positivas y negativas
Primero, el socio vuelve a enviar el mismo mensaje controlado al buzón piloto. Debe recorrer el flujo de correo previsto y dejar de fallar por el motivo SPF confirmado. Mail logs, smtpd_main.log y, para los rechazos, smtpd_reject.log se correlacionan mediante la marca de tiempo, el remitente, el destinatario y el Message-ID. Servicios y logs de Sophos Firewall explica la asignación de logs.
A continuación se realizan dos pruebas negativas. Un mensaje del mismo remitente desde otra IP de origen y otro mensaje desde la IP confirmada a un destinatario distinto no deben recibir la misma excepción. Además, un archivo de prueba inofensivo continúa sujeto a la ruta normal de Malware y File Protection. No se utiliza malware real.
Una entrega correcta por sí sola no demuestra el alcance. Lo decisivo es que el mensaje esperado se entregue, que las variantes fuera del alcance sigan analizándose normalmente y que no se omita involuntariamente una segunda comprobación de seguridad.
Reconocer excepciones arriesgadas
Un comodín de dominio amplio combinado con una red de origen grande puede eliminar la protección de una parte considerable del flujo de correo. En especial, las excepciones para Malware, Zero-Day Protection, Data protection y File protection necesitan una decisión de riesgo documentada y un alcance piloto muy reducido. Ante un error de análisis todavía desconocido, no se desactiva preventivamente todo el grupo.
Las opciones que parecen funcionales también son relevantes para la seguridad. Omitir Encryption puede enviar contenido confidencial sin protección. Sin DKIM signing falta la firma saliente prevista; sin DKIM verification no se evalúa una prueba de identidad entrante. Una excepción de Banner puede eliminar textos o etiquetas obligatorios. Estos cambios se coordinan con los responsables de correo y cumplimiento.
Acotar errores según el síntoma
El mensaje sigue siendo rechazado
Primero se evalúa la nueva entrada del log en lugar del mensaje de prueba anterior. La IP de origen real, el remitente del sobre, el destinatario y el Reason deben coincidir con el alcance y la comprobación seleccionada. Un FQDN con comodín en Sources or hosts no funciona. Si el mensaje se rechaza por RBL, IP reputation, RDNS/HELO u otra comprobación, una excepción exclusiva para SPF no resuelve ese motivo independiente.
La excepción coincide con demasiados mensajes
Las tres capas del alcance se comparan individualmente con el flujo de correo real. A menudo, *@domain sin una IP de origen restringida o con demasiados destinatarios es el factor amplio. La excepción no se corrige omitiendo más comprobaciones, sino reduciéndola a la combinación confirmada más pequeña y repitiendo las pruebas negativas.
El correo supera la comprobación, pero no se entrega
Una excepción controla comprobaciones de seguridad, no MX, la ruta interna, el relay, TLS o el servidor de correo de destino. Mail logs y el spool muestran si el mensaje falla después del análisis por DNS, enrutamiento, política o entrega. La excepción no se amplía si el error se produce después de la comprobación de seguridad.
La excepción BATV no se aplica
Comprobar si la misma dirección del remitente figura en Sender addresses y Recipient addresses. Después, volver a contrastar el Reason BATV concreto y los demás campos del alcance. Una segunda excepción más amplia no sustituye al campo BATV que falta.
Operación y reversión
Cada excepción tiene un responsable, un motivo de falso positivo demostrado y una fecha de revisión. Los cambios se contrastan con el audit trail; Rastrear cambios de configuración en Sophos Firewall describe la evidencia adecuada. El flujo de correo real sigue siendo visible por separado en Mail logs y en los archivos MTA.
Para la reversión, se elimina la excepción o se restaura el estado anterior documentado. Después se vuelven a probar la situación de error original y un mensaje de control permitido. Si la causa del fabricante o de DNS aún no se ha corregido, la reversión no debe provocar silenciosamente pérdidas de correo en producción; primero se planifica una ventana de mantenimiento o una corrección alternativa más restringida.
Lista de comprobación
- Existe un falso positivo reproducible y se conoce el Reason exacto.
- Se han documentado la IP de origen, el remitente del sobre, el destinatario y el Message-ID.
- Solo se omite la comprobación afectada.
- Sources or hosts, Sender y Recipient forman el alcance útil más pequeño.
- No se utilizan FQDN con comodín como excepciones de host.
- Una excepción BATV contiene la dirección del remitente en ambos campos de dirección.
- Las pruebas positivas y negativas confirman coincidencia y no coincidencia.
- Las demás comprobaciones de spam, malware, archivos, datos y DKIM permanecen activas.
- Se han documentado el responsable, la justificación, la fecha de revisión y la reversión.
FAQ
¿Una excepción de correo permite automáticamente el relay SMTP?
¿Se puede utilizar un FQDN con comodín en Sources or hosts?
*@example.net solo es posible en los campos de remitente y destinatario.