Configurar Mail Protection de Sophos Firewall en el modo heredado

En el Legacy mode, Sophos Firewall funciona como proxy de correo transparente. El servidor de correo interno sigue siendo el endpoint SMTP real; el firewall reenvía el tráfico mediante las reglas de firewall y NAT existentes y, al mismo tiempo, lo analiza en busca de spam, malware, tipos de archivo o coincidencias de Data Control.

Esto es fundamentalmente distinto del MTA mode. El firewall no se convierte en un Mail Transfer Agent, no asume la entrega de correo mediante dominios protegidos ni ofrece un MTA mail spool para esta ruta. Por tanto, una prueba correcta del puerto SMTP no demuestra ni el análisis del proxy ni que se aplique la política correcta.

⚠️ Cambiar el SMTP Deployment Mode es una modificación global de la ruta de protección del correo. Antes del cambio deben estar documentados el backup, las políticas existentes, las reglas de firewall y NAT y una vía de recuperación probada. Un problema del MTA no justifica pasar al Legacy mode sin planificación.

Legacy mode en nueve pasos

1. Documentar la ruta SMTP entrante y saliente existente con direcciones IP, puertos, NAT y Firewall Rule IDs.
2. Comprobar si el proxy transparente encaja realmente mejor que el MTA mode.
3. Asegurar un backup de la configuración y un acceso de administración independiente.
4. En Email > General settings, seleccionar Switch to legacy mode.
5. Definir el SMTP hostname, los límites de tamaño, la acción para mensajes demasiado grandes, IP Reputation, los límites DoS, los puertos y el comportamiento TLS.
6. Crear solo las políticas SMTP malware y SMTP spam necesarias, o comprobar su orden.
7. Limitar las rutas DNAT entrantes y SNAT salientes al servidor de correo real.
8. Activar Scan SMTP o Scan SMTPS en las reglas de firewall que realmente coincidan.
9. Validar los mensajes de prueba entrantes y salientes con Rule ID, resultado de la política, certificado y logs del proxy heredado.

Elegir entre Legacy mode y MTA mode

Legacy mode encaja sobre todo en entornos existentes donde el servidor de correo interno ya está publicado directamente mediante NAT y se desea conservar esta ruta. SFOS se sitúa de forma transparente entre el peer remoto y el servidor. El destino MX, la aceptación SMTP y la lógica de entrega siguen perteneciendo al diseño del servidor de correo existente.

MTA mode es la opción más adecuada cuando el firewall debe aceptar los mensajes, enrutarlos por dominio protegido, retransmitirlos y mantenerlos en un spool durante errores temporales de entrega. Mail logs y mail spool pertenecen expresamente a este modelo operativo. La configuración completa se explica en Configurar Mail Protection en MTA mode.

Según la ayuda de SFOS 22, MTA mode no está disponible en XGS 87/87w ni XGS 88/88w. Sin embargo, esto no convierte automáticamente Legacy mode en una buena arquitectura de correo en la nube. Microsoft 365, Google Workspace y los servicios alojados modernos aplican sus propios requisitos de TLS, autenticación y protección contra abusos. Antes de usar un proxy transparente hay que confirmar su compatibilidad.

En resumen: MTA mode posee un flujo de correo propio. Legacy mode protege una ruta SMTP que ya funciona. Mezclar ambos modelos lleva a buscar en el log equivocado, en un destino NAT incorrecto o en un spool que no existe.

Topología de ejemplo y vía de recuperación

El ejemplo siguiente usa valores de documentación y debe adaptarse al entorno real antes de implementarlo:

• servidor de correo interno 10.20.30.25 en la zona DMZ
• dirección SMTP pública 192.0.2.25 en la ruta WAN
• servicio SMTP entrante TCP 25
• SMTPS opcional en TCP 465, solo si los peers y el servidor usan realmente esta variante
• reglas de firewall SMTP_In_Legacy y SMTP_Out_Legacy

192.0.2.25 pertenece al rango TEST-NET y no es un valor de producción. Antes del cambio se ejecutan una prueba externa de entrada y una prueba de salida con marca de tiempo. Se guardan las Rule IDs que coinciden actualmente, la dirección de origen pública usada por el servidor para la salida y la cadena de certificados.

La vía de recuperación no consiste únicamente en volver a cambiar el modo. También debe ser posible restaurar al estado anterior documentado las nuevas opciones de análisis, el orden de las políticas, DNAT, las reglas SNAT reflexivas o manuales y las pruebas temporales.

Definir la configuración global del correo

Donde MTA mode está disponible, la ayuda lo identifica como modo predeterminado. En Email > General settings, seleccionar deliberadamente Switch to legacy mode después de asegurar la vía de recuperación documentada. Cambiar de modo por sí solo no crea una ruta de correo Legacy validada.

En Email > General settings, SMTP hostname solo se aplica a las notificaciones generadas por el sistema en las cadenas HELO y del banner SMTP; el valor predeterminado es SMTP. No sustituye el FQDN del servidor de correo productivo ni su DNS público. Si se modifica, hay que validar una notificación de SFOS y no solo un mensaje normal generado por el servidor.

Comprobación de la API XML: La documentación de SFOS 23 incluye el estado de operación 506 para Email Configuration, asociado a Message.AVGeneralConfInvalidSmtpNtfyHostname. Se trata de una clave de mensaje sin resolver, no de un mensaje de error en inglés ni de un código de estado HTTP. Si este estado aparece en la respuesta real de la API XML, comprobar el nombre de host enviado para las notificaciones, la respuesta de la operación y la configuración guardada antes de considerar que el cambio se ha realizado correctamente. La clave no permite deducir reglas de validación concretas. La entrada adicional en la documentación no demuestra que el comportamiento se introdujera en SFOS 23 ni que se aplique a REST.

Límite de tamaño, acción para mensajes grandes y protección DoS

En Email > General settings > SMTP settings, Don’t scan emails greater than define el tamaño máximo de los mensajes que se analizan. En la ruta SMTP, el valor 0 significa 51,200 KB según la ayuda de SFOS 22, no ilimitado. Para mensajes más grandes están disponibles Accept, Reject y Drop.

Accept entrega un mensaje demasiado grande sin analizarlo. Reject lo rechaza e informa al remitente, mientras que Drop lo descarta sin notificación. Esta elección es una decisión operativa y de riesgo consciente. Un Drop no probado dificulta el diagnóstico; un Accept no evaluado crea una brecha de análisis que debe documentarse.

Verify sender’s IP reputation comprueba la IP del remitente antes de los criterios de spam de la política SMTP y rechaza los mensajes procedentes de direcciones IP con mala reputación. Los seis campos SMTP DoS admiten estos rangos en SFOS 22:

• Maximum connections: de 1 a 20000 conexiones con el servidor de correo
• Maximum connections/host: de 1 a 10000 conexiones de un host
• Maximum emails/connection: de 1 a 1000 mensajes por conexión
• Maximum recipients/email: de 1 a 256 destinatarios por mensaje
• Emails rate: de 1 a 20000 mensajes de un host por minuto
• Connections rate: de 1 a 20000 conexiones de un host por segundo

