Configurar y probar notificaciones por correo en Sophos Firewall

Para que las notificaciones por correo electrónico funcionen, Sophos Firewall necesita dos configuraciones separadas: en Administration > Notification settings se configura el transporte de correo. En System services > Notification list se determina qué eventos se notifican realmente por correo electrónico.

El resumen de cuarentena para usuarios también utiliza este transporte, pero su horario, enlace al portal y asignación de usuarios son ajustes independientes.

Los textos visibles de autenticación, SMTP, administración y SMS en Administration > Messages constituyen una tercera capa independiente. Configurar el aviso de inicio de sesión y los mensajes en Sophos Firewall explica su contenido y sus pruebas; cambiar un mensaje no configura ni el transporte SMTP ni la selección de eventos.

La vía rápida:

Configurar el servidor de correo, el puerto, la autenticación, el cifrado, el remitente y el destinatario en Administration > Notification settings.
Enviar un correo de prueba y confirmar su entrega en el buzón de destino o en el seguimiento del servidor de correo.
Activar el interruptor global Email notifications en System services > Notification list.
Seleccionar únicamente los eventos ante los que pueda reaccionar un destinatario responsable.
Además del correo de prueba, provocar de forma controlada un evento real seleccionado y comprobar su entrega.

Un correo de prueba correcto solo demuestra que la ruta SMTP funciona en principio. Todavía no demuestra que el interruptor global de correo y los eventos adecuados estén activados. A la inversa, una fila de evento seleccionada no envía ningún mensaje mientras el transporte de correo no funcione. Esta separación también explica por qué un servidor SMTP configurado por sí solo todavía no satisface operativamente el punto Notification Emails del Health Check de Sophos Firewall.

Cambiar la dirección del destinatario desde Device Console

Si WebAdmin no está disponible o hay que corregir la dirección del destinatario mediante un acceso controlado a la consola, se utiliza 2. System Configuration > 3. Set Email ID for system notification. Esta opción solo cambia la dirección de correo del administrador para las alertas del sistema. No configura el servidor, el remitente, la autenticación y TLS ni el interruptor global y los eventos de la Notification list.

Primero se documenta la dirección anterior. Después se confirma el cambio con y, se introduce la nueva dirección y se comprueba que la dirección mostrada por SFOS no contiene errores. Enter vuelve al menú. A continuación, un correo de prueba y un evento real controlado deben llegar al nuevo destinatario; la confirmación de la consola por sí sola no demuestra la entrega.

Preparar el envío de correo

Antes de configurar, hay que aclarar con el administrador de correo responsable el servidor, el puerto y el método de autenticación. Si se utiliza un FQDN como smtp.example.net, el firewall debe poder resolverlo y alcanzar el servidor por la ruta prevista. Solo se necesita una conexión general a Internet si el servidor de correo o el proveedor OAuth elegido se encuentra en Internet. Un relay SMTP interno también puede funcionar sin que el firewall tenga acceso directo a Internet.

Antes de realizar cambios, anote la opción de servidor de correo seleccionada, el servidor, el puerto, Authentication, Connection security, el remitente, el destinatario, la interfaz de administración y los eventos seleccionados. Si el cambio afecta a los certificados, anote también la selección actual en Administration > Notification settings o Email > General settings, según corresponda. Compruebe que las credenciales y los tokens OAuth necesarios estén disponibles en un gestor seguro de contraseñas o secretos; no los incluya en capturas de pantalla sin proteger. Esta información permite restaurar la configuración anterior si la nueva ruta de correo no supera la prueba de entrega.

Un ejemplo realista:

Mailserver: smtp.example.net
Port: 587
Authentication: Basic
Connection security: STARTTLS
Sender: fw-zrh-01@example.net
Recipient: firewall-alerts@example.net
Management interface IP address: interfaz de gestión interna del firewall

Todos los valores con example.net se sustituyen por el dominio propio y las direcciones autorizadas por el administrador de correo. Una dirección de distribución suele ser mejor que un buzón personal: las responsabilidades pueden cambiar sin tener que reconfigurar cada firewall.

