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. Se elige la condición fiable más restringida, porque host de origen, remitente y destinatario son alternativas, no una condición AND conjunta. All checks y los comodines amplios no son una solución rápida estándar.

Crear la excepción en siete pasos

1. 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.
2. 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.
3. En Email > Policies and exceptions > Add an exception, seleccionar solo la comprobación afectada que se haya demostrado.
4. Activar solo la condición adecuada más restringida en Sources or hosts, Sender addresses o Recipient addresses.
5. Probar positivamente un mensaje equivalente y negativamente al menos una variante fuera del alcance.
6. En Email > Mail logs, comparar resultado y Reason antes y después; probar por separado las demás protecciones con casos inofensivos.
7. 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.

Esta excepción pertenece al MTA mode. Una política SMTP route and scan reúne enrutamiento y acciones de spam, malware, archivos y datos. En legacy mode, SFOS actúa como proxy transparente y usa políticas separadas SMTP malware scan y SMTP spam scan; el objeto de excepción MTA no es el control adecuado. Véanse Configurar Mail Protection de Sophos Firewall en modo MTA y Configurar Mail Protection en modo heredado.

Encryption se refiere aquí al cifrado de correo de la política MTA, por ejemplo SPX Email Encryption, no al cifrado de transporte SMTP. Require TLS negotiation, validación de certificados y Skip TLS negotiation se configuran aparte en Email > General settings > SMTP TLS configuration. Por tanto, una excepción de correo no corrige errores de negociación TLS, enrutamiento, relay ni reglas de firewall.

Comprender la coincidencia antes de guardar

Los tres grupos no forman una condición AND. La API oficial de SFOS 22.0 los denomina ForTheseSourceHost, ORTheseSenderAddresses y ORTheseRecipientAddresses. Con varios grupos activos basta una coincidencia del host de origen o remitente o destinatario. IP, dominio del socio y buzón piloto crean tres vías de coincidencia, no una combinación más restringida.

Este objeto no ofrece un AND entre grupos; dos excepciones también ampliarían el alcance. Si hacen falta dos criterios simultáneos, se corrige la causa o se separa el flujo mediante una política o ruta de gateway adecuada.

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 un objeto de origen publicado y realmente observado en el flujo de correo propio. Si otros clientes comparten las IP del proveedor, incluso ese objeto puede ser demasiado amplio. No se exceptúa una comprobación de seguridad basándose únicamente en esa red.

Remitente y destinatario

En Sender addresses y Recipient addresses se admite una dirección como sender@example.net o un comodín como *@example.net. Un segundo grupo no es un anclaje más restrictivo porque se une con OR. Un remitente no es una prueba independiente de confianza al exceptuar SPF o DKIM; una excepción de destinatario se aplica a mensajes coincidentes de todos los remitentes.

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 desde el gateway dedicado de un socio. 203.0.113.25 es una dirección de documentación que se sustituye por la IP pública observada en Mail logs. Solo sirve si la IP pertenece exclusivamente al gateway fiable; en un relay cloud compartido el bypass sería demasiado amplio.

1. Abrir Email > Policies and exceptions > Add an exception.
2. Introducir un nombre trazable como FP-SPF-partner-example-review-2026-09-30.
3. Seleccionar únicamente SPF entre las comprobaciones que se omitirán.
4. En Sources or hosts, introducir el host 203.0.113.25.
5. Dejar Sender addresses y Recipient addresses desactivados o vacíos; añadirían coincidencias OR.
6. Guardar sin añadir más hosts ni comprobaciones.

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

El socio reenvía el mismo mensaje controlado, que ya no debe fallar por el Reason SPF confirmado. En Email > Mail logs se filtra por periodo, remitente, destinatario o asunto y por Result y Reason. SPF, RBL, Malware, Zero-day protection, DKIM verification y BATV tienen filtros Reason. Para profundizar se usan smtpd_main.log y, en rechazos, smtpd_reject.log; Servicios y logs de Sophos Firewall explica su función.

Después se realiza una prueba negativa por una ruta SMTP controlada no exceptuada. No debe omitir la comprobación documentada debido a esta excepción. Con una excepción solo por host, otros remitentes o destinatarios que usen esa IP no son pruebas negativas: coinciden con la misma rama OR. Un archivo inofensivo puede probar aparte Malware y File Protection; no se utiliza malware real.

Una entrega correcta no demuestra por sí sola el alcance. La documentación oficial de Mail logs describe Reasons y estado de entrega, pero no un campo “matched exception” ni una lista de comprobaciones omitidas. Se evalúan conjuntamente Reason antes/después, configuración y casos positivos y negativos separados. Una entrega correcta no se presenta como prueba de que se ejecutaron todas las demás protecciones.

Reconocer excepciones arriesgadas

Un solo comodín de dominio amplio o una red de origen grande puede eliminar la protección de una parte considerable del flujo de correo. Introducir ambos no reduce el alcance, sino que añade coincidencias OR. En especial, las excepciones para Malware, Zero-Day Protection, Data protection y File protection necesitan una decisión de riesgo documentada y un alcance muy reducido y fiable por sí mismo. 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

Los tres grupos se comparan por separado con el flujo real. Cada grupo OR activo amplía las coincidencias. Se reduce la excepción a un grupo fiable con el mínimo de valores y se repite la prueba negativa.

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 SMTP 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. Para un error TLS, comprobar el certificado, Require TLS negotiation y el otro extremo; Encryption en la excepción y un alcance mayor no lo resuelven.

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.

Antes del cambio se registran nombre, comprobaciones, valores de alcance y Reason anterior. Para conservar el estado se elimina solo la nueva excepción, sin tocar políticas ni otras excepciones. Después se prueban de nuevo el error original y un mensaje de control; si la causa no está corregida, primero se planifica una ventana o una corrección 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.
• Se prefiere un único grupo adecuado; los grupos adicionales amplían la coincidencia mediante OR.
• 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, junto con los Reasons anteriores y posteriores, confirman el efecto previsto.
• 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