Que un valor sea admisible no significa que sea adecuado. Los límites de producción se derivan del volumen real y de una línea base para no tratar los picos legítimos de envío como un DoS.

Bypass spam check for SMTP/S authenticated connections omite globalmente el control de spam para las conexiones que el servidor de correo identifica como autenticadas. Solo es aceptable después de comprobar la autenticación, los orígenes permitidos y la protección contra abusos de esta ruta. Un inicio de sesión correcto no sustituye el análisis de malware ni una prueba negativa con una conexión no autenticada. Los dominios de Spam check exceptions también constituyen un bypass global y no se utilizan como sustituto rápido de una excepción de alcance restringido.

El banner global ofrece Inline, no conversion, MIME part y Off. Inline, no conversion añade el texto directamente a los mensajes salientes; MIME part lo incorpora como parte MIME independiente. Off no añade ningún banner. En Email banner solo se introduce texto, por ejemplo, un breve aviso de confidencialidad. El banner requiere análisis SMTP o SMTPS en la regla de firewall coincidente. Comprobar en el destinatario un mensaje de texto plano y otro HTML para verificar que se mantienen el contenido, la estructura MIME y la presentación previstos. Como modificar el cuerpo puede invalidar una firma DKIM existente, validar también los encabezados de la ruta saliente real.

Planificar POP/IMAP y los puertos por separado

POP/IMAP tiene su propia selección TLS certificate para la CA en POP and IMAP TLS configuration. Mantener Allow invalid certificate desactivado para rechazar certificados de servidor no válidos; aquí Disable legacy TLS protocols también bloquea solo protocolos anteriores a TLS 1.1. La configuración SMTP no sustituye estos ajustes. La ruta completa de acceso al correo se explica en Análisis de correo POP/IMAP; la administración de CA y certificados en Gestión de certificados.

Legacy mode también incluye el análisis transparente de POP3/S e IMAP/S. En POP/S and IMAP/S settings, 0 en Don’t scan emails greater than significa 10,240 KB. Recipient headers determina en qué headers busca SFOS los destinatarios usados por las políticas POP/IMAP; los valores predeterminados son Delivered-To, Received y X-RCPT-TO. Solo deben cambiarse si lo justifica un header capturado del servidor utilizado.

Los puertos estándar documentados son SMTP 25, SMTPS 465, POP3 con STARTTLS 110, POP3S 995, IMAP con STARTTLS 143 e IMAPS 993. SFOS también puede analizar correo en otros puertos; la ayuda menciona expresamente el 587. Un puerto alternativo debe figurar como servicio en la regla de firewall correspondiente y estar asociado al protocolo de análisis activado. Cambiar solo el puerto no convierte TLS implícito en STARTTLS ni a la inversa.

Una política POP-IMAP scan puede combinar grupos de remitentes y destinatarios con criterios como la clasificación de entrada, la dirección IP de origen, el tamaño del mensaje o un encabezado. Las únicas acciones disponibles son Accept y Prefix subject. La política no activa el proxy por sí sola: en Scan email content de la regla de firewall correspondiente también debe seleccionarse el protocolo POP3, POP3S, IMAP o IMAPS que se utilice realmente.

No sobrevalorar TLS por una casilla

En SMTP TLS configuration se selecciona el certificado CA o de servidor previsto para el análisis. Allow invalid certificate permanece desactivado. Según la ayuda, Disable legacy TLS protocols solo desactiva protocolos anteriores a TLS 1.1 y no demuestra una sesión TLS 1.2 o TLS 1.3 concreta.

Sophos también señala una limitación importante del modo heredado: el firewall establece la conexión TLS mediante la dirección IP del dominio en lugar del nombre de dominio. Si varios dominios comparten una dirección IP, la validación del certificado puede fallar. En este caso, Sophos recomienda otra ruta de protección, como Sophos Email Security. La comprobación no se elude con Allow invalid certificate.

Require TLS negotiation exige TLS para los Remote Hosts o redes seleccionados; Require sender email domains lo exige para los dominios remitentes. Si no puede establecerse la conexión TLS, SFOS descarta los mensajes afectados. Skip TLS negotiation permite intencionadamente conexiones SMTP sin cifrar con los peers seleccionados y solo debe usarse en excepciones documentadas. Según la ayuda, cada campo admite hasta 512 entradas de host; antes de usar listas amplias se descartan solapamientos entre las listas de exigencia y omisión.

Aplicar las políticas de análisis de forma consciente

Sin una suscripción Email Protection válida, el tráfico de correo puede seguir permitido, pero no recibe protección Email Protection. La accesibilidad no demuestra la licencia ni el análisis. Los ajustes globales de correo se procesan antes de las políticas SMTP y POP-IMAP. En Email > General settings > SMTP settings, activar IP Reputation en Legacy mode mediante Verify sender’s IP reputation y guardar con Apply; el control de MTA se llama Reject based on IP reputation. El banner global del correo saliente solo admite texto.

Tras activar la suscripción Email Protection, Sophos Firewall aplica automáticamente la política predeterminada default-smtp-av al tráfico SMTP en Legacy mode. Las políticas propias se crean en Email > Policies y se procesan en el orden de la lista. Por eso, primero hay que comprobar qué política existente coincide con el remitente y destinatario concretos.

Crear nuevas políticas SMTP de Legacy mode en Email > Policies > Add policy, con SMTP malware scan o SMTP spam scan. Para modificar una política existente, abrir Email > Policies, seleccionar Edit en la política correspondiente, cambiar los ajustes necesarios y guardar la política. Después, volver a comprobar el orden de las políticas y repetir las pruebas positiva y negativa.

En Email > General settings > Malware protection se selecciona globalmente Sophos o Avira como motor antivirus primario. Si se selecciona Avira, SFOS desactiva Zero-day Protection en las políticas SMTP que usan Single antivirus. Antes de cambiar el motor, se hace un inventario de todas las políticas afectadas y después se vuelven a validar.

SMTP malware scan

El orden se cambia arrastrando las entradas de la lista de políticas. Registrar la posición anterior y repetir después ambos casos de prueba: una política piloto limitada no debe quedar oculta detrás de otra más amplia que ya coincida.

Al crear la política, definir un nombre claro y los grupos de direcciones de correo o dominios de remitentes y destinatarios. En Block file types, elegir los adjuntos que se bloquearán; Ctrl+Shift permite seleccionar varios tipos. MIME whitelist permite los headers MIME seleccionados, mientras que los tipos restantes se bloquean según la ayuda. Esta autorización de tipos de archivo no omite el antivirus. En cambio, Disable significa expresamente que los mensajes no se analizan.

Delivery option for recipient se aplica a adjuntos infectados, protegidos y sospechosos:

• Don’t deliver: no se envía al destinatario ni el mensaje ni una notificación.
• Deliver original: envía el mensaje original al destinatario; no lo limpia.
• Remove and deliver: elimina el adjunto infectado, notifica su eliminación y entrega el mensaje. Esta acción no se aplica a los tipos definidos en Block file types; esto no permite deducir otra acción de entrega para los tipos bloqueados.