La opción Management interface IP address no controla por qué interfaz sale del firewall la conexión SMTP. La dirección IP seleccionada se incluye en la notificación y ayuda a identificar el firewall remitente. Por eso, cuando hay varias sedes conviene elegir una IP de gestión que sea comprensible de forma duradera; con un solo firewall también puede bastar None.

Las interfaces físicas, bridge y LAG solo aparecen en el desplegable si tienen una dirección IP asignada. Si falta una interfaz, este requisito explica su ausencia; no se deben asignar direcciones IP ni modificar interfaces o rutas únicamente para añadir identificación a un mensaje.

Configurar el servidor de correo

Elegir Built-in o External email server

Sophos Firewall puede utilizar el Built-in email server o un External email server. El envío integrado resulta práctico para empezar de forma sencilla. En entornos productivos, un relay o servidor de correo cloud propio suele ser más fácil de controlar, porque la autenticación, el seguimiento del correo, las autorizaciones de remitente y los errores de entrega quedan visibles en un punto central.

Por eso recomendamos el External email server cuando ya existe un servicio SMTP operado de forma fiable.

Para el envío integrado basta esta breve rama:

Activar el Built-in email server en Administration > Notification settings.
Introducir el remitente, el destinatario y, opcionalmente, Management interface IP address.
Guardar y enviar el correo de prueba.

Con el Built-in email server no existe un seguimiento propio del relay en el que el administrador pueda comprobar la aceptación y el reenvío. Por eso hay que verificar la entrega real con especial cuidado. Si falla repetidamente o el dominio destinatario y los requisitos de seguridad exigen una ruta SMTP controlada, un External email server es la variante más manejable.

Configurar External email server

Abrir Administration > Notification settings.
Seleccionar External email server.
Introducir la dirección IPv4 o el FQDN del servidor de correo y el puerto indicado.
En Authentication, seleccionar None, Basic u OAuth 2.0 según el servidor.
En Connection security, configurar el cifrado de transporte exigido por el servidor de correo.
Introducir el remitente, el destinatario y, opcionalmente, Management interface IP address.
Guardar y ejecutar la función de correo de prueba.

El puerto predeterminado de SFOS es 25, pero no constituye una recomendación para todos los entornos. Lo decisivo es el listener del relay propio. Son habituales el 25 para un relay interno autorizado por la IP de origen, el 587 para entrega autenticada con STARTTLS o el 465 para SSL/TLS directo. El puerto, la autenticación y el modo de cifrado deben coincidir como conjunto con el servidor de correo.

None no significa lo mismo en los dos campos de selección: en Authentication desactiva el inicio de sesión en el servidor de correo. Esto puede ser correcto para un relay interno que autoriza exclusivamente la IP de origen del firewall. En Connection security, en cambio, None significa transmisión SMTP sin cifrar. Esta opción no es adecuada para rutas por Internet y solo debería utilizarse internamente si el modelo de seguridad lo permite expresamente.

Con Basic, el firewall utiliza nombre de usuario y contraseña. Según Sophos, el nombre de usuario distingue entre mayúsculas y minúsculas. El relay debe admitir el método de inicio de sesión utilizado; un mensaje de error sobre Authentication method indica en particular una diferencia respecto a LOGIN o PLAIN.

STARTTLS se malinterpreta con facilidad: el firewall sigue la capacidad del servidor de correo. Si el servidor ofrece STARTTLS, la conexión se cifra; si no lo ofrece, el mensaje puede transmitirse sin cifrar. Quien necesite imponer el cifrado debe utilizar SSL/TLS con el puerto y el listener del servidor correspondientes.

⚠️ Allow invalid certificate en Email > General settings no debería activarse como solución rápida. Es preferible corregir en el servidor de correo o en la cadena de confianza un certificado caducado, no fiable o que no coincide con el nombre del servidor.