Los adjuntos protegidos siguen sin analizarse; se notifica al destinatario por defecto, salvo que se configure lo contrario. Guardar con Save y comprobar los resultados reales de entrega y notificación con casos positivos y negativos inofensivos.

Una política SMTP malware scan controla los tipos de archivo bloqueados, las excepciones MIME, el análisis antivirus y las acciones de entrega. Con Single antivirus, según la ayuda, el motor elegido solo se aplica a mensajes entrantes; los salientes se analizan con ambos motores. Dual antivirus ejecuta los motores primario y secundario uno tras otro.

La acción Quarantine se combina con las acciones para destinatario y administrador. Don’t deliver, Deliver original y Remove and deliver tienen consecuencias muy diferentes. Un archivo adjunto protegido o no analizable no debe equipararse automáticamente a malware. Por ello, cada acción necesita un mensaje de prueba, un estado esperado para el destinatario y una vía de liberación documentada.

Quarantine no significa automáticamente que el destinatario no reciba ningún mensaje; la Delivery option for recipient sigue siendo decisiva. Según Sophos, Notify sender solo funciona junto con Don’t deliver. Los adjuntos protegidos no se analizan, pero pueden generar una notificación. En Delivery option for administrator, Don’t deliver no notifica a los administradores; Send original les envía el mensaje original. Este puede incluir adjuntos peligrosos o sin analizar y no es un sustituto seguro de una notificación. Comprobar por separado los resultados para remitente, destinatario, administrador y cuarentena.

⚠️ Remove attachment en Delivery option for administrator queda excluido de esta guía: el nombre del campo sugiere una acción para el administrador, pero la descripción menciona un mensaje sin adjunto para el destinatario y una notificación de eliminación para los administradores. No permite establecer una asignación de entrega segura. No activar esta opción por primera vez en producción. Para una prueba piloto aislada de adjuntos infectados, usar Don’t deliver para destinatarios y administradores, supervisar la cuarentena por separado y comprobar los resultados con patrones de prueba inofensivos. Cambiar una configuración existente de Remove attachment solo tras una aclaración documentada con Sophos Support y una verificación controlada; no suponer que el mensaje es seguro ni que se limpia automáticamente.

Prueba piloto limitada en lugar de una política de ejemplo sin verificar

Para el servidor 10.20.30.25, limitar inicialmente una política con nombre claro a un grupo de destinatarios de prueba del dominio de ejemplo example.net; sustituir dominio y grupo por valores propios controlados. Si el dominio no está en la libreta de direcciones, añadirlo mediante Create new. En Block file types, elegir, por ejemplo, Executable files, seleccionar Dual antivirus y Quarantine y planificar por separado las acciones para destinatarios y administradores indicadas arriba. Añadir una autorización MIME solo si está justificada. Un adjunto protegido sigue sin analizarse; no copiar sin evaluar Send original para adjuntos protegidos de una política de ejemplo.

El límite de ejemplo 2048 KB corresponde a Don’t scan emails greater than en la configuración SMTP global, no a la política piloto ni a un valor predeterminado fijo. Limita el análisis a mensajes pequeños. Antes de adoptarlo, planificar la acción para mensajes demasiado grandes y una prueba justo por encima del límite según el volumen real; de lo contrario, Accept crea una brecha de análisis, o Reject y Drop causan problemas de entrega. Las políticas propias de SMTP spam y POP/IMAP son complementos opcionales según las necesidades, no requisitos para crear la ruta NAT.

SMTP spam scan

Definir un nombre y los grupos de direcciones de correo o dominios de remitentes y destinatarios. Elegir conscientemente una coincidencia exacta o por palabra clave para estos grupos: la búsqueda por palabra clave no debe ampliar involuntariamente el alcance. No asumir sintaxis regex, comodines ni AND/OR no documentada.

• Inbound email is y Outbound email is: elegir por separado la dirección; los criterios son spam, probable spam, virus outbreak o probable virus outbreak.
• Source IP/network address y Destination IP/network address: indicar la IP o red necesaria del remitente o destinatario.
• Sender remote blacklist: seleccionar el grupo RBL adecuado para el remitente.
• Message size: definir un límite superior o inferior; no confundirlo con el límite global para mensajes demasiado grandes.
• Message header: elegir el header; para Other, introducir los detalles, elegir coincidencia exacta o por palabra clave y definir el valor de la palabra clave.

Reject rechaza el mensaje e informa al remitente. Accept lo entrega. Prefix subject añade un prefijo al asunto y también lo entrega; por ejemplo, Probable spam identifica una prueba controlada. Drop descarta sin avisar al remitente; Quarantine retiene el mensaje en cuarentena. La selección de plantilla SPX está documentada para Accept y Prefix subject, exclusivamente para mensajes salientes. Esto no implica compatibilidad SPX con todas las demás acciones ni el cifrado automático de todos los mensajes aceptados. Guardar con Save y comprobar la coincidencia y la acción por separado.

Una política SMTP spam scan puede coincidir con la clasificación de spam, el origen o destino, una RBL, el tamaño del mensaje, los headers o una Data Control List. Según la ruta, están disponibles las acciones Reject, Accept, Change recipient, Prefix subject, Drop y Quarantine.

El criterio Data control list y la asignación SPX de esta política solo se aplican a los mensajes salientes. En cambio, None aplica la acción elegida a todos los mensajes entre los grupos de remitentes y destinatarios indicados. Change recipient no entrega adicionalmente al destinatario original, sino que lo sustituye por el destino configurado. Estos tres alcances se prueban con un caso de destinatario positivo y otro negativo antes de colocar la política en el orden de producción.

Preparar tipos de archivo propios y Data Control

Las categorías predefinidas de archivos de correo son Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files y Web files. Clasifican por extensión o cabecera MIME; no indican que un archivo sea seguro. Por ejemplo, Executable files incluye exe, cmd, bat y com; pdf aparece en Document files y Page layout files, y application/octet-stream aparece en varias categorías. No considerar las categorías mutuamente excluyentes ni permitir de forma amplia una cabecera MIME genérica para solucionar un solo adjunto. La referencia interna detallada está en Web Protection; comprobar los valores en la instalación de destino antes de elegir una plantilla o definir un tipo propio restringido.

Las CCL pueden detectar patrones como números de tarjeta de crédito o de seguridad social, direcciones postales y direcciones de correo. Usar datos sintéticos para la prueba piloto, nunca registros personales reales. Incluir solo patrones adecuados a la finalidad y la región; una coincidencia no demuestra la autenticidad de los datos ni una clasificación jurídica.

Asignar un nombre al tipo de archivo propio y guardar el objeto con Save antes de modificar la política. La ruta de creación separada de MTA es Email > Policies and exceptions > File type > Add; no sustituye la ruta de Legacy. Los tipos de archivo también se usan en políticas web; su configuración pertenece a Web Protection. Asignar también un nombre claro a la Data Control List y seleccionar Save después de elegir las CCL.

En Legacy mode se crean tipos de archivo propios en Email > Policies > File type > Add a partir de una plantilla, extensiones o tipos MIME. Las extensiones se escriben sin punto inicial y solo se pueden editar los tipos propios. Un tipo nuevo no se incorpora automáticamente a las policies existentes. Hay que abrir la scan policy afectada, añadir el tipo y volver a guardarla. Una prueba positiva con un adjunto y otra negativa similar muestran si se aplica realmente la acción prevista.

Una Data Control List se crea en Email > Data control list > Add a partir de las Content Control Lists necesarias. Los filtros Type y Region ayudan a seleccionar solo patrones adecuados de datos financieros, de identidad u otros datos sensibles. La coincidencia de la lista aún no define ninguna acción; esta se establece en la scan policy vinculada. Una lista piloto reducida con una prueba positiva y otra negativa es más segura que una colección amplia de CCLs sin verificar.

En Legacy mode se puede seleccionar SPX en esta política para los mensajes salientes. Sin embargo, el modelo de contraseña, el portal y la validación constituyen un flujo de seguridad propio; se describen en Configurar el cifrado de correo SPX. No se añade una Data Control List ni una asignación SPX a la primera prueba básica del proxy.

Una clasificación errónea confirmada no se corrige desactivando una política de alcance amplio. En Legacy mode se ajusta de forma específica la política SMTP malware scan o SMTP spam scan correspondiente; una prueba positiva y una prueba negativa fuera del alcance previsto deben confirmar el efecto. En cambio, Crear y probar excepciones de correo de forma segura describe exclusivamente el objeto de excepción de MTA mode: el origen, el remitente o el destinatario son condiciones alternativas (OR), no una condición AND que combine exactamente las tres características. Este objeto de excepción de MTA no es un control de Legacy mode.

Correspondencias documentadas de tipos de archivo

Esta referencia conserva las correspondencias de las categorías de correo; no es una lista de permitidos ni una prueba de malware. Comprobar la instalación de destino antes de modificarla. Los tokens MIME técnicos se mantienen sin cambios, incluso grafías documentadas inusuales como text/x-script.phyton; esto no demuestra conformidad con estándares ni define una nueva regla MIME propia.

Audio files

• Extensiones: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, au, ram, mp3, wmv.
• Cabeceras MIME: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv.

Backup files

• Extensiones: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• Cabeceras MIME: application/octet-stream.

Compressed files

• Extensiones: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• Cabeceras MIME: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Extensiones: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• Cabeceras MIME: application/pics-rules, application/octet-stream, application/vnd.ms-officetheme.

Database files

• Extensiones: accdb, db, dsn, mdb, mdf, pdb, sql, sqlite.
• Cabeceras MIME: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Extensiones: as, asc, c, cbl, cc, class, cp, cpp, cs, csproj, dev, dtd, f, fs, fsproj, fsx, ftl, gem, h, hpp, ise, ism, java, m, ocx, pas, pod, pro, py, r, rb, sh, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj.
• Cabeceras MIME: text/plain, text/x-c, application/java, application/java-byte-code, application/x-java-class, text/xml, text/x-fortran, text/x-h, text/x-java-source, text/x-m, application/octet-stream, text/pascal, text/x-script.phyton, application/x-bsh, application/x-sh, application/x-shar, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl.

Disk image files

• Extensiones: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• Cabeceras MIME: application/x-cdlink.

Document files

• Extensiones: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, thmx, aw, bld, blg, bvp, cdd, cdf, contact, csv, dat, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, mw, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vcf, vdb, vxml, windowslivecontact, wlmp, xfd, xml, xsl, xslt, lit, log, lst, odt, opml, pages, rtf, sig, tex, txt, wpd, wps, pdf.
• Cabeceras MIME: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/octet-stream, application/vnd.ms-project, application/x-project, application/vnd.ms-officetheme, application/cdf, application/x-cdf, application/x-netcdf, text/comma-separated-values, text/csv, application/csv, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/tab-separated-values, text/x-vcard, application/xml, text/xml, application/x-ms-reader, text/plain, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf.

Dynamic files

• Extensiones: pl, jsp, asp, php, cgi, shtml.
• Cabeceras MIME: text/x-script.perl, text/asp, text/x-server-parsed-html, text/html.

Encoded files

• Extensiones: bin, enc, hex, hqx, mim, mime, uue.
• Cabeceras MIME: application/mac-binary, application/macbinary, application/octet-stream, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Extensiones: exe, cmd, bat, com.
• Cabeceras MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/octet-stream, text/plain.

Image files

• Extensiones: bmp, gif, jpeg, jpg, pcx, png, heic, heif.
• Cabeceras MIME: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/heif.

Page layout files

• Extensiones: idml, indd, inx, isd, mdi, pct, pdf, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• Cabeceras MIME: image/x-pict, application/pdf, application/x-mspublisher, application/octet-stream, application/vnd.ms-xpsdocument.

Plugin files

• Extensiones: 8bi, arx, crx, plugin, vst, xll.
• Cabeceras MIME: application/x-visio, application/excel, application/vnd.ms-excel, application/x-excel.

System files

• Extensiones: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, ico, key, lnk, msp, prf, profile, scf, scr, sys.
• Cabeceras MIME: application/vnd.ms-cab-compressed, application/octet-stream, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp, image/x-icon.

Video files

• Extensiones: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, mp, rm, wmv, flv, swf.
• Cabeceras MIME: application/octet-stream, application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash.

Web files

• Extensiones: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• Cabeceras MIME: application/atom+xml.

Utilizar el email journaling opcional respetando la protección de datos

Asignar un nombre claro a la entrada de journaling y guardar la selección de destinatarios y el destino del journal con Save antes de comenzar las siguientes pruebas.

En Email > General settings > Email journaling > Add, SFOS puede enviar copias de los mensajes SMTP/S entrantes de destinatarios o grupos de direcciones seleccionados a una dirección de journaling separada. La selección Any abarca todos los mensajes entrantes. La función solo se aplica a SMTP/S; no registra el tráfico POP ni IMAP.

El journaling crea una copia adicional del correo. No constituye automáticamente un archivo a prueba de manipulaciones ni demuestra el cumplimiento de las obligaciones legales de conservación. Antes de activarlo se definen la finalidad, los destinatarios autorizados, el acceso al buzón de journaling, el cifrado, el periodo de conservación, el espacio necesario y el responsable.

Para la primera prueba se selecciona un único buzón de prueba en lugar de Any. Un mensaje entrante dirigido a ese buzón debe aparecer en el destino normal y en el buzón de journaling; un mensaje para un destinatario no incluido no debe generar ninguna copia. La dirección de journaling no debe iniciar un flujo que devuelva la copia a SFOS y provoque un bucle.

La selección de destinatarios solo se amplía después de las pruebas positiva y negativa. Para el rollback se elimina la entrada de journaling o se restablece el estado anterior documentado. Las copias ya entregadas permanecen en el buzón de journaling y se gestionan de acuerdo con sus propias reglas de conservación.

Identificar de forma segura los objetos de correo Legacy mediante la API XML