El certificado que utiliza SFOS también depende del modo de correo. Con STARTTLS en MTA Mode, el firewall utiliza el certificado definido en Email > General settings. En Legacy Mode, se puede seleccionar un certificado para STARTTLS directamente en Administration > Notification settings; si no se selecciona ninguno, SFOS también utiliza el certificado de Email > General settings. Con SSL/TLS utiliza el certificado de Email > General settings. Por tanto, no cambie un certificado de forma aislada sin tener en cuenta el flujo de correo de producción.

Gmail y Microsoft 365 con OAuth 2.0

Para Gmail y Microsoft 365, la ayuda actual de SFOS 22 exige OAuth 2.0. Para ello, en Notification settings se introducen Provider, Client ID, Client secret y Refresh token. Aunque la ayuda general de Sophos indica que el Client secret es opcional para Microsoft 365, el procedimiento para Microsoft 365 documentado por Sophos crea y utiliza uno expresamente. Por eso también se configura para este procedimiento.

En Gmail hay que configurar un proyecto y la Gmail API en Google Cloud, así como generar un cliente OAuth y un Refresh Token. El procedimiento siguiente describe la configuración completa.

Configurar Gmail OAuth 2.0 paso a paso

Iniciar sesión en Google Cloud Console con la cuenta de Google prevista, crear un proyecto nuevo y seleccionarlo.
Abrir APIs & Services > Library, buscar Gmail API y activar la API.
En APIs & Services > Credentials, hacer clic en Create credentials > OAuth client ID.
Si antes se solicita la pantalla de consentimiento, abrir Configure the OAuth consent screen > Get started. Introducir el nombre de la aplicación y la dirección de correo, seleccionar User type: External, añadir la dirección de contacto del desarrollador y crear la configuración.
Seleccionar Create OAuth client, establecer Application type: Web application y asignar un nombre inequívoco.
En Authorized redirect URIs, añadir exactamente https://developers.google.com/oauthplayground.
Crear el cliente OAuth y guardar inmediatamente de forma segura el Client ID y el Client secret.
En Audience > Add users, añadir la cuenta de Google que enviará posteriormente las notificaciones.
Abrir Google OAuth 2.0 Playground. Activar Use your own OAuth credentials mediante el icono de engranaje e introducir el Client ID y el Client secret.
En Step 1 Select & authorize APIs, desplegar Gmail API v1, seleccionar el scope https://mail.google.com e iniciar Authorize APIs. Utilizar la cuenta remitente prevista.
En Step 2 Exchange authorization code for tokens, intercambiar el código por tokens y copiar de forma segura el Refresh token.
En el firewall, configurar el External email server en Administration > Notification settings con Authentication: OAuth 2.0 y Provider: Gmail. Introducir el Client ID, el Client secret y el Refresh token, guardar y enviar un correo de prueba.

Google no considera que un proyecto OAuth con User type External y Publishing status Testing sea una configuración productiva permanente: al utilizar el scope de Gmail, el Refresh Token caduca al cabo de siete días según Google OAuth 2.0. El scope de Gmail https://mail.google.com utilizado por Sophos permite, además de enviar, leer, crear y eliminar permanentemente correos electrónicos. Por eso la aplicación OAuth, las credenciales y una cuenta de envío preferiblemente dedicada deben protegerse y administrarse igual que una contraseña de servidor de correo.

En Microsoft 365, la aplicación necesita los permisos delegados SMTP.Send y offline_access; Authenticated SMTP debe estar activado para la cuenta remitente. La vía estándar documentada utiliza smtp.office365.com, el puerto 587 y STARTTLS. Si la dirección del remitente difiere del buzón autenticado, la cuenta necesita además Send As. El procedimiento completo de Entra aparece justo a continuación.

Configurar Microsoft 365 OAuth 2.0 paso a paso