Las referencias de la API XML para SFOS 22 y 23 describen objetos de correo específicos de Legacy. Una ruta de menú de MTA mode, una tabla plana de parámetros o un ejemplo con alternativas separadas por barras no constituyen una solicitud lista para copiar. El acceso a la API, el transporte, los estados de operación, las claves de mensaje sin resolver y la comprobación posterior a la escritura se explican en Proteger el acceso a la API XML. Las correspondencias siguientes ayudan a interpretar una configuración existente; no afirman que se haya probado una llamada de escritura ni se aplican automáticamente a REST o a la Central API.

Antes de realizar un cambio, guardar un backup, el contenido actual del objeto, las políticas que lo referencian y su orden. Aclarar la solicitud concreta y los valores de campo contradictorios mediante la ayuda de la API del build instalado o con Sophos Support. Después, comprobar por separado los objetos guardados y el efecto real sobre el correo. Que un campo figure como obligatorio en la tabla no indica si omitir otros campos conserva sus valores anteriores. Tampoco demuestra cómo se vacían, sustituyen o fusionan las listas ni que los cambios sean atómicos.

EmailConfiguration: cada campo pertenece a un contexto de protocolo y TLS

En EmailConfiguration, los campos con el mismo nombre se distinguen por sus elementos padre:

• GeneralSettings/EmailSignature y GeneralSettings/EmailBannerMode corresponden al banner saliente. La tabla de la API enumera los valores de modo inline_plain, mimepart y off; el ejemplo, en cambio, contiene alternativas próximas a las etiquetas de la UI. No tratar estos textos como valores idénticos de la API sin comprobarlo. EmailSignature es una cadena de caracteres con un máximo de 2000 caracteres según la tabla de la API.
• SMTPSSettings/DontScanEmailsGreaterThan es el límite de análisis SMTP en KB; SMTPSSettings/ActionForOversizeEmails es la acción independiente Accept, Reject o Drop para los mensajes que lo superan. BypassSpamCheck, VerifySendersIPReputation, SMTPSDosSettings y los seis límites DoS también se encuentran en SMTPSSettings.
• POPIMAPSettings/DontScanEmailsGreaterThan es otro límite entero en KB. POPIMAPSettings/RecipientHeaders/Header es una lista de cadenas de encabezado para detectar destinatarios, no una lista de destinatarios SMTP.
• SMTPTLSConfiguration y POPSIMAPTLSConfiguration contienen cada uno sus propios TLSCertificate, AllowInvalidCertificate y DisableTLS1. El certificado SMTP no sustituye al certificado POP/IMAP. RequireTLSWithHost, RequireTLSWithSenderDomain y SkipTLSHosts pertenecen al contexto TLS de SMTP; son listas de cadenas independientes, no una excepción común de activación/desactivación. No confundir el límite de la UI de 512 entradas de host con el máximo de 512 caracteres indicado en la tabla de la API.

Distinguir la tabla de la API, el ejemplo y la referencia de la UI: La tabla de la API indica 1024 como valor predeterminado para ambos límites de análisis. Para MaximumConnections, MaximumConnectionsHost, MaximumEmailsConnection, MaximumRecepientsEmail, EmailsRate y ConnectionsRate, indica, respectivamente, 5000, 100, 100, 100, 1000 y 100. El ejemplo, en cambio, usa 1000 para MaximumEmailsConnection; el ejemplo de la UI de 2048 KB explicado arriba tampoco es un valor predeterminado. El significado de 0 sigue siendo el de la referencia de la UI específica de cada protocolo descrita arriba, no un ajuste ilimitado deducido del ejemplo de la API.

La tabla de la API permite de 1 a 512 para MaximumRecepientsEmail, mientras que la referencia de la UI indica de 1 a 256 para Maximum recipients/email. La grafía de la API MaximumRecepientsEmail se mantiene sin cambios; no deducir de ella un nombre de campo corregido ni que 512 sea un valor válido y seguro en la UI. Los otros cinco rangos DoS coinciden con los rangos de la UI indicados arriba. El estado guardado y la ayuda del build de destino siguen siendo determinantes.

Otras contradicciones impiden copiar el ejemplo sin comprobarlo: para VerifySendersIPReputation, la tabla indica on/off y enumera Disable como valor predeterminado, mientras que el ejemplo muestra Enable. Para SMTPSDosSettings, el tipo de datos INTEGER aparece junto al valor predeterminado de tabla Disable y el valor de ejemplo Enable. Según la tabla, BypassSpamCheck tiene el valor predeterminado Disable, pero el ejemplo lo activa. Ambos contextos TLS permiten certificados no válidos en el ejemplo. No adoptar estos ajustes inseguros del ejemplo ni construir una carga útil supuestamente válida a partir de datos contradictorios; se mantiene la decisión segura sobre TLS y bypass descrita arriba.

Para la operación Email Configuration, están documentados 200 con Message.AVGeneralConfUpdateSuccess, 500 con Message.AVGeneralConfUpdateFail y 505 con Message.ASConfigSubOperationFail. SFOS 23 añade la correspondencia ya explicada arriba de 506 con Message.AVGeneralConfInvalidSmtpNtfyHostname. Son estados de operación y claves sin resolver, no códigos HTTP ni textos de ejecución confirmados. En particular, después de 505, volver a leer primero los ajustes SMTP, POP/IMAP y TLS; no dar por hecho ni un rollback completo ni que se haya guardado todo, y no repetir la operación a ciegas.

Malware SMTP: tratar a destinatarios y administradores de forma independiente

El objeto se llama AntiVirusMailSMTPScanningRules. Name identifica la política y After/Name, la referencia a la política predecesora que muestra el ejemplo. SenderList/Sender y ReceiverList/Receiver son listas independientes; BlockFileTypes/FileType es la lista de tipos de archivo bloqueados. La tabla de la API también enumera WhiteList como lista MIME, pero el ejemplo no muestra su anidamiento correspondiente. No inventar por ello un nodo XML padre adicional.

Para Scanning, la tabla de la API enumera Single Anti-Virus (Maximum Performance), Dual Anti-Virus (Maximum Security) y Disable, con el valor predeterminado Disable. El ejemplo Disable/Disable no es una enumeración completa ni un valor utilizable para el análisis antivirus deseado. Quarantine y NotifySender son controles independientes con Enable/Disable; según la tabla de la API, el valor predeterminado de ambos es Disable. Estos valores de tabla no sustituyen a la política predeterminada existente ni demuestran el estado actual del análisis.

Para los adjuntos infectados, sospechosos y protegidos, hay en cada caso dos acciones que se eligen de forma independiente:

• Destinatarios: ReceiverActionInfected, ReceiverActionSuspicious, ReceiverActionProtectedAttachment con Don'tDeliver, DeliverOriginal o RemoveAndDeliver.
• Administradores: NotifyAdministratorInfected, NotifyAdministratorSuspicious, NotifyAdministratorProtectedAttachment con Don'tDeliver, SendOriginal o RemoveAttachment.

La tabla de la API indica Don'tDeliver como valor predeterminado para los seis campos de acción. Esto no equivale a la descripción de la UI de una notificación predeterminada para los adjuntos protegidos ni demuestra el estado actual de entrega. Los efectos y límites explicados arriba siguen siendo decisivos: DeliverOriginal o SendOriginal pueden transmitir adjuntos sin analizar o peligrosos; la cuarentena no demuestra que se haya impedido la entrega al destinatario. La opción de administrador no aclarada RemoveAttachment sigue excluida, aunque la API la enumere como valor. Comprobar por separado los resultados para remitente, destinatario, administrador y cuarentena.

AntiSpamRules: no confundir coincidencia, orden y acción

En AntiSpamRules, Name identifica la regla. After/Name es la referencia que muestra el ejemplo para situarla después de otra regla. Antes de Add, Edit u Order, guardar el orden real y el nombre de la regla referenciada; esta documentación no describe automáticamente una sintaxis para la primera posición o para predecesoras inexistentes.

RecipientList/Action con RecipientEmail y SenderEmailList/Action con SenderEmail controlan por separado la coincidencia de destinatario y remitente. La tabla de la API enumera Equals o Contains para ambas acciones de coincidencia, con el valor predeterminado de tabla Contains. No son la acción de entrega. En cambio, MarkSpamIf contiene Condition y los campos correspondientes OtherHeader, Operator y MatchIs. Un tamaño de mensaje requiere una comparación de tamaño; un encabezado, una coincidencia de texto; una clasificación, un valor de clasificación. La fila de la tabla plana describe MatchIs como un tamaño de mensaje entero, pero el ejemplo usa Spam. No concluir por ello que todos los tipos de condición sean numéricos. El valor de tabla 4 y los distintos identificadores de condición del ejemplo no justifican inventar una correspondencia de encabezados o valores enumerados.

SMTPAction/Action y SMTPAction/ActionParameter determinan la acción SMTP y su valor adicional; SMTPAction/Quarantine es independiente de ellos. POPIMAPAction/Action y POPIMAPAction/ActionParameter pertenecen a la ruta de acceso al correo, cuyo ejemplo solo muestra Accept y Prefix Subject. No trasladar una acción SMTP a POP/IMAP. En Change recipient, el parámetro es el destino de entrega sustituto, no una dirección de journaling adicional. Se mantienen las restricciones descritas arriba para Data Control y SPX salientes.

También aquí el ejemplo y la tabla se contradicen: para Quarantine, el ejemplo muestra Enable/Disable, mientras que la tabla permite 0 y Enable. La tabla de acciones SMTP también enumera Accept With SPX; no deducir esta grafía de la API de la etiqueta de la UI ni de un Accept normal. Antes de una llamada de escritura, aclarar el valor concreto dependiente de la condición en lugar de enviar las alternativas del ejemplo separadas por barras.

Para Order SMTP Scanning Policy, figuran 200 con Message.SpamRuleUpdateRuleOrderSuccess y tanto 500 como 505 con Message.SpamRuleUpdateRuleOrderFail. Por tanto, la misma clave identifica dos filas de estado; no explica sus causas. Para Add SMTP Scanning Policy, está documentado 502 con Message.SpamRuleRecordExists. Antes de repetir Add u Order, comprobar el nombre y contenido existentes y el orden guardado; la comprobación central de seguridad de la API y las pruebas positiva y negativa de la política también se aplican aquí.

DataControlList: las firmas aún no son una acción de entrega

El objeto Legacy DataControlList contiene Name y Signatures/Signature, una lista de nombres de firmas CCL. La tabla plana usa para ellos los nombres name y signaturename; esto no justifica cambiar silenciosamente las etiquetas XML mostradas en el ejemplo. La tabla indica que el nombre es una cadena obligatoria con un máximo de 255 caracteres y que las firmas son una lista opcional de cadenas. Usar el nombre real de la firma de la selección CCL disponible en la propia instalación, no copiarlo del ejemplo de países. La acción sigue procediendo únicamente de la política vinculada. No usar el otro objeto MTADataControlList en lugar de este objeto Legacy.

Para Add Data Control List y Update Data Control List, ambas referencias enumeran 502 con Message.DLPAddSameName y 545 con Message.MTAModeDisableCheck. 545 es una correspondencia documentada entre estado y clave, no una afirmación verificada de que Legacy mode prohíba esta función o de que sea necesario cambiar de modo. Por tanto, no cambiar de modo para solucionar el error. Comprobar la lista guardada y sus referencias antes de repetir Add o Update y aclarar la respuesta real mediante la ayuda del build instalado o con Sophos Support.

AVASAddressGroup: exactamente una rama según el tipo

AVASAddressGroup es el grupo de direcciones Legacy para estas reglas de correo, no un objeto cuya equivalencia quede demostrada por una ruta de menú de MTA. Name identifica el grupo; la tabla de la API indica un máximo de 50 caracteres y, para la Description opcional, un máximo de 255. La tabla de GroupType enumera RBLIPv4, RBLIPv6, IPAddress y EmailAddressOrDomain, mientras que el ejemplo usa genéricamente RBL. No normalizar estas grafías de forma silenciosa.

El comentario del ejemplo exige exactamente una rama adecuada al tipo: RBLList/RBLName o RBLFile, IPAddressList/IPAddressNetwork o IPAddressFile, o bien EmailAddressList/EmailAddressDomain o EmailAddressFile. Las entradas de las listas son cadenas; la tabla indica que admite varios valores y que ignora los duplicados. El ejemplo muestra las alternativas juntas, pero no indica que deban enviarse todas las listas y archivos. Para grupos de correo/dominios, EmailImportType distingue los valores Manual e Import. La tabla indica los formatos csv y txt para EmailAddressFile, pero describe contradictoriamente el campo como entrada manual; el ejemplo remite al nombre de archivo de una solicitud multipart. Ninguna de las dos cosas demuestra una vinculación multipart completa ni una llamada de importación segura. Aclarar estos detalles para el build concreto antes de importar.

Para Add Address Group, están documentados 502 con Message.AddrGrpRecordExists, 541 con Message.AddrGrpImportFailed, 542 con Message.AddrGrpEmptyFile1 y 543 con Message.AddrGrpSomeEmailNotImported. No deducir de las claves sin resolver qué entradas se han importado realmente ni que se haya realizado un rollback completo. Comparar los miembros guardados con la lista prevista antes de la siguiente importación.

Para Delete Address Group, 504, 505 y 506 tienen la misma clave Message.AddrGrpForeignKeyExists; 507 está asociado a Message.AddrGrpEmailArcKeyExists. Las claves no distinguen de forma fiable los objetos concretos que lo referencian. Hacer un inventario de las políticas y referencias de journaling antes de eliminarlo, evaluar la respuesta exacta de la operación y comprobar después si el grupo sigue existiendo. No eliminar a ciegas una política de protección vinculada para forzar una llamada de eliminación.

TrustedDomain, journaling y selección de motor tienen alcances diferentes

AntiSpamTrustedDomain/DomainList/DomainName es una lista de cadenas de dominio. Add y Delete usan DomainName como identidad de la lista. La descripción de la API habla de un bypass del análisis para mensajes de dominios de confianza, pero no especifica exactamente qué analizadores se omiten. La UI describe Spam check exceptions como un bypass del spam. No ampliar estas dos afirmaciones hasta convertirlas en una garantía sobre todos los análisis ni en una equivalencia exacta demostrada entre API y UI. Gestionar los dominios solo con una finalidad documentada y un alcance limitado; comprobar la lista y el efecto de protección esperado antes y después de Add o Delete. No inventar a partir de la página de Delete una solicitud XML completa que no figura en ella.