En Microsoft Entra admin center, crear una New registration en Identity > Applications > App registrations.
Asignar un nombre inequívoco. Para el procedimiento documentado por Sophos, seleccionar Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) e introducir https://outlook.office365.com/ como plataforma Web en Redirect URI. La misma URI debe reutilizarse exactamente más adelante.
Registrar la aplicación y guardar de forma segura el Application (client) ID.
En API permissions > Add a permission > Microsoft Graph > Delegated permissions, añadir SMTP.Send y offline_access. A continuación, ejecutar Grant admin consent.
Para la cuenta remitente, activar Authenticated SMTP en Users > Active users > Mail > Email apps > Manage email apps.
En Certificates & secrets > Client secrets > New client secret, crear un secreto con una fecha de caducidad supervisada. Copiar inmediatamente de forma segura el Value mostrado; Entra deja de mostrarlo después de recargar la página.
Abrir la siguiente URL en un navegador. Sustituir YOUR_CLIENT_ID por el Application ID; la redirect_uri debe coincidir con el registro de la aplicación.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=https://outlook.office365.com/&response_mode=query&scope=https://outlook.office365.com/.default+offline_access&state=12345

Iniciar sesión con la cuenta remitente prevista y copiar el código de autorización de corta duración de la URL de redirección.
Enviar el código con un cliente API como application/x-www-form-urlencoded al endpoint de token. Sustituir todos los marcadores por los valores de esta aplicación.

POST https://login.microsoftonline.com/common/oauth2/v2.0/token

client_id=YOUR_CLIENT_ID
&scope=https://outlook.office365.com/.default offline_access
&code=YOUR_AUTHORIZATION_CODE
&redirect_uri=https://outlook.office365.com/
&grant_type=authorization_code
&client_secret=YOUR_CLIENT_SECRET

Guardar inmediatamente de forma segura el Refresh token devuelto. El código de autorización, el Client secret, el Access token y el Refresh token no deben incluirse en tickets, capturas sin protección ni logs.
En el firewall, configurar el External email server en Administration > Notification settings con Authentication: OAuth 2.0 y Provider: Microsoft 365. Introducir smtp.office365.com, el puerto 587, STARTTLS, Client ID, Client secret y Refresh token, guardar y enviar un correo de prueba.

Sophos exige que el sistema que ejecuta el cliente API y el firewall utilicen la misma zona horaria al generar el token. Comprobar antes la hora del sistema y la zona horaria. La zona horaria del firewall no debe cambiarse de forma improvisada en producción; Sophos exige después un reinicio, que debe realizarse en una ventana de mantenimiento.

Microsoft Security Defaults desactiva SMTP AUTH. Esta medida de protección no debería desactivarse de forma general para todo el tenant solo para que un firewall pueda enviar mensajes. Si la autorización específica para la cuenta remitente no encaja con el modelo de seguridad, la vía más limpia es un relay interno o externo previsto para este fin.

⚠️ Para NC-166854, OAuth de Microsoft 365 para Notifications no funciona en los builds de SFOS 22.0.0.274, 22.0.0.323, 21.0.2.349 y 21.5.1.261; no se especifica una versión corregida. Antes de poner en servicio esta ruta de correo, hay que documentar el build exacto de SFOS y exigir que el correo de prueba se entregue correctamente. Que los campos Client ID, Secret y Token se hayan guardado todavía no demuestra que funcione.

Si un build indicado está afectado, se utiliza un relay SMTP compatible u otra ruta de correo verificada hasta que exista una confirmación fiable de un firmware corregido. Las excepciones TLS inseguras o una Basic Authentication no verificada no son un buen sustituto de una ruta de alertas funcional.

Seleccionar eventos en Notification list

Después de una prueba de correo correcta, se abre System services > Notification list. Allí se activa primero Email notifications, después se marcan las casillas de la columna Email para los eventos necesarios y se guarda con Save.

No todos los firewalls necesitan la misma selección. Una base razonable se orienta a los riesgos y a las funciones realmente utilizadas:

Admin: inicios de sesión fallidos y demasiados intentos de inicio de sesión fallidos.
HA: puertos o interfaces supervisados desconectados cuando se utiliza un clúster HA.
Disk/Memory: advertencias de almacenamiento para que un área de informes o del sistema llena no se descubra por primera vez durante la ventana de mantenimiento. Comprobar el almacenamiento y los informes en Sophos Firewall explica los umbrales y las consecuencias.
Firmware: firmware nuevo y, sobre todo, instalaciones fallidas de acuerdo con el proceso de actualización propio.
Solo SFOS 23 – Firmware > Security updates: En System services > Notification list, activar la columna Email para Security updates. Siguen siendo necesarios el interruptor global Email notifications y una ruta SMTP funcional. Las actualizaciones de seguridad mediante hotfix no disponen de notificaciones SNMP; esta limitación no se aplica de forma general a todos los hotfixes ni a todos los eventos de firmware. No se garantiza la entrega inmediata, y la ausencia de correo no demuestra ni éxito ni fallo. Comprobar las actualizaciones aplicadas mediante el procedimiento de verificación de hotfixes de SFOS 23.
System: actualizaciones fallidas de firmas o bases de datos, inicio del sistema, uso elevado de CPU y Gateway status.
IPS y Active threat response: empezar por eventos críticos o de bloqueo cuando exista un proceso de triaje.
RED, AP y VPN: solo para dispositivos realmente utilizados y conexiones importantes.
Web - Instant alerts: categorías web seleccionadas de forma consciente. Estos mensajes se envían en lotes de cinco minutos y necesitan una activación separada de la categoría, tal como se describe en Web Categories e Instant Alerts.

Activar todos los eventos de forma indiscriminada genera rápidamente fatiga de alertas. En particular, las notificaciones VPN pueden repetirse aproximadamente cada 60 segundos hasta que se resuelva la causa; si existen varias redes locales y remotas, también puede generarse un mensaje por cada par de subredes. Es mejor una selección pequeña con una reacción clara: quién recibe la alerta, qué urgencia tiene y cuál es el primer paso de comprobación.

El firewall envía automáticamente algunas Default Notifications y no permite desmarcarlas. Entre ellas se encuentran determinados cambios de rol y estado de HA, el estado de hosts virtuales y los reinicios o apagados mediante WebAdmin. También para estos mensajes debe estar disponible la ruta de correo configurada.

Interpretar las condiciones de activación y las repeticiones

Una casilla activada no significa que cada cambio breve de estado genere un correo. En SFOS 22.0 y 23.0, los siguientes eventos tienen estas condiciones:

Admin: Sign-in failed incluye credenciales incorrectas o una OTP (contraseña de un solo uso) incorrecta. Too many failed sign-in attempts se activa al alcanzar el número de intentos fallidos configurado en Administration > Admin and user settings > Login security. Este umbral explica la alerta; no es una instrucción para provocar el bloqueo de una cuenta.
High CPU usage: El primer registro de notificación solo se genera cuando el uso de CPU alcanza el 95 % y se mantiene de forma continua en el 95 % o por encima durante al menos 25 minutos. Se generan más registros cada 25 minutos hasta que el uso baja del 95 %. Por tanto, un pico breve sin correo de evento no demuestra un fallo de SMTP.
Gateway status: La selección del evento está activada de forma predeterminada. Para enviar mensajes también debe estar activado el interruptor global independiente Email notifications.

Para los eventos de disco, el uso debe mantenerse de forma continua en el umbral correspondiente o por encima durante al menos 50 segundos. Después, los registros y las notificaciones se repiten con la siguiente frecuencia predeterminada hasta que el uso baja del umbral:

Área	Umbral de notificación	Repetición
Almacenamiento de configuración	≥80 %	cada 50 segundos
Almacenamiento de firmas	≥90 %	cada 50 segundos
`/var`	≥80 %	cada 12 horas

En /var, el umbral inferior ya genera registros; las notificaciones solo empiezan en el umbral superior del 80 %. Si el uso supera el umbral superior y después baja del inferior, se registra la recuperación, pero no se envía ninguna notificación de recuperación. Esto es distinto del comportamiento de advertencia y detención de los informes explicado en el artículo de almacenamiento enlazado arriba; aquí, la ausencia de un correo de recuperación no es un fallo de entrega.

Para IPsec, el alcance documentado es más limitado que cualquier cambio Up/Down de VPN: las notificaciones solo se aplican a túneles host-to-host y site-to-site con las condiciones de desconexión descritas:

Dead peer detection (DPD).
Fallo al restablecer la conexión después de DPD.
La IPsec Security Association (SA) ha caducado y debe restablecerse.
Esta lista también incluye que el túnel vuelva a levantarse tras perder conectividad sin intervención del administrador.

Si se configura una descripción en los ajustes de la conexión IPsec, la notificación la incluye. Esto no garantiza notificaciones para cada desconexión manual ni para túneles de acceso remoto o SSL VPN.

Los tiempos de CPU describen la generación de registros de notificación y los intervalos de disco la repetición documentada, no una hora garantizada de llegada al buzón. Si falta un correo, primero se comparan la condición del evento, la marca de tiempo del registro y el seguimiento del servidor de correo. No se deben provocar saturaciones de CPU o disco, bloqueos de inicio de sesión, interrupciones de HA ni fallos de VPN en producción solo para probar una alerta.

Comprobar el correo de prueba y un evento real

La comprobación consta de dos etapas.

1. Confirmar la entrega SMTP con un correo de prueba

Enviar el correo de prueba en Administration > Notification settings. El mensaje de éxito del firewall todavía no basta: el buzón de destino, el filtro de spam o el seguimiento del servidor de correo debe mostrar que el mensaje se ha aceptado y entregado realmente.

Se comprueba lo siguiente:

El remitente y el destinatario son correctos.
El firewall esperado puede identificarse mediante el asunto, el contenido o la IP de gestión.
El mensaje no permanece en spam o cuarentena.
La lista de distribución acepta los mensajes del remitente configurado.

2. Probar toda la cadena de eventos

Después se provoca de forma controlada un evento seleccionado. Algunos ejemplos adecuados son:

un único inicio de sesión fallido con una cuenta de prueba, después de comprobar los bloqueos y umbrales de inicio de sesión;
el estado Up/Down de un túnel VPN de prueba destinado expresamente a ello;
Gateway status durante una prueba de failover WAN planificada.

Reiniciar o desconectar un gateway productivo, un puerto HA o el propio firewall solo para comprobar un correo electrónico sería desproporcionado. Una situación de mantenimiento o failover ya planificada es una prueba mejor.

La cadena completa solo queda confirmada cuando el evento llega al destinatario correcto en el tiempo esperado: detección del evento, selección del evento, interruptor global de correo, transporte SMTP y entrega.

Delimitar errores de forma sistemática

El correo de prueba ya falla

La API de SFOS 22 distingue varias clases de error:

Failed to connect o SMTP server failed to respond: comprobar la resolución FQDN, la ruta, el puerto, el firewall precedente y el listener del servidor de correo.
Password mismatch: comprobar el nombre de usuario, las mayúsculas y minúsculas, la contraseña y, si procede, si la cuenta está bloqueada.
Authentication method mismatch: comprobar si el relay y SFOS admiten conjuntamente LOGIN o PLAIN con Basic Authentication.
STARTTLS not supported: el puerto y Connection security no coinciden con el listener del servidor.
Mail server refused to communicate: comprobar la autorización del relay, la dirección del remitente, la IP de origen permitida y los logs del servidor de correo.
Couldn’t generate the OAuth 2.0 access token: comprobar Provider, Client ID, Secret, Refresh Token, permisos y hora del sistema.

Desde un sistema de administración con una ruta de red comparable se pueden comprobar previamente DNS y STARTTLS sin modificar el servidor de correo:

nslookup smtp.example.net
openssl s_client -starttls smtp -connect smtp.example.net:587 -servername smtp.example.net

Se sustituyen smtp.example.net y 587 por el servidor y el puerto propios. nslookup solo confirma la resolución de nombres del sistema de administración. openssl s_client muestra la disponibilidad SMTP, el handshake TLS y la cadena de certificados, pero no comprueba la ruta desde la perspectiva del firewall, su inicio de sesión ni la entrega posterior.

En Log Viewer y, para un análisis más profundo, en cschelper.log, el momento de la prueba puede correlacionarse con el correo generado por el sistema. El acceso a los logs de servicios y la delimitación respecto a Advanced Shell se describen en Servicios y logs de Sophos Firewall. Los logs MTA como smtpd_main.log pertenecen principalmente a Mail Protection y no son de forma general el log de Notifications.

El correo de prueba llega, pero faltan correos de eventos

En ese caso el transporte funciona y la búsqueda comienza en System services > Notification list:

¿Está activado globalmente Email notifications?
¿Está seleccionado el evento concreto en la columna Email?
¿Ha ocurrido realmente el evento esperado y corresponde a la categoría correcta?
¿Existe un retraso o agrupación conocidos, por ejemplo con Web Instant Alerts?
¿Muestran el filtro de spam, la cuarentena o el seguimiento del servidor de correo una aceptación o un rechazo?

Para un evento especializado concreto también debe comprobarse su condición funcional. Por ejemplo, una alerta IPS no se produce únicamente por una casilla activada, sino cuando una regla IPS adecuada registra y descarta el evento. Una notificación VPN depende del tipo de túnel y del estado Up/Down real.

Microsoft 365 OAuth guarda, pero no envía

Primero se compara la versión y el build de SFOS con NC-166854. Después se comprueban Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP para la cuenta remitente y la hora correcta del sistema.

Si el correo de prueba sigue fallando en un build que no figura como afectado, no se trata automáticamente del mismo error. El mensaje exacto, el build de SFOS y los logs de inicio de sesión del proveedor deben incluirse en el análisis posterior o en un ticket de soporte.

Operar las notificaciones

Si la entrega falla después de un cambio, restaure primero la configuración de correo anotada: opción de servidor, servidor, puerto, Authentication, Connection security, remitente, destinatario e interfaz de administración, además de la selección de certificado anterior si se modificó. Mantenga la selección de eventos si no formaba parte del cambio. Después de guardar, confirme de nuevo la ruta de alerta anterior mediante un correo de prueba y un evento seleccionado activado de forma controlada. La restauración solo termina cuando ambos mensajes han llegado realmente.

Mantener el destinatario como lista de distribución funcional con un responsable definido.
Volver a comprobar el correo de prueba y un evento real después de modificar el servidor de correo, DNS, routing, el certificado, las credenciales, la aplicación OAuth o el firmware.
Probar la ruta completa de alertas al menos trimestralmente si ningún sistema de monitorización central la supervisa continuamente.
Documentar la caducidad y la rotación de contraseñas, Client Secrets y Tokens.
Adaptar periódicamente la selección de eventos a funciones nuevas y servicios desactivados.
Definir para cada alerta importante un primer paso de comprobación y una vía de escalado.

La lista diaria de administración de Sophos Firewall resume qué señales de estado, seguridad y administración deben revisarse también de forma activa durante el funcionamiento.

El correo electrónico es un buen canal de alerta directo, pero no sustituye el almacenamiento central de logs ni su correlación. Para disponer de un historial más largo y realizar evaluaciones de seguridad, puede utilizarse Enviar Syslog de Sophos Firewall a un SIEM. Para la monitorización clásica del estado y los traps, Monitorización de hardware mediante SNMP es el complemento adecuado.

Para enviar análisis PDF a diario o semanalmente no se utiliza Notification list, sino una programación de informes independiente. Programar informes de Sophos Firewall y enviarlos por correo explica la selección, los bookmarks, la prueba de transporte y el control del contenido.