AntiSpamEmailArchiver, en cambio, genera copias: Name identifica la entrada, RecipientList/Recipient limita los destinatarios originales y SendCopyOfEmailTo es la dirección separada para las copias. Según la tabla de la API, el nombre, los destinatarios y la dirección para las copias son obligatorios; el nombre y la dirección para las copias pueden tener un máximo de 50 caracteres. La fila de destinatarios se describe como una cadena escalar, mientras que el ejemplo la muestra dentro de un elemento padre de lista. No resolver esta discrepancia con una carga útil catch-all inventada. El piloto con un único buzón descrito arriba, junto con la protección de datos, la prevención de bucles y la prueba negativa, también se aplica a la automatización; cambiar los destinatarios no equivale a cambiar la dirección para las copias.

MalwareProtection/PrimaryAntiVirusEngine es, a su vez, un selector de motor escalar global, no un filtro de destinatarios ni una política de análisis individual. La tabla de la API indica Sophos como valor predeterminado; el ejemplo Sophos/Avira muestra alternativas, no un valor combinado que deba enviarse. Hay que seguir comprobando el efecto de Avira sobre Zero-day Protection en las políticas SMTP Single antivirus explicado arriba. Después de un cambio, comprobar el valor global guardado y todas las políticas afectadas; las rutas de documentación separadas no convierten esto en configuraciones de motor independientes.

Combinar NAT y reglas de firewall

Publicar la ruta SMTP entrante

En Rules and policies > NAT rules, elegir la familia IP adecuada y abrir Add NAT rule. Debe existir un objeto IP host del servidor interno en Hosts and services > IP host para seleccionarlo en Translated destination (DNAT). En el ejemplo entrante simple, Translated source (SNAT) y Translated service (PAT) permanecen en Original; en Original service, elegir solo los servicios SMTP utilizados, como SMTP y SMTP[S]. Comprobar todos los campos antes de guardar con Save. La traducción del destino NAT no equivale al campo de firewall Destination networks, que se trata por separado más abajo.

Para los mensajes entrantes, una regla DNAT traduce la dirección WAN pública al servidor de correo interno. Original Source se limita tanto como permita el diseño de correo; Original Destination es la dirección pública prevista; Translated Destination es 10.20.30.25 o el servidor de correo real. Original service y translated service permanecen limitados a los puertos SMTP que realmente se ofrecen.

Una regla reflexiva crea además SNAT para la dirección opuesta. Solo se selecciona si esta identidad de origen pública exacta es la prevista para la ruta de salida. Varios enlaces WAN, smarthosts o rutas de proveedor diferentes necesitan su propio diseño de routing y SNAT. El orden general y la zona de destino después de NAT se explican en Publicar un servidor con DNAT.

Usar dos reglas de firewall limitadas

Para crear una regla en Rules and policies > Firewall rules, elegir la familia de protocolo real IPv4 o IPv6 y abrir Add firewall rule > New firewall rule. Definir el nombre y los campos necesarios y guardar con Save. No reutilizar las direcciones IPv4 de ejemplo de este artículo en una regla IPv6.

⚠️ Las descripciones de Destination networks son contradictorias: el ejemplo de correo Legacy indica el servidor interno, mientras que el flujo general de reglas DNAT basa la coincidencia del firewall en el destino público original. Esta guía no resuelve el caso específico del proxy mediante conjeturas. Documentar la regla entrante cuyo funcionamiento ya está demostrado y conservarla para la prueba piloto. No crear una regla entrante de producción a partir de ninguna de las dos asignaciones ni cambiar el destino por suposición. Para una ruta nueva, aclararlo con Sophos Support o una verificación controlada adecuada antes de aprobarla, con Rule ID, hit DNAT y capturas antes y después de la traducción. La variante SNAT saliente no resuelve el conflicto.

Para la validación, dos reglas separadas son más claras que una regla bidireccional con varias zonas y objetos Any:

• Entrante: WAN hacia la zona del servidor interno, endpoint SMTP 10.20.30.25, solo los servicios SMTP necesarios, logging activado. El endpoint no prescribe un valor para el campo sin resolver Destination networks.
• Saliente: zona y host del servidor de correo interno hacia WAN o el smarthost concreto, solo los servicios SMTP necesarios, logging activado

En Scan email content, se activa Scan SMTP en ambas direcciones necesarias y Scan SMTPS solo cuando se usa realmente SMTPS. Si falta en Services el puerto estándar del protocolo elegido, SFOS ofrece Add ports. Para un puerto no estándar, se define deliberadamente el servicio correspondiente. Servicio, NAT, listener del servidor y opción de análisis deben describir la misma ruta de puerto; Add ports no sustituye esta comprobación.

Las reglas se colocan por encima de otras más generales que ya coinciden con el mismo tráfico. Después de guardar, la Firewall Rule ID registrada es decisiva. La estructura de reglas, la zona NAT y el orden se explican en Configurar reglas de Sophos Firewall de forma segura.

Opcional: utilizar otra dirección de origen pública para la salida

En la regla de firewall saliente, During scheduled time determina cuándo se aplica la regla. Elegir conscientemente All the time para un servidor disponible permanentemente. Un horario limitado puede cambiar la regla coincidente fuera de la ventana; comprobar también allí Rule ID y flujo de correo. No es un horario de la regla SNAT. La regla creada automáticamente al activar MTA mode pertenece a otro flujo y no se modifica como sustituto de esta regla del servidor Legacy; para ese caso se usa la guía MTA.

Este diseño se aplica al tráfico SMTP reenviado del servidor interno, no a mensajes MTA generados por el sistema. Es útil cuando se necesita otra identidad pública asignada en lugar de la dirección MASQ de WAN. La asignación del proveedor, la ruta, SPF, RDNS y las autorizaciones del proveedor deben corresponder a esa identidad; SNAT no modifica estos requisitos.

1. En Network > Interfaces > Add interface > Add alias, seleccionar la interfaz WAN física real, IP version IPv4 y la dirección asignada con el valor IPv4/Netmask adecuado; Save. La ruta del proveedor, Device Access y la verificación del alias se explican en Configurar una IP alias.
2. En Hosts and services > IP host > Add, crear un host con nombre para la misma dirección pública: IP family IPv4, Type IP, IP address la dirección asignada; Save. Un objeto host por sí solo no vincula una dirección a la interfaz.
3. En Rules and policies > NAT rules > New NAT rule, limitar Original source al servidor de correo interno real y establecer Translated source (SNAT) en el IP Host público. Limitar Original destination a los destinos de correo necesarios o al smarthost y Original service a los servicios SMTP necesarios. Translated destination (DNAT) y Translated service (PAT) permanecen en Original. Inbound interface y Outbound interface deben corresponder a la ruta real del servidor hacia WAN. Guardar con Save y colocar por encima de otras reglas SNAT que también coincidan; comprobar por separado los órdenes NAT y firewall. Fundamentos de NAT explica el modelo de primera coincidencia. Any, Top, Port1 y Port2 de los ejemplos no son valores obligatorios.
4. En Rules and policies > Firewall rules > Add firewall rule > New firewall rule, crear una regla IPv4 saliente adecuada o comprobar la regla limitada existente: Action Accept, zona y host reales del servidor como origen, WAN y los destinos necesarios, solo los servicios SMTP necesarios, Log firewall traffic activado. Elegir Scan SMTP y, si corresponde, Scan SMTPS como se indicó antes; Save y comprobar el orden del firewall independientemente de NAT.
5. Crear una conexión SMTP nueva hacia un destinatario externo controlado. Comprobar conjuntamente Firewall Rule ID, NAT Rule ID, IP de origen traducida en la captura o en el destinatario externo y la entrega real. Una sesión existente o una prueba del puerto SMTP no bastan. Probar también negativamente un origen fuera del alcance o un servicio no permitido.

Para revertir, restaurar primero las reglas documentadas y su orden, y comprobar la IP de origen anterior y la entrega mediante una conexión nueva. Eliminar el alias y el IP Host solo si ningún otro servicio depende de ellos.

Validar el flujo de correo y el análisis del proxy

Primero se envía un mensaje externo pequeño a un buzón de prueba. A continuación, el servidor de correo interno envía un segundo mensaje a un destinatario externo controlado. Ambas pruebas reciben asuntos únicos y marcas de tiempo UTC.

Para STARTTLS en el puerto 25 y una conexión TLS directa en el puerto 465, pueden ayudar las siguientes comprobaciones de solo lectura desde un sistema de prueba autorizado:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

Sustituya mail.example.net por el FQDN real y pruebe solo los puertos que se ofrezcan realmente. Estos comandos de OpenSSL muestran la cadena de certificados presentada y los parámetros TLS negociados; examine cualquier error de verificación de certificados. No verifican explícitamente el nombre de host esperado y pueden continuar pese a los errores de verificación, por lo que una conexión no demuestra que la autenticación del certificado haya sido correcta. No demuestran ni la entrega correcta del correo ni el análisis de malware, spam o Data Control.

En Log Viewer, el origen, destino, servicio, acción y Firewall Rule ID deben coincidir con las reglas nuevas. Para el proxy SMTP/S heredado se correlacionan awarrensmtp.log y awarrenmta.log con la misma marca de tiempo. Los archivos de log se explican en Servicios y logs de Sophos Firewall.

A continuación, realice pruebas negativas independientes para el ámbito de la regla de firewall y la coincidencia con la política de mensajes. Un origen o servicio fuera del ámbito del piloto no debe coincidir con la regla de firewall del piloto y debe seguir el resultado documentado de permitir o bloquear; otra regla autorizada puede seguir proporcionando protección. Un mensaje de prueba sin el criterio de la política del piloto no debe coincidir con esa política ni recibir su acción específica, pero debe conservar cualquier análisis predeterminado o adicional que sea aplicable. Para cada caso, registre la Firewall Rule ID, la política y el resultado de entrega esperados y compárelos con el resultado observado. No utilice malware real en las pruebas de producción; utilice patrones de prueba inofensivos establecidos y un buzón controlado para validar el análisis.

Delimitar errores según el síntoma

SMTP funciona, pero la política no se aplica

Primero se comprueba la Firewall Rule ID. Si coincide otra regla, se corrigen el orden, origen, destino, objetivo NAT y servicio. Si coincide la regla esperada, Scan SMTP o Scan SMTPS, el orden de políticas y los grupos de remitentes y destinatarios deben ajustarse a la prueba. Una política por sí sola no activa el proxy transparente.

El correo entrante no llega al servidor

Se comprueban por separado la dirección de destino pública, el hit DNAT, el translated destination, la zona de destino, el listener del servidor y la ruta de retorno. Una conexión TCP abierta hasta el firewall no demuestra que DNAT y la regla de firewall lleguen al servidor interno. Packet Capture y Rule ID deben mostrar entrada y reenvío.

El correo saliente usa una dirección IP pública incorrecta

Se comprueban SNAT, la regla reflexiva, el gateway WAN, la ruta SD-WAN y el comportamiento de los reply packets. El proxy heredado no selecciona automáticamente la dirección de origen pública necesaria para SPF, RDNS o la autorización del proveedor. Antes de cambiar globalmente Route Precedence, se demuestra la ruta concreta.

TLS falla después de activar el análisis

Se registran el FQDN, la IP de destino, el certificado, el emisor, la cadena y la versión negociada. Con varios dominios en una dirección IP, la comprobación de certificados basada en IP que está documentada puede ser la causa. Allow invalid certificate no se activa como solución rápida.

Falta un mensaje y no aparece nada en MTA mail spool

Esto no es un criterio de éxito útil en Legacy mode, porque mail spool y los mail logs específicos de MTA pertenecen a MTA mode. La cadena relevante consta de la regla de firewall, NAT, logs del servidor SMTP, Log Viewer, awarrensmtp.log y awarrenmta.log. Los mensajes en cuarentena se comprueban por separado en Email > SMTP quarantine.

Realizar un rollback seguro

Para el rollback, primero se restauran las reglas piloto y las opciones de análisis al estado anterior documentado. Después se retiran las nuevas asignaciones de políticas o se restablece su orden. Las modificaciones temporales de DNAT, SNAT o certificados solo se eliminan si ningún otro servicio depende de ellas.

Solo entonces se restablece el SMTP Deployment Mode si el cambio incluía esa conmutación. El flujo de correo entrante y saliente original debe volver a funcionar con las Rule IDs, direcciones públicas y logs del servidor esperados. Como rollback estándar no se eliminan mensajes, contenido de la cuarentena ni logs del proxy.

Lista de comprobación operativa

• El proxy transparente es una elección consciente y se han descartado requisitos de MTA.
• Están documentados el backup, el acceso de administración y las Rule IDs originales.
• El SMTP hostname, los límites de tamaño SMTP y POP/IMAP, la acción para mensajes grandes, IP Reputation y los límites DoS están justificados.
• Los puertos estándar o alternativos utilizados y los POP/IMAP recipient headers coinciden con la ruta real del servidor.
• Se han comprobado el motor antivirus primario y su efecto sobre Zero-day Protection en políticas Single antivirus.
• Se han comprobado el certificado, las excepciones TLS y los dominios afectados.
• DNAT, SNAT, la zona de destino y los puertos reales del servidor coinciden.
• Las reglas entrante y saliente son limitadas, tienen logging y se ha demostrado que coinciden.
• Las políticas predeterminadas y propias poseen un orden comprensible.
• El journaling opcional está limitado a los destinatarios necesarios y tiene una finalidad documentada de protección y conservación de datos.
• Se han superado las pruebas positiva, negativa, TLS y de entrega.
• Los logs del proxy heredado y del servidor de correo pueden correlacionarse por tiempo.
• Están registrados el responsable, la fecha de revisión y la vía de recuperación completa.

FAQ